Go语言需用第三方库实现断路器，最成熟的是sony/gobreaker；它严格遵循三态模型、滑动窗口计数、无锁高性能、支持自定义熔断逻辑，且避免手写常见错误。
Go 语言本身不内置断路器（circuit breaker），必须用第三方库实现；最成熟、生产可用的是 sony/gobreaker，不是 afex/hystrix-go（已归档）或自己手写状态机。
为什么选 gobreaker 而不是其他库
它严格遵循 Martin Fowler 定义的断路器三态（Closed/Open/Half-Open），状态切换逻辑清晰，且默认使用滑动时间窗口计数（非简单计数器），能更好应对突发流量。而 hystrix-go 的熔断判定基于固定时间窗口内的请求数+失败率，窗口切换时有统计毛刺；自己实现容易漏掉半开状态的超时重试控制、并发安全、重置策略等细节。
常见错误现象：panic: concurrent write to map —— 手写断路器没加锁；always in Open state —— 半开状态没设置 ReadyToTrip 回调或超时太短。
- 它支持自定义
ReadyToTrip函数，可按失败率、连续失败次数、响应延迟等任意条件触发熔断 - 底层用
sync/atomic管理状态，无锁读写，性能开销极低（微秒级） - 不依赖 context 或 goroutine 泄漏：所有定时行为由调用方控制（比如在
HalfOpen状态下，由你决定何时发起试探请求）
gobreaker 最简可用示例
别一上来就配一堆参数。先跑通闭环：发起请求 → 失败 → 熔断 → 半开试探 → 恢复。
立即学习“go语言免费学习笔记（深入）”；
import (
"errors"
"time"
"github.com/sony/gobreaker"
)
<p>var cb *gobreaker.CircuitBreaker</p><div class="aritcle_card flexRow">
<div class="artcardd flexRow">
<a class="aritcle_card_img" href="/xiazai/gongju/2525" title="Go语言（Golang）1.26.0"><img
src="https://img.php.cn/upload/manual/001/589/237/6a6adeed24a4a355.png" alt="Go语言（Golang）1.26.0" ></a>
<div class="aritcle_card_info flexColumn">
<a href="/xiazai/gongju/2525" title="Go语言（Golang）1.26.0">Go语言（Golang）1.26.0</a>
<p>Go语言（Golang）1.26.0版本官方下载，版本号 1.26.0，适合旧项目维护、兼容性测试和指定版本开发环境搭建。</p>
</div>
<a href="/xiazai/gongju/2525" title="Go语言（Golang）1.26.0" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a>
</div>
</div><p>func init() {
cb = gobreaker.NewCircuitBreaker(gobreaker.Settings{
Name: "payment-service",
MaxRequests: 1, // 半开状态下只允许 1 次试探
Timeout: 60 * time.Second,
ReadyToTrip: func(counts gobreaker.Counts) bool {
return counts.ConsecutiveFailures >= 3
},
})
}</p><p>func CallPaymentAPI() error {
_, err := cb.Execute(func() (interface{}, error) {
// 这里放真实 HTTP 调用或 RPC
return nil, errors.New("timeout") // 模拟失败
})
return err
}
注意：MaxRequests: 1 是关键——半开时只允许一次试探，避免雪崩；ConsecutiveFailures 统计的是连续失败，不是窗口内总失败数；Execute 返回 (interface{}, error)，你要自己类型断言返回值。
和 HTTP 客户端集成的常见坑
断路器不能套在 http.Client.Do 外层就完事。HTTP 超时、重定向、连接池复用都会干扰断路器对“失败”的判断。
- 务必把断路器放在业务逻辑层，而不是 transport 层：比如封装一个
Pay(ctx, req)函数，再用cb.Execute包裹它，而不是包裹client.Do(req) - 网络超时（如
context.DeadlineExceeded）应视为失败，但 DNS 错误（net.DialError）可能要区分是否重试——需在ReadyToTrip中根据err类型定制逻辑 - 不要在
Execute内部做重试：断路器只管“是否允许执行”，重试逻辑应由上层控制（比如配合backoff.Retry） - 如果用了
roundtripper级代理（如 Jaeger 注入 header），确保断路器包裹的是最终发出请求前的最后一环，否则 span 会漏埋点
监控与动态配置怎么加
gobreaker 提供 cb.State() 和 cb.Counts()，但它们是瞬时快照，不能直接打点。你需要用 goroutine 定期采样并上报。
常见错误现象：goroutine leak —— 忘了用 ctx.Done() 控制采集循环；metrics drift —— 每次调 Counts() 都清零内部计数器（它其实是“自上次采样以来”的增量）。
- 推荐用
prometheus.CounterVec记录cb.Counts().TotalFailures和.TotalSuccesses，标签带上state（来自cb.State()） - 动态修改
Timeout或ReadyToTrip不被支持，只能重建CircuitBreaker实例——所以初始化时建议从配置中心（如 etcd/Viper）加载，并监听变更后热替换 - 日志中记录
cb.State()变更（尤其是Open → HalfOpen），这是故障恢复的关键信号，别只打 debug 日志
真正难的不是接入，是定义什么算“失败”、多大比例该熔断、半开试探间隔设多长——这些必须结合你的服务 SLO 和下游稳定性数据来调，没有通用值。
