链接分析，怎样判断采集是否遗漏
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /700de56845c6.html
📄
链接分析，怎样判断采集是否遗漏
判断采集是否遗漏，核心不是看采集总量多不多，而是把“已知链接集合”与“实际可达链接集合”做交叉比对：先建立一份可复现的链接清单，再检查清单里每个链接是否被采集过、采集结果是否有效、是否还有入口未被清单覆盖。只要这三步中有一步对不上，就说明存在遗漏，而不是采集工具本身一定有问题。
先区分三种“遗漏”，否则会误判
链接分析里常说的采集遗漏，实际可能指三种不同情况，处理方式完全不同。
- 未发现：某个链接从未进入待采集队列，通常是因为它只出现在脚本生成内容、分页深处或站外入口中，爬虫没有触达路径。
- 已发现未抓取：链接已进入队列，但因规则限制、超时、状态码异常或去重逻辑被跳过。
- 已抓取未入库：请求成功，但解析失败、字段映射错误或写入被覆盖，导致数据看不到。
这三种情况的表现相似，都是“结果里没有”，但排查方向相反。先定位属于哪一类，再决定改入口、改抓取规则还是改解析逻辑。
用入口清单和结果清单做交叉比对
最直接的做法是准备两份清单：一份是入口清单，即你确认应该被采集的链接来源；另一份是结果清单，即采集完成后实际产出的链接记录。两份清单按规范化后的URL做匹配，差异部分就是遗漏候选。
入口清单至少要覆盖：
- 站点地图或列表页中的显式链接。
- 分页、筛选、排序等动态参数产生的链接。
- 正文内链、相关推荐、上一篇/下一篇等导航链接。
- 站外已知来源，例如合作方页面、历史提交记录中的入口。
结果清单则要包含：请求URL、最终URL、HTTP状态码、抓取时间、解析状态。比对时先做URL规范化，去掉无意义的会话参数和锚点，再判断差异。否则同一页面因参数不同会被误判成遗漏。
检查可达性与有效性的四个判断项
比对出差异后，不要立刻认定是遗漏。逐项检查以下条件，只有全部通过才说明该链接确实应该被采集：
- 是否可公开访问：返回200且内容非空。返回403、404、超时或跳转到登录页，属于不可达，不算采集遗漏。
- 是否在允许范围内：robots规则、抓取频率限制或项目白名单是否排除了它。被规则主动排除的链接，是策略选择而非遗漏。
- 是否被去重合并：同一内容有多个URL时，去重逻辑可能只保留一个。要确认被合并的URL是否有独立采集价值。
- 是否解析成功：请求成功但解析为空，属于解析层遗漏，需要检查字段选择器和编码。
假设某列表页有200条链接，结果清单只有180条，差异20条。逐项检查后发现其中15条返回404，3条被robots排除，2条解析为空。那么真正的遗漏是那2条解析失败的链接，而不是全部20条。这个判断结果直接决定下一步是修解析规则，而不是扩大抓取范围。
用增量对比和抽样验证确认是否还有隐藏遗漏
交叉比对只能发现“已知入口”中的遗漏。要判断是否还有未被入口清单覆盖的链接，可以用两种方法。
增量对比：在相同条件下重复采集一次，比较两次结果清单的差异。如果第二次多出链接，说明第一次存在未发现或未抓取的情况。注意两次之间页面内容可能变化，差异需要人工确认。
抽样验证：从结果清单中随机抽取若干页面，检查其正文内链是否都出现在结果清单中。如果抽到的页面里有链接未入库，说明入口覆盖不完整，需要补充链接来源。
这两种方法各有代价。增量对比需要重复执行，耗时较长，但能发现动态变化导致的遗漏；抽样验证成本低，但只能推断整体情况，不能保证覆盖全部隐藏链接。入口来源稳定、页面更新不频繁时，抽样验证足够；页面由脚本动态生成或分页极深时，增量对比更可靠。
选择处理顺序：先修哪一层
确认遗漏类型后，按以下顺序处理，避免同时改动多个环节导致无法定位问题：
- 先补入口。如果遗漏集中在未发现类型，优先补充列表页、分页和站内导航的链接来源。
- 再调抓取规则。如果遗漏集中在已发现未抓取，检查超时设置、并发限制和状态码处理逻辑。
- 最后修解析。如果请求成功但结果为空，检查字段映射、编码和页面结构变化。
每次只改一层，改完后重新执行交叉比对，确认差异是否缩小。如果差异没有变化，说明判断的类型不对，需要回到第一步重新分类。
下一步可以做的具体动作是：选一个已知页面，手动列出它包含的全部链接，与采集结果逐条比对，记录每条差异的原因。这份记录比任何总量指标都更能说明采集是否真的遗漏。
