核心要点
先分类错误：429/5xx/网络超时是可重试，400/参数错/内容审核拒绝是不可重试，别盲目重试
设合理超时 + 对可重试错误做指数退避重试（base 1s、最多 3 次、带随机抖动），并保证调用幂等
加并发控制与限流排队（令牌桶/信号量），触发熔断后降级：切小模型、读缓存、返回兜底文案
全链路监控错误率与 P95 延迟，异常告警，避免静默失败
标准回答
第一步：把错误分好类
对照状态码处理：429（限流）、500/502/503（服务端）、连接超时这类是「可重试」；400（参数错）、401（鉴权）、内容审核拒绝是「不可重试」，重试只会浪费配额，应直接报错或走人审。
第二步：超时 + 退避重试
每次请求设合理超时（如 30s，流式可更长），对可重试错误用指数退避：第 1 次等 1s、第 2 次 2s、第 3 次 4s，加随机抖动避免同时重试打爆服务。重试前确认请求幂等（带 request_id），防止重复扣费或重复写库。
第三步：限流、降级、熔断
本地用令牌桶或信号量控制并发，超额的请求排队而不是一起打过去。连续失败触发熔断，期间走降级路径：切到更小/更快的模型、命中缓存、或返回预设兜底文案。
第四步：监控兜底
记录每次请求的模型、token、延迟、错误码，看错误率和 P95，异常实时告警，留 badcase 复盘。
常见误区
⚠️ 常见踩坑
对 400 参数错或内容审核拒绝也盲目重试，白白消耗配额还拖慢响应；重试不做幂等，导致同一笔请求重复扣费或重复落库。
追问
追问 1：指数退避为什么要加随机抖动（jitter）？
如果大量请求同时失败、又用同样的退避间隔，它们会在同一时刻一起重试，形成「重试风暴」再次打垮服务。加随机抖动让各请求错峰重试，削平瞬时峰值。
追问 2：熔断和限流有什么区别？
限流是主动控制发出去的请求速率（令牌桶/排队），防止自己把上游打爆；熔断是被动保护，监测到错误率过高时直接快速失败、停止打无用请求一段时间，给上游恢复时间，期间走降级路径，超时后再半开试探恢复。
延伸学习
与本题相关的知识库文章、术语、工具与行业资讯。