标准熔断器在突发流量下易误熔断，因其依赖固定窗口或硬计数统计失败率，无法区分雪崩前兆与偶发抖动，且忽略延迟反馈；应改用EWMA动态评分+延迟直方图+自适应半开探测。
为什么标准 circuitbreaker 包在突发流量下容易误熔断
Go 生态里常见的 sony/gobreaker 或 resilience-go 熔断器，底层多基于固定窗口或滑动计数器统计失败率。当突发流量在极短时间内（比如 100ms 内）集中打进来，哪怕成功率仍高于阈值（如 95%），失败请求数的绝对值也可能瞬间冲高，触发熔断——这不是系统真不可用，而是统计粒度太粗、响应太“刚性”。
关键问题在于：它们没区分「失败是因过载导致的雪崩前兆」还是「偶发网络抖动」；也没有根据当前负载动态调整敏感度。
-
gobreaker的Settings.ConsecutiveFailures是硬计数，不带时间衰减 - 滑动窗口若用数组实现（如 10 个 1s 桶），突发流量会扎堆塞进同一个桶，放大波动
- 所有主流实现默认不采集成功请求的延迟分布，无法识别“慢成功”这种隐性过载信号
用指数加权移动平均（EWMA）替代固定窗口计数
把失败率换成对“异常信号”的连续评分更稳妥。例如维护一个 errorScore，每次失败时按衰减因子 α 更新：errorScore = α * errorScore + (1−α) * 1.0；成功时则反向压制：errorScore = α * errorScore − (1−α) * 0.2（系数可调）。α 取 0.95～0.99，让历史影响缓慢衰减。
这样，短时爆发只会抬升分数，但不会直接跳变；持续失败才会让分数越过阈值。你不需要存窗口数据，内存恒定，也规避了桶切换时的统计毛刺。
- 初始化时设
errorScore = 0.0，阈值建议从0.7起调 - 避免在锁内做浮点运算，可改用定点整数（如放大 1000 倍）提升性能
- 注意：
math.Float64bits在并发更新时需用atomic.AddUint64模拟 CAS，别直接读写float64
加入请求延迟反馈，让熔断器感知“慢”而非只看“错”
真实过载常表现为 P95 延迟陡增，而非错误率飙升。可在熔断器中嵌入一个轻量级延迟直方图（如 hdrhistogram），每完成一次调用就记录耗时。当最近 60 秒内 P95 > 2 * 基线延迟（基线取过去 10 分钟 P95 中位数），且 errorScore > 0.6，才进入半开状态。
这相当于给熔断器加了一双眼睛：它不再机械计数，而是综合“错得多不多”和“慢得厉不厉害”做判断。
- 基线延迟需异步定期更新（比如每分钟重算一次），避免被瞬时毛刺污染
-
hdrhistogram的RecordValue是无锁的，但GetQuantileValue需要快照，建议用Copy后再查 - 不要在每次调用后都计算 P95——攒够 100 个样本再触发一次评估，减少 CPU 开销
半开状态必须带自适应探测节奏
传统熔断器在半开时只允许固定数量（如 1 个）请求通过，极易因单次偶然失败又跌回熔断。更好的做法是：根据当前 errorScore 和延迟基线偏移量，动态决定探测请求数量与间隔。
例如：若 errorScore = 0.65 且 P95 偏移 1.8x，只放行 1 个探测请求，间隔 1s；若 errorScore = 0.52 且偏移 1.2x，则放行 3 个，间隔 200ms。探测成功后，按比例下调 errorScore，而非直接归零。
- 探测请求应走独立的轻量路径（绕过日志、metrics 上报等非核心逻辑），减少干扰
- 务必设置探测超时（如基础超时的 50%），避免半开期被长尾请求拖死
- 没有“自动恢复”这回事——如果探测期间出现新失败，立即退回熔断，且将
errorScore加倍惩罚
真正难的是平衡灵敏度和稳定性：太激进，业务抖动就熔；太保守，雪崩来了拦不住。参数不是配出来，是压测时盯着 errorScore 曲线和延迟分位图调出来的。别信默认值。
