关键词研究工具：一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d0239c81e71b.html
📄
关键词研究工具：一次全站扫描被中断后怎样判断已覆盖范围
结论先说：扫描中断后，不要问“跑了多少条”，而要问“哪些入口已经留下可复核的完成记录”。如果工具按队列处理、且你能看到已处理条目的状态标记，那么已覆盖范围大致等于“状态为完成”的那部分；如果它只是流式输出、没有逐条落盘状态，那么中断前刷出的结果只能算抽样，不能当作全站覆盖。使这个结论失效的反例是：工具在中断后自动从断点续跑，并补写了缺失状态，此时你看到的完成记录可能包含中断后补上的部分，必须用时间戳区分。
先分清三种中断留下的痕迹
同样叫“中断”，留下的证据完全不同，判断方法也不同。
- 进程被杀或浏览器标签关闭：内存里的队列丢失，磁盘上通常只剩已写出的结果文件。此时覆盖范围看文件里的条目数，而不是界面上的进度条。
- 网络断开或接口超时：请求可能已经到达服务端并计费，但响应没回来。这类条目处于“未知”状态，既不能算已覆盖，也不能算未覆盖。
- 手动暂停：多数工具会保留队列位置，恢复后从暂停点继续。此时已覆盖范围以暂停前的完成标记为准，恢复后新增的部分要单独标记。
实际动作：中断后第一件事是找到结果输出文件或任务日志，按状态字段分组计数，而不是重新发起一次全站扫描。这样做的结果是，你会得到“完成 / 未知 / 未开始”三组数字，下一步只需针对“未知”这组重跑，而不是全部重来。
用两个可区分的证据判断“已覆盖”
判断某条入口是否真的被处理过，靠两个独立证据，缺一不可。
- 有该条目的完成记录：例如日志中出现该 URL 或该词，且状态不是“排队中”。
- 记录时间早于中断时刻：如果时间戳晚于中断时刻，说明它是续跑补上的，要单独归类。
只有第一条、没有第二条时，你无法排除“中断后自动补跑”的干扰。反过来，只有时间戳、没有状态字段时，也无法判断该条目是成功还是失败重试。假设一次扫描计划处理 5000 个入口，中断时日志显示 1800 条状态为完成、200 条状态为超时、其余无记录，那么可宣称的已覆盖范围是 1800 条，200 条属于待重跑，剩余 3000 条未处理——注意这里的数字只是说明比较方法，不代表任何工具的实际表现。
需要提醒：抓取量或请求量归零，不能单独证明“没有遗漏”。它也可能意味着日志写入被缓冲、进程已退出但文件未刷新，或者服务端限流后静默丢弃。要看文件最后修改时间和日志末尾是否有截断迹象。
缺少完整权限时能做的最小动作
如果你拿不到任务日志、也看不到队列状态，只剩导出的结果文件，仍然可以做一件事：按导出文件的条目清单，与你的入口清单做差集。
具体做法是：把导出结果里的唯一标识（URL、词或 ID）提取出来，和原始入口清单比对，得到“出现在结果里”和“没出现在结果里”两组。没出现的那组就是你需要重新覆盖的范围。这个动作的局限是：结果里出现过的条目，只能说明它被处理过，不能说明它被处理完整——例如一个页面只抓到了部分字段。所以差集法适合判断“哪些完全没碰”，不适合判断“哪些碰了但没跑完”。
适用条件是：导出文件包含唯一标识字段，且入口清单本身是完整、去重后的。如果入口清单本身来自上一次不完整的扫描，差集结果会继承同样的缺口，这时要先修正入口清单。
中断后不要立刻做的三件事
- 不要直接全量重跑：会重复消耗配额，也会让新旧结果混在一起，反而更难判断覆盖范围。
- 不要用“进度百分比”反推条数：百分比常常是按预估总量算的，预估本身可能不准，中断后更不可靠。
- 不要把“无报错”当作“已完成”：静默失败和限流丢弃都不会报错，需要靠状态字段或时间戳识别。
下一步动作的顺序建议是：先锁定中断时刻，再按状态分组，然后只对“未知”和“未开始”两组重建队列。重建队列时保留原有唯一标识，避免和已完成的条目重复。这样做的结果是，恢复后的覆盖范围可以和中断前的记录直接拼接，而不需要重新解释一遍数据。
把结论限定在可复核的范围内
最终你能对外说明的覆盖范围，应当只包含“有完成记录且时间戳早于中断时刻”的条目。超出这个范围的任何说法，都需要标注为估计或待验证。如果工具本身提供断点续跑且能区分补跑记录，那么覆盖范围可以扩展到续跑完成的部分，但前提是你能拿到区分标记。拿不到标记时，宁可把范围说小，也不要把未知算成已覆盖——这是中断后唯一稳妥的判断方式。
