教程：OpenAI 兼容接口的错误处理与指数退避重试

调用大模型接口时，失败是常态而非例外。把「失败」当成一种需要设计的状态，而不是 try/catch 里随手吞掉的异常，是生产级代码与 Demo 的分水岭。

第一步：给错误分类

先看 HTTP 状态码：4xx 多为请求本身的问题（参数、鉴权、额度），5xx 与网络错误多为服务端或链路抖动。前者重试没有意义，后者重试通常有效。

• 400/422：参数错误，不重试，修请求
• 401/403：鉴权问题，不重试，查密钥
• 429：限流，可重试，尊重 Retry-After
• 5xx / 超时：可重试，走退避

第二步：指数退避 + 抖动

退避间隔按 2 的幂次增长（1s、2s、4s…），并叠加随机抖动。抖动的作用是打散重试时刻，避免所有客户端在同一毫秒集体重试，把限流阈值顶死。

第三步：代码骨架

核心是一个带上限的重试循环：记录 attempt、计算 delay、sleep、重发；超过最大次数则抛错并保留最后一次响应体用于排障。伪代码要点是「只对可重试错误重试」。

• maxAttempts 建议 3~5，超过即失败
• baseDelay 1s，上限 30s 左右
• delay = min(base * 2^n, cap) * (0.5 + random/2)
• 重试前重新构造请求体，避免复用已读流

第四步：超时与取消

连接超时与读取超时要分开设置：长文本生成可能合法地耗时数十秒，读取超时设太短会误杀正常请求。流式接口配合 AbortController，用户取消时立刻断开，别为已放弃的请求继续付费。

第五步：把失败变成可观测

记录每次重试的 attempt、错误码、耗时，并统计重试率。重试率异常升高通常意味着上游在限流或你的并发设太高，这比事后翻日志有用得多。

重试不是「多试几次总会成功」，而是把不确定性收敛在可控成本内。分类、退避、上限、观测，四件事缺一不可。