旺格子优化：一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d810e6de2bfd.html
📄
旺格子优化：一次全站扫描被中断后怎样判断已覆盖范围
被中断的扫描不能靠“跑了多久”或“抓了多少页”来推算覆盖范围，因为中断点之后的数据可能根本没写入。更可靠的做法是：找到最后一条成功落库的记录，把它当作可确认边界，再用站点结构反推边界之外还有哪些区域完全没碰过。下面用一个假设情境把判断过程串起来。
假设情境：扫描到一半进程被杀掉
假设你在做一次全站扫描，任务跑到中途因为机器重启或手动终止而停掉。任务日志只显示“已处理 N 个地址”，但 N 这个数字可能包含重复访问、跳转和失败重试，并不能直接当作已覆盖的页面数。此时你手上真正可信的证据只有落库的结果表，而不是运行日志里的计数。判断覆盖范围的第一步，是承认日志计数和实际覆盖是两回事。
先锁定可确认边界，再谈覆盖率
把结果表按写入时间排序，取出最后一条记录对应的地址和时间戳，这条记录就是可确认边界。边界之前的地址可以认为已被处理，边界之后的地址状态未知。这里有一个容易被忽略的条件：如果结果表是批量写入而不是逐条写入，最后一批可能只写了一半，那么边界本身也是模糊的。遇到这种情况，要把最后一批整体视为未确认，宁可缩小可确认范围，也不要高估。
判断动作：导出结果表中所有地址，去重后得到已确认集合。把这个集合与站点已知的地址来源做差集，差集就是待确认区域。这一步的结果直接决定下一步——如果差集很小，重跑一次补全即可；如果差集覆盖了整类页面，说明中断发生在结构遍历的早期阶段，需要重新规划扫描顺序。
用站点结构反推边界之外还剩什么
可确认边界只能告诉你“处理到哪”，不能告诉你“还剩什么”。要补上这一半，需要借助站点自身的结构来源，常见的有以下几类：
- 栏目页和列表页：如果边界停在第 3 页，第 4 页之后的列表项大概率未覆盖。
- 站点地图：把结果集合与站点地图中的地址做对比，缺失部分即为未覆盖。
- 内链图：从首页出发按层级展开，看边界地址处于哪一层，同层未出现的地址需要单独确认。
- 分页与筛选参数：带参数的地址是否被计入结果，取决于扫描时是否展开参数，这一点必须核对，不能默认。
这几类来源的可靠性不同。站点地图通常最完整，但可能滞后；内链图反映实际可达性，但深层页面容易被漏掉。把多个来源合并去重后再做差集，比只依赖一种来源更稳妥。
三个信号帮你区分“没跑到”和“跑了没记”
中断后最麻烦的情况是：某些地址其实被访问过，但结果没写进去。以下信号可以帮助区分：
- 结果表中相邻两条记录的时间间隔。如果间隔异常大，中间可能有一批数据丢失。
- 失败记录的数量。如果失败记录集中在中断点附近，说明进程在崩溃前已经在报错，覆盖范围可能比边界更小。
- 重复地址的比例。重复率高说明扫描逻辑在边界附近出现了回退或重试，实际覆盖的独立页面数低于记录总数。
需要提醒的是，抓取量归零或请求量骤降本身不能单独证明任务处理正确，也可能是目标站点限流、网络中断或扫描被主动暂停。这些解释在判断覆盖范围时都要纳入考虑，不能只看一个指标就下结论。
决定重跑范围的具体依据
综合上面的证据后，通常面临两个选择：全量重跑，或只补差集。两者成立的条件不同：
- 只补差集：适用于可确认边界清晰、结果表逐条写入、差集范围明确的情况。动作是把差集地址单独跑一遍，跑完后与已有结果合并。结果是总覆盖范围等于两次结果之和，但要注意两次扫描的时间差可能带来状态不一致。
- 全量重跑：适用于结果表批量写入、边界模糊、或失败记录比例较高的情况。动作是清空或隔离旧结果后重新执行。结果是覆盖范围可确认，但代价是重复消耗资源。
如果差集里包含大量带参数的地址，还要先确认这些参数是否真的产生独立内容，否则补跑会引入大量重复。这一步的判断依据是参数是否改变页面主体内容，而不是参数是否存在。
把结论固化成可复查的记录
无论选择哪种方式，都要把判断依据写下来：可确认边界的地址和时间戳、差集的来源和数量、选择的补跑方式及理由。这样下次再遇到中断时，可以对照上次的记录快速判断，而不必从头推理。记录本身不需要复杂格式，一份包含边界地址、差集来源和决策理由的清单就够用。
回到最初的问题：判断已覆盖范围的关键不是估算百分比，而是找到可确认边界并明确边界之外的结构性缺口，再据此决定补跑还是重跑。
