推广工具资源：一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a91fbc3222f1.html
📄
推广工具资源：一次全站扫描被中断后怎样判断已覆盖范围
先看中断发生在哪一层：如果扫描日志保留了“已完成对象清单”，就以清单为准；如果只有进度条和计数，就按“最后一条完整记录”截断，把之后的对象全部视为未覆盖。不要用百分比反推覆盖范围，因为不同工具的进度口径可能按对象数、按URL数或按耗时计算，百分比相同不代表覆盖相同。
两种可行动作：按日志截断，还是重跑全量
判断覆盖范围时，实际可选的动作通常只有两个：以最后一条完整记录为界，保留之前的结果，或者放弃本次结果，重新发起全量扫描。两者的适用前提不同。
选择保留截断，前提是日志能定位到具体对象，且扫描是幂等的——同一个对象重复处理不会产生副作用。此时把中断点之前的结果视为已覆盖，中断点之后的对象列入待补清单，下一次只补这部分。代价是补扫范围依赖日志质量，如果日志只记录计数不记录对象标识，截断点就不可靠。
选择重跑全量，前提是扫描本身开销可控，或者结果之间存在顺序依赖——比如后一个对象的判断依赖前一个对象的状态。这种情况下，保留半份结果反而会引入不一致。代价是重复消耗资源，且如果扫描对象在两次运行之间发生变化，两次结果无法直接合并。
用三类证据判断“已覆盖”到底覆盖了什么
中断后不要只看“处理了多少条”，要分别核对三类证据：
- 对象标识证据：日志或中间结果里是否记录了每个已处理对象的唯一标识（URL、ID、文件路径）。有标识才能去重和补扫；只有计数则无法判断具体缺了谁。
- 完成状态证据：每条记录是“已写入最终结果”还是“已开始处理”。很多工具会先占位再回填，中断时留下的可能是空壳记录。这类记录不能算已覆盖。
- 时间边界证据：中断时刻是否与某批任务的提交时刻重合。如果扫描是分批提交的，中断可能发生在批次之间，此时整批未提交的对象都未覆盖，而不是只缺最后几条。
假设一个场景：某次扫描日志显示处理了1200条，其中1100条有完整对象标识和写入状态，100条只有开始标记。那么可安全保留的是1100条，剩余100条和中断后未出现的对象一起补扫。这个判断不需要知道扫描总量，只需要日志结构支持区分状态。
中断原因会影响判断结论
同样的中断点，原因不同，处理方式也不同。
如果是主动停止（手动终止、达到预设上限），通常说明工具在停止前已完成当前对象的写入，截断点相对干净，保留结果的风险较低。
如果是被动中断（进程被杀、连接断开、超时），当前对象很可能处于写入一半的状态。此时最后一条记录是否可信，取决于写入是否原子。可以做一个动作验证：抽取最后几条记录对应的对象，单独重新处理一次，对比结果是否一致。如果一致，说明截断点可用；如果出现冲突或空结果，说明这批记录不可信，应把截断点前移。
如果是资源耗尽（内存、配额、并发限制），中断往往不是发生在单个对象上，而是整批任务一起失败。这时按对象截断会低估缺失范围，更稳妥的做法是把最后一批整体视为未覆盖。
补扫之前先决定要不要改写扫描配置
判断覆盖范围的目的不是复原这次扫描，而是决定下一步。补扫前值得先回答一个问题：这次中断暴露的是偶发问题还是配置问题。
如果中断由外部因素引起，且原配置在中断前运行正常，直接按截断点补扫即可，不必改动参数。
如果中断反复出现在相近的进度位置，说明配置本身可能有问题，比如单批对象数过大、并发过高、单对象处理超时设置不合理。此时只补扫剩余对象，很可能会在相近位置再次中断。更合理的动作是先缩小单批范围或降低并发，再补扫，代价是总耗时增加，但能减少再次中断的概率。
判断依据可以是一次小规模试跑：用原配置处理一小批未覆盖对象，观察是否稳定完成。如果稳定，按原配置补扫；如果不稳定，先调整再补扫。这个试跑不承诺结果，只是用来区分偶发与配置问题。
把覆盖判断固化成可复用的检查点
与其每次中断后临时推断，不如在扫描配置里预先留出可判断的痕迹。可行的做法包括：要求日志记录对象标识和完成状态，而不只是计数；把扫描拆成可独立完成的小批次，每批结束后落一次结果；在批次边界处记录检查点，使中断后的截断点天然落在批次之间。
这些做法会增加日志量和少量写入开销，换来的是中断后不需要猜测覆盖范围。是否值得，取决于扫描的规模和重跑成本：对象多、单次耗时长时，检查点的收益更明显；对象少、重跑便宜时，直接重跑全量反而更简单。具体工具是否支持这些日志字段和批次控制，需要以实际使用的版本和文档为准。
