友链查询一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /df92d8a8d2f9.html
📄
友链查询一次全站扫描被中断后怎样判断已覆盖范围
先做一件事：不要直接重跑。中断后的覆盖范围不能靠“跑了多久”或“扫了多少条”判断，而要靠持久化记录与目标清单的差集来还原。如果扫描器在中断前把每个已处理域名写入可续跑的日志或结果文件，你就能精确知道边界；如果只存在内存里，那这次扫描的覆盖范围基本无法证明，只能按未覆盖处理。
先分清中断类型，它决定覆盖范围能不能还原
中断大致分三类，对覆盖判断的影响完全不同。
- 进程被杀或崩溃：未落盘的进度丢失，只有已写入文件或数据库的部分可算覆盖。
- 网络或目标站点超时导致扫描自行停止：已完成的条目通常已记录，但停止点附近可能存在“发出请求但未收到响应”的模糊区。
- 主动暂停：如果工具支持断点续跑并已保存游标，覆盖范围最清晰，按游标继续即可。
判断依据不是中断原因本身，而是是否存在可核对的持久化痕迹。没有痕迹时，任何“大概扫了一半”的估计都不能作为决策依据。
用目标清单减已记录清单，得到真实覆盖边界
把这次扫描的输入清单（比如待查的域名或页面列表）导出，再导出结果文件里已经出现的对象，做差集。差集就是未覆盖部分，交集就是已覆盖部分。
- 确认输入清单在扫描期间没有被修改；如果中途加过对象，要按加入时间分段核对。
- 检查结果文件是否按追加方式写入，而不是最后一次性写出。后者在中断时往往为空或残缺。
- 对差集里的对象，标记为“未处理”，不要标记为“无友链”。这两者含义完全不同。
假设一次扫描输入 500 个域名，结果文件里有 214 条完整记录，且文件是逐条追加写入的，那么可判定已覆盖 214 个，剩余 286 个需要补扫。这个数字只是假设示例，用于说明差集方法，不代表任何工具的实际表现。
模糊区要单独处理，不能算作已覆盖
中断点附近常出现一种情况：请求已经发出，但结果没写回。这类对象既不在结果文件里，也无法确认是否被访问过。合理做法是把它们归入“待复核”，而不是直接补扫或直接跳过。
可区分的证据包括：
- 结果文件最后一条记录的时间戳，与中断时间接近，说明边界就在附近。
- 是否存在请求日志；有日志且日志晚于结果文件，说明有已发出但未记录的对象。
- 目标站点是否返回过限流或封禁信号；这类信号会让后续请求大面积失败，使“未覆盖”和“被拒绝”混在一起。
如果发现大量请求被限流，那么覆盖范围的问题就退居其次，先要解决访问条件，否则补扫仍会中断。此时下一步动作应是降低并发或延长间隔，而不是继续扩大扫描量。
保留、改写还是退出：按前提分别决定
保留原结果并补扫差集，适用于结果文件逐条落盘、输入清单稳定、且中断原因已排除。这样做的代价最小，但要求你能信任已有记录的完整性。
改写扫描方式后重跑，适用于结果只在内存中、无法还原边界，或输入清单在扫描期间发生过变化。此时旧结果的参考价值低，继续在残缺数据上补扫会引入难以区分的偏差。
退出这次扫描、改用更小批次，适用于反复中断且原因指向资源限制或目标侧限制。把全站拆成若干可独立完成的小批次，每批结束后立即固化结果，比追求一次跑完更可控。
三种选择的分界不在扫描规模，而在你是否能证明已覆盖部分的边界。能证明就补扫，不能证明就重跑，反复失败就缩小批次。
把覆盖结论写成可复核的记录
无论选择哪条路，都建议留下这样一份简短记录：输入清单版本、结果文件路径、已覆盖数量、未覆盖数量、模糊区数量、中断原因、下一步动作。这样下次中断时，判断依据来自记录而不是记忆。
如果扫描涉及外部服务或具体工具，其日志格式、续跑能力和数据保留方式需要以该工具的实际说明为准，不同版本之间可能存在差异，使用前应自行核对。
覆盖范围判断清楚之后，再决定是否补扫、重跑或缩小批次，才不会把一次中断变成一串无法解释的缺口。
