OpenAI API 返回 429 时，先看响应正文中的错误码，再看 Retry-After 和速率限制响应头。只有临时请求速率问题适合限次等待后重试；额度、余额或硬支出上限导致的 429，反复重试不会补出额度。
先把错误归类
保存一次失败请求的 HTTP 状态、error.code、请求时间，以及响应头中的 Retry-After 和 x-ratelimit-* 字段。日志里不要写 API 密钥、完整用户输入或 Authorization 头。官方速率限制文档列出 RPM（每分钟请求数）、TPM（每分钟 Token 数）等指标，任一维度先到上限就可能阻止请求；限制还会随模型、组织和项目而变化。
| 观察到的线索 | 优先动作 |
|---|---|
error.type 为 rate_limit_error，剩余请求数为 0 |
降低并发或请求频率，等待请求窗口恢复。 |
| 剩余 Token 数不足 | 缩短输入、控制输出长度或降低并发，等待 Token 窗口恢复。 |
error.code 为 slow_down |
按 Retry-After 放缓增长，再逐步增加请求量。 |
| 支出/余额相关错误码 | 检查平台账单和限额；不做自动无限重试。 |
例如，假设某次响应头显示剩余请求数为 0、x-ratelimit-reset-requests: 2s，这是演示数据，不是实际账号限额。应至少等窗口恢复后再发下一次请求。若响应带 Retry-After，优先遵守该等待时间。
写一个不会失控的重试流程
- 只对已确认的临时限流、
slow_down或暂时过载分支启用重试；先判断操作是否可安全重复。 - 设总尝试次数，例如最多 3 次；有
Retry-After就等待它，没有就逐次增加等待时间并加入少量随机抖动。 - 每次失败重新读取错误码和响应头。若变成计费/额度错误，立即停止并提示管理员处理。
- 重试仍失败时把任务放入受控队列或返回可解释的失败，不让前端无限循环请求。
如果请求会触发工具写入、付款或其他外部副作用，网络超时后不能盲目重发：先核对副作用是否已经发生，再决定是否重试。仅凭 429 状态码不足以认定可重试，因为官方支出限制说明明确指出，达到组织或项目硬支出上限也可能返回 429。
修复后怎么验证
在业务低流量时用一条短输入测试，确认请求成功，并观察响应头中剩余请求或 Token 是否回升；随后缓慢恢复并发。若短输入仍返回 organization_usage_limit_exceeded、credit_balance_exhausted 或支出限制码，转去排查账户额度。本篇依据 2026 年 10 月 1 日官方资料整理，未读取你的账号限额，具体数值请以自己控制台和响应头为准。
Ai菜鸟网。发布者：AI小管家，转载请注明出处：https://www.alyyhw.com/30915.html
