值班交接：收到429后，先暂停重试，再检查限流原因

先把429理解成“请求需要慢下来”

程序调用接口，收到429，先别急着连点重试。这个状态码表示请求触发了服务端的限流规则。它描述的是请求过多，不等于密码错误，也不能单凭它判断整个服务已经故障。你可以把接口想成办事窗口：窗口还在工作，但暂时不接受你继续往前挤。([datatracker.ietf.org](https://datatracker.ietf.org/doc/rfc6585/?utm_source=openai))

本次值班的处理原则很简单：先看返回信息，再决定等待多久；先控制新增请求，再安排有限重试。目标不是让请求尽可能快地重新发出，而是让它有机会成功，并且不把等待变成新的拥堵。

先读返回信息，别凭429猜恢复时间

检查响应头里有没有Retry-After。它表示服务端建议等待多久，可能是秒数，也可能是一个具体日期。例如，值为30时，应至少等待30秒；如果是日期，就计算距离那个时间还有多久。这个响应头不是每次429都会附带，因此程序也需要准备没有等待提示时的处理分支。([rfc-editor.org](https://www.rfc-editor.org/rfc/rfc9110.html?utm_source=openai))

同时查看响应正文中的错误说明，并核对服务商文档。把“发生了什么”和“下一步做什么”分开记录：前者保留原始错误，后者写清楚等待、检查配置或联系支持。不要仅凭状态码给用户承诺一个恢复时间。

重试要越等越久，也要错开发送

没有明确等待提示时，可以采用指数退避。通俗地说，就是连续失败后逐步拉长等待间隔，而不是每隔很短时间就再试一次。还应加入随机延迟，也叫抖动，避免许多客户端同时失败后，又在同一时刻一起回来。重试本身也会增加负载，安排不当可能让拥堵更严重。([d1.awsstatic.com](https://d1.awsstatic.com/builderslibrary/pdfs/timeouts-retries-and-backoff-with-jitter.pdf?utm_source=openai))

下面是一套便于新手理解的示例策略，不是任何平台的默认限制或服务承诺：

• 把额外重试次数设为最多三次，并为整个任务设置总等待期限。
• 没有服务端等待提示时，可以依次采用两秒、四秒、八秒作为基础间隔，再加入少量随机延迟。
• 存在Retry-After时，不要让随机计算出的较短间隔覆盖服务端要求的等待时间。
• 达到重试上限或超过任务期限后，应停止自动尝试，并向调用方返回明确结果。

把重试集中管理，别让每一层都补发

检查客户端库、业务代码和后台任务是否分别设置了重试。若每层都觉得“再试一次没关系”，最终发出的请求可能远多于你预想。更稳妥的做法是在选定的一层统一管理重试，并确认其他层的行为，避免重复补发。([d1.awsstatic.com](https://d1.awsstatic.com/builderslibrary/pdfs/timeouts-retries-and-backoff-with-jitter.pdf?did=ba_card-body&trk=ba_card-body&utm_source=openai))

对于会发送邮件、提交订单或执行其他实际操作的任务，还要确认重复执行是否安全。接口调用与后续业务动作应分开处理；不能因为生成请求需要重试，就把已经完成的业务操作一起重做。涉及副作用的操作，只有具备相应的幂等保护，才能安全地自动重试。([d1.awsstatic.com](https://d1.awsstatic.com/builderslibrary/pdfs/timeouts-retries-and-backoff-with-jitter.pdf?utm_source=openai))

交班前，把排队和排查线索留下

建议给新请求设置有界队列，并限制同时执行的数量。队列满了就明确提示繁忙，不要无限积压。日志至少记录发生时间、目标模型、请求标识、等待提示、重试次数和最终结果；避免记录密钥及不必要的用户正文。这样下一班能判断问题是否集中在某类请求，而不是从一串“调用失败”重新猜起。

如果你需要按量付费接入多个模型家族，可以把Relay365列入评估，并在创建账户后先用小批量请求验证接入和错误处理。选用中转服务不应成为删除客户端限流保护的理由；接入时仍应确认实际限制、错误说明和重试行为。

交班记录最后写清三件事：是否仍在出现429、当前采用什么等待策略、达到上限后请求去了哪里。优雅处理429，不是永远重试，而是知道何时等待、何时停止，并让用户知道任务的真实状态。