网络营销推广软件：一次全站扫描被中断后怎样判断已覆盖范围

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

网络营销推广软件：一次全站扫描被中断后怎样判断已覆盖范围

先给结论：中断后不能凭“进度条停在哪”或“最后一条日志的时间”判断覆盖范围，而应回到扫描任务自身的分片记录和已处理URL清单。如果这两类记录都不完整，最稳妥的做法是把本次结果标记为“部分覆盖”，只用于发现线索，不用于得出全站结论，然后重新规划一次可续跑的扫描。

矛盾现象：日志显示跑了大半，结果却像只扫了几页

这是中断后最常见的分歧场景。负责执行的人看到日志里有大量请求记录，认为覆盖已经接近完成；负责用数据的人打开结果文件，发现有效条目很少，认为这次基本没扫到东西。两边说的可能都是真的，因为他们看的是不同层面的证据。

日志里的请求条数，记录的是“发出过多少次请求”，其中可能包含重试、跳转、被拒绝的页面、重复抓取的同一地址。结果文件里的条目，记录的是“成功解析并写入的页面”。一次中断如果发生在写入阶段之前，请求记录会很多，落盘结果却很少；如果中断发生在解析阶段，落盘结果也可能远少于实际抓到的页面。所以请求量和结果量都不能单独代表覆盖范围。

两种解释：是“抓取中断”还是“写入中断”

要判断覆盖范围，先要区分中断发生在哪一环。这两种情况的处理方式完全不同。

两种解释都会表现为“结果比预期少”，但能区分它们的证据不一样。抓取中断通常伴随待抓队列里仍有大量未处理条目；写入中断则表现为待抓队列接近清空，而已完成计数与结果条目数之间存在明显缺口。查看队列状态和完成计数，比看总请求数更有判断力。

能区分两种解释的证据：分片状态、队列余量和落盘计数

中断后建议按下面顺序核对，每一步都能缩小判断范围。

  1. 查分片或批次状态：多数扫描工具会把任务拆成多个分片或批次。如果分片状态里既有“已完成”也有“进行中”或“未开始”，覆盖范围就是已完成分片对应的URL集合，而不是整个站点。
  2. 查待抓队列余量：队列里还剩多少条未处理URL，直接反映还有多少没抓。队列接近空但结果很少，更可能是写入或解析环节出了问题；队列仍有大量条目，则更可能是抓取被提前终止。
  3. 比对完成计数与落盘条目数：如果工具同时记录“已处理数”和“已写入数”，两个数字的差值就是中断造成的缺口。差值小，说明大部分结果已经可用；差值大，说明结果文件不能代表已抓范围。
  4. 抽查几个已知URL：从站点地图或导航里挑几个分布在不同层级、不同栏目的地址，看它们是否出现在结果中。抽查只能验证“是否覆盖到某类页面”，不能证明全覆盖，但能快速暴露明显的盲区。

假设某次扫描共规划了1000个URL，中断时已完成计数为620，落盘条目为180。这个差值说明有约440个页面处于“抓过但未写入”或“计数口径不同”的状态，结果文件只能反映其中一部分。此时若直接用180条数据去推断全站问题分布，结论会明显偏向先被写入的那批页面。正确动作是先确认计数口径是否一致，再决定是补写还是重跑，而不是直接拿180条去下判断。

把分歧变成可核对的项目：中断后的处理顺序

当多个角色对“扫了多少”有不同理解时，与其争论，不如把判断依据列成一张可核对的清单，逐项确认后再决定下一步。

确认完这些项目后，通常会出现两种合理结论：如果已完成分片覆盖了主要目录，且落盘缺口不大，可以把本次结果当作“部分覆盖的可用样本”，用于发现线索，但结论要限定在已覆盖范围内；如果缺口很大或分片状态不明，则应把本次结果只当作草稿，重新发起一次支持断点续跑、且能记录分片状态的扫描。前者的动作是标注覆盖边界后再分析，后者的动作是重跑后再分析，两者对下一步的影响完全不同。

哪些现象不能单独作为判断依据

有几个常见信号容易被误当成覆盖完成的证据，需要单独说明。请求量归零可能只是进程退出，不代表队列已清空；日志最后一条时间很新，可能只是重试请求，不代表新页面被抓；结果文件体积不小，可能包含大量重复地址或错误页。这些现象都有多种合理解释，只有和分片状态、队列余量、落盘计数放在一起看，才能支撑关于覆盖范围的判断。

因此，中断后的第一步不是急着解读结果，而是先确认这次扫描到底覆盖了哪些URL、哪些还留在队列里。把覆盖范围写清楚，再决定是补跑还是重跑，后续基于这份数据做的任何判断才有可核对的前提。

图1 图2
nginx