基于Resilience4j注解的CircuitBreaker fallback优先触发，Feign Error Decoder未执行

核心思路 #

问题根源是Resilience4j的CircuitBreaker切面默认包裹了整个Feign调用流程，导致异常刚抛出就被fallback拦截，没机会走到Feign错误解码器。要让错误解码器先处理响应、抛出自定义异常，再让CircuitBreaker决定是否触发fallback（或者直接跳过fallback）。

具体步骤 #

• 配置CircuitBreaker忽略自定义异常
  在application.yml里给你的CircuitBreaker实例添加忽略规则，这样当Feign错误解码器抛出你的自定义异常时，CircuitBreaker不会触发fallback，而是让异常向上传递：

resilience4j.circuitbreaker:
  instances:
    [你的断路器名称]:
      ignoreExceptions: com.your.package.YourCustomException

这里的ignoreExceptions指定的异常会被CircuitBreaker视为“非失败”，不会触发熔断或fallback，正好符合你要让自定义异常替代fallback的需求。

• 完善Feign错误解码器实现
  确保你的错误解码器能正确获取Feign的Response对象，解析后在特定场景抛出自定义异常。示例代码：

public class CustomFeignErrorDecoder implements ErrorDecoder {
    @Override
    public Exception decode(String methodKey, Response response) {
        // 直接获取Response的状态码、body等信息
        int status = response.status();
        if (status == HttpStatus.BAD_REQUEST.value()) {
            try (InputStream bodyStream = response.body().asInputStream()) {
                String errorBody = new String(bodyStream.readAllBytes(), StandardCharsets.UTF_8);
                // 抛出自定义异常，携带解析后的信息
                return new YourCustomException("请求非法: " + errorBody, status);
            } catch (IOException e) {
                return new FeignException.BadRequest(methodKey, response);
            }
        }
        // 其他状态码按默认逻辑处理
        return new Default().decode(methodKey, response);
    }
}

• 调整fallback逻辑（可选）
  如果只需要在非自定义异常的场景保留fallback，确保fallback方法不捕获你的自定义异常即可。要是想完全用自定义异常替代fallback，直接去掉CircuitBreaker的fallback配置，或者把fallback方法设为空实现。

• 验证流程
  模拟触发目标API的错误场景，检查是否先进入Feign错误解码器处理响应、抛出异常，再让CircuitBreaker跳过fallback，最终让自定义异常传递到业务代码中被处理。

内容的提问来源于stack exchange，提问作者Ankit Shrivastav