网站优化助手：一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c52b66b7fa4d.html
📄
网站优化助手：一次全站扫描被中断后怎样判断已覆盖范围
先看扫描器是否留下了可续跑的进度记录，再决定保留、改写还是退出。如果进度文件记录了已完成队列和当前游标，保留并续跑通常比重新全扫更省资源；如果只中断在日志里、没有可恢复状态，那么已覆盖范围无法可靠重建，应把这次结果降级为线索，而不是结论。
中断点决定覆盖范围能不能被信任
全站扫描的覆盖范围由三个变量共同决定：抓取队列的推进位置、每个URL的处理状态、以及中断时正在写入的批次。三者中任意一个缺失，覆盖范围就只能估算。
- 可续跑中断：扫描器把队列和游标持久化，重启后从断点继续，已覆盖范围等于断点之前的完成量。
- 不可续跑中断：状态只存在于内存，进程结束后队列丢失，只能靠日志时间戳反推大致进度。
- 写入中断：数据正在落库时被切断，最后一批记录可能部分写入，需要按主键或时间戳去重校验。
判断属于哪一种，最直接的动作是查看扫描器的工作目录或数据库中是否存在进度表、队列快照或检查点文件。存在检查点且时间戳与中断时刻接近，说明覆盖范围可续；只有一份汇总日志，说明只能估算。
三个可核对的覆盖证据
不要凭“扫了多久”推断覆盖范围。时间长短受站点响应速度和并发限制影响，与覆盖量没有稳定关系。可核对的证据有三类：
- 已处理URL清单：对比扫描器记录的URL数量与站点地图、站内链接或日志中出现的URL总量。前者明显小于后者，说明覆盖不完整。
- 批次边界：如果扫描按分页或分片推进，检查最后完成的批次号。批次边界清晰，覆盖范围就清晰；批次内混有未完成记录，边界就模糊。
- 错误与跳过记录：超时、被拒、被规则排除的URL是否单独计数。这些URL不属于“已覆盖”，把它们算进覆盖率会高估实际范围。
假设一次扫描计划处理一万个URL，中断时日志显示已处理六千，其中四百个因超时被跳过。那么有效覆盖是五千六百，而不是六千。这个差额会直接影响下一步：如果有效覆盖已覆盖主要栏目，可以针对剩余部分做增量扫描；如果有效覆盖集中在低价值页面，续跑的意义就不大。
保留、改写还是退出：三种前提下的取舍
已覆盖范围确定之后，处理方式取决于剩余工作的价值和重跑成本。
保留并续跑适用于：检查点存在、剩余URL仍属于本次分析目标、且站点在这段时间内没有发生结构性改版。续跑前先确认游标指向的位置没有因为页面增删而错位，否则会出现漏扫或重复扫。
改写扫描范围适用于：剩余URL数量大但优先级低，或者中断原因是目标站点对高频请求做了限制。此时把全站扫描改成按栏目、按模板或按优先级分批扫描，每批独立记录覆盖范围，中断的影响就被限制在单批之内。这个动作的结果是：后续任何一批中断，都不需要重新判断全站覆盖，只需判断该批覆盖。
退出本次结果适用于：没有检查点、日志不足以重建队列、且已覆盖部分集中在重复模板页。在这种情况下，基于不完整数据得出的结论可能误导后续决策，重新组织一次范围更小、目标更明确的扫描比修补旧结果更可靠。
续跑之前必须确认的一件事
无论选择保留还是改写，续跑前都要确认扫描目标在中断期间是否发生变化。页面新增、删除或改版会让旧游标失去参照。核对方法是：抽取中断点前后各若干条已记录URL，重新请求并比对状态码、标题或内容指纹。如果差异集中出现，说明站点已变动，续跑需要重置游标或重新生成队列。
这一步的结果决定下一步：指纹一致，可以按原队列续跑；指纹大面积不一致，应放弃旧队列，用当前站点结构重新生成扫描范围，并把旧结果仅作为历史参考。
把覆盖范围写进记录，而不是留在记忆里
判断完成后，把本次实际覆盖的URL数量、跳过数量、未覆盖区间和判断依据写进扫描记录。下次中断时，这份记录就是最快的参照。覆盖范围一旦可追溯，保留、改写或退出的决定就不再依赖印象，而是依赖可核对的数字和边界。
