热度指数查询：一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c488d9386e4a.html
📄
热度指数查询：一次全站扫描被中断后怎样判断已覆盖范围
先别重新跑全站。把中断前已经落盘的查询结果、任务日志和待查清单放在一起，按“已确认覆盖、疑似覆盖、未覆盖”三档重算，再决定补查哪一段。判断依据不是扫描进度条，而是每个查询对象是否留下了可核对的返回记录。
先固定一个可核对的覆盖单位
热度指数查询常以页面、关键词、内容编号或站点栏目为对象。中断后最容易出现的误判，是把“任务启动过”当成“对象查过了”。你应当先选一个最小覆盖单位，例如一个URL或一个查询词，再规定它满足什么条件才算覆盖。
可用的覆盖证据通常包括：该对象在结果文件中存在一条记录；记录里的查询时间早于中断时间；返回状态不是超时、限流或空响应；对象标识与待查清单能一一对应。四项缺一项，就归入疑似覆盖，而不是已覆盖。
假设一次任务计划查询200个对象，中断时结果文件里有120条记录，其中8条状态为超时。那么已确认覆盖是112个，疑似覆盖是8个，未覆盖是80个。这个拆分只是比较方法，不代表任何工具的真实产出规模。
用中断点前后各截一段做交叉验证
日志里的最后一条成功记录只能说明任务走到过哪里，不能证明之前的对象都成功了。更稳妥的做法，是从结果文件中各抽一段：中断点前最近的一批，以及更早批次里随机抽出的若干条，逐条回到待查清单核对。
如果两段都能对应上，说明结果落盘和清单编号基本一致，可以按记录数估算覆盖范围。如果只有最近一段对得上，更早批次大量缺失，那么结果文件可能只保留了部分批次，不能拿总记录数直接当覆盖数。
这一步的实际动作是建立一张对照表：对象标识、结果文件是否存在、状态、时间、归属批次。做完后你会得到补查范围。若缺失集中在某一批次，下一步就补该批次；若缺失分散，则按对象逐个补，而不是整站重跑。
区分“没查到”和“没查成”
中断后的结果里，空值最容易被误当成低热度。热度指数查询返回空结果，至少有三种合理解释：对象本身没有可统计的数据；请求被限流或超时；查询参数与对象不匹配。三者对应的下一步完全不同。
- 若同一批次多个对象同时为空，优先怀疑限流、超时或参数错误，先补查该批次。
- 若只有个别对象为空，且其他批次正常，可先标记为待复核，不必立刻重跑全站。
- 若空值对象集中在某一栏目或某一类标识上，先检查对象格式和查询条件，再决定是否补查。
把空值直接计入已覆盖，会让后续判断建立在错误分母上。把空值全部当成失败，又会浪费大量重复请求。按批次和对象类型分组看空值分布，是成本较低的分辨方法。
按缺口类型决定补查顺序
确认缺口后，不必从第一个对象重新开始。可以按以下顺序处理：
- 先补中断点附近、已有部分记录的批次，避免同一批数据新旧混杂。
- 再补完全没有任何记录的对象，这类缺口最明确。
- 最后处理疑似覆盖对象，用同一条记录规则复核，而不是凭印象放行。
补查时保留原批次标识和查询时间。这样下一次中断时，你仍然能按同一套规则判断覆盖范围，而不必重新定义什么叫“查过”。
需要核对具体工具的任务日志字段、结果文件格式和中断恢复方式时，以该工具当前实际提供的说明为准；不同工具对批次、状态和导出范围的定义并不一致。
把判断结果写成下一次可复用的清单
一次中断处理完后，把本次的覆盖单位、证据条件、缺口分类和补查顺序记下来。下一次热度指数查询开始前，先确认结果文件是否按对象逐条落盘、是否带状态和时间、是否能与待查清单对应。若不能，就先调整查询对象的组织方式，再启动全站任务。
判断已覆盖范围的核心不是恢复进度条，而是让每个对象都有可核对的记录。记录对得上，补查范围就清楚；记录对不上，先修记录规则，再谈补查。
