网站快照查询：一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c44d7933d017.html
📄
网站快照查询：一次全站扫描被中断后怎样判断已覆盖范围
先别急着重跑。中断后要判断已经覆盖到哪里，最可靠的做法是找到扫描过程中留下的逐条记录或分批日志，用“最后一个完整结束的批次”作为边界，而不是用时间、进度条或印象来推断。如果日志只记了总数不记明细，那么已覆盖范围就不可验证，此时应把这次结果降级为线索，而不是当作全站基线。
先分清中断类型，再决定是否保留结果
扫描被中断的原因不同，已覆盖范围的可信度差别很大。常见三种情况：
- 主动停止或超时退出：如果工具是顺序处理并逐条写入结果，已写出的记录通常对应完整处理过的对象，边界相对清晰。
- 程序崩溃或连接断开：可能正在写入一条记录时中断，最后一条状态不明，需要单独复核。
- 配额或权限中途失效：后半段可能返回空值或错误值，而不是没有处理，这类“看似覆盖”最容易误判。
判断动作：打开结果文件，按处理顺序排序，找出最后一条状态为“成功”或“已完成”的记录，把它之前的部分视为已覆盖，之后视为未覆盖。如果结果里混有错误码，要先按错误码分组，错误记录不计入已覆盖。
用可核对的边界代替进度百分比
进度条、耗时和“已处理 N 条”的提示都可能因重试、并发或缓存而失真。更稳的边界证据有三类：
- 有序主键或序号：结果中带有递增编号、时间戳或 URL 排序，可据此确认断点位置。
- 分批清单：如果扫描按分页、按目录或按批次推进，最后完整结束的批次号就是边界。
- 抽样回查：从断点前后各取少量对象，重新单独查询，确认断点前确实有结果、断点后确实没有。
假设一次扫描按字母顺序处理了 4000 个页面后中断，日志显示最后完整结束的是第 12 批（每批 300 条），那么可确认覆盖约 3600 条，剩余约 400 条未处理。这个数字只是用于说明边界推算方法，实际以你的日志为准。抽样回查若发现断点前的对象也查不到结果，说明中断影响的不只是尾部，整批结果都要重新评估。
保留、改写还是退出：三种取舍的适用前提
保留适用于：日志有序、断点明确、错误记录可区分，且业务只需要已覆盖部分的信息。此时把边界写进结果说明，后续增量补扫剩余部分即可，不必全量重跑。
改写适用于：结果大体可用，但断点附近状态混杂，或部分字段在中断后不可信。做法是保留已确认部分，把断点附近的一段标记为待复核，缩小重跑范围，而不是推翻整次扫描。
退出适用于：日志只有总数、没有明细，或中断发生在权限、配额失效之后，无法区分“没处理”和“处理失败”。这种情况下继续使用结果会把未知当成已知，应放弃本次数据，重新设计带逐条日志的扫描方式。
一个实际动作：在结果文件里新增一列“覆盖状态”，把断点前的记录标为已确认，断点附近的标为待复核，断点后的标为未处理。这个动作会直接决定下一步是增量补扫、局部复核还是全量重来。
补扫之前先确认边界是否稳定
决定补扫后，不要立刻从断点接续。先确认两件事：断点之后的对象清单是否完整可枚举；断点之前的结果是否受同一批参数影响。如果两次扫描的参数、范围或过滤条件不一致，拼接出来的数据不能视为同一次全站覆盖。
补扫完成后，用同一套边界方法核对新增部分与原有部分的衔接处，确认没有重复也没有遗漏。若衔接处出现大量重复记录，说明断点定位偏早；若出现空档，说明断点定位偏晚，需要回退重扫一小段。
什么情况下这次结果只能当线索
当扫描工具不提供逐条状态、只给汇总数字，或者中断原因涉及权限与配额变化时，已覆盖范围无法被验证。此时把结果用于发现线索可以，用于判断全站状态不行。判断标准很简单：能否指出“最后一条被完整处理的对象是谁”。指不出来，就不能把这次扫描当作基线。
另外，请求量或抓取量突然归零，不能单独证明扫描已经正确停止或覆盖完整，也可能是限流、网络中断或目标端临时不可达造成的。需要结合日志中的错误类型一起看，才能确定边界是否可信。
