自动推广软件：一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /88e44fb25f24.html
📄
自动推广软件：一次全站扫描被中断后怎样判断已覆盖范围
先给结论：中断后不要凭“跑了多久”估算覆盖范围，而要把扫描记录、站点清单和未处理队列三份证据对齐，判断哪些页面已经过处理、哪些只是被访问过、哪些根本没进入队列。只有能区分这三种状态，后续补扫才不是重跑一遍。
先分清“访问过”“处理过”“写入结果”是三种状态
自动推广软件在扫描阶段通常会留下日志或任务记录，但日志里的“已请求”不等于“已分析”。假设一个情境：某站点约两千个可抓取页面，扫描进行到中途因网络或额度限制被中断，日志显示已请求一千二百个。这个数字只能说明请求发出过，不能直接当作覆盖范围。
可核对的状态至少有三层：
- 已请求：软件向该地址发起了访问，但可能超时、被拦截或返回异常状态。
- 已处理：返回内容被成功解析，页面标题、链接、可推广元素等字段已生成。
- 已写入结果：处理结果落到了最终报表或待办清单里，能被后续步骤引用。
判断覆盖范围时，以“已写入结果”为准，而不是以“已请求”为准。如果软件只提供请求数，就要用站点自身的页面清单去反推缺口。
用一份站点清单做差集，而不是相信进度条
进度条的百分比通常基于软件自己预估的总量，中断后这个分母可能已经失真。更可靠的做法是准备一份独立于软件的页面清单：从站点地图、栏目页或已有导出文件整理出完整 URL 列表，再与扫描结果做差集。
具体动作可以这样执行：把扫描结果中的 URL 去重后导出，与站点清单逐条比对，得到三类集合——两边都有的、只在扫描结果里的、只在站点清单里的。第三类就是明确的未覆盖范围。这个动作的结果直接决定下一步：如果未覆盖集中在少数栏目，可以只补扫这些栏目；如果未覆盖分散且比例高，说明中断发生在早期，整体重扫更省事。
需要提醒的是，差集只能反映 URL 层面的覆盖，不能反映每个页面内部字段是否完整。若软件支持按字段导出，还应检查关键字段的空值比例。
把分歧转成可核对的项目
多个角色对“扫了多少”有不同理解，往往是因为各自看的是不同层的数据：运营看进度条，技术看请求日志，决策者看最终报表。与其争论，不如把分歧拆成可以逐项核对的问题：
- 这次扫描的目标总量是多少，依据是什么文件？
- 中断时已写入结果的 URL 有多少，去重后是多少？
- 未覆盖的 URL 集中在哪些路径或栏目？
- 已覆盖页面中，关键字段为空的比例是多少？
每个问题都对应一个可导出的数据项。把答案填进同一张对照表，分歧就会从“感觉没扫完”变成“某栏目有若干 URL 未进入结果”。这一步的结果会影响责任划分和补扫范围，而不是停留在印象层面。
中断原因会影响补扫策略，不要一律重跑
中断原因不同，覆盖范围的可靠性也不同。如果是网络超时导致中断，已写入结果的部分通常仍有效，补扫未覆盖部分即可。如果是软件额度或授权限制触发中断，需要先确认剩余额度是否够用，再决定补扫还是等下一周期。
如果是站点侧返回大量异常状态导致中断，那么“已请求”里可能混有大量失败记录，此时覆盖范围要按成功解析的页面重新计算。还有一种情况是软件本身没有持久化任务状态，中断后无法续跑，只能整体重来——这时判断覆盖范围的意义在于确认是否值得换一种分批方式，而不是继续等待恢复。
不同原因对应不同证据：超时看错误码分布，额度限制看用量记录，异常状态看返回状态码。缺少这些证据时，不要仅凭“请求数归零”或“进度条停住”就断定扫描已完全失效，那可能只是界面刷新问题或统计延迟。
补扫前先确认这次判断是否站得住
在启动补扫之前，用一个小样本验证判断：从“未覆盖”集合里抽若干 URL，手动确认它们确实没有出现在结果文件中；再从“已覆盖”集合里抽若干 URL，确认其字段完整。如果抽样发现已覆盖集合里也有大量空值，说明问题不在中断，而在处理环节，补扫同样的范围不会改善结果。
这个验证动作的结果决定下一步方向：抽样通过，按差集补扫；抽样不通过，先排查解析或字段映射问题，再考虑是否重新扫描。覆盖范围的判断只有落到可复核的样本上，才对后续决策有意义。
