站长工具综合查询一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ffb23d4c80eb.html
📄
站长工具综合查询一次全站扫描被中断后怎样判断已覆盖范围
先看中断前是否留下了逐页或分批的结果，再决定是续跑还是重跑：如果工具按URL逐条返回且你能导出已完成部分，已覆盖范围通常可以用“成功返回的URL集合”来界定；如果只有汇总数字、没有明细，中断后的汇总值往往不能直接当作覆盖范围。一个会让上述判断失效的反例是分页或游标查询：即使前几页成功返回，也不能推断中间没有遗漏，因为排序变化、超时重试和并发抓取都可能让同一页在不同批次里覆盖不同对象。下面按可操作的判断顺序展开。
先区分三种“中断”，它们的覆盖边界完全不同
同样是扫描被中断，留下证据的方式差别很大，判断方法也不同。
- 请求层中断：连接被重置、超时或返回错误码。此时已覆盖范围等于中断前所有成功响应的对象，失败对象需要单独列出重试。
- 任务层中断：进程被终止、会话过期或手动停止。要看是否有断点记录或已完成批次文件；没有的话，只能按最后一条成功记录的序号往后推。
- 数据层中断：结果写了一半、导出文件损坏或字段缺失。这类中断最危险，因为行数看起来完整，但部分字段为空，不能用行数判断覆盖。
判断时优先找“对象清单”而不是“数量”。数量相同不代表对象相同，尤其在并发抓取时，重复请求会占用名额，让实际覆盖对象少于计数。
用可区分证据确认覆盖到哪一步
不要只看总数。下面几组证据能互相校验，出现矛盾时以更细的那组为准。
- 输入清单与输出清单求差集：把提交的URL列表与成功返回的URL列表比对，差集就是未确认覆盖的部分。这是最直接的方法，前提是输入清单本身完整。
- 检查时间戳连续性：按返回时间排序，看是否存在明显的时间断档。断档前后各取几条核对，能判断中断点大约落在哪个区间。
- 抽查边界对象：取中断点前后的若干条，确认它们的状态码、字段和抓取时间是否正常。如果边界对象字段残缺，说明中断影响范围可能比记录显示的更大。
- 核对去重后的唯一对象数：如果工具支持按URL去重，唯一对象数比总请求数更接近真实覆盖；两者差距过大说明重试或重复提交较多。
这里有一个假设例子：假设提交1000个URL，扫描中断后导出成功记录800条，去重后唯一URL为760个。那么未确认覆盖至少是240个，而不是200个，因为40条是重复请求。这个差值会直接决定下一步是补跑240个还是重跑全部。
什么情况下必须重跑而不是续跑
续跑成立需要同时满足：对象清单可稳定复现、结果字段结构未变、中断点之后没有依赖前面状态的逻辑（例如累计统计、跨页关联）。只要有一条不满足，续跑就可能产生拼接错误。
典型的必须重跑情形：
- 结果按排序分页返回，而排序依据在两次运行之间可能变化。
- 扫描包含跳转跟踪或跨域关联，中断导致链路只走了一半。
- 导出文件字段缺失或编码异常，无法确认哪些行是完整的。
- 任务使用会话级凭证，中断后凭证已失效，续跑实际是另一次全新运行。
反过来，如果工具明确支持断点续跑、且你能验证续跑批次与已完成批次的对象不重叠，那么补跑未完成部分是更省时间的选择。是否支持、如何触发，需要以你所用工具的当前说明为准，不同工具差异较大。
下一步动作：先做一次小范围校验再决定规模
在补跑或重跑之前，取未确认覆盖部分中约二三十个对象做一次小范围校验，记录成功数、失败原因和字段完整度。如果这批的成功率和字段完整度与中断前一致，可以按补跑处理；如果明显偏低，说明中断可能伴随环境问题（如限流、凭证失效），此时重跑并调整请求节奏更稳妥。这个校验结果直接决定后续是补跑剩余对象，还是先解决环境问题再全量重来。
最后提醒一点：请求量、抓取量归零或某项计数突然下降，都不足以单独证明覆盖正确。它也可能是限流生效、任务被暂停或数据尚未落盘。把计数与对象清单、时间戳、字段完整度三者交叉核对，才能对已覆盖范围给出可靠结论。
