那天挂完任务就睡了，早上起来看结果，缺了一大块。日志里从第三个小时开始，成片的连接超时，而前两个小时一切正常。最后交出来的数据只有预期的六成。后来把几处改动加上，同样的情况又出现过一次，损失从四成压到了百分之几。

先分清是 IP 到期还是被目标站封

这两种表现很像，处理方式完全不同。到期是成批同时失效——把 IP 按首次获取时间排个序，能看到失效时间点挤在一起；被封是零散地、慢慢地增加，跟请求的行为更相关。我那晚是前者：任务里的一批短效 IP 生命周期到了，本地池又没补上，等于后面几小时在空转。

改动一：本地池加水未线

原来的逻辑是"池子空了就再去提"，问题在于提取本身要点时间，而任务不会等。改成低于阈值就补货：池子里剩两成就触发一次批量提取，一次取 10 到 20 条。口径变了一下，空转就基本没了。做这件事的前提是接口能实时提——我这边用的是 API 实时提取，短效 IP 自动轮换，池子覆盖全国 300 多个城市，补货时还能按城市指定。

改动二：任务分片 + 断点

把一个大任务拆成每 1000 条一批，每批跑完把进度落一次盘。这样即便中段出问题，前面的结果都在，重跑时从断点接上就行。这处改动最不起眼，但收益最大——原来一崩就是整晚白跑。

改动三：失败任务重入队列，但有上限

失败的直接重试容易死磕同一条 URL。我加了两条限制：同一条最多重试三次，两次之间做退避。超出的丢进"待人工看"的表里，不占着线程。改完之后失败队列的长度稳定在很小的一个数。

改动四：把余量和时效纳入调度

提取接口返回里 leftIp 是剩余量、leftTime 是订单剩余有效期，我在调度器里各挂了一条预警线：余量低于两成、或者有效期不足一天，就提前提醒去续，别等任务跑着跑着断供。提的时候顺带带上 bufferTime，只要剩余有效期够长的 IP，能少浪费一批刚到手的。

后来那次

同一个目标站，任务跨了七个小时。中途池子告过一次急，预警触发、补货、继续跑，最终完成率 99% 以上。代价是代码多了一百多行——但比再来一次整晚白跑划算得多。

容错要点：先分清 IP 到期（成批同时失效）还是被封（零散增加）；本地池设水位线提前补货；任务分片并落盘断点；失败重试设上限与退避；用 leftIp / leftTime 提前预警，用 bufferTime 过滤即将失效的 IP。