网站历史记录查询一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /98df998139fb.html
📄
网站历史记录查询一次全站扫描被中断后怎样判断已覆盖范围
先给结论：中断后不能凭“已经跑了多久”或“抓到了多少条”判断覆盖范围，而要回到扫描任务的进度记录，看它是否按URL清单或分片边界留下了可核对的断点。如果只留下一个总数，最稳妥的做法是把这次结果当作部分样本，而不是全量历史；接下来要么从断点续扫，要么换用能按分片记录状态的查询方式重来。
两个常见解释：是任务真的跑了一半，还是只写入了能显示的部分
全站扫描被中断后，最容易出现两种互相矛盾的现象：结果列表看起来已经有很多条，但导出文件却很短；或者抓取日志显示处理了不少地址，可最终报告只覆盖首页和少数栏目。它们通常对应两种解释。
- 解释一：任务确实推进到了某个位置，只是结果尚未完整落盘。扫描程序可能先把发现到的URL写入临时队列，再逐条查询历史记录。中断发生在队列写入之后、结果写回之前，于是“发现量”很大，“完成量”很小。
- 解释二：任务只完成了可见入口，没有真正展开全站。如果扫描依赖站内链接逐层发现，中断可能发生在第二层或第三层，此时首页、栏目页和部分文章页已有记录，但深层页面、分页列表和参数页并未进入队列。
这两种解释对应的补救动作不同。前者可以从断点继续，后者需要先补全URL发现，再重新查询。判断错方向，会让后续动作建立在错误前提上。
能区分两种解释的证据：断点、分片边界和URL来源
不要只看总数，先找三类可核对证据。
- 断点记录。检查任务是否保存了最后处理的URL、时间戳或队列偏移量。若存在明确的最后一条地址，可以用它去比对站点结构中的位置，判断扫描停在哪一层。
- 分片边界。如果扫描按字母、目录、站点地图分段，查看已完成分片和未开始分片的边界。分片边界清楚，覆盖范围就能用“已完成分片并集”描述；没有边界，只能描述为“已返回结果”。
- URL来源。区分结果里的地址来自站点地图、站内链接还是手动导入。来源单一且集中在栏目页，往往说明深层页面未被展开；来源多样且包含分页和参数地址，覆盖范围更接近全站。
一个假设例子：某次扫描计划处理一万个地址，中断时报告显示“已处理三千”。如果断点记录停在/category/page/12，且分页链接是按顺序入队的，那么可以判断前十二页对应范围已覆盖，后续分页未覆盖。如果报告只有“已处理三千”而没有断点，三千这个数字可能包含大量重复地址或跳转地址，不能直接当作覆盖量。此时应把结果标记为部分样本，下一步先补做URL去重和分层统计，再决定是否续扫。
两种做法如何取舍：从断点续扫，还是重新全量扫描
两种做法都成立，但条件不同。
适合从断点续扫的条件：任务保存了明确的断点或分片状态；站点结构在中断前后没有明显变化；历史记录查询接口对同一地址返回的结果稳定。满足这些条件时，续扫的代价较小，但需要接受一个前提：中断期间新增或删除的页面不会被这次任务完整覆盖，后续要补一次差异检查。
适合重新全量扫描的条件：没有断点记录；扫描依赖动态链接发现，队列无法复原；或者站点在中断期间发生了改版、迁移。重新扫描的代价是时间和请求量增加，但覆盖范围更容易从零开始核对，不必猜测中断点之前的结果是否完整。
实际动作上，可以先做一次小范围验证：从断点位置向后取一个分片，单独查询并核对返回地址数量与站点地图中该分片的地址数量是否接近。如果两者差距明显，说明断点续扫仍会漏，应该转为重新扫描；如果差距在可解释范围内，再继续续扫。这个动作的结果直接决定下一步是补差异还是重来，而不是凭感觉二选一。
覆盖范围写进报告时，要带上限定条件
如果最终要把这次查询结果交给其他人使用，覆盖范围不能只写“已扫描全站”。更准确的写法是：本次任务覆盖了哪些分片或目录、断点在哪里、哪些来源未展开、结果对应的时间窗口是什么。这样即使扫描被中断，读者也能判断哪些结论可用、哪些需要补查。
还要注意，请求量下降、抓取量归零或结果条数变少，都不能单独证明覆盖已经完整。它们也可能是请求被限制、页面返回错误、查询接口临时不可用造成的。把这些现象与断点记录、分片边界放在一起看，才能对覆盖范围作出可复核的判断。
