百度相关搜索软件：一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /39a193f27bc5.html
📄
百度相关搜索软件：一次全站扫描被中断后怎样判断已覆盖范围
中断后不要直接重跑，先判断“已经扫过的部分是否值得保留”。判断依据不是工具显示的进度百分比，而是断点处是否形成了可验证的完整单元：如果扫描按页面逐条落盘，已覆盖范围就是已落盘且能通过完整性校验的那部分；如果结果只存在内存或临时队列中，中断后基本无法确认边界，只能重扫。下面把两种解释和区分证据讲清楚。
两种常见解释：任务真断了，还是只是展示层断了
中断后看到的现象通常是“进度条不动、日志停止、导出为空”。这至少有两种解释。
- 解释一：抓取任务本身中断。请求线程或队列已经停止，未落盘的数据随进程消失，已落盘的部分才是真实覆盖。
- 解释二：只是展示或导出环节中断。后台仍在处理或结果已分批写入，只是前端进度、汇总页没有刷新，导致看起来像全断了。
这两种解释对应的处理动作完全相反：前者要评估已落盘范围再决定是否续扫，后者应先确认数据源和落盘目录，而不是重新发起全站扫描。
区分两种解释的证据：看落盘文件、时间戳和断点记录
要区分上面两种情况，可以按下面顺序取证。
- 查落盘目录的文件数量和最后修改时间。如果文件在中断后仍有新增，或最后修改时间晚于你看到“卡住”的时间，说明后台可能仍在写入，属于解释二的可能性更大。
- 抽查最后几条记录是否完整。打开最后一个结果文件，看字段是否齐全、URL 是否重复、是否有明显截断。字段残缺往往说明写入被强行终止，这部分不能算作有效覆盖。
- 找断点或检查点文件。部分工具会记录已完成的批次或页码，这类文件比进度条更可信；如果没有检查点，只能按已落盘文件反推边界。
- 核对任务日志的结束方式。正常结束、超时退出、被手动终止，这三种日志形态不同，能帮你判断是任务层还是展示层的问题。
需要提醒的是，请求量归零或抓取量突然下降，并不能单独证明任务已经停止。它也可能是目标站点限速、网络抖动或工具主动降速造成的。只有落盘证据和日志结束方式同时指向中断，才能下结论。
用一个小例子说明怎样估算已覆盖范围
假设一次全站扫描计划覆盖 5000 个页面，工具按每 100 条写一个结果文件。中断后目录里有 32 个完整文件，第 33 个文件字段残缺。此时可以按如下方式估算：
- 完整文件覆盖约 3200 条，可作为已覆盖的下限。
- 第 33 个残缺文件只能算部分覆盖，需要重新扫这一批。
- 剩余约 1700 条属于未覆盖，需要补扫。
这个数字只是假设示例，用来演示判断方法，不代表任何工具的真实表现。实际估算时，应以你目录中的文件数和每批条数为准，并保留一定余量，避免把边界批次算作已完成。
决定保留还是重扫：看三个条件
判断已覆盖范围之后，是否保留已有结果，取决于三个条件。
- 结果是否可去重。如果每条记录带唯一 URL 或唯一标识，补扫后可以合并去重，保留旧结果成本低。
- 数据是否对时间敏感。如果相关搜索词变化快，旧结果可能已经过期，保留价值下降，重扫更稳妥。
- 补扫是否支持断点续传。支持续传时，从断点批次继续即可；不支持时，需要评估重扫全站的耗时是否可接受。
一个可执行的动作是：先对已落盘文件做一次去重和字段完整性检查，把不合格的记录单独列出。如果不合格比例很低，就保留合格部分并补扫剩余批次；如果残缺文件占比高，直接重扫反而更省事。这个检查结果会直接影响下一步是“续扫”还是“重扫”，不要跳过。
补扫前要固定的边界
无论选择续扫还是重扫，都建议先固定本次扫描的边界，避免范围漂移。
- 记录本次覆盖的 URL 规则或目录范围，补扫时沿用同一规则。
- 保留中断前的日志和结果文件，不要覆盖，便于后续核对。
- 如果工具的具体断点机制、导出格式或版本行为不明确，以该工具当前文档和实际落盘结果为准，必要时先做小范围试扫验证。
把这些边界固定下来之后，再决定补扫范围，才能让“已覆盖”和“未覆盖”有明确分界，而不是凭进度条猜测。这样处理后，下一步无论是合并结果还是重新扫描，都有可核对的依据。
