用 github.com/sony/gobreaker 实现熔断器最稳，它是 Go 社区事实标准，轻量无依赖、支持自定义失败判定与回调；初始化必须传 Settings，Timeout 设为后端 P95 耗时的 2–3 倍，ReadyToTrip 默认统计最近 100 次调用失败率 ≥ 50%，可按错误类型过滤；OnStateChange 回调需异步安全上报，避免阻塞或并发写；HTTP 请求应封装到 Execute 闭包中，每次使用独立 context；熔断器不处理重试，需外层自行添加；状态切换（尤其 HalfOpen→Closed）是服务恢复的关键信号；须防 goroutine 泄漏，确保所有请求受 context 控制，且 gobreaker.Timeout > HTTP client Timeout。
用 github.com/sony/gobreaker 实现熔断器最稳
直接上生产环境，别自己手写状态机。gobreaker 是 Go 社区事实标准，轻量、无依赖、支持自定义失败判定和回调，且经过大量服务验证。
常见错误现象：panic: runtime error: invalid memory address —— 多是没初始化 gobreaker.NewCircuitBreaker 就直接调用了 Execute；或者在并发场景下误把同一个 gobreaker.CircuitBreaker 实例当全局单例复用，却没注意它本身不是线程安全的（实际是安全的，但配置变更需同步）。
- 初始化时必须传入
gobreaker.Settings，其中Timeout建议设为后端依赖 P95 耗时的 2–3 倍，太短会误熔断，太长拖垮调用方 -
ReadyToTrip函数决定何时熔断，默认统计最近 100 次调用中失败率 ≥ 50%，可按需改成基于错误类型过滤（比如只把*http.Client.Timeout当失败，忽略 404） - 不要在
OnStateChange回调里做耗时操作（如发 HTTP 请求、写磁盘），否则阻塞熔断器状态切换
HTTP 客户端请求怎么套熔断逻辑
不是给整个 http.Client 加熔断，而是给「一次具体请求」加。典型模式：封装一个带熔断的请求函数，把原始 Do 逻辑塞进 cb.Execute 的闭包里。
使用场景：调用下游微服务 API、第三方支付网关、内部配置中心等强依赖外部网络的服务。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 每次请求都应新建独立的
context.Context，别复用或漏传，否则超时控制和取消信号失效 - 熔断器不处理重试，
gobreaker只负责“是否允许执行”，重试逻辑得自己在Execute外层加（比如用backoff.Retry） - 如果下游返回
503 Service Unavailable，建议在ReadyToTrip中显式识别并计入失败，而不是只看 error 是否非 nil
resp, err := cb.Execute(func() (interface{}, error) {
req, _ := http.NewRequestWithContext(ctx, "GET", url, nil)
return http.DefaultClient.Do(req)
})
if err != nil {
// 熔断中会返回 gobreaker.ErrOpenState
return nil, err
}
return resp.(interface{}), nil
熔断器状态变化后怎么通知监控系统
靠 OnStateChange 回调上报 Prometheus 或日志，但要注意它会在 goroutine 中异步触发，不能假设执行顺序，也不能依赖其返回值。
容易踩的坑：在回调里直接调用 log.Printf 打印完整 error 对象，结果 panic —— 因为某些 error 实现了 fmt.Stringer 但内部有锁或 panic 逻辑；或者回调中修改了被多个 goroutine 共享的 map，引发 fatal error: concurrent map writes。
- 上报前先做浅拷贝或只取关键字段（如状态字符串、时间戳、当前失败计数）
- 避免在回调里调用任何可能阻塞的 I/O，包括数据库查询、HTTP 请求；如有必要，启动新 goroutine 并加超时
- 状态从
HalfOpen切回Closed时，代表恢复成功，这是比请求成功更可靠的“服务可用”信号
goroutine 泄漏和超时传播怎么防
熔断器本身不管理 goroutine 生命周期，但 Execute 内部发起的请求如果没受 context 控制，就可能卡住 goroutine，尤其在 HalfOpen 状态下试探性请求失败后未及时结束。
性能影响：泄漏的 goroutine 积累到几千个就会明显拖慢 GC 和调度器响应。
- 所有传给
Execute的函数必须接受context.Context并在内部正确传递（比如http.NewRequestWithContext） -
gobreaker.Settings.Timeout和 HTTP client 的Timeout不是同一层：前者控制“整个 Execute 过程最多等多久”，后者控制“单次 HTTP 连接+读写最多耗多久”，两个都要设，且前者 > 后者 - 别在
Execute闭包里启动后台 goroutine（比如用go func(){...}()），否则熔断器无法感知其完成，超时后会强行中断，但 goroutine 还在跑
复杂点在于：熔断器的状态切换时机和业务超时边界不完全对齐，尤其是 HalfOpen 下的试探请求失败后，要等 SteadyStateSleepTime 才重试，这个间隔如果设得太长，用户感知就是“服务突然卡住好几秒”。得结合链路追踪里的延迟毛刺来调参，而不是拍脑袋定 60 秒。
