关键词指数查询：一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2dfaeb9874a6.html
📄
关键词指数查询：一次全站扫描被中断后怎样判断已覆盖范围
先给结论：判断已覆盖范围，不能看扫描进度条停在哪里，而要看“中断前最后一次成功写入的批次边界”和“该批次对应的输入清单是否完整”。只有当输入清单可枚举、每批写入有唯一标识、且中断后没有发生重复覆盖时，才能把已写入批次视为有效覆盖；否则应把整次扫描视为未完成，重新划定一个更小的可验证范围。
中断后先确认三件事，而不是先重跑
全站扫描被中断，常见反应是直接重跑。但在旧内容退出场景里，重跑可能掩盖真正的问题：你并不知道哪些旧页面已经被处理过。先确认三件事，成本低，却能决定下一步是补扫还是重扫。
- 输入清单是否在扫描前固定。如果扫描是边发现边处理，中断时未处理的页面可能根本没进入清单，此时进度百分比没有意义。
- 每批写入是否有可回查的标识。例如批次号、时间戳或来源清单的哈希。没有标识，就只能靠人工比对，判断成本会急剧上升。
- 中断原因是否影响已写入数据。如果是连接中断，已提交批次通常完整；如果是写入过程中进程被杀，最后一批可能只写了一半。
假设一次扫描把旧文章按栏目分成 20 批，每批 50 条，写入时记录批次号。中断发生在第 13 批，那么可先抽查第 12 批和第 13 批：第 12 批能完整回查，第 13 批缺失或重复，就把有效覆盖边界定在第 12 批。这个例子只用于说明判断方法，不代表任何工具的真实行为。
哪些证据能支持“已覆盖”，哪些只能算猜测
能支持已覆盖的证据，通常具备可复核性：输入清单、批次标识、写入日志、去重后的结果数量。四者能互相对应，覆盖范围才站得住。只有其中一项，比如“我记得跑到一半”，不足以支撑决策。
反过来，下面这些现象单独出现时，不能证明处理正确：
- 扫描请求量突然归零，可能是中断、限流、任务被暂停，也可能是输入清单已经耗尽。
- 结果列表为空，可能是真的没有可退出内容，也可能是查询条件写错或权限变化。
- 某个旧页面仍可访问，可能是未被覆盖，也可能是覆盖后未生效或缓存未更新。
这里的关键取舍是：如果旧内容退出涉及不可逆动作，比如删除或下线，宁可把覆盖范围判小，也不要判大。判小只是多花一次补扫成本；判大则可能留下未处理的旧页面，后续排查更麻烦。
一个会让上述结论失效的反例
如果扫描任务在中断后自动重启，并且没有幂等控制，那么“已写入批次”可能被重复处理。此时即使批次号存在，也不能简单按最大批次号判断覆盖范围，因为中间批次可能被跳过，或者后写入的数据覆盖了前一次的部分结果。
另一种失效情形是输入清单在扫描期间发生变化：旧系统仍在产生新页面，或者合作关系退出导致部分来源被移除。清单变了，中断前的覆盖边界就不再对应现在的全站范围。遇到这两种情况，正确动作不是继续补扫，而是冻结输入清单，重新做一次小范围验证。
下一步动作：用最小可验证范围反推全量
具体动作可以这样安排：先选一个边界清晰的子集，比如某个栏目或某个旧系统下的固定页面列表，单独跑一遍并记录批次标识。跑完后核对输入数量、写入数量和可回查数量是否一致。如果一致，再按同样批次大小推进剩余范围；如果不一致，先修幂等或清单冻结机制，而不是扩大扫描。
这个动作的结果会直接影响下一步：子集验证通过，说明覆盖判断方法可用，可以按批次补扫；子集验证不通过，说明当前扫描流程本身不可靠，此时任何全站覆盖结论都只是猜测。对需要退出的旧内容，先保留仍有价值的部分，再对确认未覆盖的范围做一次定向处理，比直接重跑全站更可控。
