排名查询，一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c508fe74d744.html
📄
排名查询，一次全站扫描被中断后怎样判断已覆盖范围
结论先给：中断后的已覆盖范围，不能靠扫描进度条或“已完成百分比”判断，而要用“可核对的落盘证据”反推——即已写入结果集的URL集合、时间戳和批次边界。如果这些证据不完整，默认把整次扫描视为未完成，重新跑的成本通常低于基于残缺数据做决策的风险。下面给出区分不同情况的证据、一个会让结论失效的反例，以及中断后最该做的下一步动作。
先分清三种“中断”，它们的覆盖含义完全不同
同样是扫描停下来，落盘状态不一样，覆盖范围的可信度也不一样。可以用下面的特征做区分：
- 批次边界中断：结果文件按批写入，最后一批完整落盘，只是没有下一批。此时已覆盖范围等于“所有已完整写入的批次”，边界清晰，可以核对。
- 单条写入中断：正在写某一条记录时进程被杀，可能出现半行、字段缺失或编码截断。这种记录必须剔除，不能算作已覆盖。
- 状态与数据不一致：进度记录显示处理到第N条，但结果文件里查不到对应记录。这说明“处理过”不等于“已保存”，进度数字在这里没有证据价值。
判断动作很具体：打开结果文件，检查最后若干行是否结构完整（字段数一致、无截断），再与进度记录中的批次编号比对。如果最后一批不完整，就把该批整批丢弃，而不是只删掉坏行——因为同一批里可能还有你没发现的静默丢失。
用可核对的证据反推覆盖范围
不要依赖工具界面上的“已扫描X条”。可靠的做法是自己构造三个可核对的量：
- 去重后的URL计数：对结果集中的URL做去重，得到实际写入的唯一地址数。这个数字才是“已覆盖”的下限，不是上限。
- 批次编号的最大连续值：如果批次是递增编号的，中断点之前的最大连续编号决定了可信边界。出现跳号，说明中间有丢失，跳号之后的批次不能直接接续使用。
- 时间戳跨度：记录最早和最晚的时间戳。如果最晚时间戳距中断时刻有明显空档，说明中断前可能已有一段时间没有成功写入，这段空档内的URL是否覆盖无法确认。
把这三个量对齐后，你能得到一个保守的已覆盖集合。假设一次扫描计划覆盖1万个URL，结果文件去重后有6200条，批次编号连续到第62批（每批100条），时间戳最晚值距中断约几分钟——在假设批次写入是原子性的前提下，可以认为前6200条左右是可信覆盖，剩余部分需要重扫。注意这是假设，不是实测结论，实际是否原子写入要看你所用工具或脚本的落盘方式。
一个会让上述结论失效的反例
上面的推理有一个关键前提：结果文件里的记录顺序与扫描顺序一致，且每条记录只写一次。如果工具采用并发写入或多进程分片，这个前提就不成立。此时“去重后6200条”可能来自扫描顺序的后半段，而前半段因为分片失败根本没写入；批次编号也可能各分片独立编号，最大连续值没有全局意义。
识别这种反例的信号是：结果文件中的URL分布与你的站点结构明显不符，比如只覆盖了某个目录，或时间戳在同一秒内大量聚集。一旦出现这类信号，前面基于“连续批次”的估算全部作废，只能把整次扫描当作未完成处理。这也是为什么“请求量归零”或“进度停在某处”不能单独证明中断点就是覆盖边界——并发、重试、缓存命中都可能造成类似现象，需要结合写入证据一起看。
中断后最该做的下一步动作
先做一次小规模续扫验证，再决定是续跑还是全量重跑。具体动作：从疑似未覆盖的区间中抽取一小批URL（例如按站点目录或ID区间取若干条），单独跑一次扫描并记录落盘结果。如果这批URL能被正常写入且结构完整，说明工具和落盘链路没问题，可以按批次边界续跑剩余部分；如果这批也出现写入异常，说明问题不在中断本身，而在写入环节，此时续跑只会重复产生不可信数据，应当先修复落盘逻辑再全量重跑。
这个动作的结果直接决定下一步：续跑成功，你只需补齐缺失区间并再次核对去重计数；续跑失败，整次扫描的数据都不应进入后续分析。无论哪种情况，最终用于决策的覆盖范围都应以“去重后唯一URL数”为准，而不是任何进度百分比。
