2026年生产环境必须弃用hystrix-go，改用sony/gobreaker：前者已归档、存在原子计数竞争导致熔断失效、不支持context.Context透传；后者状态稳定、支持自定义ReadyToTrip和OnStateChange，且需按下游服务粒度独立配置实例。
2026 年生产环境必须弃用 hystrix-go，它已归档、原子计数竞争致熔断失效、不支持 context.Context 透传 —— 应立即迁移到 sony/gobreaker。
这不是优化建议，而是故障止损动作。你看到的“熔断生效”，很可能是请求仍在后台 hang 着，goroutine 持续堆积，直到 OOM 或超时级联崩溃。
为什么 hystrix-go 在 2026 年完全不可信
hystrix-go 自 2023 年起归档，官方不再维护。在 Go 1.21+ 高并发场景下，它的核心统计逻辑存在严重竞态：
-
RequestVolumeThreshold和SleepWindow的原子计数器在高 QPS 下会因sync/atomic使用不当而丢失更新，导致熔断器永远卡在Closed状态 - 完全不支持
context.Context透传：即使你在业务函数里用了http.NewRequestWithContext，hystrix.Do也无法将 cancel 信号传递到底层http.Client，超时后 goroutine 仍存活 -
hystrix.Go返回的 channel 若未消费，会永久阻塞 goroutine，且无超时兜底机制
gobreaker.Execute 的 fallback 触发条件极容易误解
gobreaker.CircuitBreaker.Execute 的第三个参数（fallback）**不会**因为主函数返回 error 就执行。它只在两种情况下触发：
立即学习“go语言免费学习笔记（深入）”；
- 熔断器当前处于
gobreaker.ErrOpenState状态（即已打开） - 主函数执行时发生 panic（注意：不是
return err）
这意味着：
- HTTP 请求返回
500、net/http: request canceled、dial tcp: i/o timeout—— 这些都只是普通 error，会被计入失败统计，但**不走 fallback** - 如果你希望这些网络错误也触发降级，必须在主函数内主动
panic，或在外层包装一层判断逻辑 - 常见误写：
return nil, err→ 不触发 fallback；正确写法：panic(err)或if err != nil { return nil, err }+ 单独 fallback 处理
每个下游服务必须配独立的 gobreaker.CircuitBreaker 实例
复用同一个 gobreaker.CircuitBreaker 实例去保护 user-service、order-service、payment-service，等于把所有故障源绑在同一根保险丝上。
- A 服务因 DB 延迟导致错误率飙升 → 熔断器打开 → B 服务所有请求被拒 → 故障污染
- 正确的做法是按服务粒度隔离实例，例如：
userCB := gobreaker.NewCircuitBreaker(...)、orderCB := gobreaker.NewCircuitBreaker(...) - 配置参数也要差异化：支付类服务对延迟敏感，
Timeout应设为 800ms；用户信息类可放宽至 2s
gobreaker 的状态机没有隐藏陷阱，但 ReadyToTrip 必须自定义才可靠
gobreaker 默认的 ReadyToTrip 函数只看错误率，但真实服务中，超时、连接拒绝、5xx 响应码的语义不同。直接用默认策略会导致：
- 偶发 DNS 解析失败（
lookup xxx: no such host）被计入失败 → 错误率虚高 → 误熔断 - 大量
429 Too Many Requests被当成失败 → 实际是限流，不该触发熔断
务必重写 ReadyToTrip：
cb := gobreaker.NewCircuitBreaker(gobreaker.Settings{
Name: "payment-service",
ReadyToTrip: func(counts gobreaker.Counts) bool {
// 只对 5xx 和网络层致命错误熔断
fails := counts.TotalFailures - counts.Responses[429] // 排除 429
return fails >= 5 && float64(fails)/float64(counts.Requests) >= 0.6
},
})最易被忽略的一点：gobreaker 不自动清理旧状态。如果服务长期运行且下游地址变更（如 K8s Service IP 切换），旧熔断器实例可能持续维持 Open 状态，需配合健康检查定期重建实例。
