关键词软件优化：一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /fe80ab485652.html
📄
关键词软件优化：一次全站扫描被中断后怎样判断已覆盖范围
先给结论：中断后的覆盖范围不能靠“跑了多久”或“还剩多少条”来推算，而要把已落盘的结果按URL清单重新对账。能对账的部分才算已覆盖；对不上的部分，无论界面显示过什么，都应视为未覆盖，重扫时只补这部分。
先分清两种中断：进程被杀和主动停止
这两种情况对覆盖范围的含义完全不同，判断方式也不同。
进程被杀（崩溃、断电、容器被回收）时，工具通常来不及写收尾状态，最后一个批次可能只写了一半。此时不能相信进度条或日志末尾的百分比，只能相信已经完整写入的结果文件或数据库记录。判断依据是：结果里是否存在重复行、是否存在字段缺失的记录、最后一条记录的写入时间是否早于中断时间。
主动停止（手动终止、达到时间上限）时，多数工具会在停止前完成当前批次的提交。覆盖范围相对清晰，但仍要确认停止点是否落在批次边界上。若停止发生在批次中间，处理方式和进程被杀相同。
两种情况的共同动作是：不要在原任务上直接“继续”。先导出当前结果，再决定补扫范围。继续执行容易让工具从错误的断点重启，反而制造重复或遗漏。
用URL清单对账，而不是用条数对账
判断覆盖范围最可靠的办法，是拿一份独立的URL清单去比对结果集。清单来源可以是站点地图、上一次完整扫描的导出文件、或服务器访问日志里去重后的路径。比对时看三件事：
- 结果集中出现、清单中也存在的URL：已覆盖。
- 清单中存在、结果集中缺失的URL：未覆盖，需要补扫。
- 结果集中出现、清单中不存在的URL：可能是重定向、参数变体或历史遗留，单独标注，不算覆盖缺口。
只比对条数是不够的。假设清单有8000条，结果有5200条，这5200条里可能包含大量清单外的参数页，真正覆盖的清单URL可能只有4000条。条数接近不代表覆盖接近。
实施动作：把结果集和清单各导出为一行一个URL的纯文本，用sort和comm做差集，得到缺失清单。这个缺失清单就是补扫的输入。补扫完成后，把新旧结果合并再去重，重新对账一次，确认缺失清单归零或只剩已知例外。
一个假设例子：中断在60%时该补多少
假设一次全站扫描计划处理10000个URL，中断时工具显示已完成6000个。导出结果后发现实际写入5800条，其中300条是清单外的参数页。与清单对账后，清单内已覆盖5500条，缺失4500条。
如果直接按“已完成60%”补扫剩余40%（4000条），会漏掉500条——这500条正是中断批次里没写完的部分。正确做法是按缺失清单补扫4500条。补扫后合并结果，再对账一次，若缺失清单仍不为零，说明补扫本身也发生了中断或过滤，需要再查原因，而不是继续加量重扫。
这个例子的数字只用于说明对账方法，实际数量以你自己的清单和结果为准。
哪些情况会让对账结果不可信
对账方法成立的前提是清单本身可信、结果写入完整。以下情况需要先处理，再判断覆盖：
- 清单本身是旧的，站点在此期间新增或删除了大量页面。此时缺失清单里会混入已删除页面，需要先更新清单。
- 结果文件是流式写入且没有事务保护，中断时最后一批可能部分写入。先检查最后一批的完整性，把不完整的记录剔除后再对账。
- 工具在扫描中做了URL规范化（去参数、统一大小写、跟随重定向），导致结果里的URL和清单不是同一形态。对账前要统一规范化规则，否则差集会虚高。
- 扫描被中断后，工具自动重试过若干次，结果里可能存在同一URL的多条记录。先去重再对账。
这些例外不处理，对账得到的缺失清单会偏大或偏小，补扫范围随之失真。
把分歧变成可核对的项目
多个角色对“覆盖了多少”有不同理解时，争论进度百分比没有意义。把分歧落到三个可核对的项目上：清单版本、结果导出时间、对账脚本的输出。谁的说法都能用这三项验证。核对通过后，补扫范围和下一步动作自然确定：缺失清单为零则进入结果分析，不为零则先补扫再分析。这一步做完，中断就不再是判断障碍，而只是一个需要补齐的输入缺口。
