外链生成工具一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7a15c02117a0.html
📄
外链生成工具一次全站扫描被中断后怎样判断已覆盖范围
中断后不要凭扫描时长或进度条估算覆盖范围：先看工具是否留下可复核的断点记录（已处理对象清单、最后完成的目标标识、失败队列），再用小样本回扫验证断点前后的一致性。若断点记录完整且回扫结果吻合，可以保留已覆盖部分并续跑剩余队列；若记录缺失或回扫出现大量不一致，应把该次结果整体降级为参考，重新划定扫描范围后再执行。
先分清中断发生在哪一层，决定保留还是重跑
外链生成工具的全站扫描通常跨三个层次：目标发现（从站点结构或入口清单里找出待处理对象）、外链获取（对每个对象抓取或调用接口）、结果落库（写入可导出的记录）。中断发生在不同层，覆盖范围的判断方式完全不同。
- 如果中断在目标发现阶段，已覆盖范围本身就不完整，后续获取再顺利也缺对象，此时应重跑发现，而不是续跑。
- 如果中断在获取阶段且落库是逐条写入，已写入的记录通常可用，缺的是未处理队列。
- 如果落库是批次提交，中断可能导致整批回滚，已抓取但未提交的部分等于没覆盖，需要按批次边界重跑。
判断依据不是工具界面显示了多少百分比，而是能否导出“已处理对象标识”列表并与原始目标清单做差集。差集能对上，覆盖范围才可确认。
用断点记录和回扫样本交叉验证覆盖边界
假设一次扫描目标为一批页面，中断前工具记录了最后完成的页面标识和失败队列。可执行的动作是：从已完成清单中随机抽少量对象重新扫描一次，同时从失败队列中抽少量对象单独执行。结果分三种情况处理。
- 回扫的已完成对象结果与首次记录一致，失败对象可正常处理：说明断点记录可信，保留已覆盖部分，只补跑失败队列和未开始部分。
- 回扫的已完成对象出现较多缺失或结构变化：说明首次扫描期间目标本身在变动，或工具写入不完整，已覆盖范围不可直接沿用，应缩小到稳定子集后重跑。
- 失败对象再次失败且原因相同：属于目标侧问题（如访问受限、对象不存在），不应算作未覆盖，而应单独标记为不可获取，避免无限重试。
这里的假设是工具支持按对象标识单独执行。如果工具只支持整站重跑，那么“保留已覆盖部分”这个选项实际不成立，只能在退出与全量重跑之间取舍。
保留、改写、退出三种取舍各自成立的前提
保留适用于：断点记录可导出、落库为逐条写入、回扫样本一致、且剩余队列能单独续跑。此时续跑的成本明显低于全量重跑，覆盖范围以“已完成清单 + 续跑结果”合并计算。
改写适用于：断点记录部分可用，但目标清单在中断前后发生了变化。做法是把扫描范围改成带时间边界的子集，例如只处理某个目录或某类对象，让覆盖范围有明确口径，而不是笼统宣称全站已覆盖。
退出适用于：工具不提供断点续跑、不提供已处理标识导出，或回扫样本与首次结果大面积不一致。继续在同一批结果上叠加只会让口径更混乱，此时重新规划扫描范围比修复旧结果更省事。
别把请求量归零或进度停滞当成覆盖完成的证据
中断后如果发现后续请求量归零，这只能说明扫描没有继续发出请求，不能说明已覆盖范围正确。请求量归零的合理解释至少包括：队列已空、任务被暂停、目标侧限流、工具进程退出、落库失败导致重试被跳过。这些原因对应的覆盖范围完全不同。
同样，进度条停在某个数值也不代表该数值之前的对象都已完整处理，批次提交模式下未提交的部分不会体现在进度里。要区分这些原因，需要看失败队列、落库记录和进程日志三类证据是否互相吻合，而不是只看单一指标。
续跑前先固定口径，再决定下一步动作
无论选择保留还是改写，续跑前都应先固定三件事：本次覆盖的对象范围（用标识清单而非数量描述）、未覆盖部分的处理方式（续跑、重跑还是标记为不可获取）、以及结果导出时的字段口径。固定口径后，如果续跑结果与已完成部分能按同一标识合并，就可以进入结果复核；如果合并时出现重复或冲突记录，说明两次执行的边界不一致，应回到范围划定这一步重新处理。这个动作的结果直接决定后续是继续补跑，还是把整批结果退回为参考数据。
