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

网络营销自动化工具全站扫描被中断后，怎样判断已覆盖范围

先看中断类型，再看扫描器留下的状态记录：如果是任务被手动停止或超时退出，已覆盖范围通常只能从“已提交URL/已返回状态”的日志里推断；如果是进程崩溃或网络断开，则要按分片或批次边界判断，不能把最后一条日志当成全站覆盖终点。下面以你手里的一份扫描日志和站点URL清单为对象，给出可执行的处理顺序。

先区分中断发生在哪一层

全站扫描一般分三层：URL发现、请求抓取、结果写入。中断发生在不同层，已覆盖范围的含义完全不同。

• 发现层中断：站点地图、内链或列表页还没遍历完，此时已覆盖范围只是“已发现URL”，不等于已抓取。
• 抓取层中断：URL已入队但请求未全部返回，要看队列里“已完成”和“处理中”的标记。
• 写入层中断：请求成功但结果没落库，日志里可能有状态码，导出文件里却没有对应记录。

判断动作：打开日志，先找中断前最后一条带批次号或分片号的记录。假设日志显示“batch 17/40 completed”，那只说明前17批完成，第18批之后不能算已覆盖。这个动作的结果决定你下一步是补扫剩余批次，还是重扫整个站点。

用三类可核对证据交叉验证覆盖范围

单看一条“扫描已停止”的提示不足以定论，至少用三类证据交叉核对：

1. URL清单对比：把日志中已返回状态码的URL去重，与站点地图或已知入口清单比对，算出未出现的那部分。
2. 分片或批次边界：如果工具按分片处理，检查每个分片是否有完成标记，未标记的分片视为未覆盖。
3. 时间戳连续性：看最后几条记录的时间间隔是否突然拉大。间隔异常可能意味着进程卡住，而不是正常结束。

这里要注意一个反常现象：请求量归零不一定代表扫描完成，也可能是队列为空、被限流或进程已退出。三者需要靠日志级别和退出码区分，不能只凭数量下结论。

把日志转成一份可执行的补扫清单

假设你手里有一份CSV日志，字段为url、status、batch、timestamp。可以按下面的顺序处理：

1. 筛选出status为空或为0的记录，这些是未完成请求。
2. 按batch分组，找出没有完整结束标记的批次。
3. 把未完成批次里的URL单独导出为补扫清单。
4. 对已返回状态码的URL做去重计数，与站点地图总数比较，得出覆盖率。

如果工具支持断点续扫，优先用补扫清单续跑，而不是全量重扫。全量重扫会重复请求已覆盖URL，可能触发限流，反而拉长整体时间。如果不支持续扫，就按批次边界重新组织任务，把未完成批次作为下一轮输入。

判断结果能否用于后续决策

补扫完成后，不要直接拿覆盖率当结论。先确认补扫清单里的URL是否真的返回了有效状态，再确认结果写入是否完整。可以用一个小样本做核对：从补扫清单里抽若干条，手动请求并比对日志记录。如果手动结果与日志一致，说明写入层没有丢数据；如果不一致，说明问题在写入环节，需要先修复再谈覆盖范围。

只有当日志、导出文件和抽样核对三者一致时，已覆盖范围才可作为后续分析的基础。否则，宁可把范围标为“部分覆盖”，也不要把它当成全站结果使用。