移动优化软件一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 (compatible; QlyzeBot/1.0; +https://app.qlyze.io/bot)
🔗 /f1ae73128e5a.html
📄
移动优化软件一次全站扫描被中断后怎样判断已覆盖范围
结论先行：中断后不要看进度条百分比，而要看扫描器在中断前是否已把“发现队列”和“已完成结果”分开落盘。如果两者都在，你可以按已处理URL清单判断覆盖范围；如果只有一个总数，覆盖范围只能算“未知”，不能按比例折算。这个判断成立的前提是扫描任务本身支持断点续跑或至少保留了中间文件，否则任何估算都只是猜测。
先分清“已发现”和“已检测”是两件事
全站扫描被中断时，最容易混淆的是发现阶段和检测阶段。发现阶段只负责收集URL，检测阶段才真正对页面做移动端渲染、资源检查或交互测试。如果你的移动优化软件在中断后只留下一个“已发现 8000 条”的计数，而没有标记其中哪些已经完成检测，那么这 8000 只是候选集合，不是覆盖范围。
可核对的做法是查看任务目录或导出文件里是否存在两类记录：一类是待处理队列，另一类是已完成结果。只有已完成结果里的URL才算覆盖。假设一个站点有约 5000 个可访问页面，扫描中断时已完成结果文件里有 1200 条，待处理队列里有 2600 条，剩余约 1200 条既不在结果也不在队列里，说明发现阶段本身也没走完。这时覆盖范围应表述为“已完成 1200 条，发现未完成”，而不是“覆盖了 24%”。
用三种证据交叉确认，而不是相信单一计数
多个角色对覆盖范围有分歧时，把争论转成可以核对的项目。以下三类证据能帮助判断：
- 任务日志的时间戳：看最后一条写入记录的时间，以及中断前是否出现连续的空队列或错误重试。
- 已完成结果文件的行数：这是最接近真实覆盖的计数，但要排除重复URL和重定向产生的中间记录。
- 站点地图或入口清单的比对：把已完成结果里的URL与已知入口做差集，差集越大，未覆盖范围越明确。
一个实际动作是：把已完成结果导出为纯URL列表，与站点地图中的URL做一次差集统计。如果差集里大量是分页、筛选参数或已下线页面，那么已覆盖范围对核心页面的代表性可能比数字看起来更好；如果差集里包含主要栏目和详情页，则覆盖范围不足以支撑整站结论。这个动作的结果直接决定下一步是重新全量扫描，还是只补扫差集部分。
什么情况下“已覆盖范围”这个结论会失效
反例出现在扫描器把“已请求”当成“已检测”时。有些移动优化软件在发出请求后立即写入结果，但移动端渲染或脚本执行可能还没完成就中断了。此时结果文件里的URL数量接近真实，但每条记录的内容不完整，覆盖范围在数量上成立、在质量上不成立。
判断方法是抽查已完成结果中的若干条，看是否包含移动端特有的字段，例如视口配置、触控目标尺寸、资源加载状态。如果这些字段大量为空，说明中断发生在检测中途，覆盖范围不能按条数计算。另一个失效条件是站点在扫描期间发生发布或改版，已完成结果对应的是旧版本页面，此时覆盖范围只对旧版本有效，不能直接用于当前决策。
下一步动作：按差集补扫，而不是重跑全量
如果已完成结果字段完整、差集明确，优先补扫差集部分，并保留原有结果。补扫时把并发调低一档，减少再次中断的概率。补扫完成后，把新旧结果合并去重，再统计覆盖范围。如果已完成结果字段不完整，或者无法确认中断时页面版本，则应重新全量扫描，并把任务配置为分段落盘，确保下次中断后仍有可核对的中间文件。
无论选择哪种方式，最终交付给其他角色时应写明三件事：已完成检测的URL数量、未覆盖部分的来源、以及结论适用的页面版本。这样覆盖范围就从一句“扫了多少”变成可复核的项目。
