网站营销软件：一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2d19f67c32c1.html
📄
网站营销软件：一次全站扫描被中断后怎样判断已覆盖范围
先看扫描是否留下了可核对的进度记录。如果软件按URL逐条写入结果表，并且中断时最后一条记录的时间戳、状态码和页面标识都完整，那么已覆盖范围通常可以按“最后成功写入记录”之前的部分来界定，再对边界附近的若干条做抽样复核。如果软件只在内存里累计、结束时才统一写库，中断后往往只能确认“扫描启动过”，不能确认覆盖到哪里，此时应把这次结果视为不完整，重新规划一次可分批续跑的扫描。
中断后的两种常见解释
现象是：扫描进度条停在某个百分比，日志里既有已抓取的URL，也有报错。此时有两种解释。
- 解释一：覆盖范围等于已写入结果的那部分。软件采用逐条落盘或分批提交，中断只影响尚未处理的任务。已写入的记录可以继续用于后续分析，只是边界附近可能缺少几条。
- 解释二：覆盖范围无法从界面进度判断。软件把抓取、解析、写库分成不同阶段，进度条反映的是抓取阶段，而结果表可能滞后。中断后看到的结果数量少于实际抓取数量，或者多于已解析数量，都不能直接当作覆盖范围。
这两种解释对应不同的下一步：前者可以做增量续跑，后者需要先恢复一致性再决定是否重跑。
能区分两种解释的证据
要判断属于哪一种，可以查三类证据，而不是只看进度百分比。
- 结果表的写入方式。查看是否存在自增主键、抓取时间字段或批次号。如果每条记录带独立时间戳，并且时间戳连续递增到中断时刻，说明是逐条落盘，覆盖范围可按时间边界估算。
- 任务队列的剩余状态。如果软件保留待处理队列，中断后队列里还有未完成项，说明已处理项和未处理项可以分开，覆盖范围以已出队并写入的为准。若队列随进程消失，则只能依赖结果表反推。
- 日志与结果表的数量差。把日志中“开始抓取某URL”的行数与结果表中该URL的记录数对比。差距集中在中断前最后一段时间，说明写库滞后；差距散布在整个过程，说明部分页面在解析阶段被丢弃，覆盖范围需要按状态码重新筛选。
一个注明假设的判断例子
假设某次扫描计划覆盖1000个URL，中断时结果表有620条记录，日志显示已发起抓取700次。若结果表每条都带抓取时间，且第620条的时间戳与中断时刻接近，那么可以初步判断已覆盖约620条，剩余约380条未处理。下一步不是直接重跑全部1000条，而是先对第600至620条做抽样，确认这些页面的标题、状态码、关键字段是否完整。如果抽样发现最后20条中有多条字段为空，说明写库发生在解析之前，覆盖范围应收缩到字段完整的最后一条，再从该条之后续跑。
这个例子的数字只用于说明比较方法，实际阈值需要按业务对完整性的要求来定。
中断后先做的实际动作
建议先执行一个动作：导出结果表中带时间戳或批次号的记录，按时间排序，找到连续写入的最后一段，并对这段的末尾若干条做字段完整性抽查。
这个动作的结果会直接影响下一步。如果末尾记录字段完整，可以从中断点之后续跑，节省重复抓取；如果末尾记录字段缺失或时间戳跳跃，说明覆盖边界不可靠，应把这次扫描标记为不完整，改用分批提交或降低并发的方式重新扫描，并在每批结束后核对批次号，避免再次中断后无法判断范围。
关键前提变化时的取舍
如果业务前提发生变化，例如网站结构改版、URL规则调整或扫描目标从全站改为重点栏目，那么即使能判断出旧的覆盖范围，也不应直接沿用。此时应重新定义扫描清单，而不是在旧结果上续跑。判断依据是：旧结果中的URL是否仍与当前业务对象一一对应。如果对应关系已经断裂，覆盖范围再精确也不能用于当前决策。
反之，如果只是扫描被中断、网站结构和目标都未变，那么优先做边界复核和增量续跑，比整站重扫更省资源，也更容易核对两次结果之间的差异。
把覆盖范围写进下次扫描的配置
为了避免再次中断后无从判断，可以在下次扫描前做两件事：开启分批提交或定期落盘，并让每批结果带可识别的批次标识。中断后只需查最后一批的批次号和该批内的记录数，就能快速界定覆盖范围。具体软件是否支持这些设置，需要以当前版本的配置项和文档为准，不能假设所有工具都有相同选项。
覆盖范围判断的终点不是得到一个百分比，而是能回答“哪些URL已经处理、哪些还没有、边界是否可信”。只有这三个问题都有明确答案，中断后的结果才能继续用于后续分析。
