供应商一多就超时：采集失败先分清阶段

昨天查一次采集失败，差点按老经验下错结论：同一个渠道前一天才因为验证问题全军覆没，今天又有几个任务失败，第一反应当然是“又被验证拦了”。打开日志才发现，这次根本不是同一回事。

先看现场。某比价渠道的洛杉矶站点，当天 7 个任务里 3 个失败、1 个完成、3 个还在排队。失败的 3 个全是洛杉矶，同一渠道的另一个城市能正常完成，其他渠道也都正常。这已经不太像“采集器整体出问题”，更像某个站点特有的问题。

再看失败卡在哪一步。前一天的失败发生在验证环节，错误信息里有人工验证的字样；这次的日志没有验证痕迹，任务卡在结果提取阶段：程序逐个供应商去取数，单个供应商的选择步骤 90 秒超时就判失败。有一个任务重试后推进到了 16/24 个供应商，最后栽在结果数对不上——表头数是 0，预期是 1。也就是说，页面本身慢、供应商又多，提取还没跑完就超时了。

这个区分很重要，因为修法完全不同。验证拦截要解决的是“怎么证明自己不是机器人”；提取超时要解决的是“页面太慢、供应商太多，单步时限够不够、失败了能不能断点续取”。按验证去修超时，或者按超时去修验证，都是南辕北辙。

查采集失败，我现在固定先问三句，贴出来可以直接套用：

第一，卡在哪一阶段？验证、提取、入库，阶段不同，根因就不同。 第二，错误信息到底写了什么？是验证类的词，还是超时、数量对不上的词？别凭“昨天也是它失败”推断。 第三，横向对照怎么样？同渠道其他站点正常吗？其他渠道正常吗？只有一个站点出问题，就先往这个站点的页面特性上想。

失败标签相同，不代表是同一个病。先定位阶段，再谈修法。