中断后的第一件事不是重跑,而是先判断断点前的结果是否已经构成一个可用的覆盖切片。判断依据只有两类:工具是否留下了可核对的进度记录,以及这些记录能否与站点自身可枚举的URL集合对齐。两者都具备,就可以按断点续扫或分段补扫;两者都缺失,就只能把这次结果当作不完整样本,重新规划一次可断点恢复的扫描。
扫描中断通常表现为两种形态,处理方式并不相同。
选择依据很直接:如果工具支持断点恢复,优先续扫,代价最低;如果不支持,就不要在旧结果上反复拼接,直接进入重新枚举阶段,否则越补越乱。
判断覆盖范围需要一个分母。这个分母不应来自工具报告,而应来自站点侧可独立枚举的来源,常见有三类:
把工具结果中的URL与这三类来源分别求交集和差集,会得到三组数字:工具已覆盖且来源也有的、工具已覆盖但来源没有的、来源有但工具未覆盖的。第三组就是中断造成的缺口。这里要注意,来源本身也可能不完整,比如站点地图长期未更新、日志被轮转截断,所以缺口数量是下限而不是精确值。
一个假设例子:假设站点地图列出1000条URL,工具结果含620条,其中600条与地图重合,另有20条是地图未收录的新页面。那么可确认的未覆盖至少是400条,实际可能更多,因为地图本身可能遗漏。这个数字的作用是决定下一步是补扫400条还是重新全量扫描,而不是当作最终覆盖率。
中断后常出现与直觉相反的结果:结果条数不少,但有效覆盖很低。以下信号可以用来区分原因。
这三类信号不能单独证明覆盖正确或错误。例如结果条数归零,可能是任务根本没启动,也可能是输出路径写错、权限不足或结果被后续任务覆盖,需要结合日志和文件时间戳排除。
综合上面的证据,可以落到两个分支。
条件一:有持久化队列且缺口可枚举。动作是导入待抓取清单,跳过已完成URL,只对缺口部分发起扫描。结果是总耗时约为全量的缺口比例,且新旧结果可以合并。合并前要统一URL规范化规则,否则同一页面会以两种写法各出现一次,导致后续统计虚高。
条件二:无持久化状态或缺口无法枚举。动作是放弃拼接,重新发起一次带断点恢复配置的全量扫描,并在任务开始前先导出站点侧URL清单作为基线。结果是这次扫描的覆盖范围可以被完整核对,代价是重复抓取已覆盖部分。如果站点体量大、抓取有频率限制,应把任务拆成按目录或按URL分片的多个子任务,每个子任务独立记录进度,这样单次中断只影响一个分片。
例外情况:如果中断发生在扫描刚开始、已完成比例很低,续扫的收益不足以抵消状态对齐的成本,直接重扫更省事。反过来,如果已完成比例很高且工具明确支持断点恢复,重扫会浪费大量请求预算,还可能触发站点的访问限制。
无论走哪个分支,都应在任务记录里写明三件事:本次实际覆盖的URL范围、未覆盖缺口的来源依据、下次扫描的起始条件。这样下一次中断时,判断依据不再依赖回忆。对使用具体站点管理工具的人来说,断点恢复、队列导出、URL规范化这些能力是否具备、入口在哪,需要以该工具当前版本的文档或实际界面为准,不同工具差异较大,不能按通用描述假定。
覆盖范围判断的终点不是得到一个百分比,而是得到一个可以继续执行的动作:要么补扫一个明确的清单,要么重扫一个已定义好分片边界的任务。