长尾词挖掘工具，一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /79d8c9d1e9d3.html
📄
长尾词挖掘工具，一次全站扫描被中断后怎样判断已覆盖范围
结论先说：中断后不要凭“跑了多久”或“还剩多少条”估算覆盖率，能站得住脚的依据只有已落盘的输出记录本身。如果工具在中断前没有逐条写出可核对的结果文件，那么已覆盖范围基本无法判断，只能重跑或改用分批方式；如果输出文件存在，就可以按记录边界、时间边界和入口边界三条线索还原覆盖到哪里。
先确认输出是否具备可还原的边界
全站扫描类任务通常边跑边写结果，中断时最后一条记录就是最直接的证据。判断前先看输出文件里有没有这几类字段：来源页地址、种子或入口标识、抓取时间、状态标记。缺少来源页地址时，你只能知道“抓了多少条”，无法知道“从哪些页面抓的”，覆盖范围就失去参照。
一个可用的最小动作是：打开输出文件，取最后若干条记录，检查它们的来源页是否集中在同一目录、同一模板或同一批入口。如果集中在少数入口，说明中断发生在某个入口的处理过程中，该入口之后的页面大概率未覆盖。这一步的产出会直接决定下一步：是补齐剩余入口，还是整站重跑。
用入口清单反推，而不是用耗时反推
更可靠的做法是拿一份独立的入口清单来对照，例如站点地图、栏目列表或已确认可访问的分类页。把输出记录中出现的入口去重后，与清单逐项比对，落在清单上但从未出现的入口就是未覆盖部分。这种做法不依赖工具自身的进度显示，也不受中断时机影响。
需要注意一个会让结论失效的反例：如果扫描过程中入口本身发生了跳转、合并或失效，清单里的地址和实际抓取地址对不上，比对结果就会把已覆盖的入口误判为未覆盖。此时应先统一地址规范，再重新比对，否则补跑会重复劳动。
- 能对上：按缺失入口补跑，已覆盖部分不必重来。
- 对不上且无法解释：说明入口清单不可信，改用抓取日志或直接重跑。
- 输出为空或只有汇总数字：无法判断覆盖范围，最小动作是重跑并开启逐条落盘。
区分“抓过”和“抓完”是两件事
即使某个入口出现在输出里，也不代表它下面的页面都被处理完。中断可能发生在入口打开之后、子页尚未展开之时。判断时要看输出中同一入口下是否存在多个层级的记录：只有入口页一条，通常意味着未展开；出现多页且分布均匀，才更接近处理完成。
这里可以做一个假设性的短例子。假设某次扫描计划覆盖 200 个入口，输出文件里有 120 个入口各留下一条记录，另有 15 个入口留下 5 至 8 条记录。较合理的解读是：那 15 个入口处理得较深，其余 120 个可能只完成了入口页。下一步应优先检查这 120 个入口的页面结构，确认它们是否本身就只有一层，而不是急着全部重跑。
中断原因决定要不要信任已有输出
因超时、限速或手动停止而中断，已写出的记录通常仍可用，覆盖范围按记录边界判断即可。因程序崩溃、磁盘写满或编码错误而中断，最后一段记录可能不完整甚至损坏，此时应丢弃末尾若干条再统计，或者以更早的一个完整批次为界。
判断记录是否完整，可以看字段是否齐全、时间戳是否连续、同一入口的记录是否出现明显断裂。若断裂处之后仍有记录，说明写入并未真正停止，覆盖范围可能比表面看到的更靠后，需要以实际可解析的记录为准。
缺少权限时仍能执行的最小动作
没有服务器日志、没有抓取后台、也没有工具方的任务详情时，仍可做一件事：把现有输出按来源页分组计数，得到一份“已出现入口”的临时清单，再与你能公开访问到的栏目页对照。这样得到的覆盖率是下界，只能说明“至少覆盖了这些”，不能说明“其余都没覆盖”。
这个下界足以支持一个决定：如果缺失入口集中在少数几个栏目，补跑这几个栏目即可；如果缺失入口分散且数量可观，说明中断发生得较早，重跑整站比逐项补齐更省事。无论选哪种，下一次扫描都应要求逐条落盘并保留入口标识，否则同样的问题会再次出现，而这次的经验并不能替你判断下一次的覆盖范围。
