pr查询，一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9426f0dc59c4.html
📄
pr查询，一次全站扫描被中断后怎样判断已覆盖范围
结论先说：如果扫描任务留下了可续跑的检查点或分批记录，优先按“已完成批次清单”判断覆盖范围；如果只留下一个中断时的进度数字，则应把该数字视为不可靠，改为对目标集合做抽样复核。两种做法的分界在于：你能否把“已处理对象”还原成一份可列举、可去重的清单。不能还原时，任何百分比都只是过程量，不足以支撑后续的补扫或交付判断。
先分清中断留下了哪类痕迹
扫描被中断后，现场通常只有三类痕迹：一类是逐条写入的结果记录，一类是按批次或分片记录的进度，一类是只更新总量的计数器。判断覆盖范围时，这三类的可信度差别很大。
- 逐条结果记录：每条目标对应一条输出，能直接去重计数，覆盖范围最容易还原。
- 批次进度记录：知道哪些分片已完成、哪个分片正在处理，边界清楚但需要确认批内是否写全。
- 单一计数器：只知道处理了多少条，无法知道具体是哪些，也无法排除重复计数。
实际操作上，先不要急着重新全量扫描，而是把现有输出按目标标识去重，得到已覆盖集合，再与目标全集求差集。这个差集才是真正需要补扫的范围。如果去重后数量明显小于计数器显示的数字，说明存在重复写入或重试叠加，计数器不能作为覆盖依据。
两种补扫策略的取舍条件
面对不确定的覆盖范围，常见两种做法：整体重扫，或只补差集。它们各自成立的条件不同。
整体重扫成立的条件：目标规模不大、单次扫描耗时可控、结果本身允许重复覆盖且不会产生副作用。代价是重复消耗请求配额或计算资源，但如果目标集合小，这个代价可以接受，换来的是覆盖范围确定。
只补差集成立的条件：目标集合可枚举、每条目标有稳定唯一标识、已完成结果可去重。代价是需要先做一次集合比对，且如果中断发生在单条目标处理中途，可能出现半成品记录，需要额外标记为待重查。
选择依据不是哪种更“完整”，而是哪种代价更小且结果可验证。目标几万条以上、单次扫描耗时较长时，整体重扫的重复成本会明显上升，此时差集补扫更合理，前提是唯一标识可靠。
一个会让上述判断失效的反例
假设某次扫描按域名分批，进度记录显示前 8 批已完成。看起来补扫第 9 批之后即可。但如果结果写入是异步的，批次标记为完成时，该批的部分结果可能仍在缓冲区未落盘，那么“已完成批次”并不等于“已覆盖”。
这种反例的特征是：进度记录与结果记录由不同环节写入，二者时间不同步。识别方法是抽查最后一批已完成分片，看该批目标在结果集合中的命中率是否接近预期。如果明显偏低，说明进度标记超前于结果落盘，此时应按结果集合而非批次标记来判断覆盖范围，并把最后若干批一并纳入补扫。这个反例说明：判断依据要选那个“更靠近最终结果”的记录，而不是看起来更整齐的进度表。
抽样复核怎么做才有区分力
当记录不足以还原清单时，抽样复核是退而求其次的办法，但抽样要能区分“真未覆盖”和“已覆盖但无结果”。
- 从目标全集中按稳定规则抽取样本，覆盖不同分片或不同时间段，避免只抽开头部分。
- 对每个样本单独执行一次查询，记录是否返回结果、结果是否与已有输出一致。
- 若样本中大量出现“已有输出里没有、单独查询却有结果”，说明覆盖缺口集中在未落盘部分，应扩大补扫范围。
- 若样本普遍一致，只能说明缺口不大，不能证明全站已覆盖，仍需保留差集补扫这一步。
抽样只能降低不确定性，不能替代清单。它的价值在于帮你决定补扫范围是“最后若干批”还是“全部重来”，而不是直接宣布扫描完成。
下一步动作与结果如何影响后续
建议的动作顺序是：先去重现有结果得到已覆盖集合，再与目标全集比对得到差集，然后对差集补扫，最后用同一套去重规则合并结果并复核总量。这个动作的结果会直接决定下一步：如果差集很小且抽样一致，可以按补扫后交付；如果差集很大或抽样发现进度与结果严重不同步，就应放弃按进度判断，改为整体重扫或重建可续跑的检查点机制。
需要提醒的是，请求量或结果量归零、骤降，并不能单独证明扫描已正确完成，也可能来自目标源临时不可达、限流或过滤规则变化。把这类现象当作完成信号，容易把未覆盖范围误判为已覆盖。判断覆盖范围，始终以可列举、可去重的目标清单为准，其余信号只作为辅助。
