应选 gobreaker 而非 hystrix-go：后者自 2019 年停更、不兼容 Go module 且 context 支持弱；前者轻量单文件、线程安全、原生支持 context、可回调打点，并按下游服务维度配置熔断器。
Go 服务熔断该用哪个库？选 gobreaker 而不是 hystrix-go
现在还在用 hystrix-go 的项目基本都卡在维护停滞上——它自 2019 年起不再更新，不兼容 Go module 的 vendor 模式，且对 context 取消、超时传递支持薄弱。生产环境更推荐 gobreaker：轻量（单文件）、无依赖、原生支持 context.Context，且熔断状态变更可注册回调用于打点或告警。
安装命令就是：
go get github.com/sony/gobreaker
-
gobreaker.CircuitBreaker实例是线程安全的，可全局复用 - 默认策略是「连续 6 次失败触发半开，持续 60 秒」，可通过
gobreaker.Settings调整MaxRequests、Timeout、ReadyToTrip等字段 - 不要为每个 HTTP 客户端单独配一个熔断器；按下游服务维度（如
"user-service"）创建熔断器更合理
如何包装一个 HTTP 调用使其具备熔断能力？
核心是把原始调用包进 cb.Execute，它会自动判断状态并决定是否放行。注意：熔断器只管「执行是否允许」，不接管重试或降级逻辑。
func callUserService(ctx context.Context, userID string) (string, error) {
// 假设 cbUserSvc 是预先初始化好的 *gobreaker.CircuitBreaker
result, err := cbUserSvc.Execute(func() (interface{}, error) {
req, _ := http.NewRequestWithContext(ctx, "GET", "https://user/api/v1/"+userID, nil)
resp, err := httpClient.Do(req)
if err != nil {
return nil, err
}
defer resp.Body.Close()
body, _ := io.ReadAll(resp.Body)
if resp.StatusCode != 200 {
return nil, fmt.Errorf("http %d: %s", resp.StatusCode, string(body))
}
return string(body), nil
})
if err != nil {
return "", err
}
return result.(string), nil
}- 必须显式将
ctx传入http.NewRequestWithContext，否则熔断器无法感知上游超时或取消 -
Execute的函数体里不能做耗时阻塞操作（如 sleep、大循环），否则会拖慢状态判断 - 返回值必须是
(interface{}, error)，类型断言要自己处理，别漏掉result.(string)这类强制转换
熔断器总在 closed 和 open 之间抖动？检查 ReadyToTrip 条件是否太敏感
默认行为是「连续 6 次失败就跳闸」，但真实服务可能因偶发网络抖动、DB 连接池打满等短暂异常触发误熔断。这时候需要定制判定逻辑：
立即学习“go语言免费学习笔记（深入）”；
settings := gobreaker.Settings{
Name: "user-service",
MaxRequests: 3,
Timeout: 60 * time.Second,
ReadyToTrip: func(counts gobreaker.Counts) bool {
// 改为：过去 10 秒内失败率 > 50% 且至少失败 5 次才熔断
failedRatio := float64(counts.TotalFailures) / float64(counts.Requests)
return counts.Requests >= 5 && failedRatio > 0.5
},
}
cb := gobreaker.NewCircuitBreaker(settings)- 别直接修改
MaxRequests到 1 或 2，这会让熔断器过于激进 -
Timeout不是单次请求超时，而是「熔断器在 open 状态下等待多久才进入 half-open」 - 如果服务本身 SLA 是 99.9%，建议把失败率阈值设到 0.01～0.05，而不是拍脑袋写 0.5
熔断后怎么降级？别在 Execute 外层硬写 if-else
常见错误是这样写：
// ❌ 错误示范：熔断状态不可靠，且没覆盖半开场景
if cb.State() == gobreaker.StateOpen {
return fallbackData(), nil
}
result, err := cb.Execute(...)
正确做法是让 Execute 自己返回错误，再统一处理：
result, err := cb.Execute(func() (interface{}, error) { ... })
if err != nil {
if errors.Is(err, gobreaker.ErrOpenState) {
// 熔断中，走降级
return fallbackData(), nil
}
// 其他错误（如网络失败、解析异常）仍需上报或重试
return "", err
}
return result.(string), nil-
gobreaker.ErrOpenState是唯一能确定「当前被熔断拒绝」的标识，State()方法在并发下可能过期 - 半开（half-open）状态下，
Execute仍会尝试执行，失败则回退到 open，成功则恢复 closed——你不需要手动干预这个过程 - 降级逻辑本身也应加超时和简单熔断，避免降级路径成为新瓶颈
熔断不是加个库就完事，关键在失败定义是否贴合业务（比如 429 应算失败还是重试？）、指标采集是否及时（建议暴露 gobreaker.Counts 到 Prometheus）、以及降级数据是否真实可用。这些地方一松懈，熔断器反而会掩盖真正的稳定性问题。
