错误码速查与重试策略：写出更稳的客户端

发布于 2026-09-25

错误码速查与重试策略：写出更稳的客户端

调用大模型 API 时，错误处理写得好不好，直接决定你的应用在高峰期是“慢一点”还是“挂掉”。

常见错误码速查

状态码典型含义你该做什么

--- --- ---

401 Key 无效或已吊销检查 Key 是否复制完整、是否已被替换；不要重试

403 额度不足 / 模型不在白名单 / 项目已停用看返回信息定位具体原因；额度问题充值或换 Key，不要盲目重试

429 请求过于频繁等待后按退避策略重试；持续出现则降低并发

5xx 上游或网关临时故障可重试；连续失败再告警人工介入

重试的正确姿势：指数退避 + 抖动

连续快速重试只会让拥塞雪上加霜。标准做法是每次等待时间翻倍，并加一点随机抖动：

三个原则：

1. 只重试可重试的错误（429、5xx、网络超时），鉴权与额度类错误重试没有意义；

2. 设置重试上限，超过就走降级逻辑（换模型、返回缓存结果或友好提示）；

3. 给每个请求带超时，避免线程悬挂耗尽连接池。

上线前自检清单

[ ] 401/403 有明确的告警与处理分支，不会进入重试循环

[ ] 429 走指数退避，并发量有整体上限

[ ] 请求超时、连接池大小与你的并发目标匹配

[ ] 有降级方案，而不是把原始错误直接抛给最终用户

把错误处理当成功能来设计，而不是异常兜底——这是 API 应用稳定性的分水岭。