最稳妥方案是直接使用 gobreaker 库，它被 go-zero 和 kratos 验证成熟，支持滑动窗口统计、半开探测且无外部依赖；需正确配置 maxrequests（≥10）、timeout（15s）、interval（30s～2m），并在客户端调用处用 cb.execute 包裹 do 操作，配合 context.withtimeout 和 fallback 降级，同时暴露指标便于观测。
Go 用 gobreaker 实现熔断器最稳妥
直接上结论：别自己手写状态机，gobreaker 是当前 Go 生态最成熟、被 go-zero 和 kratos 等主流框架验证过的熔断库。它默认用滑动窗口统计失败率，支持半开状态探测，且不依赖任何外部组件。
常见错误是把 gobreaker.Settings 里 MaxRequests 设得过小（比如 1），导致半开状态刚进去就拒绝所有请求；或者把 Timeout 设成秒级（如 60），结果下游恢复了，熔断器还在休眠。
-
Interval控制“多长时间重置计数器”，建议设为 30s～2m，太短会误判瞬时抖动 -
Timeout是“熔断后多久尝试半开”，不是超时时间，设 15s 比较合理 - 必须配合
context.WithTimeout使用——熔断器只管开关，不替你做超时控制
cb := gobreaker.NewCircuitBreaker(gobreaker.Settings{
Name: "user-service-call",
MaxRequests: 10,
Timeout: 15 * time.Second,
ReadyToTrip: func(counts gobreaker.Counts) bool {
return counts.ConsecutiveFailures > 5
},
})
HTTP 客户端调用前加 cb.Execute 就完事
熔断不是加在服务端，而是加在发起依赖调用的客户端代码里。比如你用 http.DefaultClient 调第三方用户服务，就在 Do 前包一层 cb.Execute。
容易踩的坑是把整个 http.Client 实例塞进 Execute，其实只需要包住 Do 这一调用。另外，Execute 的第二个参数是函数，必须返回 error，否则熔断器无法识别失败。
- 返回
nil表示成功，非nil错误才计入失败计数 - 网络超时（
net/http: request canceled）、连接拒绝（dial tcp: i/o timeout）都算失败 - HTTP 5xx 响应码要你自己判断并返回 error，熔断器不会自动解析 status code
_, err := cb.Execute(func() (interface{}, error) {
resp, err := http.DefaultClient.Do(req)
if err != nil {
return nil, err // 网络层错误直接透出
}
if resp.StatusCode >= 500 {
return nil, fmt.Errorf("server error: %d", resp.StatusCode) // 主动转 error
}
return resp, nil
})
降级逻辑必须写在 cb.Execute 的 fallback 分支里
熔断器本身不提供降级能力，gobreaker 的 Execute 第三个参数才是 fallback 函数。很多人以为熔断打开后会自动走默认值，其实不传 fallback 就直接 panic。
典型场景是查用户信息失败时返回缓存或空结构体。注意 fallback 函数不能有副作用（比如再发一次请求），也不能抛 panic——它只该做安全、快速、确定性的兜底。
- fallback 返回
(interface{}, error)，类型要和主函数一致，否则类型断言会失败 - 不要在 fallback 里调用另一个可能熔断的服务，否则形成级联风险
- 如果 fallback 也报错，
Execute会把 fallback 的 error 当作最终 error 向上抛
result, err := cb.Execute(
callUpstream,
func() (interface{}, error) {
return getCachedUser(userID), nil // 快速返回缓存
},
)
别忽略 gobreaker 的指标暴露和调试成本
线上出问题时，你没法靠日志猜熔断器当前状态。它内部用原子变量维护 state（closed/open/half-open），但没暴露 getter。想确认是否误熔断，得自己加 metrics 或打 debug 日志。
性能上几乎无损耗（就是几次原子操作+函数调用），但如果你高频调用（QPS > 5k），要注意 gobreaker 默认的 CountError 是用 sync/atomic，没问题；可一旦开了自定义 OnStateChange 回调，就得小心锁竞争。
- 上线前务必用
go test -race跑一遍，尤其在OnStateChange里做 log 或 metrics 上报时 - 别在
OnStateChange里做阻塞操作（如写文件、发 HTTP），它会卡住熔断器状态切换 - 生产环境建议用
prometheus暴露gobreaker_state{breaker="xxx"}这类指标，比查日志快得多
真正难的从来不是加熔断，而是怎么定义“失败”——是只看连接错误，还是包含业务错误码？要不要排除 404？这些边界条件，比选哪个库重要得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
