AIAPI遇到429限流怎么办：指数退避、并发控制和幂等重试

导语：AI API返回429时，最危险的做法是立刻开启更多重试。并发没有降下来，重试请求反而会继续挤压服务，最终从一次限流变成整批任务失败。处理429的核心，是先识别限流类型，再控制并发、等待时间和重复请求。

429通常说明什么

429一般表示请求频率、并发数、配额或短时间消耗超过了服务允许的范围。不同平台的限制维度可能不同，有的按账号计算，有的按项目、IP、模型或时间窗口计算。

因此不能看到429就简单把sleep时间加长，应该先查看响应头、错误码和平台文档，确认到底是哪一种限制触发了。

瞬时限流通常等待一段时间后可以恢复，适合使用退避和排队。额度耗尽则可能需要等到周期重置、切换已授权资源或人工处理，继续重试没有意义。

指数退避可以让连续失败的请求逐渐拉开间隔，例如第一次等待1秒，之后逐步增加。但等待时间必须设置最大值，并加入少量随机抖动，避免大量客户端在同一时刻重新发起请求。

$delay = min($maxDelay, $baseDelay * (2 ** $attempt));
$delay += random_int(0, 300) / 1000;

退避只解决“什么时候再试”，不能解决请求本身会永久失败的问题，所以还要配合最大重试次数。

批量生成文章、图片或摘要时，应在客户端设置并发上限和任务队列。不要让每个网页请求都直接创建一个新的API请求。通过队列集中调度，才能统一控制速率、暂停任务和恢复任务。

如果请求会产生写入、扣费、发布或外部通知，重试前必须考虑重复执行。可以为每个业务任务生成幂等键，在服务端或本地记录请求状态，收到同一个幂等键时返回已有结果，而不是再次执行。

自动化任务不能无限等待。超过最大重试次数后，要记录任务ID、最后一次错误、累计等待时间和下一步建议。前台可以显示“排队中”“稍后重试”或“需要人工处理”，不要一直显示加载状态。

排查限流需要记录状态码、模型或资源类型、并发数、重试次数、等待时间和任务结果。不要记录完整Token、完整提示词或敏感业务数据。通过脱敏后的任务ID关联上下文即可。

AI API遇到429时，先判断是短期限流还是额度耗尽，再用队列和并发控制降低压力，用带上限的指数退避处理瞬时失败，最后用幂等键防止重复执行。稳定的限流处理，本质上是一个任务调度问题。