因axios/fetch无内置重试与熔断机制，无法应对服务抖动；需组合指数退避重试与断路器（如resilience4j或gobreaker+backoff），且须确保断路器统计单次请求而非重试后结果。
为什么直接用 axios 或 fetch 无法满足高可靠异步请求？
因为它们本身不带重试策略、不感知下游稳定性、也不记录失败历史。当后端服务短暂抖动（如 503、超时、连接拒绝），裸调用会立刻失败，而真实场景需要：失败后延迟重试（且间隔递增），连续失败到阈值就主动熔断，避免雪崩。这不是“加个 retry 选项”能解决的——axios-retry 不支持指数退避参数定制，更不联动断路器状态。
resilience4j 是目前最轻量可控的 Java 网关方案
它把“重试”和“断路器”拆成独立组件，可组合、可监控、不侵入业务逻辑。关键不是堆功能，而是控制粒度细：
-
RetryConfig支持自定义maxAttempts、waitDuration、intervalFunction（用IntervalFunction.ofExponentialBackoff实现指数退避） -
CircuitBreakerConfig可设failureRateThreshold（如 50%）、waitDurationInOpenState（熔断后静默期）、slidingWindowSize（滑动窗口大小决定统计精度） - 两者通过
Decorators组合：Decorators.ofSupplier(xxx).withRetry(retry).withCircuitBreaker(cb).decorate()
注意：不要把重试和断路器套在同一个 Supplier 外层再嵌套——这会导致熔断器统计的是“重试后的最终结果”，而非“单次请求成败”，失去意义。正确做法是先重试、再由断路器包裹整个重试块。
Go 里用 gobreaker + backoff 组合要避开三个坑
gobreaker 本身不带重试，必须自己集成；而 backoff 库默认重试不感知断路器状态。常见错误写法是：
for i := 0; i <p>问题在于：<code>cb.Allow()</code> 检查的是“当前是否允许发起请求”，但 <code>time.Sleep</code> 后没再检查——可能刚睡醒熔断器已跳闸。正确做法是每次循环开头都调 <code>cb.Allow()</code>，且失败后立即调 <code>cb.Failure()</code>，成功才调 <code>cb.Success()</code>。另外，<code>backoff.ExponentialBackOff</code> 的 <code>InitialInterval</code> 和 <code>MaxInterval</code> 必须显式设置，否则默认为 1s/60s，不适合高频短时服务。</p><h3>Node.js 场景下别迷信 <code>async-retry</code> + <code>opossum</code> </h3><p><code>async-retry</code> 的 <code>factor</code> 参数名易误导——它不是“乘数”，而是“底数”，即间隔按 <code>initial * factor^attempt</code> 增长；而 <code>opossum</code> 的断路器默认只统计 <code>reject</code>，不捕获超时或网络异常（需手动包装 <code>Promise.race</code> 加 <code>setTimeout</code>）。实操建议：</p>
- 用
retry({ factor: 2, minTimeout: 100, maxTimeout: 5000 })控制退避曲线 - 断路器创建时传
{ errorThresholdPercentage: 40, timeout: 10000 }，并确保所有请求都走circuit.fire(promise)而非直调 - 务必监听
circuit.on('open')和'halfOpen'事件做日志，否则熔断触发后你根本不知道
真正的难点不在拼凑组件，而在“失败判定边界”——HTTP 500 要重试，503 要熔断，429 要降频，这些状态码必须在重试前就被路由到不同策略分支，而不是全扔给同一套退避逻辑扛。
