Java断路器不拦截受检异常，而是预防性熔断调用；需在Client层将IOException等转为运行时异常再交由断路器保护，并下沉至FeignClient等调用层，避免在Controller直接使用。
Java 中不能靠断路器“拦截”受检异常本身，而是用断路器在调用前做状态判断，把本该抛出受检异常的高危调用挡在门外——本质是预防性熔断，不是事后捕获。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
明确断路器不处理受检异常的传播路径
受检异常（如 IOException、SQLException）必须被声明或捕获，断路器组件（如 Resilience4j）的注解或代理方法默认不支持 throws 声明。所以： • 断路器不会帮你自动 catch 并吞掉受检异常 • 你仍需在调用方写 try-catch 或向上 throws，但此时断路器已提前拒绝调用，根本不会走到抛异常那步 • 真正被“拦截”的，是调用动作本身；失败统计只针对已发生的调用，而断路器打开后直接跳过执行
把第三方接口包装成断路器友好的调用点
关键是在调用链最外层（如 Client 层）封装原始接口，将受检异常转为运行时异常或统一业务异常，再交给断路器保护： • 编写一个 paymentClient.charge() 方法，内部用 try-catch 捕获 HttpClient 的 IOException，转为 PaymentNetworkException（运行时异常） • 在该方法上加 @CircuitBreaker(name = "payment")，并配 @Fallback • 断路器只感知 PaymentNetworkException 是否频繁发生，不关心原始 IOException 是否受检 • fallback 方法返回降级结果，完全绕开异常处理逻辑
配合重试与异常分类提升稳定性
对易出错的第三方接口，单靠断路器不够，要分层响应： • 将连接超时、读取超时等可恢复异常标记为“允许重试”，配置 retryTemplate + 断路器联合使用 • 对 4xx 类业务拒绝（如余额不足）不计入失败计数，避免误熔断 • 设置 failureRateThreshold=50 和 waitDurationInOpenState=60s，给下游服务留出恢复时间 • 日志中记录原始异常 cause 和请求上下文（traceId、订单号），确保跳闸后可追溯根因
避免在 Controller 层直接套断路器
断路器是服务调用层的防护，不是 Web 层的兜底： • 不要在 @RestController 方法上直接加 @CircuitBreaker，会导致 HTTP 调用和远程服务调用混在同一熔断器里 • 应下沉到 FeignClient、RestTemplate 封装类，或自定义的 XxxServiceClient 中 • Controller 只负责接收请求、组装参数、调用被保护的 client 方法，并处理最终 fallback 返回值
