模型 API 返回 429，为什么越重试越慢？

先保存一条失败证据

HTTP/1.1 429 Too Many Requests
Retry-After: 30
request_id: req_42

记录响应状态、服务方请求标识、时间、调用模型和并发数；不要在日志里写入密钥或完整用户输入。429 和 400 的处理方向不同：前者通常需要控制请求节奏，后者更可能是参数问题，盲目重试不会修复。

有 Retry-After 时尊重它

HTTP 规范允许 429 响应携带 Retry-After，它可能表示等待秒数，也可能是一个 HTTP 日期。以服务方实际文档和响应为准；如果没有该头，使用有限次的指数退避并加入随机抖动，避免所有客户端在同一时刻重试。

第 1 次限流 → 等待服务方建议的时间
仍限流 → 退避，再试一次
达到重试上限 → 返回可恢复错误，不无限循环

重试之前判断副作用

读取、查询等操作通常比较容易重试；若请求会创建订单、发邮件或扣费，先确认服务是否支持幂等键，或查询上一次请求是否已经成功。一次网络超时不等于服务端没有执行。把限流控制放到共享队列中，比让每个页面各自疯狂重试更稳定。

参考：RFC 6585 的 429 定义、HTTP Retry-After 语义。