排名查询工具一次全站扫描被中断后怎样判断已覆盖范围

📍 WDQWDWQD987AAAAA:216.73.217.15
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /93fb742ba9d7.html
📄

排名查询工具一次全站扫描被中断后怎样判断已覆盖范围

中断后不要先看“成功条数”，而要把任务清单和已落库记录做一次差集：差集为空且每个目标都有时间戳，才说明本次覆盖完整；差集不为空时，只能按“已确认覆盖”和“未确认覆盖”两段处理，不能把中断前的部分结果当成全站结论。

先确认中断发生在写入前还是写入后

同样显示中断，两种状态的含义完全不同。第一种是查询已经返回、结果尚未写入存储；第二种是结果已写入、只是后续目标没有执行。判断依据不是界面提示，而是看落库记录里有没有本次任务的批次标识、目标标识和查询时间。

如果记录带批次标识且时间戳集中在中断前，说明已写入部分可以作为“已覆盖”的起点；如果只有任务开始时间、没有逐目标记录，中断前的内容无法区分“查过但没写”和“没查”，应全部归入未确认覆盖。这一步决定后面是补扫还是重扫，不能跳过。

用差集而不是完成百分比判断覆盖范围

完成百分比通常按已处理目标数估算，中断时可能停在某个中间值，但它不告诉你哪些目标真正留下了可用记录。更可靠的做法是取三份清单：本次应查目标清单、已落库目标清单、以及落库记录中查询时间落在本次任务窗口内的目标清单。三者求差集。

假设一次任务计划查询 500 个目标，中断后落库 180 条，其中 30 条时间戳早于本次任务开始。那么本次可确认覆盖是 150 个，而不是 180 个，也不是用 180 除以 500 得到的比例。这个差值会直接影响下一步：确认覆盖足够支撑局部结论时，可以先出局部报告；差集过大时，补扫成本可能高于重扫。

两种条件下分别选择补扫还是重扫

条件一：任务可断点续跑，且目标清单、查询参数、时间窗口都能原样复用。此时优先补扫差集，只对未确认覆盖的目标重新执行。动作是导出未确认清单，按原参数发起第二轮，完成后再次做差集核验。结果是两轮记录合并后覆盖完整，但要注意两轮时间不同，跨轮比较排名时应记录各自查询时间，避免把时间差当成排名变化。

条件二：任务不支持续跑，或查询参数在中断后已被修改，或目标清单本身发生过增删。此时补扫无法保证与第一轮同条件，应选择重扫全量。动作是先冻结目标清单和参数，再完整执行一次，最后用同一套差集方法验收。结果是覆盖范围清晰，代价是重复消耗查询额度或时间。

判断补扫还是重扫，不看已完成了多少，而看“剩余部分能否与已完成部分保持同条件”。能保持就补，不能保持就重。个别样本成立但规模化后出现例外，往往就出在这里：小批量时参数容易保持一致，全站扫描时中途改过滤条件、换时间窗口或调整目标范围，都会让两段结果不可合并。

覆盖范围确认后，还要标记哪些结论不能外推

确认覆盖不等于结果可用于全站判断。即使差集为空，也要检查覆盖的目标是否代表全站结构。如果本次扫描只覆盖了部分目录、部分子域或部分语言版本，那么结论只能限定在这部分范围内。写报告时应明确写出覆盖目标和未覆盖目标，而不是只写“已扫描”。

另一个例外是查询时间跨度。中断后补扫会让不同目标的查询时间分散在较长区间，若期间排名本身波动明显，合并结果里的差异可能来自时间而不是目标本身。此时更稳妥的做法是把结果按查询时间分组呈现，或对关键目标单独复测，而不是直接合并成一张全站排名表。

可执行的最小验收动作

  1. 导出本次应查目标清单，保留目标标识。
  2. 从存储中导出本次任务窗口内的记录，保留目标标识和查询时间。
  3. 求差集，得到未确认覆盖清单。
  4. 根据参数是否可复用，决定补扫差集或重扫全量。
  5. 完成后重复第 3 步，差集为空才结束验收。

这套动作的结果会直接改变下一步：差集小且参数一致，补扫即可；差集大或参数已变，重扫更省事。把覆盖范围判断和结果解读分开，才不会让一次中断把整份全站结论带偏。

图1 图2
nginx