站长工具箱：一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /fb6b3fde2201.html
📄
站长工具箱：一次全站扫描被中断后怎样判断已覆盖范围
先给结论：中断后不要从“扫描到第几页”判断覆盖范围，而要从扫描日志里已完成的URL记录和未完成队列两处交叉核对。只有当两者能拼出完整的先后顺序、且断点前后没有并发写入冲突时，才能把已抓到的结果当作有效样本；否则应把这次扫描视为部分覆盖，只用于发现线索，不用于统计占比。
两种常见做法的取舍条件
面对中断，多数人会选“续扫”或“重扫”之一。选择条件取决于扫描工具是否保留持久化队列，以及目标站点的内容是否在两次运行之间发生变化。
- 续扫成立的条件：工具把待抓URL写入磁盘或数据库，重启后能读取断点；且站点在这段时间内没有大规模改版、批量发布或删除。代价是队列中可能残留已失效URL，续扫会浪费请求并产生误报的404。
- 重扫成立的条件：扫描耗时可控（例如几分钟到十几分钟），或站点内容变动频繁、无法确认断点时的状态。代价是重复消耗带宽，对小型站点或按请求计费的服务不划算。
如果工具只在内存里维护队列，进程结束即丢失，那么“续扫”实际上等同于重扫，此时优先选重扫，避免把两次运行的结果混在一起统计。
判断已覆盖范围要看哪几类证据
不要只看进度条或“已抓取N条”的总数，这类数字在中断时往往来不及落盘。更可靠的证据有三类：
- 逐条日志的时间戳。按时间排序后，最后一条成功记录之后的时间段就是覆盖盲区。若日志只记录状态码不记录时间，覆盖判断的精度会明显下降。
- 已抓URL的唯一标识。用URL去重后计数，能排除重试造成的重复。对比“请求数”和“唯一URL数”，两者差距越大，说明中断前有越多重复请求，实际覆盖范围比总数小。
- 待抓队列的快照。如果工具在中断前导出过队列，可以直接看到剩余URL；没有快照时，只能通过站点地图或内链重新枚举，再与已抓列表做差集。
一个可操作的假设例子：某工具日志显示已抓1200条、唯一URL 900条，站点地图列出1500条URL。用1500减去900，得到约600条未覆盖，但其中可能包含站点地图里已失效的旧地址，因此这个差值只能作为上限，不能直接当作待抓数量。
会让结论失效的反例
上面“日志加队列交叉核对”的方法有一个明确反例：扫描过程中站点返回了大量超时或连接重置，而工具把这些失败也计入了“已处理”。此时已处理列表里混着未真正取到内容的URL，覆盖范围会被高估。判断方法是看失败状态码的占比，并区分“已请求”与“已成功解析”。如果失败集中在某个目录或某类模板页，那么即使总数看起来完整，该目录仍属于未覆盖区域，需要单独补扫。
另一个反例是并发写入。若工具用多线程且日志写入没有加锁，中断时可能丢失最后一批已完成记录，导致实际覆盖比日志显示的更多。这种情况无法从日志本身确认，只能靠重扫一小段URL做抽样比对。
下一步动作与结果如何影响判断
建议先执行一个低成本动作：选取断点附近的一小段URL重新抓取，与已有记录比对。如果新抓结果与旧记录一致，说明日志可信，可以按差集补扫剩余部分；如果新抓结果出现旧记录中不存在的URL或状态变化，说明中断期间站点已变动，此时应放弃合并两次结果，改为整站重扫并重新计时。
这个动作的代价是少量重复请求，收益是决定“补扫”还是“重扫”的依据。补扫完成后，仍需再核对一次唯一URL总数与站点枚举数的差距，只有差距能用地图过期、robots限制或参数化URL解释清楚时，这次扫描的覆盖范围才算可以用于后续决策。具体工具是否保留队列、日志格式如何，需要以你所用版本的实际情况为准。
