爱站关键词挖掘：一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /eeaf98a1b516.html
📄
爱站关键词挖掘：一次全站扫描被中断后怎样判断已覆盖范围
先看中断前是否留下了可核对的产物——导出文件、结果列表或页面快照。如果有，就按“已落盘的部分”划定覆盖范围；如果没有任何产物，只能把这次扫描视为未覆盖，不能凭记忆或运行时长推断。判断的核心不是猜它跑了多少，而是找到可复核的边界。
把中断现场转成可核对的三个证据层
面对一次中断的扫描，先别急着重跑。按下面三层依次检查，能确定多少算多少：
- 产物层：有没有导出文件、复制出来的列表、截图或临时保存的页面。这是最硬的证据，能直接看出覆盖到哪些对象。
- 过程层：扫描时是否记录了起始对象、处理顺序、每批数量或进度日志。没有日志时，这一层基本为空。
- 对象层：你原本要覆盖的完整对象清单是什么——栏目、页面类型、站点地图条目或一批种子词。没有这份清单，就无法判断“还差多少”。
三层里只有产物层和对象层同时存在，才可能算出覆盖率。缺对象层，连分母都没有，任何百分比都是空谈。
用首尾对象和排序规则反推边界
假设你按站点地图顺序扫描，中断前导出的一批结果里，第一条和最后一条都还在。查看这两条对应的对象在原始清单中的位置，就能圈出一个大致连续的区间。若工具是按字母、按栏目或按发现顺序处理，区间就是线性的，边界相对可靠。
但有两种情况会让这个方法失效。一是处理顺序并非稳定排序，比如并发抓取导致结果乱序，首尾对象之间可能夹着大量未处理项。二是结果里出现过重复或跳号，说明中间可能有遗漏，此时只能把已确认的对象逐个标记，不能按区间外推。
可执行的动作：把导出结果与原始对象清单做一次去重比对，列出“已出现”和“未出现”两个集合。已出现的视为已覆盖，未出现的不能直接判定为未覆盖——它可能只是排在中断点之后。这个动作的结果决定下一步：如果未出现集合很小且集中在末尾，补扫尾部即可；如果未出现集合分散，说明顺序不可靠，应整体重扫。
缺少完整数据或权限时能做什么
很多中断场景下，你拿不到完整对象清单，也没有导出权限，只能看到屏幕上滚过的一部分。此时仍可执行一个最小动作：记录当前可见结果的最后一个对象，以及它出现时的大致批次或位置。这至少给你一个“已知到达点”。
由此能推出的结论很有限：可以确认该点之前的部分对象被处理过，但不能确认它们全部成功，也不能推断该点之后的状态。如果连这个点都没有，唯一诚实的结论是“覆盖范围未知”。
不要用运行时长来估算覆盖比例。处理速度受对象大小、网络波动和并发策略影响，时长与覆盖量之间没有稳定对应关系。同样，抓取请求数归零也可能只是限流、暂停或队列耗尽，不能单独证明任务已完成或已覆盖全部对象。
一个假设例子：如何用边界决定重扫策略
假设你有一份 500 条的对象清单，中断后导出 180 条结果，且导出文件保留了处理顺序。比对后发现前 170 条与清单顺序一致，第 171 至 180 条出现跳号。此时合理的判断是：前 170 条可视为已覆盖，后 10 条状态不明，剩余 320 条未处理。
下一步动作有两种成立条件。若工具支持从指定位置续扫，且跳号部分能单独重跑，就只补第 171 条之后的内容，节省时间。若工具只能整体重扫，或跳号原因不明，就整体重来，并把这次的导出和日志保留下来，避免再次中断后无从判断。
这个例子里的数字只用于说明比较方法，不代表任何真实任务的规模或速度。关键假设是“处理顺序稳定且导出完整”，一旦这个假设不成立，区间推断就不能用。
把判断结果写成可复查的记录
无论最终决定补扫还是重扫，都建议留下一条简短记录：原始对象总数、导出结果数、已确认覆盖的边界、跳号或异常位置、以及你选择的处理方式。这份记录的价值在于，下次中断时你能快速知道上次停在哪里，而不是重新猜一遍。
如果使用的是具体工具，其是否支持断点续扫、导出格式是否保留顺序、日志能否查看，都需要以你当前实际使用的版本为准，具体信息请自行核对，不要依赖记忆中的旧界面或旧功能。判断覆盖范围这件事，靠的始终是可核对的产物和清单，而不是对工具行为的假设。
