推广工具一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /fa7d8c945fa0.html
📄
推广工具一次全站扫描被中断后怎样判断已覆盖范围
先给结论：中断后不要问“扫描完了多少”，而要问“哪些对象已经被确认处理过、哪些对象的状态未知”。判断覆盖范围最可靠的做法，是把扫描进度从“百分比”换成“对象清单加状态标记”，再用可复核的证据区分“真的没扫到”和“扫到了但结果没落盘”。
矛盾现象：进度条停在八成，两个人却得出相反结论
假设一个团队用推广工具做全站扫描，中途因网络或进程中断。甲看进度条停在约八成，认为大部分页面已经覆盖；乙抽查几个链接发现没有记录，认为基本等于没扫。两种判断都缺少同一个东西：被扫描对象的逐条状态。
进度条通常只反映任务推进的粗略阶段，它可能按批次计数、按队列长度估算，也可能在写入结果之前就先跳进。因此进度数字和实际落盘结果之间可以出现偏差。把进度当覆盖，是把“过程信号”当成了“结果证据”。
两种解释：中断发生在处理前，还是发生在写入前
中断导致的“没结果”，至少有两种成立条件不同的原因。
- 解释一：对象尚未被处理。任务在队列中排队时中断，这些对象从未进入扫描逻辑，自然没有任何记录。此时覆盖范围确实止于中断点之前。
- 解释二：对象已被处理，但结果未持久化。扫描动作已完成，结果停留在内存或临时批次里，中断时未写入最终存储。此时对象其实被“看过”，只是证据丢了。
这两种解释对应完全不同的下一步：前者需要重扫，后者只需补写或重放结果。如果不加区分就整体重扫，可能重复消耗资源；如果误以为都已覆盖，则会留下空洞。
能区分两种解释的证据
关键证据是“处理痕迹”与“结果记录”是否分离存在。
- 日志时间戳与对象标识。如果日志里能看到某对象被取出的记录，但没有对应的结果行，更倾向解释二；如果连取出记录都没有，更倾向解释一。
- 批次边界。检查最后一个完整写入的批次编号，以及中断时正在处理的批次。批次内已处理未写入的部分，正是需要补的范围。
- 结果存储的写入顺序。若结果按批次整体提交，中断往往丢失整个当前批次；若逐条提交，丢失范围会小得多。
- 可重复的抽样核对。对边界附近的对象做一次小范围重跑，比较新旧结果是否一致。一致说明原对象很可能已处理，只是记录缺失。
这里要注意：请求量或抓取量突然归零，不能单独证明任务已正确停止或已完整覆盖。它也可能是限流、网络中断或队列耗尽的正常表现。把单一指标当作结论，容易误判。
把分歧转成可核对的项目：一个假设例子
假设某次扫描涉及一千个对象，中断时进度显示约八成，但结果存储里只有六百条记录。团队两人争执不下。此时可以建立一个核对表，而不是继续争论：
- 已确认处理且有结果：直接计入覆盖。
- 已确认处理但无结果：标记为“需补写”，不必重扫。
- 未确认处理：标记为“需重扫”。
- 状态无法判断：单独列出，用抽样重跑确认。
具体动作是：先导出结果存储中已有的对象标识，再与全站对象清单做一次比对，得到“有结果”和“无结果”两个集合；然后拿“无结果”集合去日志里找处理痕迹，进一步拆成“需补写”和“需重扫”。这个动作的结果直接决定下一步：需补写的部分只补记录，需重扫的部分才重新执行扫描。覆盖范围由此从一句主观判断，变成一张可逐条核对的清单。
判断覆盖范围时的适用条件
上述方法成立的前提是：工具能导出对象级的结果标识，且日志保留到中断时刻。如果结果只提供汇总数字、日志已滚动覆盖，就只能退回到抽样核对，覆盖结论的精度会下降。此时更稳妥的做法是缩小重扫范围，而不是宣称全站已覆盖。
不同推广工具在结果存储方式、日志粒度和导出能力上差异很大，具体能导出什么字段、日志保留多久，需要以你实际使用的工具当前说明为准。判断覆盖范围的核心始终不变：用对象级状态代替进度百分比，用可复核证据代替角色间的口头结论。
