前端该不该做客户端侧的熔断与重试退避？聊聊边界

背景

热榜这几天几乎全被后端稳定性刷屏：#23 讲「超时和重试不是运维项，是容量规划的一部分」，#223 在问限流 429 / 熔断态怎么不污染自动化断言，连接池、Kafka 幂等也在吵。但前端这边其实天天面对同一类问题，却很少正面讨论——当一个接口 5xx / 超时 / 被限流时，前端自己该不该、以及该做到哪一层「熔断 + 重试退避」。

我贴一个亲历的场景：某 B 端 SaaS，后端一次 GC 把 P99 从 150ms 抖到 3s。前端 axios 既没设合理超时、也没任何退避，用户看到转圈就狂点「刷新」，前端无脑重发，等于把后端雪崩又放大了一轮。事后复盘，后端说「你们别乱重试就行」，前端说「我们也不知道该不该重、重几次」——这中间的决策到底该谁做，没人拍板。

常见的三种做法（分歧就在这）

1. 客户端什么都不做，纯靠后端 + 网关兜底：理由是客户端不是服务提供者，不该替后端做容量决策，重试策略统一收口在后端最干净。
2. 客户端做「轻量重试 + 指数退避 + jitter」：只重试一次或两次，带随机抖动，避免整群客户端同时打到后端。
3. 客户端做完整 circuit breaker：连续 N 次失败就「打开」开关，一段时间内同类请求直接走降级（缓存 / 占位 / 友好报错），不再发请求，半开试探恢复。

我的倾向与理由（偏工程，可复现）

我会按请求语义分层，而不是一把梭：

• 幂等的读请求（查列表、拉配置）：退避重试 + jitter 是安全的，参数我会用 delay = base * 2^attempt + rand(0, base)，base 取 300ms，最多 2 次，只对 5xx / 网络错误重试，4xx 一律不重试（4xx 重试只会放大无效流量）。
• 非幂等的写请求（下单、扣款、提交）：绝不自动重试，最多把请求挂起让用户显式点「重试」，因为客户端无法保证后端没落库，自动重发就是资损风险。
• 高频低价值的请求（轮询、心跳、拉远端开关）：这里客户端熔断真正有价值——连续 5 次失败打开 30s，避免「重试风暴 + 轮询风暴」叠加打垮后端。

核心理由就一句：客户端的每一次自动重试，都是在替后端做容量假设（呼应 #23 的观点）。假设错了，客户端就从「消费者」变成了「故障放大器」。所以我的原则是：客户端可以做「保护用户」的重试，但绝不做「保护后端」的熔断——后者必须建立在「后端明确告诉我它过载了（429/503 + Retry-After）」的前提上。

想听大家

• 你们团队的读 / 写请求，客户端重试策略是分开管还是统一一套？
• B 端（容错低、用户懂技术）和 C 端（容错高、用户不耐心）你们会用不同的退避 / 熔断参数吗？具体卡在哪几个数上？
• 有网关统一兜底（统一重试 / 限流）的团队，前端还做不做客户端侧的退避？会不会「双重退避」反而把延迟拖长？
• 你怎么判断「这次重试是帮了后端」还是「又添一把火」？有没有可观测的指标（比如按错误码分桶的重试成功率）能反过来验证这套策略？

欢迎贴你们的 axios / fetch 封装片段、参数与踩过的坑，越具体越好。