博客推广工具：一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 (compatible; QlyzeBot/1.0; +https://app.qlyze.io/bot)
🔗 /25119f1c015f.html
📄
博客推广工具：一次全站扫描被中断后怎样判断已覆盖范围
扫描中断后，不要用“已完成百分比”或“剩余任务数”判断覆盖范围，而应回到扫描日志里的“最后成功处理对象”和“已提交批次边界”两个锚点。多数推广工具在中断时会保留已写入数据库的批次，但内存中未提交的队列会丢失。判断覆盖范围的关键证据是：能否找到中断前最后一个“已确认写入”的对象标识，以及该标识之后是否还有“已读取但未写入”的记录。如果日志只显示进度条，不显示对象标识，那这次扫描的覆盖范围实际上不可判定，需要重新扫描或改用增量模式。
矛盾现象：进度条停在80%，但结果里只有一半站点有数据
这是博客推广工具全站扫描中断后最常见的矛盾。进度条由前端轮询任务状态得出，它反映的是“任务调度器认为已派发的分片数量”，而不是“已成功解析并落库的博客数量”。中断时，调度器可能已经把最后一批分片标记为“已派发”，但执行器还没处理完就退出了。于是进度条显示接近完成，数据库里却缺了尾部数据。
另一个来源是去重逻辑。推广工具通常按域名或博客ID去重，如果中断发生在去重表写入之后、结果表写入之前，进度条会前进，结果表却不会增加记录。这两种情况都会让“进度”和“覆盖”脱节。
两种解释：中断发生在“读取阶段”还是“写入阶段”
要判断覆盖范围，先区分中断点落在哪个阶段。
- 读取阶段中断：工具还在抓取或请求博客页面，尚未生成可落库的记录。此时已覆盖范围等于中断前成功返回并解析的对象集合。日志里通常有“请求成功/失败”计数，但失败不等于未覆盖，因为失败对象可能被重试队列接管，而重试队列在中断后是否持久化，取决于工具实现。
- 写入阶段中断：工具已经读取并解析完一批对象，正在批量写入数据库或导出文件。此时已覆盖范围等于“已提交事务”的对象集合。未提交的部分即使已经解析，也不会出现在结果里。
这两者的区别决定了你下一步该补扫全部，还是只补扫尾部。判断依据不是进度条，而是日志中是否有“commit”“batch written”“flush”之类的落库确认记录。
区分解释的证据：找“最后成功写入”的对象标识
打开扫描日志或任务详情，按时间倒序查找最后一条包含对象标识的成功记录。对象标识可能是博客URL、站点ID或域名。找到它之后，做两件事：
- 在结果表或导出文件中搜索这个标识，确认它确实存在。如果存在，说明该对象之前的数据大概率已落库；如果不存在，说明日志的“成功”只代表读取成功，不代表写入成功，覆盖范围要往前推一个批次。
- 查看该标识之后是否还有“已读取”记录。如果日志显示后续对象被读取但结果表中没有，说明中断发生在写入阶段，且尾部批次丢失。
一个假设例子：某次扫描按站点ID顺序处理，日志最后一条成功写入是ID 4200，结果表中最大ID也是4200，但日志里还有ID 4201到4250的“已读取”记录。这说明覆盖范围到4200为止，4201之后需要补扫。如果结果表中最大ID是4150，而日志最后成功写入是4200，则说明4200所在批次未提交，覆盖范围实际到4150。
这个动作的结果直接决定下一步：覆盖范围连续且尾部明确时，用增量补扫；覆盖范围出现空洞时，不能只补尾部，要按对象标识区间重新扫描。
另一个可核对证据：批次边界与去重表状态
如果工具支持查看批次记录，检查最后一个“已完成”批次的边界。批次通常按固定数量或固定时间窗口划分。中断时，最后一个批次可能处于“部分写入”状态。此时去重表里可能已经写入了这批对象的标识，但结果表没有对应记录。这会造成一个反常结果：重新扫描时，工具认为这些对象“已处理”，直接跳过，导致永久缺失。
核对方法是：对比去重表和结果表的对象数量差。如果差值等于最后一个批次的预期大小，说明中断导致去重表超前于结果表。此时需要手动清除该批次的去重记录，或强制工具对该区间重新处理。如果差值远大于一个批次，说明中断前就有写入不一致，覆盖范围不可信，应放弃本次扫描结果。
什么时候可以接受“不完整覆盖”
如果扫描目的只是发现新博客或抽样估算推广面，尾部缺失可能不影响决策。但前提是：缺失部分不集中在特定类型站点。检查方法是按域名后缀、博客平台或语言分组，看缺失对象是否集中在某一类。如果集中在某一类，说明中断可能与该类站点的响应超时有关，覆盖偏差会直接影响结论。
反之，如果扫描用于全量外链机会盘点或竞品博客库建设，任何尾部缺失都意味着数据不完整，应重新扫描或补扫到明确边界。具体工具是否支持断点续扫、是否保留未提交队列，需要核对你所使用工具的当前文档和实际日志行为，不能假定所有推广工具都一致。
