网站自动推广工具，一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /52744987947b.html
📄
网站自动推广工具，一次全站扫描被中断后怎样判断已覆盖范围
扫描中断后，不要先看“总共处理了多少条”，而要先确认工具是否留下了可续跑的检查点。有检查点，就从中断位置继续；没有检查点，就把已产出的结果按页面清单回填，再决定补扫哪一段。判断覆盖范围的核心不是数量，而是“哪些对象有明确结果、哪些对象完全没被处理”。
先区分三类记录，而不是只看成功条数
中断时工具通常会留下几种痕迹：已完成的页面结果、正在处理但未落盘的页面、以及尚未开始的页面。把这三类混在一起，就会把“部分处理”误当成“已覆盖”。可操作的做法是导出一份结果清单，再对照站点自己的URL清单，逐条标记状态。
- 已完成：有明确输出字段，且字段不是空值或占位符。
- 处理中：有开始时间但没有结束记录，或输出字段只写了一半。
- 未开始：在URL清单里存在，但结果文件中完全找不到。
假设一个站点有1000个可抓取URL，中断后结果文件里有620条。这620条里若有30条只有开始记录、没有输出，那么真正可用的覆盖是590条，而不是620条。这个差额会直接影响下一步：是补扫410条，还是补扫440条。
用页面清单做差集，得到真正的缺口
最可靠的判断依据是你自己掌握的URL清单，而不是工具界面上显示的进度。把结果文件中的URL去重后，与清单做差集，剩下的就是缺口。这一步能排除两种情况：工具重复处理同一URL造成的虚高，以及动态参数导致同一页面被算成多条。
做差集时要注意规范化：去掉末尾斜杠差异、统一大小写、剔除跟踪参数。否则同一页面会同时出现在“已完成”和“缺口”里，让覆盖判断失真。得到缺口清单后，按目录或模板分组，就能看出中断是随机发生，还是集中在某一类页面上。
中断位置能解释缺口形态时，优先续跑
如果缺口呈现明显的连续特征，比如集中在某个目录之后、或某个时间点之后的所有URL，说明工具大概率是按队列顺序处理，中断点之后的都没跑。这种情况下，从检查点或缺口起点续跑，比重新全量扫描更省资源，也不会覆盖已有结果。
反之，如果缺口零散分布在不同目录、不同模板之间，就要警惕不是简单的中断，而是部分页面被跳过。常见合理解释包括：超时、被目标站点限流、页面返回非预期状态码、或工具自身的并发上限。此时直接续跑可能仍然跳过同一批页面，需要先降低并发或延长超时，再针对缺口单独跑一轮。
一个实际动作：先只补扫缺口清单中随机抽取的20条，观察它们的完成率和输出完整度。如果这20条能稳定完成，说明原中断是偶发的，可以放心补扫剩余部分；如果仍有较高比例失败，说明存在系统性障碍，应先调整参数，而不是继续扩大补扫范围。
没有检查点时，用时间戳和日志重建边界
部分工具不提供续跑检查点，只留下日志或带时间戳的结果。这时可以用最后一条完整记录的时间，作为大致的中断边界。边界之前的URL视为已覆盖，边界之后的按未处理对待。这个方法有误差：并发处理会让时间顺序与队列顺序不完全一致，所以边界附近的一小段需要单独复核。
复核方式是从边界前后各取一批URL，检查它们是否在结果文件中出现、输出是否完整。如果边界附近出现大量半成品记录，就把边界往前移，把这段整体划入待补扫范围。宁可多补一小段，也不要把半成品当成已完成。
把覆盖结论写成一个可交接的清单
判断完成后，输出不应只是一句“大概跑了六成”。应形成一份可交接的记录，至少包含：URL清单的来源与数量、已完成数量、半成品数量、缺口数量、缺口的分组特征、以及本次采用的补扫策略。这样下一次中断时，接手的人不需要重新推断覆盖范围。
需要提醒的是，抓取量或处理量归零，并不能单独证明工具已经停止或任务已经失败。它也可能是目标站点临时不可达、本地网络中断、或结果写入延迟造成的。要结合日志、时间戳和缺口形态一起判断，才能区分“真的没跑”和“跑了但没记下来”。具体工具是否提供检查点、日志格式和续跑方式，需要以你所用版本的实际情况为准。
