重试与退避（Retry with Backoff）

一句话理解

调接口被拒后的“礼貌再试”——失败等一会儿再重试，越失败等得越久，避免把故障的服务雪上加霜。

定义

重试与退避是处理瞬时失败的套路：请求失败（超时、限流 429）后不立即硬冲，而是按指数增长的间隔重试（1 秒、2 秒、4 秒……），常再加随机抖动错开多客户端的节奏，配合重试上限与最终兜底方案。

你会在哪遇到它

官方 SDK 的默认配置文档；讨论“限流 429 怎么办”的问答；自己写调用脚本时的必修课。

背后的原理

服务端过载时，无脑立即重试等于放大攻击——所有客户端同一时刻再挤一次。指数退避把重试打散到不同时间点，给服务恢复的机会。要点：只重试可恢复的请求（重新生成一段文字无害，重复下单不行）；限流错误要读 Retry-After 头；重试耗尽要有降级（换模型路由 1041 或直接报错）。

和相近概念的区别

1 与超时设置：超时管“等多久”，退避管“失败后何时再来”，配套使用。 2 与模型路由（1041）：重试是原地再来，路由是换一家服务，故障等级不同。 3 与断点续训（1081）：训练场景“从检查点恢复”是同一思想的重型版本。

常见误区

1 失败立刻猛重试——高峰期把自己限流额度烧光，甚至被拉黑。 2 所有请求都能重试——非幂等操作重复执行可能重复扣费。 3 重试次数越多越稳——拖长用户等待体验更差，要有上限与降级。