hystrix-go的errorpercentthreshold设为50却不触发熔断，根本原因是未满足requestvolumethreshold（默认20）的最小请求数门槛，即使错误率100%，前19次失败也不会切换状态；gobreaker半开不进入常因sleepwindow单位误用或探测请求超时失败导致立即回切open。
熔断不是加了就生效，配置错一个参数，gobreaker 或 hystrix-go 就形同虚设。
为什么 hystrix-go 的 ErrorPercentThreshold 设成 50 却不触发熔断？
常见现象是调用持续失败，但熔断器始终卡在 Closed 状态。根本原因不是阈值设低了，而是没满足「统计窗口」前提——RequestVolumeThreshold（最小请求数）没达到，默认是 20。哪怕错误率 100%，前 19 次失败也不会触发状态切换。
-
RequestVolumeThreshold必须显式设置，尤其在低流量接口上，建议按实际 QPS × 统计周期估算（例如 5 QPS × 10 秒 = 50） -
ErrorPercentThreshold是「失败数 / 总请求数」的百分比，不是连续失败次数 - 如果依赖服务响应极慢（比如卡在 DNS 或 TLS 握手），
Timeout必须小于http.Client.Timeout，否则hystrix.Do根本等不到超时就 panic
gobreaker 的 HalfOpen 状态为什么一直不进入？
SleepWindow（打开状态持续时间）一过，熔断器会自动进 HalfOpen，但很多人发现它「跳过了」——实际是 OnStateChange 回调里没做日志，误以为没切换；更常见的是，在 HalfOpen 期间发起的探测请求本身又超时或失败，导致立刻切回 Open，看起来像卡住。
-
SleepWindow单位是毫秒，别写成秒（比如写60 * 1000而不是60） - 半开状态下只允许一个请求通过（
gobreaker默认行为），必须确保这个探测请求足够轻量（比如带HEAD、精简 query、关闭重试） - 别在
onFailure降级函数里再调用同一熔断器，否则形成递归调用，goroutine 泄漏
Gin 中间件里嵌套熔断，为什么并发压测时 goroutine 数暴增？
直接把 hystrix.Do 或 gobreaker.Run 塞进 Gin 中间件，每个请求都新建闭包、捕获上下文、分配临时变量，高频调用下 GC 压力大，且熔断器内部有锁和 ticker，大量并发会争抢。
- 熔断器实例必须复用，全局初始化一次，不要每次请求 new（
gobreaker.NewBreaker返回指针，直接存为包变量） - 避免在熔断回调里调用
c.Abort()或修改c.Writer，Gin 上下文非线程安全，降级逻辑应只处理数据，响应由中间件外层统一输出 - 对非核心路径（如埋点上报、日志投递）直接用
go func() {...}()异步丢弃，别套熔断——它们本就不该影响主链路
降级返回默认值，但用户看到的是空数据或 500？
降级函数（fallback）里 panic 了，或者没正确处理 error 类型，导致 hystrix.Do 把降级失败当主调用失败，反复触发熔断。
-
fallback函数签名必须和主函数一致，且不能 panic；建议用recover()包一层 - 降级结果要能被业务代码识别，比如返回
nil时主逻辑没判空，直接 dereference 就 panic - 别把降级逻辑写成「重试三次再返回默认值」——这违背降级本意，应是「立即、确定、无副作用」的兜底
最易被忽略的点：熔断器不感知网络层失败（如 DNS 解析失败、连接 refused），这些错误不会计入 ErrorPercentThreshold 统计，除非你手动包装成 error 并透传给 hystrix.Do。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
