百度相关词查询：一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0293d52f4294.html
📄
百度相关词查询：一次全站扫描被中断后怎样判断已覆盖范围
先看扫描日志里最后一条成功写入的记录，而不是看跑了多久。如果日志按“种子词—返回词—写入时间”逐条落盘，找到最后一条完整记录的位置，就能把已覆盖范围切成两段：这段之前的结果通常可用，这段之后到中断点之间的请求无法确认是否返回。接下来要做的不是重跑全站，而是决定保留、改写还是退出这次扫描。
中断前已落盘的部分，什么条件下可以保留
保留的前提是每条结果都能对应到一个明确的输入词，并且写入顺序与扫描队列顺序一致。满足这两点，中断点之前的数据可以视为一个局部快照，用于回答“这些词的相关词长什么样”，但不能回答“全站相关词一共有多少”。
如果日志只记录了任务开始和结束，中间没有逐条写入，那么中断前跑过的词就无法反推。此时保留这批数据会带来一个隐蔽问题：你会把“没写进去”误当成“没有相关词”。这种情况下更稳妥的做法是放弃这次结果，重新用可续跑的队列设计。
一个可执行的动作是：把已落盘记录按输入词去重，统计实际覆盖了多少个不同输入词，再与计划队列总数比较，得出覆盖率。这个覆盖率只说明输入词覆盖进度，不等于结果完整度。下一步决策取决于你需要的到底是“覆盖足够多的词”还是“每个词的结果都齐”。
改写扫描方式，比补跑更能解决中断问题
如果中断原因是单次任务过长、请求被限或进程被回收，直接原样重跑大概率会在相近位置再次中断。改写的关键是把一次大扫描拆成可独立完成的小批次，每批结束后写入状态标记。
- 按输入词分批，每批记录“已完成/进行中/未开始”三种状态，续跑时只处理非完成项。
- 每条结果附带批次号和写入时间，便于中断后按批次边界截断。
- 对同一输入词的多次请求做去重，避免续跑时把重复结果当成新增覆盖。
这样改写的代价是管理成本上升，收益是任何一次中断都只损失当前批次。判断是否值得改写，可以看一个假设例子：若全站计划输入词为一千个，单批五十个，中断最多损失五十个词的进度；若不分批，中断可能损失数百个词且无法确认边界。这里的数字仅用于说明分批与不分批的差异，不代表任何实际任务的规模。
什么时候应该直接退出这次扫描
出现以下情况时，继续修补这次扫描的收益很低：输入词表本身已经过时，业务前提在扫描期间发生变化；或者中断暴露出队列设计无法区分“未请求”和“已请求但无结果”。前一种情况下，即使补跑完成，结果对应的也是旧前提；后一种情况下，补跑仍然无法给出可信的覆盖边界。
退出的动作不是删数据，而是把这次结果标记为“不可用于覆盖判断”，仅留作词形参考。然后基于新的业务前提重建输入词表，再决定是否重新扫描。这个顺序很重要：先确认前提，再决定扫描范围，否则容易在错误的前提上反复补跑。
用一次小规模验证确认边界判断是否可靠
在正式续跑或重建之前，可以挑中断点附近的少量输入词单独查一遍，看返回结果是否与日志中最后几条记录的模式一致。如果一致，说明中断点判断基本可靠；如果差异明显，说明日志的写入顺序可能和实际请求顺序不一致，此时覆盖率数字需要打折看待。
验证结果会直接影响下一步：边界可靠就按批次续跑；边界不可靠就回到输入词表重建。无论哪种选择，都不要把“请求量归零”或“抓取量下降”单独当作扫描已完成的证据，这些现象也可能来自限流、队列耗尽或进程退出等不同原因，需要结合日志中的状态标记一起判断。
最后要明确一个适用条件：以上判断都建立在日志能逐条对应输入词的基础上。如果你的记录方式做不到这一点，那么这次中断后最该做的不是估算覆盖范围，而是先补上可续跑的记录机制，再谈保留还是退出。
