政策快报平台每天采集200多个信源的政策数据，日均采集量2000-3000条。
但信源不是静止的。网站改版、反爬升级、字段调整------每个信源都可能出问题。
刚上线的时候，"一个requests就能跑"的情况已经过去了。到2026年，大部分政府网站都有不同程度的反爬措施。
今天聊聊爬虫系统在应对反爬方面的实战经验。
3次关键改造
第一次：IP池建设
问题： 部分网站开始限制单IP访问频率，爬虫被ban。
方案： 自建代理IP池。我们租用了多台云服务器作为代理节点，每个节点有独立IP。爬虫请求时随机从IP池中选取一个IP发送请求。每个IP的请求频率被限制在安全范围内。
具体配置：
-
IP池规模：约50个IP节点（持续轮换）
-
请求间隔：随机3-8秒，避免规律性
-
单IP每日请求上限：不超过500次/日
-
失败重试：失败后换IP重试，最多3次
-
IP健康检查：每天检测IP可用性，失效自动剔除
效果： IP被封的问题基本解决，但频率限制只是反爬的第一层，后面还有更多挑战。
第二次：浏览器模拟
问题： 部分网站内容通过JavaScript动态加载，传统爬虫拿不到完整数据。
方案： 引入Headless浏览器（Puppeteer）进行渲染。爬虫用无头浏览器加载页面，等待JavaScript执行完毕后，再提取页面内容。
代价： 服务器资源消耗增加约3倍。Puppeteer启动和页面加载比HTTP请求慢得多。为了平衡效率和资源，我们对信源进行了分级------只有核心信源走Puppeteer渲染通道，普通信源用常规HTTP请求。
第三次：验证码识别
问题： 少数核心信源出现了验证码，OCR识别率不够高。
方案： 轻量验证码使用OCR识别（Tesseract），准确率约70%。复杂验证码（扭曲字母、滑块验证）进入人工处理队列，专门配备一人处理异常。
效果： 简单验证码自动化处理率达到70%，复杂验证码依赖人工兜底。
关键经验总结
经验1： 不要只依赖单一策略。IP池、动态请求间隔、User-Agent轮换、浏览器模拟------多层组合使用比任何单一方案都可靠。其中IP池是基础，其他策略按需叠加。
经验2： 频率控制是底线。不要对目标网站造成压力，采集公开数据可以，但不应该影响网站的正常访问。
经验3： 不是所有信源都用同样策略。分级处理------核心信源投入更多资源（Puppeteer+人工兜底），普通信源保持轻量方案（HTTP请求+基础反爬）。
经验4： 反爬是个持续博弈的过程，需要专人持续监控和调整。
结尾
爬虫系统的核心不是"技术多先进"，是"策略多灵活"和"投入多持续"。每一个信源都可能随时变化，持续监控和定期调整才是爬虫系统稳定运行的关键。