工具类应用推广：一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 (compatible; QlyzeBot/1.0; +https://app.qlyze.io/bot)
🔗 /6803091d5102.html
📄
工具类应用推广：一次全站扫描被中断后怎样判断已覆盖范围
结论先给：如果扫描器在中断时留下了按URL或按目录记录的进度文件，并且你能确认它是“写一条、提交一条”的追加式写入，那么已覆盖范围大致等于断点前的最后一条记录；如果进度只保存在内存里、界面上的百分比是估算值，那么中断后你无法从百分比反推覆盖范围，只能重新扫或分段补扫。下面给出可核对的判断依据，以及一个会让上述结论失效的反例。
先分清两种进度记录方式，它们决定判断方法
全站扫描的“已覆盖范围”本质上是一个集合问题：哪些URL已经被抓取并分析过。中断后能否还原这个集合，取决于工具把进度写到了哪里。
- 追加式日志或进度文件：每处理完一条就落盘一次，中断后文件里保留的就是已处理记录。这类记录可以逐条计数，覆盖范围可核对。
- 内存计数或界面百分比：进度只存在于进程内存，中断即丢失，界面上的百分比往往来自“已发现URL数”而非“已处理URL数”，两者不是一回事。
判断方法很直接：找到工具的日志目录或进度输出文件，看有没有带时间戳或自增序号的记录行。如果有，取最后一条记录的位置；如果没有，就默认无法还原。
用三类证据交叉验证，而不是只看一个数字
单看“已扫描 4 万条”这种汇总数字容易误判，因为汇总数字可能包含重复URL、重定向目标和参数变体。更可靠的做法是拿三类证据互相对照：
- 去重后的URL清单：把进度文件里的URL去重，得到真实处理集合的大小。
- 站点地图或内链抽样：从站点地图或首页出发抽样若干层级，看这些URL是否出现在已处理集合中，用来估计遗漏比例。
- 时间与速率：用中断时刻减去开始时刻，乘以平均处理速率，得到理论上限。这个值只能作为上限参考，不能当作已覆盖数。
假设某次扫描从上午十点开始，中断发生在十点四十分，日志里最后一条记录的时间戳是十点三十八分，那么可以合理判断：十点三十八分之后的URL大概率未被处理。这里的时间差是判断依据，不是精确覆盖率。
一个会让结论失效的反例
上面“追加式日志等于已覆盖范围”的结论，在一种情况下不成立：工具采用批量提交。也就是说，它先把一批URL放进队列，处理完一批才统一写一次进度。此时日志里最后一条记录并不代表它之前的每一条都已成功分析——队列中可能有失败项被跳过，而日志只记录了批次边界。
识别这种模式的办法是看日志的写入节奏：如果记录行的时间戳成簇出现，间隔均匀且每次成批增加，而不是逐条递增，就说明是批量提交。遇到这种情况，已覆盖范围要按“最后一批的起始位置”往前推，而不是按最后一条记录算。
中断后的下一步动作：分段补扫并保留断点
确认覆盖范围之后，不要直接从头重扫。更省成本的做法是把站点按目录或按URL区间切成若干段，只对未覆盖段补扫，并让新任务继续使用追加式进度文件。这样即使再次中断，你仍然能从上一次的最后一条记录继续，而不是重新猜测覆盖范围。
如果工具本身不支持断点续扫，退而求其次的方案是：先导出当前已处理URL清单，再用站点地图减去这份清单，得到待处理集合，手动分批提交。这个动作的结果会直接影响下一次中断时的判断成本——有清单就只需比对，没有清单就只能重扫。
哪些情况说明你其实无法判断
出现以下任一情况时，不要勉强给出覆盖结论，直接按“范围未知”处理：进度文件为空或只有汇总数字；日志时间戳与扫描起止时间对不上；工具在中断时自动清理了临时文件；站点在扫描期间发生了大规模URL变更。这些情况下，任何覆盖率数字都只是猜测，继续基于它做推广决策会放大误差。
