关键词工具：一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c80d084d8101.html
📄
关键词工具：一次全站扫描被中断后怎样判断已覆盖范围
结论有前提：如果关键词工具在中断前已经把已处理条目的状态逐条落盘，并且你能读到扫描开始时间、最后一条完成记录和队列游标，那么已覆盖范围应以“最后一条完整写入的记录”为边界，而不是以中断时页面显示的进度条或已用时估算。若工具只在内存中累计、结束时才一次性写入，那么中断后你无法从结果文件反推覆盖范围，只能重新扫描或改用能分段落盘的运行方式。
先看落盘结构，而不是看进度数字
全站扫描被中断后，最容易被误读的是进度百分比。进度条通常按“已取到的URL数÷预估总数”计算，而预估总数可能来自站点地图、历史抓取或上一轮扫描，和本轮实际可抓取范围并不一致。中断发生在抓取阶段、解析阶段还是写库阶段，也会让同一个百分比指向完全不同的覆盖含义。
可核对的证据是落盘结构。打开结果文件或数据表，检查是否存在以下任一形态：
- 每条URL一行，含状态字段（成功、超时、跳过、重复），最后一行时间戳明显早于中断时间；
- 只有汇总计数，没有逐条记录；
- 存在队列游标或断点文件，记录“下一条待处理”的标识；
- 同一URL出现多次，说明重试或分片重叠。
如果是第一种，你可以用“最后一条完整记录”划定覆盖边界，并把它之前的所有条目视为已处理。如果是第二种，覆盖范围不可判定。第三种最理想，恢复时从游标继续即可。第四种需要先去重，否则会把重试当成新增覆盖。
一个反例：写入成功不等于内容已覆盖
上面结论会在一种情况下失效：工具采用“先写占位记录、再补内容”的两阶段写入。此时最后一行记录虽然完整落盘，但它可能只是一个待处理标记，实际解析结果为空。判断方法是抽查边界附近若干条记录，看正文字段、状态字段和抓取时间是否同时存在。若只有URL和创建时间，没有抓取时间或内容长度，那么边界应向前回退到最近一条三个字段齐全的记录。
另一个会让结论失效的反例是分片并行。多个工作进程同时写同一张表时，最后一条记录的时间戳可能来自某个分片，而其他分片仍在更早的位置。此时应分别取每个分片的最大已完成位置，再取其中的最小值作为整体覆盖边界。只看全局最大时间戳会高估覆盖范围。
用一组可区分原因的证据缩小解释
中断后出现“结果数量明显少于预期”或“结果数量反而多于上次”，不要直接归因于工具失效或站点变化。可以按下面几组证据区分：
- 抓取日志里是否出现大量连接超时。若是，覆盖缺口集中在响应慢的路径，而非全站随机缺失。
- 结果中的URL是否集中在某个目录或参数模式。若是，可能是该段被规则过滤或分页参数未被展开。
- 重复率是否异常升高。若重复集中在少数模板页，说明去重键选择过宽或过窄，而不是覆盖范围本身变化。
- 中断前最后若干条记录的状态是否一致为“跳过”。若是，边界附近可能整段被规则跳过，需要单独核对该规则。
这些证据指向不同动作：超时集中就调整超时与并发后补扫该段；目录集中就检查过滤规则；重复升高就先修去重键再判断覆盖。把“数量少”直接当成“没扫到”会引导你去重扫全站，成本高且可能重复触发同样的中断。
假设例子：如何用边界记录决定下一步
假设一次扫描在运行到第4000条时被手动停止，结果表里第4000条记录含URL、抓取时间和内容长度，第3999条及之前均完整；同时存在一个游标文件，指向第4001条。此时合理动作是从游标恢复，而不是重头扫描。恢复后只需核对新增记录是否与游标之后的队列一致，并抽查边界前后各若干条的状态字段。
若同一场景下结果表只有汇总计数“已处理4000条”，没有逐条记录和游标，那么下一步不应是估算覆盖率，而是换一种能逐条落盘并保留断点的运行配置，或接受重新扫描。重新扫描前先确认站点是否会对高频请求做出限制，避免第二次中断发生在同一位置。
把判断结果写进下一次运行
无论本次覆盖范围能否确定，都应该把判断依据固定下来：记录扫描开始与结束时间、使用的入口来源、去重键、并发与超时设置、是否分片，以及中断时的最后一条完整记录标识。下一次运行前，先比对这些字段是否与上次一致；不一致时，覆盖范围不能直接沿用上次结论。具体工具是否提供断点续扫、逐条落盘或分片游标，需要以你实际使用的版本文档和运行日志为准，不能仅凭工具名称或宣传描述推断。
