最稳妥方案是直接使用 gobreaker 库而非手写状态机，它轻量无依赖、符合 martin fowler 定义，并被 go-zero 等主流框架采用；需区分重试与断路器，正确包装 roundtrip、避免闭包陷阱、确保降级逻辑纯内存化。
Go 里用 gobreaker 实现断路器最稳妥
直接上结论：别自己手写状态机，用 gobreaker 库——它轻量、无依赖、行为符合 Martin Fowler 原始定义，且被 go-zero、kratos 等主流框架内部采用。
常见错误是把重试（retry）和断路器混为一谈：Retry 解决临时抖动，CircuitBreaker 解决持续性故障；前者可能让下游雪崩，后者主动熔断保护系统。
-
gobreaker.NewCircuitBreaker接收一个gobreaker.Settings，关键字段是MaxRequests（半开态允许试探请求数）、Timeout（熔断时长）、ReadyToTrip（触发熔断的判定函数） - 默认
ReadyToTrip统计最近 100 次调用，失败率 > 60% 就熔断；高频低延迟服务可调小RequestVolumeThreshold避免误判 - 注意：
gobreaker不自动记录指标，要打点得在onStateChange回调里自己上报metrics.Counter或日志
HTTP 客户端集成断路器必须包装 RoundTrip
很多人想“给整个 http.Client 加断路器”，但 Go 的 http.Client 没法拦截单次请求——必须把断路器逻辑塞进 Transport.RoundTrip。
典型场景是调用下游 HTTP 服务时防止线程池耗尽。不包装 RoundTrip，只在外层套一层 cb.Execute，会导致超时控制失效、连接复用被破坏。
立即学习“go语言免费学习笔记（深入）”；
【极品模板】出品的一款功能强大、安全性高、调用简单、扩展灵活的响应式多语言企业网站管理系统。 产品主要功能如下： 01、支持多语言扩展（独立内容表，可一键复制中文版数据） 02、支持一键修改后台路径； 03、杜绝常见弱口令，内置多种参数过滤、有效防范常见XSS； 04、支持文件分片上传功能，实现大文件轻松上传； 05、支持一键获取微信公众号文章（保存文章的图片到本地服务器）； 06、支持一键
- 写一个自定义
RoundTripper，在RoundTrip方法里调用cb.Execute，传入原始*http.Request和底层http.DefaultTransport.RoundTrip - 务必透传
context.Context，否则cb.Execute内部超时和外部http.Client.Timeout冲突 - 错误处理要区分：
gobreaker.ErrOpenState表示已熔断，这时该返回降级响应；而net/http错误（如net/url.Error）才进失败统计
cb.Execute 的闭包陷阱：不要在闭包里捕获可变变量
这是线上最隐蔽的坑：断路器执行时 panic 或返回错误，不是因为下游挂了，而是闭包引用了循环变量或未初始化的指针。
比如在 for 循环里批量创建断路器调用，却把 req 变量直接闭包进去：cb.Execute(func() (interface{}, error) { return client.Do(req) }) —— 最后所有闭包都用同一个 req 地址，导致请求错乱或 panic: http: Request.Write on Body closed。
- 正确做法是把参数显式传入闭包：
func(req *http.Request) func() (interface{}, error) { return func() (interface{}, error) { return client.Do(req) } } - 更安全的是用局部变量复制关键字段：
method, url := req.Method, req.URL.String()，再在闭包里用它们构造新*http.Request - 如果闭包里用了
defer，确保它不依赖外部作用域的变量生命周期，尤其涉及io.Closer
熔断后降级逻辑不能依赖外部网络调用
断路器打开时，你写的降级函数（fallback）如果再去查 Redis 或调另一个 HTTP 接口，等于把故障面扩大了一倍——这违背断路器的设计初衷。
真实服务里，降级常踩的坑是“伪降级”：比如 fallback 里调用本地缓存，但缓存 client 本身没配断路器，结果缓存服务一抖，降级链路也跟着挂。
- 降级逻辑必须是纯内存操作：返回硬编码值、读取本地
sync.Map、或从已加载的配置结构体取值 - 如果真需要外部数据，得提前预热到内存，并用
time.AfterFunc定期刷新，而不是每次 fallback 都去拉 - 上线前务必压测熔断态：手动触发
cb.HalfOpen()后立即发请求，确认 fallback 不抛 panic、不阻塞 goroutine、不产生新 goroutine 泄漏
断路器真正的复杂点不在代码怎么写，而在状态切换时机和降级策略的边界判断——比如半开态下第 1 个试探请求成功，但第 2 个失败，此时是否回滚到熔断？gobreaker 默认会，但你的业务是否接受这种“试探成本”？得结合 SLA 自己权衡。
