群发推广软件一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /5fdd470a663d.html
📄
群发推广软件一次全站扫描被中断后怎样判断已覆盖范围
直接回答：中断后不要靠“感觉已经扫了大半”来下结论，而要把扫描对象拆成可枚举的清单，用已完成记录与清单的比对来界定覆盖范围。判断依据不是进度条停在哪，而是哪些目标有可核对的完成凭证。
先把“全站”还原成可枚举的清单
“全站扫描”在不同角色嘴里含义不同：运营说的是全部落地页，技术说的是全部可抓取路径，审核说的可能是全部对外可见内容。分歧的根源是没人把范围写成清单。你可以先做一步实际动作：把站点地图、栏目导航、历史导出记录三处来源合并去重，得到一份带唯一标识的目标清单。这份清单就是后续所有判断的基准，谁对覆盖范围有异议，都回到这份清单上核对，而不是争论进度条。
清单确定后，给每个目标标记状态：已完成、未开始、状态不明。中断时最危险的不是“未开始”，而是“状态不明”——扫描器可能已经访问但没写回结果，也可能根本没轮到。把状态不明单独列出，是判断覆盖范围的起点。
用完成凭证而不是进度百分比界定边界
进度百分比通常按已处理条数除以总条数计算，但中断时这个分母可能本身就不准。更可靠的做法是看完成凭证：每个已完成目标是否有独立的结果记录，记录里是否包含目标标识、处理时间和结果摘要。满足这三项，才能计入已覆盖。
假设一份清单有 500 个目标，中断时进度条显示 62%，但导出记录只有 240 条，且其中 30 条缺少目标标识。那么可确认的覆盖是 210 条，而不是 310 条。这个假设说明的是比较方法：用可核对记录数替代百分比推算，差值部分归入状态不明，等待补扫或人工确认。动作上，先导出中断前的全部记录，按目标标识去重，再与清单做左连接，得到三张表：已匹配、未匹配、重复或异常。
把角色分歧转成可核对的对照项
当运营说“主要页面都扫过了”、技术说“只跑了一半”时，双方其实在说不同的对象。把分歧转成核对项可以这样做：
- 列出双方各自认为已覆盖的目标，逐条对照唯一标识。
- 对只有一方认领的目标，检查是否存在完成凭证。
- 对双方都不认领的目标，直接归入未覆盖。
- 对双方都认领但凭证缺失的目标，标记为待复核，不提前计入覆盖。
这一步的结果会直接影响下一步：如果状态不明的目标集中在某个栏目，补扫就按栏目粒度重跑，而不是整站重来；如果状态不明分散且无规律，说明中断点不可靠，整站重扫更省事。取舍依据是补扫成本与遗漏风险的比较，而不是谁的说法更有道理。
决定补扫还是重扫的判断条件
两种选择都成立，取决于条件：
- 补扫成立：状态不明目标数量少、集中在少数栏目、且清单稳定不变。此时按未匹配清单重跑，成本低，结果可与已有记录合并。
- 重扫成立：状态不明目标占比高、分散、或扫描期间清单本身发生过变更。此时已有记录的时间基准不一致，合并会产生误导，整站重扫反而更干净。
还有一个常被忽略的信号：如果中断原因是目标侧限流或超时，那么“已完成”的记录也可能是在异常状态下产生的，需要抽样复核结果质量，而不是只看有没有记录。请求量或抓取量归零，既可能是任务真的停了，也可能是目标侧拒绝响应、记录写入失败或统计延迟，不能单独作为覆盖判断的依据。
把结论写成可复查的覆盖说明
最终交付不该是一句“大概扫了六成”，而是一份覆盖说明，至少包含：清单来源与去重规则、已确认覆盖的目标数、状态不明的目标数及分布、补扫或重扫的选择及理由、以及复核方式。这样下次中断时，任何人拿到这份说明都能重新核对，而不是重新争论。动作上，把这份说明与导出记录放在同一目录，注明生成时间，作为下一次扫描的对照基线。
