判断已覆盖范围,不能只看工具界面显示的进度百分比,而要看中断前已经产生并落盘的结果集边界。最稳妥的做法是:先冻结中断时刻的结果文件或任务日志,再按“已返回条目数、已处理输入单元数、最后成功处理的时间戳”三项交叉核对,最后用一次小范围定向复扫来验证边界。如果三项指向同一位置,覆盖范围可判定;如果相互矛盾,说明存在未落盘的中间状态,需要按更保守的边界重跑。
这是中断后最常见的分歧来源。多个角色对同一事实有不同理解,往往是因为各自看的是不同层的数据:一个人看任务面板上的进度,另一个人看导出文件,第三个人看日志。进度条通常反映调度器已分配的批次,而不是已成功写入的结果;导出文件可能包含缓冲区里提前刷盘的记录;日志则可能只记录批次开始,不记录批次结束。
两种解释都成立:
这两种解释会导致完全不同的下一步:前者只需从进度条之后继续,后者必须整段重跑,否则会漏掉输入。
关键证据不是结果条目的数量,而是输入单元与结果条目之间的映射关系。假设你扫描的是一个站点地图列表,输入单元就是 URL 或页面标识。中断后,取出已落盘的结果,逐条回溯它对应的输入单元,看这个输入单元是否在日志里被标记为“已开始处理”。
可以按以下顺序核对:
这里有一个假设例子:输入是 1000 个页面标识,任务在日志记录到第 600 个“开始处理”时中断,结果文件中却出现了第 720 个标识。若第 720 个标识在日志中没有任何处理记录,而第 600 个标识的状态是“处理中”而非“已完成”,那么合理边界应取第 599 个,而不是第 720 个。这个判断不依赖工具品牌,任何支持任务日志和结果导出的查询工具都可以按同样方式核对。
确定候选边界后,不要立即从边界处继续全站扫描。先做一次定向复扫:只取边界前后各一小段输入,重新运行,比较新结果与旧结果是否一致。
具体动作和结果影响:
这一步的作用是把“看起来覆盖了”变成“可核对的覆盖”。它不能保证后续扫描一定成功,但能避免在错误边界上继续,导致漏扫或重复处理。
当多个角色对覆盖范围有不同理解时,争论进度条和导出文件没有意义。更有效的做法是建立一张核对表,把分歧点变成可验证的条目:
每一项都指向一个可以实际检查的对象,而不是停留在“我觉得已经扫完了”或“我觉得没扫完”的判断上。核对完成后,再决定是从边界续跑、回退重跑,还是重新生成输入清单后整体重扫。
上述方法有一个前提:工具能够导出结果并保留可读的任务日志。如果结果只存在于内存、日志只有一行“任务失败”,那么无法从已有数据判断覆盖范围,只能按最保守的方式整体重扫。另外,如果扫描过程中输入清单本身发生了变化,比如页面被删除或新增,那么即使结果文件完整,覆盖范围也只能对应扫描开始时的输入快照,不能直接等同于当前全站状态。明确这一点,才能避免把“上次扫过的范围”误当成“现在仍然有效的范围”。