那一晚，我们只想确认一件事：刚改的那段采集逻辑到底对不对。
这是给一家电商供应链企业做的商品巡检系统：每天凌晨借客户自己账号的登录会话进入一家采购平台，把六个品牌共 1781 件商品逐件点进详情页，核对在不在线、有没有新上架。平台上的数据全部要登录才看得到，账号由客户自己登好，系统只是借用。为了验证改动，我们一晚上把 1781 件的全量抓取跑了 4 遍，中间还夹着几轮只抓列表的，连同重试，在客户账号上打了八千多次详情请求。
跑到后来，平台开始报错。第二天早上，所有页面都被跳回登录页，整套巡检停摆，当天一条产出都没有，只能请客户重新登录。
事后复盘，这次掉线大概率是我们自己打出来的。
改一版跑一遍全量，等于拿客户的账号做测试
「改一版、跑一遍全量、看结果」听上去很严谨，毛病在于验证的代价全记在了别人头上。账号是客户的，平台给这个账号的访问额度是客户的，这个账号在平台那里攒下的信用也是客户的。这三样不会因为我们在做测试就打折，用掉了就是用掉了；登录一失效，停下来的是客户的业务。
而且全量跑出来的结论本身也靠不住。前后三轮跑下来，系统分别判出 7 条、9 条、1 条「已下架」，逐条复核全是误报，我们连改三次判据都没治好。其中那 9 条，记录下来的原因跟商品本身无关，是平台在高频抓取时偶发的报错，系统把「这次没读到」当成了「商品没了」。
最后解开这个结的，是一个几秒钟就跑完的小测试：单独去读被判下架的那件商品，连读三次，每次一两秒就拿到完整信息；换一件真正不存在的商品，等满 18.5 秒也读不出来。判据一直是对的，错的是读取的时机：只有夹在一千多件连续抓取中间，它才会读成空壳，页面打开了，商品信息却一栏都没有。当场换个页面立刻重试，还落在同一阵高峰里，所以救不回来。故障源就是这批抓取自己造成的压力，在它里面重试，等于在同一阵拥堵里再挤一次。
顺便一句：只跟自己的历史比，看不见从第一天起就少抓
同一个项目里还有一个更安静的错。巡检起初只按一个品牌去搜，抓到 398 件就当成了全量，实际该巡的是 1781 件。当时的完整性检查是「今天抓到的不到昨天的 70% 才报警」，它只抓得住突然变少；从第一天起就少抓，每天稳定地少同样多，它永远看不出来。只跟自己的历史比，等于让错误给自己打分。能拦住它的，是平台页面上自报的那个总数，它不归我们管，正好拿来对账。
我们现在的规矩
- 验证按代价从低到高排。 用模拟数据自测，一次请求都不发到平台；单独读一件商品，几秒钟；只翻列表不进详情，几分钟验完覆盖；全量只在最后跑一次。
- 批量任务加每日次数上限。 同一天跑满三遍就拒绝再跑，兜住我们自己，也兜住别人手工反复重跑。
- 高频批量里的偶发失败不当场重试。 可疑的先攒下来，等整批跑完、歇 60 秒再单独读一次。要换的是时间，不是页面。
- 平台一时报错，不等于商品没了。 这种情况只记作「这次没读到」。平台明确回答「商品不存在」，或者页面打开是个空壳，也要隔一阵、在整批之外再读一次仍然如此，才算「已下架」的证据。
- 「抓全没抓全」拿平台页面上自报的总数对账。 抓到的不足平台自报数的 97% 就报警，某个品牌一件没抓到也单独报警。这两道后来在真跑里都响过。
验证的代价，只能记在自己账上。