快照更新软件一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ec5e2667283e.html
📄
快照更新软件一次全站扫描被中断后怎样判断已覆盖范围
结论先行：扫描中断后，不要用“跑了多久”或“任务进度条停在百分之几”来推断覆盖范围，唯一可靠的依据是已落盘的记录本身——即中断前已经写入结果集的条目，以及每条记录里携带的时间戳、来源标识和页面标识。如果软件没有把中间结果持久化，那么中断后你能判断的只是“哪些页面被访问过”，而不是“哪些页面被完整处理过”，这两者的差距往往很大。
先分清三种“覆盖”，别把它们混为一谈
全站扫描的覆盖至少有三个层次，中断后它们的状态并不一致：
- 抓取覆盖：页面是否被请求过。这通常能从日志或软件的任务记录里看出，中断后保留得最完整。
- 解析覆盖：页面内容是否被成功解析成结构化字段。请求成功不等于解析成功，编码异常、脚本渲染超时都会让这一层缺口大于第一层。
- 写入覆盖：解析结果是否已经落盘。这是最容易被高估的一层，很多工具在任务结束前才批量写库，中断时缓冲区里的数据直接丢失。
判断已覆盖范围时，你要找的是第三层的证据。如果只能拿到第一层的记录，就必须把结论降级为“访问范围”，不能当作“更新判断范围”使用。
用记录里的时间字段反推中断点
多数快照类工具会在每条结果上带一个处理时间或抓取时间。把已落盘记录按这个字段排序，取最大值，再和中断发生的时刻比较。如果最大值明显早于中断时刻，说明最后一段时间的结果没有写入，缺口就在这个时间差对应的那批 URL 上。
反过来，如果最大值接近中断时刻，也不能立刻认为覆盖完整——还要看记录数量与预期 URL 总量的比例，以及是否存在同一时间戳下大量记录集中写入的情况，后者往往意味着批量刷盘而非逐条写入，中断时更容易丢尾部数据。
一个注明假设的短例子
假设某次扫描预期覆盖 5000 个 URL，中断后结果集里有 3200 条记录，时间戳最大值距中断时刻约 40 秒。你可以先按时间戳把 3200 条分成两段：前 3000 条分布均匀，后 200 条集中在最后 40 秒内。这种情况下，合理的判断是“前 3000 条覆盖较可信，后 200 条需要重跑验证”，而不是“已完成 64%”。比例在这里没有意义，因为写入不是均匀发生的。
什么情况下上面的判断会失效
有一个反例必须提前排除：如果软件的结果集是覆盖式写入而非追加式写入，那么中断后你看到的记录可能只是最后一次刷盘的状态，之前已处理的页面被后来的批次覆盖掉了。此时按时间戳排序会得到一个看似连续的区间，但实际覆盖范围被严重低估或错位。
判断方法：检查同一 URL 是否在结果集中出现多次，或结果集的总条数是否远小于日志里的请求条数。如果两者差距悬殊，就不要用结果集反推覆盖范围，而应以请求日志为准，并把结论限定为“访问范围”。
缺少完整数据或权限时能做的最小动作
如果你拿不到日志、也没有数据库读取权限，仍有一个可执行的最小动作：对结果集中最后写入的一批 URL 做抽样复检。具体做法是从时间戳最大的记录里随机取一小批，用同样的快照查询方式重新跑一次，比较两次结果是否一致。
这个动作的结果会直接决定下一步：
- 如果抽样结果与已落盘记录一致，说明写入内容本身是完整的，缺口只在于“还有多少没写”，可以按时间戳区间补跑。
- 如果抽样结果与记录不一致，说明中断可能影响了写入的完整性，此时不应补跑，而应整段重跑，否则会得到一份新旧混杂、无法判断时效的结果集。
需要说明的是，抽样一致只能说明这批记录可信，不能推出未抽样的部分同样可信，也不能推出扫描已经覆盖了全部预期 URL。它只是一个成本最低的分界判断。
补跑范围怎么定，才不会二次浪费
确定缺口后，补跑范围通常有两种取法：按时间戳区间补，或按 URL 列表补。前者适合结果集里带有可靠时间字段、且写入是追加式的情况；后者适合你手上有完整的预期 URL 清单，能直接做差集。两者都成立时，优先按 URL 列表补，因为它不依赖对写入行为的假设。
补跑前把已确认可信的记录单独导出留档，避免补跑过程中新结果覆盖旧结果。补跑完成后，用“可信记录数 + 补跑成功数”与预期总量比较，而不是用软件显示的总进度——后者在中断后往往不可信。
