pr 查询：一次全站扫描被中断后怎样判断已覆盖范围，先确认中断发生在哪一层，而不是看进度条
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f609053a5aaf.html
📄
pr 查询：一次全站扫描被中断后怎样判断已覆盖范围，先确认中断发生在哪一层，而不是看进度条
扫描中断后，先不要重跑全站，而是把中断前已经落盘的结果当成一份不完整的样本，用“批次日志 + 抽样复核”两条线反推覆盖范围。判断的核心不是扫描了多少条，而是哪些目标被真正处理过、哪些只被列入队列却从未产生结果。只有把这两类分清，才能决定是补扫缺口还是整站重来。
先确认中断发生在哪一层，而不是看进度条
全站扫描通常分三层：目标枚举、逐条查询、结果写盘。中断可能发生在任意一层，而进度条往往只反映最外层。你需要从日志或导出文件里找出三个时间点：最后一次成功写入的时间、最后一条进入队列的记录、以及中断时的报错信息。
- 如果最后写入时间接近中断时间，说明大部分已处理结果已经落盘，缺的是队列尾部的目标。
- 如果队列里堆积大量记录但写入时间停滞，说明查询层出问题，已覆盖范围可能远小于枚举数量。
- 如果枚举本身没跑完，那么缺失的是整片目标，而不是零星几条。
这一步的实际动作是：把日志按时间排序，标出三者的位置。结果会直接决定下一步——写入停滞就补扫队列，枚举未完成就重新枚举再合并。
用可区分证据划出已覆盖边界
手头如果只有一份导出结果，可以反向构造边界：找出结果中目标标识的最小值和最大值，再和你的全量目标清单对比。中间缺失的标识不一定都是失败，也可能是查询无结果。要区分这两种情况，可以抽取几个缺失目标手动复查一次。
假设你的目标清单按编号排列，导出结果覆盖了 1 到 800 中的 1 到 500，且 501 到 800 完全没出现。此时有两种合理解释：一是中断点就在 500 附近，二是 501 之后的目标在枚举阶段就没进入队列。判断方法是看队列文件是否包含 501 之后的记录——有记录但无结果，属于查询未完成；无记录，属于枚举未完成。
注意：结果条数归零或抓取量骤降，不能单独证明中断点位置。它也可能是目标本身无数据、接口限流或过滤条件误伤。至少再找一个独立信号（如队列文件、时间戳、报错类型）交叉验证。
抽样复核比统计总数更能说明覆盖质量
总数只能告诉你处理了多少条，不能告诉你覆盖是否均匀。中断往往导致尾部目标被系统性遗漏，而头部目标重复处理。可以按目标编号分成若干段，每段随机抽几条，检查它们在结果中是否存在、字段是否完整。
- 把全量目标按原有顺序分成 5 到 10 段。
- 每段抽取固定条数，记录命中率。
- 如果只有最后一段命中率明显偏低，说明缺口集中在尾部，补扫尾部即可。
- 如果各段命中率都不稳定，说明中断可能伴随其他故障，需要先排查再决定是否重跑。
这个动作的结果会影响下一步：尾部缺口小，就针对缺失段补扫；各段都乱，说明单次补扫不可靠，应改为分批扫描并每批落盘。
决定补扫还是重跑，取决于缺口是否可枚举
补扫成立的条件是：你能明确列出缺失的目标集合，且这个集合明显小于全量。比如队列文件完整，只是查询层中断，那么缺失的就是队列中未处理的部分。
重跑成立的条件是：枚举阶段就不完整，或者结果写盘没有可靠的分批标记，无法确定哪些已处理。此时补扫可能重复劳动，也可能继续遗漏，重跑反而更可控。
一个折中做法是：先补扫可枚举的缺口，同时记录本次补扫的起止时间和目标范围。补扫完成后，再用同样的抽样方法复核一次。如果补扫后仍有段命中率异常，就说明原扫描的枚举逻辑本身有问题，此时再重跑才有依据。
把这次中断转成下一次的可恢复设计
判断覆盖范围只是补救，真正减少下次中断损失的是让扫描过程可恢复。具体做法包括：每处理固定条数就写一次盘并记录批次号；把目标清单和已处理清单分开存储；中断后优先读取已处理清单，而不是依赖进度显示。
这些动作不改变查询本身，但会让下一次中断后的判断从“猜覆盖到哪”变成“读已处理清单”。前提是你的工具支持分批落盘和断点记录；如果当前工具不支持，具体替代方案需要按你实际使用的工具核对文档，不能假定某个按钮或功能一定存在。
结尾回到你手上的那份结果：先确认中断层级，再用抽样划出边界，最后根据缺口是否可枚举选择补扫或重跑。每一步的结果都会缩小下一步的选择范围，而不是直接跳到重跑全站。
