📍 WDQWDWQD987AAAAA:216.73.216.53
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /26f9bf30345b.html
📄

搜索引擎技术分析：怎样判断采集是否遗漏

判断采集是否遗漏，不能只看总量，而要用“已知完整样本”去反查采集结果。具体做法是：先准备一份独立于采集系统的核对清单，再用清单逐项比对采集库，最后把差异分成“确实没采到”“采到了但没入库”“入库了但被过滤”三类。只有第三类才是真正的采集遗漏，前两类属于传输或处理环节的问题。

先确认什么算“遗漏”

采集遗漏有严格定义：目标页面在采集范围内、采集任务已执行、但结果中没有该页面记录。如果页面本身不在范围内，或者任务没跑到那个时间点，都不算遗漏。

• 范围外：robots 禁止、登录墙内、参数被规则排除，这类不采是设计如此。
• 未执行：任务未覆盖该时段或该分片，属于调度问题。
• 真遗漏：范围内、已执行、结果缺失，这才需要修采集逻辑。

多人协作时，先把这三类写进交付说明，能避免把调度问题误判成采集 bug 而返工。

用独立样本反查，而不是看采集总量

采集量涨跌不能证明遗漏，因为总量受页面改版、分页变化影响。可靠方法是构造独立样本：从站点地图、栏目列表页、站内搜索或数据库导出中，抽取一批 URL 作为核对清单。这份清单必须来自采集系统之外，否则等于自己查自己。

操作步骤：

1. 从站点地图取全部 URL，记为集合 A。
2. 从采集结果导出同一时间段的 URL，记为集合 B。
3. 计算 A 减 B，得到候选遗漏列表。
4. 对候选列表逐条访问，确认页面当前是否可访问、是否在采集范围内。

适用条件：站点地图本身要完整。如果站点地图只收录部分页面，反查结论会偏乐观，此时应改用栏目列表页交叉验证。

区分“没采到”和“采到没入库”

候选遗漏列表出来后，不要直接判定为采集失败。按下面顺序检查：

• 抓取日志：该 URL 是否出现在请求记录中，返回状态码是什么。
• 解析结果：如果日志有记录，解析后的字段是否为空或异常。
• 入库记录：解析正常但库里没有，检查去重规则和过滤条件。

判断结果：日志无记录，是抓取层遗漏；日志有记录但解析为空，是解析规则问题；解析正常但入库缺失，是存储或去重问题。三种原因对应三种修法，混在一起改会反复返工。

验收信号与交付标准

修完后不能只说“已修复”。可核查的验收信号包括：

• 用同一份独立样本重新比对，A 减 B 的差集缩小到可解释范围。
• 每条剩余差异都能标注原因，且原因不属于采集逻辑缺陷。
• 抓取日志、解析输出、入库记录三者能对上同一条 URL。

多人协作时，把样本清单、比对脚本和差异分类表一起交付，接手的人能独立复现结论，才算真正闭环。

下一步：选一个已确认在采集范围内的栏目，导出它的完整 URL 列表，与采集库做一次差集比对，先量化遗漏规模，再决定是否修改采集规则。