Resilience4j 的 CircuitBreaker 需配置 failureRateThreshold（如50表示50%）、slidingWindowType（COUNT_BASED或TIME_BASED）和 slidingWindowSize 才能按异常比例触发降级，且必须通过 decorateSupplier 等包装调用，异常需未被 ignoreExceptions 排除，同时 minimumNumberOfCalls 应适配流量以确保比例计算有效。
Resilience4j 的 CircuitBreaker 怎么配异常比例触发降级
Resilience4j 默认用失败次数计数，不是异常比例；要按比例触发，必须显式配置 failureRateThreshold 并启用滑动窗口。
-
failureRateThreshold设为 50 表示 50%，不是 0.5 —— 写错成小数会直接忽略配置 - 必须同时设
slidingWindowType: COUNT_BASED或TIME_BASED，否则滑动窗口不生效，failureRateThreshold形同虚设 - 搭配
slidingWindowSize: 10时，只有最近 10 次调用里失败 ≥5 次才会跳闸；时间窗口则看指定秒数内的失败占比 - 注意：异常必须是
CircuitBreaker显式记录的失败（比如抛出非忽略异常），ignoreExceptions里声明的不会计入统计
为什么 recordFailure 不生效，降级总不触发
常见原因是异常被吞了、或没走 Resilience4j 的执行路径 —— 它只对 decorateSupplier、decorateCheckedSupplier 等包装后的调用生效。
- 直接调用原始方法（没套
CircuitBreaker.decorateSupplier(...)）时，任何配置都无效 - 用了
decorateCheckedSupplier却抛出运行时异常（RuntimeException），它默认不视为失败；需手动调用circuitBreaker.recordFailure(e) - 异步场景下用了
CompletableFuture.supplyAsync包一层，但没用CircuitBreaker.decorateCompletionStage，断路器完全感知不到 - Spring Boot 自动配置时，若方法没加
@CircuitBreaker(name = "xxx")注解，或切面没生效（比如在同一个类内调用），也会静默失效
降级逻辑写在哪？fallback 和 handleException 别混用
Resilience4j 本身不提供“自动 fallback 函数”，降级必须靠你手动组合：失败时捕获 CircuitBreakerOpenException，或用装饰器链明确指定备选逻辑。
- 推荐用
Try.ofSupplier(...).recover(throwable -> fallbackValue)，比裸 try-catch 更契合函数式风格 - 不要在
recordFailure回调里写降级逻辑 —— 它只负责记日志或发告警，不控制流程 - Spring 环境下，
@CircuitBreaker(fallbackMethod = "xxx")的降级方法签名必须和原方法一致，且参数不能少；多一个Throwable参数是允许的，但位置必须在最后 - 如果降级方法抛异常，且没被
ignoreExceptions覆盖，可能再次触发断路器，形成隐式循环
并发高时断路器状态不准？滑动窗口大小和最小调用次数很关键
低流量下容易误开/误关，因为默认 minimumNumberOfCalls: 100 没达到，断路器始终处于 HALF_OPEN 或不统计状态。
立即学习“Java免费学习笔记（深入）”；
- 测试或低频服务务必调低
minimumNumberOfCalls（比如设为 5），否则永远凑不够样本，比例计算无从谈起 - 滑动窗口太小（如
slidingWindowSize: 5）会导致抖动敏感——一次网络毛刺就跳闸；太大（如 1000）又反应迟钝，雪崩已发生才响应 -
waitDurationInOpenState别设太短（低于 1s），否则频繁试探下游，反而加重压力 - 注意：Resilience4j 的断路器是实例级的，多个线程共用同一状态；没有全局锁，但内部用 CAS 保证原子性，不用额外同步
比例型断路器真正起效的前提，是流量足够填满滑动窗口且跨过最小调用门槛——这点在压测或灰度阶段最容易被忽略。
