site查询优化：一次全站扫描被中断后怎样判断已覆盖范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3d8f46c71ed5.html
📄
site查询优化：一次全站扫描被中断后怎样判断已覆盖范围
结论先行：如果扫描工具在中断前已经把处理进度写入可读的日志或结果文件，就按“最大连续处理位置”估算已覆盖范围；如果没有任何持久化记录，只能把这次结果当作不完整样本，不能按已覆盖全站来使用。判断的关键不是中断时页面显示了多少条，而是能否找到一条可复现的处理边界。
先分清两种中断：主动停止与被动失败
主动停止通常发生在你看到进度条走到某个位置后手动结束。此时工具很可能已经处理完当前批次，只是没有继续推进。被动失败则可能由网络断开、进程被终止、配额耗尽或目标站点返回异常引起，处理到哪一步往往不确定。
两种情况的判断方式不同：
- 主动停止：查看结果文件或日志的最后一条记录，如果它带有时间戳或序号，并且能对应到某个URL，那么这条记录之前的部分大概率是完整的。
- 被动失败：不能只看最后一条成功记录，还要检查失败前是否出现过连续报错。如果中断前已经有一批请求返回超时或拒绝，那么“最后一条成功记录”之后可能还有未被记录的失败尝试，覆盖范围要打折扣。
一个实际动作是：打开结果文件，找到最后一条带有序号或时间戳的记录，记下它的位置。如果这个位置与工具显示的“已处理数量”接近，说明进度记录基本可信；如果两者差距很大，说明工具可能先缓存后写入，已覆盖范围要以结果文件为准，而不是以界面数字为准。这个动作会直接影响下一步：你决定是从断点继续，还是重新跑一遍。
用“边界标记”而不是“总数”来界定覆盖范围
很多扫描工具会显示已处理数量，但总数本身不能说明覆盖了哪些URL。比如一个站点有列表页、详情页和分页，工具可能先抓取了一部分列表页，再进入详情页，中断时详情页只处理了前几十条。此时“已处理500条”并不等于“全站500条”，因为列表页和详情页的覆盖比例可能完全不同。
更可靠的做法是找边界标记。常见的边界标记包括：
- 结果文件中最后一条记录的URL，以及它在站点结构中的位置，例如属于哪个目录或哪个分页。
- 日志中最后一条“开始处理”或“完成处理”的记录，注意区分两者。
- 如果工具支持断点续传，检查它记录的断点标识是否与结果文件一致。
假设一个站点有A、B、C三个栏目，扫描工具按栏目顺序处理。结果文件里A栏目有完整记录，B栏目只有前20条，C栏目完全没有。这时已覆盖范围是A栏目全部加B栏目前20条，而不是“全站已覆盖三分之一”。下一步动作应该是先补B栏目剩余部分，再决定是否重跑A栏目。如果A栏目数据对当前决策不重要，可以跳过重跑，节省时间。
中断前出现异常返回时，覆盖范围要重新评估
有一种反例会推翻上面的判断：中断前目标站点已经开始返回大量非正常状态，比如持续超时、连接重置或返回验证页面。此时即使结果文件里最后一条记录看起来正常，它之后的一批请求可能已经被目标站点拒绝，只是工具没有把拒绝写入结果文件。这种情况下，“最大连续处理位置”仍然成立，但它代表的覆盖范围可能远小于你以为的范围。
区分方法是看日志中失败请求的比例。如果中断前最后一段日志里，失败请求占比明显升高，那么已覆盖范围要按“最后一次连续成功批次”来算，而不是按最后一条成功记录来算。这个判断会影响下一步：如果失败集中在某个目录，重新扫描时可以先跳过该目录，或者降低请求频率后再补扫。
没有持久化记录时，只能把结果当样本
如果工具在中断后没有留下任何可读的进度文件，界面也刷新了，那么你无法确认它到底处理了哪些URL。此时最稳妥的做法是把这次结果当作不完整样本，只用于观察趋势，不用于判断全站状态。比如你可以看已抓取页面中标题重复的比例，但不能说“全站标题重复率是某个数值”。
下一步动作取决于你对完整性的要求：如果只是看某个栏目的大致情况，可以手动补扫该栏目；如果要用于全站决策，建议重新跑一次，并确保这次开启日志或结果文件输出。重新跑之前，先确认工具是否支持限制范围，比如只扫描特定目录，这样即使再次中断，也能缩小未知区域。
判断之后，用一个小范围验证来确认边界
无论采用哪种判断，都建议做一次小范围验证。选一个你认为已经覆盖的目录，手动抽查其中几条URL是否出现在结果文件里。如果抽查的URL全部存在，边界判断可信度较高；如果出现缺失，说明结果文件可能不是按顺序写入，已覆盖范围需要重新界定。
这个验证动作的结果会直接影响下一步：验证通过，就从断点继续；验证不通过，就放弃断点，重新规划扫描范围。不要因为一次中断就默认全站需要重跑，也不要因为结果文件里有记录就默认覆盖完整。判断的依据始终是可复现的边界，而不是中断时的界面显示。
