推荐新项目直接用sony/gobreaker而非已归档的afex/hystrix-go，因其轻量、线程安全、原生支持context.Context；关键参数需按下游P95耗时与错误类型调优，ReadyToTrip应基于错误率而非单纯次数，降级逻辑须纯内存无副作用。
Go里没有官方Hystrix，得用go-hystrix或hystrix-go
Go生态里没有Netflix原版Hystrix，主流替代是afex/hystrix-go（已归档但仍在广泛使用）或更活跃的sony/gobreaker。后者不是Hystrix克隆，但语义接近、API更简洁，推荐新项目直接用gobreaker。如果你团队已有hystrix-go历史代码，注意它依赖gorilla/context（已废弃），在Go 1.7+中需替换为context.Context手动适配。
熔断器配置参数直接影响恢复行为
熔断是否及时触发、失败后多久尝试恢复，全靠几个关键参数控制：
-
Interval：滑动窗口时长，默认5秒——太短会导致误熔断，太长则响应滞后 -
Timeout：单次调用超时时间，必须小于下游服务真实超时值，否则熔断器没机会介入 -
MaxConcurrentRequests：并发请求数上限，设太低会人为限流，设太高则失去保护意义 -
RequestVolumeThreshold：窗口内最少请求数才开始统计错误率，默认20——流量低的服务可能永远不触发熔断 -
SleepWindow：熔断后等待多久进入半开状态，默认60秒——这是“恢复”的起点，不是立即重试
例如下游接口P99是800ms，建议设Timeout: 1000、SleepWindow: 30000（30秒），避免等太久才试探性恢复。
半开状态下失败一次就回熔断，成功需连续通过才关闭
熔断器进入半开状态后，并非“试一次成功就恢复”，而是按gobreaker默认策略：首次请求放行，若成功则重置状态；若失败，则立刻回到熔断态。但hystrix-go更严格——它要求半开期间连续minSuccesses次成功（默认1）才关闭熔断，实际效果类似。容易忽略的是：半开期间所有失败请求都会重置计数器，所以高错误率下游可能长期卡在半开与熔断之间。
立即学习“go语言免费学习笔记（深入）”；
cb := gobreaker.NewCircuitBreaker(gobreaker.Settings{
Name: "user-service",
ReadyToTrip: func(counts gobreaker.Counts) bool {
return counts.ConsecutiveFailures > 5
},
OnStateChange: func(name string, from gobreaker.State, to gobreaker.State) {
log.Printf("CB %s state change: %v → %v", name, from, to)
},
})
HTTP客户端封装必须透传context并处理ErrTooManyRequests
直接把http.Client塞进熔断逻辑容易漏掉两点：一是超时未由context.Context传递，二是熔断拒绝请求时返回的是gobreaker.ErrTooManyRequests（或hystrix.ErrMaxConcurrencyExceeded），不是HTTP状态码。必须显式拦截这类错误，否则上层可能当作500处理。
- 用
ctx, cancel := context.WithTimeout(context.Background(), timeout)构造请求上下文 - 调用前检查
cb.IsAllowed()并提前返回，避免无谓排队 - 捕获
gobreaker.ErrTooManyRequests，转成http.StatusServiceUnavailable或自定义错误码 - 别在handler里new CircuitBreaker，应全局复用实例，避免状态隔离
真正麻烦的不是加熔断，而是下游服务恢复后，上游缓存、重试逻辑与熔断器状态不同步——比如Redis缓存了旧错误响应，或重试中间件在熔断期间反复发起请求，导致ConsecutiveFailures居高不下。
