政策数据采集，听起来就是"写个爬虫定时跑"的事。
实际干起来，比想象中复杂10倍。
政策快报平台目前覆盖全国31个省市区、200+个信源，日均采集2000-3000条政策公告。这个数字背后，是无数个技术细节的堆叠。
今天不聊架构，只聊采集层。分享5条我们在爬了1000多个政府网站之后总结的经验，给打算做类似方向的技术团队一些参考。
技术踩坑总结
经验1：政府网站的"多样性"，远超你的想象
做采集的第一天，我们以为"无非就是几种CMS系统，适配一下就好"。
实际上手后发现，每个部门的网站技术栈都不一样：
-
有的用JSP，有的用PHP，有的用.NET
-
有的有独立API接口，有的只有静态HTML
-
有的列表页是动态加载，有的做了服务端渲染
-
有的发布了PDF，有的发布Word，有的直接把通知写在HTML里
-
区县级网站，甚至有些用的是10年前的CMS，连编码都是GB2312
应对策略： 不追求"通用方案"，针对每个信源单独写适配器。政策快报平台目前维护了50+个活跃适配器，每个信源一套独立的采集逻辑。
这不是"优雅"的方案，但这是"能跑"的方案。通用的爬虫框架在这里基本用不上，每个网站都需要单独处理。
判断： 不要试图做一套"万能采集系统"。在这个领域，"定制化"比"通用化"更现实。
经验2：反爬策略越来越严，不是技术问题，是策略问题
2023年之前，大部分政府网站几乎没有反爬。随便写个requests就能跑。
2024年开始，形势变了：
-
部分省级网站上了WAF（Web应用防火墙）
-
有的开始检测User-Agent和访问频率
-
极少数甚至上了验证码
应对策略： 我们遇到的问题是"频率控制"。如果每个信源固定频率访问，很容易被识别。后来改成了"随机间隔+用户代理轮换+IP池"的组合方案。
但有一条红线：不能影响网站正常访问。
政策信息是公开数据，采集本身不违法。但如果频率过高导致网站响应变慢甚至宕机，那就是我们不对。
判断： 采集策略的核心不是"怎么突破反爬"，是"怎么在不打扰网站的情况下拿到数据"。前者是黑客思维，后者是工程思维。
经验3：同一份政策，在不同信源上的呈现方式完全不同
这是最"坑"的地方。
一份国家级的政策文件，被各省市转载后：
-
有的信源加了页眉页脚
-
有的信源去掉了附件链接
-
有的信源把发布日期改成了"转载日期"
-
有的信源把政策正文截断了（只显示前2000字，需要点"查看全文"）
应对策略： 建立"主信源"机制。
政策快报平台 的做法：对于国家级政策，以gov.cn发布的内容为"主版本"；对于省级政策，以省厅官网为"主版本"。其他信源采集的内容，只做"交叉验证"，不直接使用。
如果某个政策在主信源上采集不到完整信息，才会启用备用信源。
判断： 多源采集不是"越多越好"，是"要有一个可信的主源"。否则你会陷入"不知道信谁"的困境。
经验4：政策正文的"内容抽取"，比爬虫本身难10倍
爬虫只解决了"拿到HTML"，真正难的是"从HTML里提取出有用的内容"。
做过爬虫的人都知道，不同网站的HTML结构完全不一样。同一个网站的不同栏目，结构也可能不一样。
政策快报平台早期尝试过用通用的"正文抽取算法"（如Readability、Newspaper），但效果很差。因为这些算法是为"新闻文章"设计的，政策公告的结构比新闻复杂得多------有表格、有附件列表、有红头文件格式、有时效性标注。
应对策略： 放弃通用方案，针对每个信源单独写解析规则。
每个信源维护一套XPath或CSS Selector规则，指定"标题在哪里""发布时间在哪里""正文在哪里""附件在哪里"。
维护这套规则库的工作量，比写爬虫本身大得多。但这是保证准确率的唯一方式。
判断： 在政策数据采集这个领域，"规则引擎"比"机器学习"更实用。ML可以辅助，但不能替代规则。
经验5：更新检测比初次采集重要得多
初次采集只需要跑一次全量。但后续的增量更新，才是日常工作的核心。
政策公告的特点是：频繁更新、状态变化、有撤回。
-
有的政策发布后1小时就撤回了
-
有的政策截止日期会"延期"
-
有的政策会发布"补充通知"修改原文
应对策略： 建立"变更检测"机制。定时检查已收录政策的页面状态，如果发现变更，重新采集、重新处理、重新推送。
政策快报平台的做法：对于重点信源，每天增量检测2次。检测到变更后，自动触发"重新采集→重新解析→重新推送"流程，整个过程全自动。
判断： 采集系统不是"爬一次就完事"，是一个"持续运营"的系统。维护成本通常远高于开发成本。
技术总结
爬了1000个政府网站后，我们明白了三件事：
第一，政策数据采集不是爬虫问题，是系统工程问题。每个网站都不一样，需要单独适配。
第二，通用方案在这个领域基本用不上。定制化适配是唯一能跑通的路。
第三，开发只占20%的工作量，剩下的80%是维护------信源改版、字段变动、反爬升级，每天都在发生。
如果你也想做这个方向，我的建议是：先跑通10个核心信源，把采集、解析、去重、更新检测全链路跑通，再考虑扩大覆盖面。不要一上来就想覆盖全国，会崩。