链接查询：一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /47f95a009e71.html
📄
链接查询：一次全站扫描被中断后怎样判断已覆盖范围
先给结论：中断后的覆盖范围不能靠“跑了多久”或“抓了多少条”来估，只能靠一份可对账的进度记录来界定。如果扫描前没有保存“已处理到哪”的清单，中断后最稳妥的做法是缩小范围重跑，而不是接着往前猜。下面用一个假设情境把判断过程拆开。
假设情境：中断之后先看什么
假设你用一款链接查询工具对自有站点做全站扫描，目标是把所有内链和出链列出来核对。任务跑到中途被手动停止或超时终止，界面只留下一个总数和一段日志。此时不要先看这个总数，先确认三件事：扫描的任务标识是否唯一、已完成的部分能否单独导出、断点位置是否有记录。
如果这三项都具备，覆盖范围就等于“已导出的清单 + 断点标记的位置”。如果只有总数没有断点，那这个总数既可能包含已写入的记录，也可能包含仅被排队但未处理的链接，不能直接当作覆盖量。
用进度记录界定覆盖范围
判断覆盖范围的核心，是把“进度”落到可以逐条核对的粒度上。以下三类记录的价值依次递减：
- 逐条状态：每条链接有已处理、待处理、失败三种状态，中断后能直接筛出未完成部分。
- 批次游标：按 URL 或页面序号分批，日志里留下最后完成的批次编号。
- 累计计数：只有处理条数，没有位置信息，无法定位断点。
只有前两类记录能支撑“接着跑”。如果只有累计计数，建议放弃续跑，改为按站点地图或栏目拆分后重跑，这样每次任务的范围是封闭的，中断也不会产生模糊地带。
哪些现象不能单独证明覆盖已完整
中断后常被误读为“其实已经扫完了”的信号，至少有这几种，它们都有别的解释：
- 抓取条数突然归零。可能是任务被终止，也可能是限速、被封禁或队列清空，不能据此认定全站已覆盖。
- 日志停止增长。可能只是当前批次很慢，或写入被缓冲，未必代表没有剩余页面。
- 结果里出现了首页和几个栏目页。入口页通常最先被处理，出现它们只能说明起点正常。
- 工具提示“完成”。这个提示对应的是任务状态，不等于所有目标 URL 都被成功处理，失败项可能被排除在外。
把这些现象和进度记录对照，才能区分“真的扫完了”和“看起来像扫完了”。
一个可操作的判断顺序
按下面的顺序处理，前一步的结果决定下一步：
- 导出已完成清单，统计其中不重复的 URL 数量，记为 A。
- 用站点地图、栏目列表或历史导出文件整理出应覆盖的 URL 集合，记为 B。
- 如果 A 是 B 的子集且断点位置明确，只对 B 减 A 的差集重跑，并保留两次结果的任务标识。
- 如果断点位置不明确，不要合并两次结果，直接对 B 整体重跑一次，把旧结果标记为废弃。
- 重跑后核对 A 与 B 的差集是否为空，再决定是否进入下一步的数据分析。
这个顺序的关键在于：合并两份来源不同、边界不清的清单，会把“未覆盖”混进“已覆盖”，后续无论做什么判断都建立在错误基数上。
把范围说清楚，比跑得更快更重要
链接查询的扫描结果通常用于后续决策，比如判断哪些页面缺少内链、哪些外链需要清理。只要覆盖范围本身是模糊的，这些结论就都不可靠。中断并不可怕，可怕的是把中断前的部分结果当成全量结果继续用。下一次启动扫描前，先确认工具是否支持断点记录和分范围导出；如果不支持，就主动把站点拆成多个小任务，让每次中断都落在可界定的边界内。
