WordPress插件一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e89eb872d946.html
📄
WordPress插件一次全站扫描被中断后怎样判断已覆盖范围
扫描中断后，不能把“页面列表里有多少条记录”直接当成已覆盖范围。更可靠的做法是：先找到插件在本次任务中留下的进度标记，再用“已处理对象数 + 最后成功时间 + 跳过原因”三项交叉判断。只有这三项能互相印证时，才适合继续在原任务上追加扫描；否则应缩小范围重新扫描，而不是盲目重跑全站。
先分清中断发生在哪一层
WordPress插件执行全站扫描时，通常要跨过三个层次：数据库查询、远程请求、结果写入。中断原因不同，已覆盖范围的判断方式也不同。
- 数据库查询中断：已覆盖范围通常等于最后一批成功写入的记录，未写入的批次一般可以安全重扫。
- 远程请求中断：部分对象可能已发出请求但未收到结果，这类对象既不算已覆盖，也不能直接算失败，需要单独列出。
- 结果写入中断：请求可能已完成，但结果没有落库。此时已覆盖范围要以写入记录为准，而不是以请求日志为准。
如果插件只提供一个“已扫描 N 条”的计数，而没有时间戳和状态字段，这个数字只能当参考。因为它无法区分“处理成功”“请求已发出但结果未知”“因超时被跳过”这三种情况。
用三个证据交叉确定覆盖边界
判断已覆盖范围时，建议按下面顺序核对，任何一项缺失都要降低结论的确定性。
- 最后成功写入的时间戳：把任务开始时间到该时间戳之间的对象视为候选已覆盖区间。时间戳之后的对象状态未知。
- 对象标识是否连续：如果插件按 ID 或分页游标推进，检查已写入的标识是否连续。出现空洞说明中间有跳过或写入失败。
- 跳过原因分类：把“无内容可扫”“请求超时”“权限不足”“格式不支持”分开统计。只有“无内容可扫”可以视为已覆盖；其余都算未完成。
假设一次扫描计划处理 500 个对象，中断时写入记录显示已处理到第 320 个，但其中 40 个标记为“请求超时”。那么已覆盖范围不是 320，而是 280 个确定完成的对象；那 40 个需要重新处理。这个例子说明，计数必须扣除不确定项，否则后续决策会建立在偏大的覆盖范围上。
保留、改写还是退出：先看覆盖缺口落在哪
扫描中断后是否继续保留原有内容或合作关系，取决于缺口集中在哪一类对象上。
- 缺口集中在低价值对象：如果未覆盖的多是空页面、重复内容或已失效条目，可以保留已覆盖部分的结果，直接进入改写或退出决策，不必补扫全站。
- 缺口集中在核心对象：如果未覆盖的包含主要栏目、主要合作方或关键内容类型，已覆盖部分的结论不足以代表全站，应先补扫这些对象再判断。
- 缺口无法定位：如果插件没有留下可核对的标识或时间戳，只能缩小范围重新扫描。此时把旧结果用于保留或退出决策，风险较高。
一个实际动作是：先导出已写入记录的对象标识列表，再与站点对象总表做差集。差集就是未覆盖范围。如果差集里核心对象占比高，下一步应补扫差集；如果差集里几乎都是边缘对象，下一步可以直接对已覆盖部分做取舍评估。
重新扫描时怎样避免再次中断
如果决定补扫，不要直接重跑全站。更稳妥的方式是分批执行，并让每批结束后写入进度标记。
- 把扫描范围按对象类型或时间区间拆成小批，每批完成后记录批次标识和结束时间。
- 对“请求超时”类对象单独设一个重试队列，避免它们反复拖慢主流程。
- 在插件允许的情况下，把扫描和结果写入分开：先确认请求完成，再确认写入成功，两个状态都记录。
这样做的结果是：下一次中断时，已覆盖范围可以直接从批次标记读出，不需要再靠推测。如果插件本身不提供这些标记，就需要在外部记录每批的起止对象，或者改用支持断点续扫的替代方案。具体某个插件是否支持断点续扫、如何配置批次大小，需要以该插件当前版本的文档和实际界面为准。
什么时候可以不再补扫
补扫不是必须完成全站才算结束。出现以下条件时，可以停止补扫并进入保留或退出决策：
- 未覆盖对象经过抽样核对，确认与已覆盖对象属于同一类型，且不改变整体结论。
- 未覆盖对象的数量占比很小，且集中在可单独处理的边缘范围。
- 继续补扫的代价已经超过重新建立一份新范围的成本。
但要注意：请求量、抓取量或扫描计数归零，并不能单独证明覆盖已经完成。它也可能是任务被提前终止、写入失败或统计口径变化造成的。要结合时间戳和对象标识一起看，才能判断覆盖边界是否真的闭合。只有证据链能互相印证时，把已覆盖结果用于保留、改写或退出才是稳妥的。
