网站推广软件：一次全站扫描被中断后怎样判断已覆盖范围，矛盾现象：进度条归零，不代表覆盖为零
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /286570e52d54.html
📄
网站推广软件：一次全站扫描被中断后怎样判断已覆盖范围，矛盾现象：进度条归零，不代表覆盖为零
中断后不要先看“已扫描多少条”，而要把日志或导出结果按URL区间切成连续段，找到最后一个完整结束的段，再确认它之后是否有跳扫或重复抓取。已覆盖范围通常等于“连续完成段”的并集，而不是中断前累计计数。
矛盾现象：进度条归零，不代表覆盖为零
网站推广软件的全站扫描被中断后，常见两种相反结果：一种是界面显示进度回到起点或任务列表里只剩“已停止”；另一种是导出文件里已经有大量URL记录。直觉会认为前者说明什么都没扫到，后者说明几乎扫完。实际更可能是：进度状态只记录当前会话，而覆盖记录已经写入临时文件或任务日志。
判断覆盖范围时，先把“任务状态”和“覆盖证据”分开。任务状态回答的是“这次运行有没有正常结束”，覆盖证据回答的是“哪些URL已经被处理过”。中断后前者通常不可靠，后者才值得核对。
两种解释：扫描到一半，还是扫描记录被截断
解释一：扫描确实覆盖了一部分，只是中途停止。此时已处理URL会呈现连续区间，例如按字母序、栏目序或站点地图顺序排列，最后一个完整段之后没有新记录。
解释二：扫描记录被截断或只写入了部分批次。此时会出现不连续：前面的URL有记录，中间大段缺失，后面又冒出少量记录；或者同一URL出现多次，时间戳跨度很大。这种不连续更像写入中断、并发批次丢失或导出范围被限制，而不是“扫描到一半”。
区分这两种解释，关键不是看总数，而是看顺序和边界。连续段支持“确实扫过”，跳跃段支持“记录不完整”。
可核对的证据：用四个检查点缩小范围
第一，看任务日志的最后一条完整记录。如果最后一条带有明确的“批次结束”或“分页结束”标记，并且下一条是中断提示，那么覆盖范围可以按该标记之前的连续段计算。
第二，看URL排序是否稳定。假设导出文件按发现顺序排列，取前100条和后100条，检查它们是否属于同一栏目或同一层级。如果前后混杂且中间缺失，说明覆盖范围不能按总数估算。
第三，看重复率。随机抽取已记录URL中的一小段，与站点地图或栏目列表对照。如果重复率异常高，说明扫描可能在原地打转，累计计数会虚高，实际覆盖范围反而更小。
第四，看时间戳分布。把记录按时间排序，观察是否存在长时间空白后突然出现一批记录。若有，说明中断可能发生在空白期，后续批次是恢复后的补扫，需要单独标记。
实际动作：把导出结果按时间戳排序，标记出最后一个连续批次，然后只对该批次之后的URL做一次小范围补扫。补扫结果如果与已有记录大量重合，说明原覆盖范围基本可信；如果大量新增，说明原覆盖范围被高估，下一步应以补扫后的并集为准。
假设例子：一次中断后的覆盖判断
假设某次扫描在导出文件中留下三组记录：A组从首页到栏目页共200条，时间连续；B组缺失约300条；C组有50条产品页，时间戳比A组晚很多。此时不能把总数250条当作覆盖范围。更合理的判断是：A组是已覆盖的连续段，C组是恢复后的补扫段，B组是未知缺口。下一步应优先补扫B组对应的URL区间，而不是重新全站扫描。
如果补扫B组后，C组记录大量重复出现，说明C组可能只是同一批次的重复写入，实际覆盖范围仍以A组加B组为准。这个动作的结果会直接决定后续是继续补扫，还是可以停止并进入结果分析。
边界条件：什么情况下不能按连续段判断
当网站推广软件采用多线程或分布式抓取时，URL写入顺序可能天然跳跃，连续段判断会失效。此时应改用“批次标识”或“分片标识”核对，而不是依赖排序。若工具没有提供批次标识，只能通过小样本补扫来反推覆盖范围，并明确假设：补扫未命中的URL视为已覆盖，补扫命中的URL视为缺口。这个假设需要在下一次完整任务中验证，不能直接当作长期结论。
另外，如果中断发生在导出阶段而非扫描阶段，已有记录可能完整，只是文件不完整。此时应重新导出同一任务的结果，再比较两次导出的URL集合差异。差异很小，说明覆盖范围可信；差异很大，说明覆盖范围需要重新核对。
