软件营销技巧：一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /5a5b81141500.html
📄
软件营销技巧：一次全站扫描被中断后怎样判断已覆盖范围
扫描被中断后，不能凭“跑了多久”或“扫到多少条”直接判断覆盖范围，而要先把中断原因、任务日志和已抓取清单三者对齐。如果中断发生在任务启动阶段，已覆盖范围通常接近零，应重跑；如果中断发生在抓取中途且日志完整，可以按已确认的页面清单做增量补扫，而不是整站重来。两种选择的分界点是：已抓取记录能否与目标页面集合逐条对应。
先分清两种中断条件，再决定重跑还是补扫
判断覆盖范围的第一步不是看数量，而是看任务是否留下了可核对的抓取记录。可以按以下两种条件区分：
- 条件一：日志只有任务开始与结束时间，没有逐页状态。此时已覆盖范围不可核对，只能视为未完成。合理动作是重新发起全站扫描，并让工具输出逐页结果。若继续在旧结果上补扫，很可能重复抓取同一批页面，却漏掉中断点之后的页面。
- 条件二：日志包含逐页状态，能区分成功、失败、跳过。此时可以把成功与失败分开处理：成功页面计入已覆盖，失败页面进入待补扫清单，跳过页面单独核对原因。合理动作是先补扫失败与未抓取部分，再抽样验证成功页面是否真的解析到了目标字段。
这两种条件对应的是不同的下一步。前者需要重建任务，后者需要维护一张待补扫清单。把两者混在一起，就会出现“看起来扫完了，实际只覆盖了一半”的误判。
用目标页面集合反推覆盖范围，而不是用抓取数量
抓取条数本身说明不了覆盖范围，因为同一页面可能被重复抓取，分页、参数页和重定向页也会让条数虚高。更可靠的做法是先确定目标页面集合，再与已抓取记录做差集。
假设一个用于说明比较方法的短例子：某站点有 500 个需要检查的页面，中断前日志显示成功 180 条、失败 20 条、跳过 40 条，合计 240 条。此时不能认为覆盖了 240/500，因为跳过的 40 条可能是重复 URL 或非目标页面。正确动作是先把 240 条按 URL 去重，再与 500 条目标集合比对，得到真正未覆盖的页面数。这个差集才是补扫的范围。如果去重后未覆盖页面接近全部，说明中断发生得很早，重跑比补扫更省事；如果未覆盖页面集中在某几个目录，补扫这几个目录即可。
这一步的实际影响是：它决定了后续是整站重跑还是定向补扫，也决定了是否需要重新校验已成功页面的字段完整性。
把角色分歧转成可核对的项目
多个角色对“扫了多少”有不同理解时，争论通常来自各自看的是不同口径：有人看任务状态，有人看导出条数，有人看页面样本。与其反复解释，不如把分歧转成三个可核对的项目：
- 目标页面清单：谁定义、依据什么规则、是否包含分页与参数页。
- 已抓取记录：是否逐页、是否含状态码、是否含抓取时间。
- 差异清单：未抓取、抓取失败、抓取成功但字段为空，分别列出 URL。
完成这三项后，分歧会从“覆盖了多少”变成“哪些 URL 还没覆盖”。这是一个可以分配、可以验收的项目列表，而不是一个无法验证的百分比。
需要说明的例外是：如果工具本身不提供逐页记录，或导出内容被截断，那么上述差异清单无法完整建立。此时应把结论限定为“覆盖范围不可确认”，并在下一次扫描时先解决记录粒度问题，而不是用不完整的数据做决策。
补扫之后必须做一次抽样验证
补扫完成不等于覆盖正确。中断可能导致部分页面被抓取但解析不完整，例如标题、链接或结构化字段缺失。合理动作是从成功页面中按目录或模板分层抽样，人工核对若干条记录与页面实际内容是否一致。如果抽样发现字段缺失集中在某个模板，说明该模板的解析规则需要调整，补扫范围也要相应扩大；如果抽样一致，才可以把已覆盖范围作为后续分析的基础。
这里的判断依据是抽样结果与页面实际内容的一致性，而不是抓取总量。总量归零或数量异常都不能单独证明处理正确，它也可能来自任务配置变更、访问被限制或导出过滤条件变化，需要结合日志一起看。
把结论写成可交接的状态说明
最终要留下的不是一句“扫描中断了”，而是一份可交接的状态说明：目标页面总数、已确认覆盖数、未覆盖清单、失败原因分类、补扫动作和验证结果。这样下一个执行者不需要重新推断覆盖范围，可以直接从差异清单继续。若目标页面集合本身发生变化，例如新增了目录或页面模板，则原覆盖结论只对旧集合成立，需要重新计算差集后再决定是否补扫。
