在线推广软件：一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0063b648a38f.html
📄
在线推广软件：一次全站扫描被中断后怎样判断已覆盖范围
中断后不要重新跑一遍全站扫描来求心安，先把“扫描任务日志”和“实际产出记录”分开看。判断已覆盖范围，靠的是任务已处理到哪个边界、产出里有哪些可验证结果，而不是靠扫描进度条。若日志只显示“已扫描约60%”，这既可能表示按URL顺序推进到六成，也可能表示按分片并行、各部分完成度不一，需要进一步用产出反推。
先分清三种“中断点”，覆盖范围的含义完全不同
第一种是任务级中断：扫描进程停止，日志停在某个时间戳。此时覆盖范围大致等于“中断前已写入产出记录的那部分”，未写入的即使进程处理过，也无法在后续判断中当作已覆盖。
第二种是数据源级中断：扫描仍在跑，但某个数据源（如站内链接表、历史导出文件、第三方接口）返回不完整。这时覆盖范围要按数据源分别计算，不能把“任务完成”当成“全量覆盖”。
第三种是解析级中断：页面抓到了，但解析规则在中途报错，产出里出现大量空字段。此时“已抓取”不等于“已覆盖”，需要按字段完整度重新划定有效范围。
实际操作上，可以先从产出记录里抽出最后一条成功写入的时间戳和标识，再与任务日志的停止时间对比。如果两者接近，说明覆盖范围大致可信；如果产出明显早于停止时间，说明中间有一段处理未落盘，不能算已覆盖。
用产出反推覆盖范围：三个可验证的证据
第一个证据是产出记录里的主键连续性。假设扫描对象是站内URL，产出表里若存在从A到M的连续记录，而N之后缺失，可以初步判断覆盖到M附近。但要注意，如果扫描本身是按分片并行，主键连续并不代表时间顺序，缺失也可能只是分片未完成，而不是整体未覆盖。
第二个证据是分片或批次标记。很多扫描工具会按批次写入状态字段，例如batch_status为“完成”“部分”“未开始”。统计各批次状态，比看总进度条更能说明覆盖范围。若某个批次标记为“部分”，该批次内的对象只能算部分覆盖。
第三个证据是抽样复核。从已产出记录中随机抽一小批对象，用独立方式（如手动访问、另一份导出文件）核对是否与产出一致。如果抽样一致率高，可以认为已覆盖部分可信；如果一致率低，说明产出本身有问题，覆盖范围需要重新界定。
这三个证据不必全部满足。通常先看批次标记，若标记清晰，可直接据此划定范围；若标记缺失，再用主键连续性和抽样复核交叉验证。
保留、改写还是退出：按覆盖范围决定下一步
如果已覆盖范围集中在旧内容或旧合作关系，且产出里这些对象的状态字段完整，可以选择保留并进入改写流程。适用前提是：这些对象仍然有业务价值，且改写成本低于重新扫描和重新建立关系的成本。
如果已覆盖范围里混有大量解析失败或字段缺失的对象，直接改写风险较高，因为你不确定缺失字段是否影响判断。此时更稳妥的动作是先对这部分做一次小范围重扫，只补缺失字段，而不是全站重跑。重扫结果会告诉你：缺失是偶发中断造成的，还是解析规则本身不适用于这批对象。如果是后者，改写前需要先调整规则。
如果已覆盖范围对应的旧系统或旧合作关系已经确定要退出，那么覆盖范围是否完整只影响退出时的清理清单，不影响退出决策本身。此时可以把已覆盖部分作为“已知可清理”的基线，未覆盖部分单独列一份待确认清单，避免把未确认对象直接当作不存在。
假设一个场景：某次全站扫描中断后，产出记录显示旧落地页A到F已完整写入，G到J只有标题没有正文，K之后无记录。若这批旧落地页仍计划保留，那么A到F可以进入改写队列，G到J需要先补正文再判断，K之后需要重新扫描或手动确认。这个划分动作会直接影响后续工作量估算：改写队列的大小取决于G到J的补全结果，而不是取决于最初的总数。
中断后不要直接全量重跑的两个理由
全量重跑看似省心，但会覆盖掉中断前已产出的记录，导致你失去判断“哪些是第一次已覆盖、哪些是第二次新覆盖”的对照依据。如果后续需要区分旧数据和新数据，这个对照依据很重要。
另一个理由是，全量重跑可能重复消耗数据源配额或触发不必要的请求。若中断原因是数据源限流，直接重跑可能再次中断，反而拖长确认时间。更合适的动作是先补跑未覆盖部分，再根据补跑结果决定是否需要全量重跑。
判断已覆盖范围的核心不是追求一个精确百分比，而是得到一份可执行的清单：哪些对象可以直接进入下一步，哪些需要补数据，哪些需要重新确认。这份清单越具体，后续保留、改写或退出的取舍就越有依据。若清单里仍有大量“状态不明”的对象，说明覆盖范围尚未确认，此时不宜直接进入改写或退出执行阶段。
