火车头采集规则怎样避免重复建设页面：先管住唯一标识再谈发布
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2820b4a0cb64.html
📄
火车头采集规则怎样避免重复建设页面：先管住唯一标识再谈发布
用火车头采集规则避免重复建设页面，关键不是把采集速度降下来，而是让每条内容在入库前就有一个稳定的唯一标识，并让发布环节按这个标识判断“已存在就更新、不存在才新建”。如果规则只负责抓取和填充字段，却把去重交给发布后的人工检查，重复页面几乎必然会随着采集批次增加而累积。
准备阶段：先确定用什么字段判断“同一篇内容”
在写采集规则之前，要先明确重复的判定依据。常见做法是选一个在源站和本站都相对稳定的字段作为唯一标识，例如来源页面的完整地址、来源站点的文章编号，或者“来源域名+原标题”的组合。不要只用标题做唯一标识，因为标题可能被改写、加后缀或出现同名不同文的情况。
判断依据是否合适，可以看三点：
- 同一篇内容重复采集时，这个字段的值是否保持不变；
- 不同内容之间，这个字段是否不会撞车；
- 字段能否在采集规则里稳定提取，而不是依赖页面临时排版。
如果来源地址带有多余参数，例如跟踪参数、分页参数，应先按规则清洗成规范形式再作为标识，否则同一页面会因为参数不同被当成新页面。
实施阶段：把去重判断放在发布之前
火车头采集规则本身负责抓取和字段映射，去重动作通常要落到发布接口或入库逻辑上。可行的顺序是：采集时生成唯一标识，发布前用这个标识查询目标系统是否已有对应内容，再决定新建还是更新。
具体可以按下面的步骤执行：
- 在采集规则里增加一个字段，专门存放清洗后的唯一标识，不要和正文、标题混在一起。
- 在发布配置中，把该字段映射到目标系统能够查询的字段上，例如自定义字段或固定格式的别名。
- 发布接口先按该字段查询：查到记录就执行更新，查不到才执行新建。
- 对更新操作限定范围，只覆盖正文、图片等会变化的部分，避免把已人工调整过的标题、分类反复冲掉。
这一步是本题最关键的一步：把“是否重复”的判断从发布之后提前到发布之前。发布后再删重复页面，不仅要处理已生成的地址，还可能影响已被抓取的链接和站内入口，清理成本远高于入口拦截。
验证阶段：用少量样本检查判断结果
规则改完后不要直接全量跑。先取同一来源的几条内容，连续采集两次，观察第二次的结果：如果目标系统里记录数没有增加，而是原有记录被更新，说明去重生效；如果记录数翻倍，说明唯一标识没有正确映射，或者发布接口没有执行查询逻辑。
还要检查两类边界情况：
- 来源页面改版后，唯一标识字段是否仍然能提取到；
- 同一内容在不同栏目下出现时，是被合并还是被当成两篇。
判断结果时要区分“可能原因”和“已经定位的原因”。记录数增加可能来自标识字段为空、查询条件写错、发布接口不支持更新，也可能来自目标系统对某些字段做了自动转换。不要看到重复就断定是采集规则的问题，应逐项核对标识值和查询结果。
维护阶段：把去重当成长期规则而非一次性设置
来源站点的地址结构、栏目划分和页面模板都可能变化，唯一标识的提取方式也会随之失效。维护时可以固定做两件事：每次调整采集规则后，用少量样本重跑验证；定期抽查新增内容中是否存在同一标识对应多条记录。
如果目标系统支持，可以为唯一标识字段建立唯一约束或索引，让重复写入在数据库层面被拒绝，而不是只依赖发布接口的判断。这样即使规则临时出错，也能在入库环节拦住大部分重复页面。
下一步，先检查现有采集规则里有没有独立的唯一标识字段，以及发布配置是否真的执行了“先查后写”。这两项确认清楚，再决定是改规则还是改发布接口。
