博客写作软件一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4152154592f0.html
📄
博客写作软件一次全站扫描被中断后怎样判断已覆盖范围
先给结论：中断后不要按“扫描到一半所以覆盖约一半”来估算，而要先确认软件是否把进度和已处理清单落盘。落盘完整时，直接读已处理清单即可界定覆盖；落盘不完整时，只能靠可核对的中间产物反推，覆盖范围通常比进度条显示的更小。下面把两种做法、适用条件和代价讲清楚，再给一个能立刻执行的动作。
两种做法成立的条件不同
第一种做法是信任软件给出的进度记录，直接从未完成的位置续扫。它成立的前提有三个：进度是持久化的，中断后重新打开仍能看到；已处理项有唯一标识，能区分“处理过”和“跳过”；续扫逻辑幂等，重复处理同一项不会产生错误结果。满足这三条时，续扫代价最低，覆盖范围等于“已完成清单 + 本轮新增”。
第二种做法是放弃续扫，把这次中断当作一次不完整样本，重新全量扫描。它适合进度只存在于内存、没有落盘清单，或者扫描本身很轻量、重跑成本低于核对成本的情况。代价是时间和资源翻倍，好处是覆盖范围可被完整证明，不依赖对软件内部状态的推断。
判断走哪条路，先看一个信号：中断后重新打开，软件是否还能列出已处理的具体条目。能列出，走第一种；只能看到一个百分比或进度条，走第二种。百分比是派生数据，不是覆盖证据。
为什么进度条不能当作覆盖依据
进度条通常按“已耗时 / 预估总耗时”或“已发现 URL 数 / 预估总数”估算，两者都会在中断时失真。常见失真来源包括：
- 预估总数来自上一轮或抽样，本次站点结构变了，分母本身不准；
- 部分条目被跳过（重复、被规则排除、请求失败重试），它们可能计入也可能不计入进度；
- 中断发生在写入阶段，内存里已处理但尚未落盘的条目会丢失。
所以“显示 60%”既可能对应覆盖 60%，也可能对应覆盖 30% 或 75%。把进度条当覆盖范围，是这类判断里最常见的错误。
用中间产物反推覆盖范围的三个证据
如果没有可靠的已处理清单，可以找这三类可核对的产物，按可信度从高到低排列：
- 带时间戳的输出文件。每一批结果写入时留下的文件，其条目数就是确定覆盖的下限。注意最后一批可能只写了一半，需要按行数校验是否完整。
- 请求或访问日志。如果软件或运行环境记录了请求，日志里出现过的目标就是已覆盖。但日志可能包含失败重试和重复请求，需要去重后再计数。
- 软件自身的状态文件。部分工具会把断点写入本地状态文件，格式通常是 JSON 或数据库。能读出来就直接用；读不出或字段含义不明时，不要猜。
三类都没有时，覆盖范围无法界定，只能按“未覆盖”处理。
一个假设的例子
假设一次全站扫描在运行约四十分钟后被手动中断，软件显示进度 70%，输出目录里有三个结果文件，请求日志记录了约两千条请求，站点已知页面约五千个。此时可以这样推算：三个完整结果文件共覆盖一千二百个页面，日志去重后一千五百个，两者取交集得到确定覆盖约一千一百个，占已知页面的两成多。进度条的 70% 与这个结果差距很大，说明分母或计数方式有问题。下一步应放弃续扫，改为重新全量扫描，并把“每批结果落盘”作为下次运行的检查项。这个例子里的数字仅用于说明比较方法，不代表任何真实项目。
使结论失效的反例
如果站点在中断前后发生了结构性变化，比如栏目改版、大量页面删除或新增，那么“已知页面约五千个”这个分母本身已经失效，前面所有按比例推算的覆盖范围都不成立。此时唯一可靠的做法是重新确定当前页面集合，再重新扫描，而不是修补旧数据。同理，如果软件在续扫时会重置已处理状态，第一种做法也会失效。
下一步动作
中断后先做一件事：打开软件，尝试导出或查看已处理条目列表。能导出，就与输出文件比对，取两者交集作为确定覆盖范围，再决定是否续扫；不能导出，就直接重新全量扫描，并在下次运行前确认输出是否按批落盘。这个动作的结果直接决定后续是补扫还是重跑，也决定你能不能向别人证明覆盖到了哪里。
