关键字批量查询一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c1f9401e5d4e.html
📄
关键字批量查询一次全站扫描被中断后怎样判断已覆盖范围
中断后不要先问“跑了多少条”，而要问“哪些范围留下了可复核的完成证据”。如果扫描工具只显示进度百分比，没有逐批完成标记，那么百分比归零、进度条停住或日志最后一行缺失，都不能单独证明未覆盖；合理的解释还包括进程被强制结束、输出缓冲未落盘、任务被拆成多个分片而只中断了其中一个。判断覆盖范围，应从最后一次完整落盘的结果倒推，而不是从断点位置正推。
先固定一个可复核的对照单位
把“全站”拆成能逐条核对的单位，例如按目录、按URL前缀、按参数模式或按页面模板分组。对读者手里已有的页面清单或站点地图，先做一次去重和规范化，得到一份基准清单。基准清单不需要和扫描工具的内部队列一致，但必须能回答：某个具体URL是否在清单里出现过。
假设一个站点有A、B、C三个目录，扫描中断时日志显示A处理完毕、B处理到一半、C未开始。此时能确认的覆盖范围只有A，且前提是A的完成标记与输出文件同时存在。如果只有“A完成”字样而输出文件为空，就不能把A计入覆盖。这个假设用于说明比较方法，不代表任何真实项目结果。
用完成证据而不是进度状态判断边界
可用的完成证据通常有三类：逐批写入的结果文件、带时间戳且连续的处理日志、以及能对应到基准清单的记录数。三类证据要交叉验证，而不是只看其中一项。
- 结果文件：检查文件是否按批生成、最后一批是否完整、文件内记录能否对应到基准清单中的具体URL。
- 处理日志：检查最后一条完整记录的时间戳与中断时间的关系，确认中断发生在写入之前还是之后。
- 记录数对照：把已落盘记录与基准清单做差集，差集里既有真正未覆盖的，也可能有被工具跳过或去重掉的，需要进一步分类。
如果三类证据指向不同边界，取最保守的那个作为已覆盖范围。保守不是悲观，而是为了让下一步补扫的起点明确。
把分歧转成可核对的项目
多个角色对“扫了多少”有不同理解时，分歧往往来自各自看到的界面不同：有人看进度条，有人看导出文件，有人看数据库里的记录数。解决办法不是争论哪个数字对，而是把分歧拆成可核对的项目，让每个人指出自己依据的具体对象。
- 列出所有被引用的数字及其来源，例如“进度条显示60%”“导出文件有1200行”“数据库计数为1100”。
- 为每个数字标注它对应的时间点和范围，确认是否包含去重、是否包含失败重试。
- 用基准清单做一次差集，把结果分成三类：已确认覆盖、确认未覆盖、状态不明。
- 只对“确认未覆盖”和“状态不明”安排补扫，已确认覆盖的部分不重复处理。
完成这一步后，下一步的动作会变得具体：补扫范围由差集决定，而不是由某个进度数字决定。如果差集仍然很大，说明基准清单本身可能需要先校准，而不是直接扩大扫描范围。
决定是否重扫前先确认三件事
重扫全部内容成本高，且可能引入重复记录。决定重扫前，先确认：中断是否影响了输出写入、工具是否支持按已完成清单续跑、以及基准清单是否在中断后发生过变化。三项中任何一项不确定，都应先做小范围验证，再决定全量重扫还是增量补扫。
一个可操作的动作是：从“状态不明”里抽取少量页面，用同一工具单独处理，观察结果能否与已有记录对齐。如果对齐，说明边界判断可用，补扫可以按差集进行；如果对不齐，说明问题出在基准清单或去重规则，此时应先修正对照单位，再谈覆盖范围。这个动作的结果直接决定下一步是补扫还是先修清单。
把结论写成可交接的覆盖说明
最终要留下的不是一句“扫完了”或“没扫完”，而是一份覆盖说明：基准清单版本、已确认覆盖的范围、确认未覆盖的范围、状态不明的范围、以及每类的判断依据。这样即使换人接手，也能从同一份说明继续，而不必重新争论中断时到底跑到哪里。
覆盖说明里应避免使用“大概”“应该”这类词，凡是无法对应到具体URL或具体批次的，一律归入状态不明。状态不明不是失败，它只是提醒下一步需要验证，而不是直接当作已覆盖或未覆盖来处理。
