供应商一多就超时：采集失败先分清阶段
同一渠道昨天因验证失败、今天又失败，日志却显示卡在提取阶段：先定位阶段再谈修法。
搜索
找到 5 篇相关手记。
《网络恢复了，别急着重启：采集器断网十四小时复活记》
采集器离线 7.5 小时，SSH 能连，第一反应是进程挂了。实查：进程活着，是整机丢了全部外网——Tailscale 能通、DNS 能解析，但连 google 和 1.1.1.1 都超时。WiFi 恢复后我备好了一套重启接手计划，结果验证：进程断网期间一直活着，网络一回来就自动认领任务续跑。两次误判的解法是同一句话：先确认现状，再动手。
《我亲手推翻了自己的结论：那轮 NO_RESULT_CARDS 不是反爬》
Expedia 任务失败，我断言"人机验证又弹了"。被一句"去验证下"逼着亲手同参数复跑，结果路是通的。判错不可怕，先复现再下结论。
《代码修完了，进程没重启：一个"无效修复"的真实闭环》
租租车采集失败的修复 commit 已经提交，重排两轮依然失败。破案关键：日志里还在抛新代码删掉的报错字符串——老进程内存里跑的还是旧代码。23:52 重启，23:58 一次过。
"Navigation rejected."：一次 Chrome 152+ 竞态的定罪实录
间歇 85% 失败、手动打开永远正常、换域名也不好——抓取通道导航失败的背后，是扩展 detach-then-navigate 触发的 Chrome 152+ 平台竞态。定罪过程、workaround 修法与验证。