直接用 gobreaker：它是 Go 生态事实标准，被 grpc-go 和 consul 客户端广泛采用；自己手写易在并发下漏判失败或半开卡死；配置需重点调优 ReadyToTrip、sleepWindow（建议10–30秒）和 maxRequests（3–5），并按依赖维度拆分熔断器。
为什么不用自己手写熔断器：go-hystrix 已停更，gobreaker 是当前事实标准
直接上结论：别造轮子。Go 生态里 gobreaker 是最成熟、被 grpc-go 官方示例和 consul 客户端等广泛采用的实现，它不依赖上下文传播、不强制用 interface{} 包装函数，且错误分类逻辑清晰。自己用 channel + mutex 模拟状态机看似简单，但容易在并发请求激增时漏判失败、误开熔断，或在半开状态未做试探性放行就卡死。
常见错误现象：gobreaker.StateHalfOpen 状态下所有请求都直接返回 ErrTooManyRequests（其实是没配好 ReadyToTrip 回调）；或者熔断后恢复延迟过长，因为默认 sleepWindow 是 60 秒，远超多数服务的故障自愈时间。
-
gobreaker的核心是cb.Execute，它只包装一个func() (interface{}, error)，不侵入业务逻辑 - 错误判定靠
Settings.OnStateChange和Settings.ReadyToTrip，后者必须显式判断哪些 error 该计入失败计数（比如网络超时要熔，但404不该） - 默认失败阈值是 5 次，但实际应结合 QPS 调整：高流量服务建议设为 10–20，低频调用可降到 3
gobreaker 怎么配才不踩坑：重点看 ReadyToTrip 和 sleepWindow
90% 的“熔断不生效”或“一直不恢复”问题，出在两个参数上。默认配置对本地调试友好，但上线后大概率失效。
使用场景：HTTP client 调用下游微服务、数据库连接池初始化、第三方 SDK 的同步方法封装。
立即学习“go语言免费学习笔记（深入）”；
-
ReadyToTrip必须返回true仅当错误属于「可重试失败」：例如net.ErrTimeout、context.DeadlineExceeded、io.EOF，但不能包含sql.ErrNoRows这类业务正常返回 -
sleepWindow别用默认 60s：生产环境建议设为 10–30 秒，否则下游已恢复，你的服务还在拒绝请求 -
maxRequests控制半开状态下最多放行几个试探请求，设太小（如 1）会导致恢复慢，设太大（如 100）可能压垮刚恢复的下游——通常 3–5 是安全值
和 context 配合时的隐藏陷阱：熔断器不自动 cancel 下游请求
很多人以为 cb.Execute 包裹了带 context.WithTimeout 的函数，熔断触发时下游请求就会自动中断。错。熔断器只决定“是否执行”，不干预已开始的 goroutine。
错误现象：熔断开启后，仍看到大量 context deadline exceeded 日志，甚至下游被打挂。
- 必须在被包裹的函数内部显式检查
ctx.Err()，并在收到context.Canceled或context.DeadlineExceeded时主动退出 - 不要把整个 HTTP 请求逻辑塞进
cb.Execute，而应在http.Client.Do前先做熔断判断，再传入带 timeout 的ctx - 如果用
gorilla/mux或gin，熔断逻辑应放在 handler 入口，而非中间件里——中间件无法感知 handler 内部的 context 取消
性能和可观测性怎么加：别只打日志，用 OnStateChange 推指标
线上出问题时，光看 “circuit open” 日志没用。你需要知道：是哪个下游触发的？每分钟失败多少次？半开状态持续多久？这些信息 gobreaker 都能给你，但得主动接。
性能影响极小：状态变更回调是同步调用，只要里面不做阻塞操作（比如写磁盘、发 HTTP），耗时稳定在纳秒级。
-
Settings.OnStateChange回调里，用prometheus.CounterVec记录状态切换次数，标签带上service和state - 避免在回调里做 JSON 序列化或调用
log.Printf—— 高频切换时会拖慢主流程 - 如果用 OpenTelemetry，可在
OnStateChange中创建一个span并设status=error，但注意别重复采样（熔断本身不是错误，只是策略）
真正难的是定义“失败”的边界：同一个熔断器不该既管数据库超时，又管 Redis 连接失败。按依赖维度拆，比按功能拆更可控。这点容易被忽略，一拆就暴露底层依赖治理的问题。
