百度推广查询，全站扫描中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9f0dd3535811.html
📄
百度推广查询，全站扫描中断后怎样判断已覆盖范围
先看中断时正在处理的那一条记录，再结合已产出的结果文件、日志和扫描队列，把“已覆盖”拆成可核对的三类：已写入结果、已请求但未写入、未请求。不要用“扫描到一半”这种模糊说法，也不要仅凭结果条数推断覆盖率。下面以你手头的一份扫描结果文件和一个中断日志为对象，逐步把它变成可执行的补扫方案。
先确定中断发生在哪一层
全站扫描通常有三层状态：待处理队列、已发出请求、已写入结果。中断可能发生在任意一层，不同层对应的覆盖判断完全不同。
- 队列层中断：待处理列表还在，但请求没有全部发出。此时已覆盖范围等于结果文件中的记录，加上日志里标记为“已请求”但尚未写入的部分。
- 请求层中断：请求已发出但响应未返回或未落盘。这部分既不算已覆盖，也不能直接重扫，需要先确认是否有重复请求风险。
- 写入层中断：结果已返回但写文件失败。此时覆盖范围要以日志中的请求记录为准，而不是以结果文件为准。
实际动作：打开中断日志，找到最后一条成功写入的记录和最后一条发出的请求。如果两者之间有明显间隔，说明中断发生在写入层或请求层，结果文件会低估覆盖范围。这个判断直接决定下一步是补扫还是重扫。
用三个可核对信号交叉验证覆盖范围
单一信号容易误判，建议同时核对以下三项，并记录各自的数量和边界。
- 结果文件中的唯一标识数量：比如URL、页面ID或查询词条。去重后计数，作为已覆盖的下限。
- 日志中标记为已请求的记录：如果日志按批次记录，找出最后完整批次和中断批次，中断批次内逐条核对。
- 扫描队列的剩余量：如果队列支持持久化，读取剩余条目；如果不支持，只能从原始站点清单减去已请求部分。
假设一个场景：你有一份包含1000个页面的站点清单，扫描中断后结果文件有420条唯一记录，日志显示已发出请求510条，队列剩余490条。这里420和510之间的90条差异，就是“已请求但未确认写入”的部分。这90条需要优先核对，而不是直接算作已覆盖或未覆盖。这个假设只用于说明比较方法，实际数字以你的日志为准。
如果三项信号无法对齐，优先相信日志中的请求记录，因为结果文件可能因缓冲未刷新而丢失尾部数据。但日志本身也可能不完整，所以需要保留原始清单作为基准。
把分歧转成可以核对的项目
多个角色对“覆盖了多少”有不同理解时，通常是因为各自看的信号不同。运营看结果条数，技术看日志，负责人看队列剩余。把分歧拆成下面这张核对表，每人填自己掌握的部分，再合并。
- 基准清单：扫描对象的完整列表，注明来源和生成时间。
- 已写入结果：结果文件路径、去重后的唯一标识数、最后写入时间。
- 已请求未写入：日志中最后批次内已发出但结果文件中不存在的标识，逐条列出。
- 未请求：基准清单减去已请求部分，注明是否包含已请求未写入的条目。
实际动作：让每个角色只填自己直接掌握的那一列，不推测其他列。合并后如果“已写入+已请求未写入+未请求”不等于基准清单总数，说明有一列重复计算或遗漏，需要回到日志逐条核对。这个动作的结果会直接告诉你补扫范围是“仅未请求”还是“未请求+已请求未写入”。
补扫前先决定是否重扫已请求部分
判断已覆盖范围之后，下一步是决定补扫策略。两种选择成立的条件不同：
- 只补扫未请求部分：适用于请求本身没有副作用、已请求未写入的条目可以单独重试、且日志能精确给出这些条目的标识。此时补扫范围最小，耗时最短。
- 重扫整个中断批次：适用于请求有副作用（比如会计入调用次数或改变远端状态）、日志无法精确区分已写入和未写入、或者结果文件可能包含部分写入的脏数据。此时重扫范围更大，但一致性更容易保证。
选择依据不是“哪个更快”，而是“已请求未写入的条目能否被安全地单独重试”。如果无法确认，重扫中断批次更稳妥。这个决定会影响下一步：只补扫未请求部分时，你需要一份精确的未请求清单；重扫中断批次时，你需要一份中断批次的完整清单和去重规则。
中断后的核对顺序与记录方式
按以下顺序操作，可以避免反复中断导致状态混乱：
- 冻结当前结果文件和日志，复制一份用于核对，不在原文件上继续写入。
- 从日志中提取最后完整批次和中断批次的边界，记录批次编号或时间戳。
- 用基准清单减去已请求标识，得到未请求清单；再从中断批次中减去已写入标识，得到待确认清单。
- 对待确认清单逐条重试或标记为需重扫，重试结果追加到新结果文件，不覆盖旧文件。
- 补扫完成后，用“新结果唯一标识数+未请求清单剩余数”与基准清单总数比对，确认没有遗漏。
如果补扫再次中断，重复上述顺序，但基准清单不变，只更新已请求和已写入部分。这样每次中断后都能从上次的核对点继续，而不是从头推断覆盖范围。最后一步的比对结果如果仍不相等，说明基准清单本身可能包含重复或无效条目，需要先清理基准清单再继续。
