断路器模式不减少try-catch语法开销，但通过提前熔断、避免异常抛出、解耦重试降级、异步上报指标，显著降低异常频率与影响，从而间接减轻其性能负担。
断路器模式本身不减少 try-catch 语法开销，但它能显著降低异常实际发生的频率和影响范围，从而间接削弱 try-catch 在高并发场景下的性能负担。关键不是少写几行 catch，而是让系统更早拦截失败、避免层层抛异常、减少异常对象创建与栈展开——这些才是真正拖慢响应的根源。
用断路器提前拦截故障，避免异常穿透到业务层
当下游服务（如支付接口、用户中心）持续超时或返回 5xx，若每次调用都走完整链路再抛 ClientResponseException 或 TimeoutException，就会触发大量异常创建、日志记录、堆栈填充。断路器在连续失败达到阈值后直接熔断，后续请求在入口就返回降级结果，根本不进入 try-catch 包裹的远程调用逻辑。
- 熔断状态下，调用直接走 fallback 方法，跳过所有可能抛异常的 I/O 操作
- 无需在 service 层写 try { remoteCall(); } catch (FeignException e) { return fallback(); } —— 异常根本不会发生
- 配合 Resilience4j 的 CircuitBreaker.decorateSupplier()，可将原始调用包装为“自带熔断能力”的 Supplier，业务代码完全无感知
把重试和降级逻辑从 catch 块中移出，消除阻塞式异常处理
常见反模式是在 catch 中同步 sleep + retry，既延长单次响应时间，又因线程阻塞加剧资源争抢。断路器天然支持配置重试策略（如 RetryConfig.withMaxAttempts(3)），且重试发生在断路器内部、与业务 try-catch 解耦：
- 重试由独立线程池执行，不占用主请求线程
- 失败后自动触发 fallback，无需在 catch 块里手动构造返回对象或查缓存
- 避免了在 catch 中调用 Redis、DB 等二次依赖——这些操作本身又可能抛新异常，形成嵌套 try-catch 链
结合指标上报，替代“异常即监控”的低效做法
很多团队靠 catch (Exception e) { log.error("xxx", e); } 实现错误统计，但高频异常会导致日志刷屏、磁盘 IO 拖慢响应。断路器自带事件监听（onStateTransition、onCallNotPermitted），可异步上报熔断次数、失败率、降级数等聚合指标：
立即学习“Java免费学习笔记（深入）”；
- 不再依赖异常抛出来触发监控，也就不再需要为“可观测性”而刻意保留宽泛的 try-catch
- 指标数据更稳定（不受异常堆栈长度、日志格式变化影响），且不参与事务上下文
- 当 errorRateThreshold 达到 50%，系统自动告警，无需等运维翻日志才发现问题
避免断路器自身成为异常源，保持轻量闭环
断路器若实现不当（如状态变更未加锁、缓存失效竞争），反而会引入新的异常点。应确保：
- 使用 Resilience4j 或 Sentinel 等成熟实现，不手写状态机
- 断路器实例复用（按服务粒度单例），避免每个请求新建对象造成 GC 压力
- fallback 方法必须是纯内存操作（如返回兜底 JSON、读本地配置），禁止再发起远程调用或 DB 查询
