收到 429 后立即重试，一分钟内打了两千次，配额恢复时间被拖到 10 分钟。日志里能对上时间点，这种反而好排。
重试是固定 100 毫秒间隔，没有读 Retry-After，也没有指数退避。限流期间继续加压，恢复只会更慢。这一点先确认清楚，后面就不用反复试。
curl -i https://api.example.com/v1/chat -d @req.json | grep -i retry-after
围绕「限流退避缺失」排查时，命令行跑一遍比在面板里点十次有用，面板会替你做掉不少隐式操作。偶发问题先统计频率，一小时几次和一天一次，查法完全不同。
改完顺手把文档补一句，省得下次自己重新推一遍。监控和日志的时间要对上，时区不一致会多绕很大一圈。
临时改动用注释写上日期和原因，过两周自己都记不清为什么这么写。
处理上按这个顺序：429 时读响应头 Retry-After 按秒等待；退避改成指数加随机抖动；设置最大重试次数和总等待上限；超上限进死信队列人工处理。
结果对不对很好判断，429 期间请求频率明显下降 恢复后第一批请求成功。