关键词分析：怎样判断采集是否遗漏
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4a9e38963412.html
📄
关键词分析：怎样判断采集是否遗漏
判断采集是否遗漏，核心不是看总抓取量，而是核对“应该被采集的对象”和“实际进入分析库的对象”之间的差集。做法是先建立可穷举的预期清单，再用站内日志、数据库记录或抓取结果逐项比对，最后把差异按类型归因。只要差集为空，才算没有遗漏；差集不为空，就要继续判断是入口缺失、规则漏配，还是采集被拦截。
先定义“应该采集”的边界
采集遗漏无法直接测量，因为没有预期清单就没有比对基准。先明确三类对象：
- 入口清单：栏目页、列表页、站点地图、分页链接中出现的所有详情页地址。
- 实体清单：数据库或后台中已经发布、状态为可访问的记录，例如文章ID、商品ID。
- 规则清单：采集配置里声明的链接匹配规则、翻页规则、字段映射。
三份清单数量不必相等，但必须能互相解释。如果入口清单有1200条，实体清单有1180条，规则清单只覆盖1000条，那么至少200条存在遗漏风险。这一步的判断结果是：得到一份“理论应采集合集”，后续所有比对都围绕它展开。
用差集定位遗漏，而不是看总量
把实际采集结果与理论应采集合集做差集运算。具体操作：
- 导出实际采集到的唯一标识（URL、ID或标题哈希）。
- 导出理论应采集合集的唯一标识。
- 用表格函数或脚本求“在理论集合中、不在实际集合中”的记录。
差集里的记录就是遗漏候选。此时不要直接下结论，因为差集可能包含重复、已删除、重定向或参数变体。逐条检查这些候选的状态码和最终地址：返回200且内容有效，属于真实遗漏；返回404或410，属于预期外但可接受；301跳转到已采集地址，属于重复而非遗漏。判断结果是：真实遗漏数量 = 差集中状态有效且未采到的记录数。
检查入口与翻页是否断链
大量遗漏往往来自入口层，而不是内容层。检查项：
- 分页是否完整：列表页最后一页的页码是否被规则识别，是否存在“下一页”按钮由脚本生成而未被抓取。
- 筛选与排序参数：同一列表按不同条件展示的内容是否只采集了默认视图。
- 站点地图与栏目页是否一致：站点地图中列出但栏目页未链接的地址，是否被规则覆盖。
- 链接是否被隐藏：需要登录、点击展开或滚动加载才出现的链接，静态抓取通常拿不到。
如果差集中的记录集中在某个栏目或某几页之后，优先怀疑翻页中断；如果分散在各栏目，优先怀疑规则匹配或去重逻辑。判断结果是：入口层遗漏会在差集中呈现明显的分页或栏目聚集特征。
核对字段级遗漏与去重误伤
页面采到了，不代表字段采全。字段级遗漏的检查方法：
- 抽取若干条已采集记录，对照原页面检查标题、正文、时间、分类等字段是否为空或截断。
- 检查去重规则是否把不同内容判为重复，例如仅按标题去重会误伤同名不同文的记录。
- 检查编码与转义是否导致部分字段丢失，例如正文中的特殊符号被过滤后长度异常。
字段级遗漏的判断标准是：同一模板下多个页面的同一字段缺失率明显偏高。若只是个别页面缺失，更可能是页面本身结构异常，而非采集规则整体遗漏。
用日志和状态码确认拦截与失败
如果差集中的地址在采集时返回403、429、503或超时，说明不是规则没覆盖，而是请求被拒绝或中断。检查项：
- 采集日志中失败请求的地址是否与差集重合。
- 失败是否集中在某一时间段或某一频率之后，判断是否触发限流。
- 重试后是否成功，区分临时失败与持续拦截。
这类遗漏的处理方向是调整请求频率、补充请求头或改用合规接口，而不是修改链接规则。判断结果是：日志中可解释的失败记录，应从“规则遗漏”中剥离，单独归为“采集失败”。
下一步：从差集中随机抽取20条真实遗漏记录，按入口、规则、字段、拦截四类归因，统计各类占比，再决定先修哪一层。
