errorRateThreshold 配成 20% 日常抖动就把整条链路熔断

支付查询接口的熔断规则配成异常率 20%，上线第二天上午 10 点整条链路进 OPEN，10 分钟里 3.2 万次请求全走 fallback。同一时段依赖服务自己的错误率只有 0.4%，P99 从 180 毫秒抖到 260 毫秒。第一次遇到会往复杂处想，其实漏掉的多是个小前提。

resilience4j.circuitbreaker.instances.payQuery:
  slidingWindowType: TIME_BASED
  slidingWindowSize: 60
  minimumNumberOfCalls: 200
  failureRateThreshold: 50

统计窗口只有 10 秒，样本不到 200 个请求，两三个超时就能把比例顶过 20%。阈值是照压测数据定的，压测里没有这么多慢请求，线上一个 GC 停顿就把窗口打满。这一点先确认清楚，后面就不用反复试。

「熔断阈值误触发」这个问题文档写得含糊，实际行为以当前版本为准，别照旧版本的结论套。

具体做法是，把滑动窗口拉到 60 秒并且最小请求数设到 200 避免小样本误判；阈值按依赖方 SLO 留一倍余量 错误率到 50% 再断而不是 20%；对超时和业务异常分开统计 只有超时才计入熔断计数；改完在灰度实例上跑一天 对比熔断次数和依赖真实错误率。

改完照着核一遍，灰度实例一天熔断 0 次，依赖方真实错误率 0.4% 时不再进 OPEN，人工打挂依赖 30 秒能正常熔断。