站长工具网一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2fe1c79d644c.html
📄
站长工具网一次全站扫描被中断后怎样判断已覆盖范围
中断后不要先点“重新扫描”，而应把已跑完的部分当作一次不完整抽样：只有能确定扫描顺序、并发数和断点位置时，剩余未覆盖范围才可推算；如果顺序随机或分片无记录，最稳妥的判断是已覆盖范围不可靠，需要换一种带断点记录的方式重跑。
先确认扫描是顺序型还是分片型
不同工具的中断行为差异很大，判断依据不是“跑了多久”，而是它按什么单位推进。
- 顺序型：从URL列表头部依次抓取，中断点之后全部未处理。此时已覆盖范围约等于中断前成功完成的条目，可用日志里的最后一条记录核对。
- 分片型：把站点拆成多个批次并行处理，中断时可能已完成若干批、剩余批次完全没动。此时不能按时间比例估算，只能按批次完成标记统计。
假设一个站点有1万条URL，工具按每批500条分片，中断时日志显示第7批完成、第8批处理到一半。那么已覆盖约3250条（6批完整加半批），而不是“跑了七成时间所以覆盖七成”。这个假设只用于说明按批次计数比按时间估算更接近事实。
用三组可核对的证据区分“真覆盖”和“假覆盖”
中断后最危险的情况是把“请求发出过”当成“结果已拿到”。以下三组证据能帮你区分。
- 完成标记：每条URL是否有明确的成功/失败/超时状态。只有成功和明确失败算已处理，处于“进行中”的条目应归入未覆盖。
- 结果落盘：扫描结果是否在中断前已写入文件或数据库。如果结果只存在内存里，进程一停就丢失，已覆盖范围实际为零。
- 去重记录：工具是否记录了已抓取的URL指纹。没有指纹记录时，重跑会重复请求同一批页面，既浪费时间也可能触发站点限流。
如果三组证据里缺少任意两组，建议不要在原任务上续跑，而是导出已有日志，重新组织一次可断点续传的扫描。
两种条件下该续跑还是该重跑
判断标准可以压缩成两个条件：顺序可确定与结果已持久化。
- 两者都满足：可以续跑。动作是从断点位置继续，并在开始前把已完成URL列表单独存一份，跑完后与总列表做差集，差集就是本次真正新增覆盖的部分。
- 只满足其一或都不满足：应重跑，但重跑前先降低并发、缩短单批规模，让下一次中断时损失更小。重跑不是失败，而是把不可控的一次性任务拆成可恢复的小任务。
这里有一个容易被忽略的例外：如果站点本身有大量动态参数URL，即使顺序可确定，续跑也可能因为参数顺序变化而漏掉部分页面。此时更可靠的做法是先固定URL清单，再按清单顺序扫描。
把覆盖范围写成一个可复核的差值
无论续跑还是重跑，最终都要给出一个能复核的数字，而不是“大概扫完了”。做法是：
- 导出本次扫描实际请求过的URL集合，记为A。
- 导出站点当前已知URL清单，记为B。
- 计算B减A，得到未覆盖集合。如果这个集合里包含大量本应优先检查的页面，说明中断造成的缺口集中在关键路径上，需要优先补扫。
这个差值还能帮你判断下一步：未覆盖集合小且集中在低优先级页面，可以接受当前覆盖度；未覆盖集合大或包含首页、栏目页、重要详情页，则应安排一次完整重扫，而不是继续在旧任务上打补丁。
中断后不要用请求量归零当作完成信号
扫描中断后，请求量或抓取量归零只说明进程停了，不说明任务完成了。归零还可能来自被目标站点限流、网络断开、工具自身崩溃，甚至只是日志写入延迟。要区分这些解释，可以查看中断前最后几条记录的时间间隔：如果间隔突然拉大再归零，更可能是限流或网络问题；如果记录戛然而止且没有错误码，更可能是进程被终止。确认原因后再决定是调整频率重跑，还是修复环境后续跑，避免把一次外部限制误判为扫描完成。
