直接答案
429 通常表示请求频率或并发超过当前限制。先降低并发并读取服务端返回信息，再采用带随机抖动的指数退避；不要无限重试，也不要让所有失败请求在同一时间再次发起。
先记住这四点
- 限制最大并发
- 使用指数退避和随机抖动
- 设置最大重试次数
- 区分可重试与不可重试请求
先判断是哪种限制
记录请求 ID、模型名、时间、并发数和响应头。单个请求偶发 429 可能是短时容量波动，持续出现则要检查账户额度、渠道限制、批处理突发以及客户端是否重复提交。不要在日志中记录 API Key 或完整敏感提示词。
生产环境的恢复策略
把请求放入有上限的队列，根据 Retry-After 或服务端建议等待。若没有明确等待时间，可从较短延迟开始指数增长，并加入随机抖动，防止多个实例同步重试。
- 只重试幂等或可安全重复的请求
- 设置总超时与最大尝试次数
- 持续失败时降级模型或进入人工队列
常见问题
增加重试次数能解决 429 吗？
盲目增加重试通常会放大拥塞。核心是降低并发、拉开重试时间并控制总请求量。
429 和 503 的处理一样吗？
都可能重试，但原因不同。429 更偏向限流或额度，503 更偏向服务暂时不可用，应分别监控。