关键词热度查询：一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e97ea2d071f6.html
📄
关键词热度查询：一次全站扫描被中断后怎样判断已覆盖范围
先看中断发生在哪个阶段，再决定是重跑还是补跑。如果任务在“发现链接”阶段就断了，已覆盖范围通常很小，直接重跑更省事；如果它已经进入“逐条查询热度”阶段，并且工具把每条结果实时落盘，那么已覆盖范围可以用任务日志或导出文件核对，只需补跑缺失部分。判断依据不是中断时长，而是任务是否有可核对的进度标记。
两种条件下，选择重跑还是补跑
条件一：任务没有中间产物，或者产物只在内存里。此时无论中断得多晚，你都拿不到可靠清单，重跑是唯一可控选择。理由很简单——没有落盘记录，任何“我记得跑到哪了”都只是估计，补跑会产生重复和遗漏。
条件二：任务按批次写入了日志或结果文件。这时先别重跑，把已写部分读出来，提取每条记录里的URL或查询词，去重后形成“已完成集合”，再与原始待查清单做差集。差集就是需要补跑的范围。选择依据是：补跑能避免重复消耗查询额度，也能让前后两批数据的时间条件更接近。
用可核对的证据区分“已覆盖”与“看起来覆盖”
中断后最容易误判的是把“任务启动时的全站URL数”当成已覆盖数。实际证据要落到具体记录上：
- 结果文件里是否有逐条热度字段，而不只是汇总计数。
- 日志是否记录了每个批次的起始与结束标记，而不是只有一条“开始运行”。
- 时间戳是否连续，中断点前后是否出现明显跳跃。
如果结果文件只有总数没有明细，总数归零或偏小都不能单独证明任务没跑过——也可能是写入被中断、文件被覆盖，或者工具在异常退出时回滚了缓存。反过来，总数很大也不能证明覆盖完整，可能包含重复行或上一次任务的残留。要区分这些解释，最直接的动作是打开文件看前几行和最后几行的结构，确认字段含义与本次任务的配置一致。
一个注明假设的短例子
假设一次全站扫描待查1000个URL，任务按每50条写一个批次文件。中断后目录里存在7个完整批次文件，第8个文件只有部分行。此时已完成集合是前7批共350条，加上第8批中能解析出URL的行。补跑范围就是剩余约650条。这个例子的数字仅用于说明差集方法，不代表任何工具的实际性能。动作要点是：先解析、去重，再生成补跑清单，而不是按文件个数乘批次大小估算。
补跑时如何让前后两批结果可比
补跑前记录当前的时间范围、地区或设备条件，并尽量与中断前保持一致。如果中断前后隔了很久，热度本身可能已经变化，这时要在最终结果里标注两段的采集时间，而不是把两批数据直接混在一起排序。下一步动作是把补跑清单单独跑一次，完成后与已完成集合合并，再检查总数是否等于原始清单去重后的数量。若不等，优先排查重复URL和大小写差异，而不是立即再跑一遍全量。
什么情况下例外，必须整体重跑
当任务配置在中断后被修改过，比如换了查询条件、改了匹配规则，补跑结果与旧结果就不可比，此时整体重跑更稳妥。另一种例外是工具本身不支持断点续跑，且结果文件格式在中断时被写坏，无法稳定解析。判断标准是：你能不能从现有产物中还原出一份可信的已完成URL清单。能还原就补跑，不能还原就重跑。具体工具是否支持断点续跑、结果文件如何命名，需要以你所用版本的说明为准。
