spring boot 全局异常处理无法直接捕获由 resilience4j 或 hystrix 触发的熔断异常，因为熔断器会在调用链外层拦截并抛出特定异常（如 callnotpermittedexception），这些异常不会进入 controller 层的 @exceptionhandler。要解决这个问题，必须在业务逻辑层或配置类中显式捕获这些异常，并将其转换为统一的业务响应对象，或者在调用处进行预处理。
为什么全局异常处理器抓不到熔断异常
全局异常处理器（如 @ControllerAdvice）仅能捕获从 Controller 方法中“冒泡”上来的异常。熔断机制通常通过 AOP 或代理模式包裹在 Service 方法外部执行。当服务提供者不可用或达到阈值时，熔断器会立即抛出 io.github.resilience4j.circuitbreaker.CallNotPermittedException 或 TimeoutException。由于这些异常是在 Service 层被抛出并被熔断器内部处理或重新抛出的，它们往往被视为“已处理”或仅在 Service 层可见，若未在 Service 层转换，它们可能会直接导致 HTTP 500 错误，而不是预期的业务错误码。
import io.github.resilience4j.circuitbreaker.CircuitBreakerRegistry;
import io.github.resilience4j.timelimiter.TimeLimiter;
import io.github.resilience4j.timelimiter.TimeLimiterConfig;
import java.time.Duration;
import java.util.concurrent.Executors;
public class CircuitBreakerDemo {
public static void main(String[] args) {
// 1. 配置熔断器
var config = io.github.resilience4j.circuitbreaker.CircuitBreakerConfig.custom()
.failureRateThreshold(50)
.waitDurationInOpenState(Duration.ofMillis(1000))
.build();
var registry = CircuitBreakerRegistry.of(config);
var circuitBreaker = registry.circuitBreaker("userService");
// 2. 包装调用
var decoratedSupplier = CircuitBreaker.decorateSupplier(circuitBreaker, () -> {
// 模拟远程调用失败
throw new RuntimeException("Service Unavailable");
});
try {
decoratedSupplier.get();
} catch (io.github.resilience4j.circuitbreaker.CallNotPermittedException e) {
System.out.println("Caught: " + e.getClass().getSimpleName());
} catch (RuntimeException e) {
System.out.println("Caught: " + e.getClass().getSimpleName());
}
}
}
上述代码展示了熔断器如何独立于 Spring MVC 流程工作。当 get() 被调用且熔断器处于打开状态时，它会抛出 CallNotPermittedException。如果在 Service 层没有 try-catch 块，这个异常会一直向上抛出。如果 Controller 层也没有捕获它，Spring 的默认错误处理器会接管，返回一个通用的 500 页面，而不是你自定义的业务 JSON 结构。
如何在 Service 层统一转换熔断异常
最稳妥的做法是在 Service 实现类中，对受熔断保护的方法调用进行 try-catch 包装，将特定的熔断异常转换为自定义的业务异常（如 BusinessException）。这样，全局异常处理器就能捕获到标准的业务异常，从而返回统一的格式。例如，创建一个 GlobalExceptionHandler 来专门处理 BusinessException，并在 Service 中将熔断异常映射为该类型。
import org.springframework.web.bind.annotation.RestControllerAdvice;
import org.springframework.web.bind.annotation.ExceptionHandler;
import org.springframework.http.ResponseEntity;
import org.springframework.http.HttpStatus;
@RestControllerAdvice
public class GlobalExceptionHandler {
@ExceptionHandler(BusinessException.class)
public ResponseEntity<result> handleBusinessException(BusinessException ex) {
return ResponseEntity.status(ex.getHttpStatus())
.body(new Result(ex.getCode(), ex.getMessage()));
}
@ExceptionHandler(Exception.class)
public ResponseEntity<result> handleGeneralException(Exception ex) {
return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR)
.body(new Result(500, "Internal Server Error"));
}
}
// 假设的 Service 层处理逻辑
public class UserServiceImpl implements UserService {
private final CircuitBreaker circuitBreaker;
public String getUser() {
try {
return callRemoteService();
} catch (io.github.resilience4j.circuitbreaker.CallNotPermittedException e) {
throw new BusinessException(503, "Service temporarily unavailable due to circuit breaker");
} catch (Exception e) {
throw new BusinessException(500, "Unexpected error");
}
}
}</result></result>
通过这种方式，无论底层是网络超时、服务宕机还是熔断触发，最终都会转化为 BusinessException，由 GlobalExceptionHandler 统一处理。这确保了 API 响应的一致性，前端可以根据 code 字段做出相应的 UI 提示，比如显示“系统繁忙，请稍后重试”。
基于熔断器状态的具体问题：如何区分不同熔断阶段
在实际开发中，可能需要根据熔断器的不同状态（关闭、打开、半开）返回不同的提示信息。可以通过检查异常类型或捕获更具体的异常来实现。例如，CallNotPermittedException 表示熔断器已打开，而 TimeoutException 可能表示调用超时但未触发熔断。可以在 Service 层分别捕获这些异常，并设置不同的错误码和消息，以便前端能更精确地理解当前状况。
