百度关键词工具：一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a6c0f577a7ca.html
📄
百度关键词工具：一次全站扫描被中断后怎样判断已覆盖范围
先别重跑，也先别把中断前的记录当完整清单。判断已覆盖范围的关键不是“跑了多久”，而是中断时是否留下了可核对的处理边界：最后一条成功记录、队列里未处理项、以及失败项是否被单独标记。只有这三类信息至少保留两类，才能对覆盖范围做出可用判断；否则只能重新建立一次可续跑的扫描。
条件一：中断后仍有日志和断点记录，可以估算覆盖范围
如果扫描过程中持续输出了日志，并且记录了断点位置，那么判断覆盖范围要按“已确认处理”和“仅进入队列”分开。已确认处理指工具返回了该条记录的结果，无论结果为空还是有值；仅进入队列则只代表待处理，不能算已覆盖。
可执行的最小动作是：取中断前最后一条成功记录，按扫描顺序向前回溯，统计连续成功的记录数，再与总待处理量比较。这个比例可以作为覆盖范围的下限估算，而不是精确值，因为并发处理时日志顺序可能不等于实际完成顺序。
接下来要检查失败项。如果日志里同时记录了请求失败、超时或解析异常，这些条目必须从已覆盖范围中剔除。此时下一步不是补跑全部，而是只补跑失败项和断点之后的未处理项。这样做的结果是：扫描总量可能减少，但覆盖判断更可靠。
条件二：只有部分结果、没有断点记录，不能直接推断覆盖范围
如果中断后只拿到一份导出文件，没有断点、没有队列状态、也没有失败标记，那么无法从结果条数反推覆盖比例。结果条数少，可能是没扫完，也可能是扫描完成但符合条件的结果本来就少；结果条数多，也可能只是重复项或未去重数据。
这种情况下，唯一能执行的最小动作是：先检查导出文件是否包含时间戳、批次号或状态字段。如果有时间戳，可以按时间排序，找到最后一条记录的时间，再与扫描开始时间对比，判断中断发生在早期还是后期。但这只能说明时间进度，不能说明空间覆盖，因为不同条目的处理耗时并不相同。
如果连时间戳都没有，就不要对覆盖范围下结论。此时合理的下一步是重新建立一次带断点和失败标记的扫描，而不是在旧结果上继续拼接。重新扫描的结果会影响后续决策：如果新扫描能稳定输出断点，才具备续跑和增量处理的条件。
用“已确认、待确认、已失败”三分法代替百分比
比起估算一个覆盖百分比，更实用的是把中断时的状态分成三类：
- 已确认：有明确返回结果的条目，包括空结果。
- 待确认：在队列中但未返回结果的条目。
- 已失败：返回错误、超时或解析异常的条目。
这三类一旦分开，后续动作就明确了：已确认部分可以直接进入分析；待确认部分需要续跑；已失败部分需要单独重试，并且要记录重试次数。如果失败项集中在某一类条目上，比如特定长度或特定字符集，那说明问题可能出在输入格式，而不是扫描范围本身。
假设一个短例子：某次扫描计划处理1000条记录，中断时日志显示已确认620条、待确认300条、已失败80条。此时覆盖范围应报告为“已确认620条，另有80条失败待重试”，而不是“覆盖62%”。因为那300条待确认里，可能有部分已经处理但未写入日志，也可能完全没开始。把待确认当未覆盖，是一种保守但可解释的处理方式。
例外：中断原因决定是否需要先修复再续跑
并非所有中断都适合直接续跑。如果中断原因是权限失效、网络中断或配额耗尽，那么续跑前必须先确认这些条件是否恢复。否则续跑会再次中断，并且可能把同一批条目反复标记为失败，干扰对覆盖范围的判断。
如果中断原因是工具自身崩溃或进程被杀死，而日志和断点仍可读取，那么续跑通常是可行的。但要注意：续跑前应核对断点对应的条目是否已经写入结果，避免重复处理。重复处理本身不一定有害，但会让结果条数虚高，从而影响对覆盖范围的判断。
最后，无论选择哪种方式，都要把“本次扫描覆盖了什么”和“本次扫描没有覆盖什么”写成同一份记录。只记录已覆盖部分，会让下一次扫描重复劳动；只记录未覆盖部分，又无法判断已有结果能否使用。覆盖范围判断的终点不是得到一个数字，而是明确下一步是补跑、重试还是重新开始。
