先看中断时正在处理的那一条记录,再结合已产出的结果文件、日志和扫描队列,把“已覆盖”拆成可核对的三类:已写入结果、已请求但未写入、未请求。不要用“扫描到一半”这种模糊说法,也不要仅凭结果条数推断覆盖率。下面以你手头的一份扫描结果文件和一个中断日志为对象,逐步把它变成可执行的补扫方案。
全站扫描通常有三层状态:待处理队列、已发出请求、已写入结果。中断可能发生在任意一层,不同层对应的覆盖判断完全不同。
实际动作:打开中断日志,找到最后一条成功写入的记录和最后一条发出的请求。如果两者之间有明显间隔,说明中断发生在写入层或请求层,结果文件会低估覆盖范围。这个判断直接决定下一步是补扫还是重扫。
单一信号容易误判,建议同时核对以下三项,并记录各自的数量和边界。
假设一个场景:你有一份包含1000个页面的站点清单,扫描中断后结果文件有420条唯一记录,日志显示已发出请求510条,队列剩余490条。这里420和510之间的90条差异,就是“已请求但未确认写入”的部分。这90条需要优先核对,而不是直接算作已覆盖或未覆盖。这个假设只用于说明比较方法,实际数字以你的日志为准。
如果三项信号无法对齐,优先相信日志中的请求记录,因为结果文件可能因缓冲未刷新而丢失尾部数据。但日志本身也可能不完整,所以需要保留原始清单作为基准。
多个角色对“覆盖了多少”有不同理解时,通常是因为各自看的信号不同。运营看结果条数,技术看日志,负责人看队列剩余。把分歧拆成下面这张核对表,每人填自己掌握的部分,再合并。
实际动作:让每个角色只填自己直接掌握的那一列,不推测其他列。合并后如果“已写入+已请求未写入+未请求”不等于基准清单总数,说明有一列重复计算或遗漏,需要回到日志逐条核对。这个动作的结果会直接告诉你补扫范围是“仅未请求”还是“未请求+已请求未写入”。
判断已覆盖范围之后,下一步是决定补扫策略。两种选择成立的条件不同:
选择依据不是“哪个更快”,而是“已请求未写入的条目能否被安全地单独重试”。如果无法确认,重扫中断批次更稳妥。这个决定会影响下一步:只补扫未请求部分时,你需要一份精确的未请求清单;重扫中断批次时,你需要一份中断批次的完整清单和去重规则。
按以下顺序操作,可以避免反复中断导致状态混乱:
如果补扫再次中断,重复上述顺序,但基准清单不变,只更新已请求和已写入部分。这样每次中断后都能从上次的核对点继续,而不是从头推断覆盖范围。最后一步的比对结果如果仍不相等,说明基准清单本身可能包含重复或无效条目,需要先清理基准清单再继续。