必须按下游服务维度创建独立 gobreaker.CircuitBreaker 实例，因熔断器是每个依赖的“保险丝”，共用实例会导致故障扩散；HTTP、gRPC、DB 等各依赖需专属实例并带服务标识；gRPC 下应按方法名动态路由；Settings 中 Timeout 建议从 30s 起步，ReadyToTrip 应基于错误率（如请求量≥20且失败率＞60%），Interval 设 30s～2min，MaxRequests 半开试探设为1；cb.Execute 仅包裹真实调用（如 client.Do），fallback 需纯内存无副作用、匹配签名、加 timeout；须将 Metrics 暴露至 Prometheus 监控状态切换与 fallback 触发频次。
直接用 sony/gobreaker，别碰 hystrix-go——它已归档、panic 不 recover、不透传 context.Context，2026 年生产环境还在用等于主动埋雷。
为什么必须按下游服务维度创建独立 gobreaker.CircuitBreaker 实例
熔断器不是全局开关，而是每个依赖的“保险丝”。共用一个实例会让支付服务故障把用户服务也拖垮。
- HTTP 客户端、gRPC 连接、数据库连接池，每个都配专属实例，
Name带服务标识，比如"payment-service-call" - 别在 handler 里对本服务逻辑做熔断——那是 panic 恢复或业务校验的事
- gRPC 场景下，按 RPC 方法名（如
"/user.UserService/GetUser"）动态路由到对应熔断器，避免状态污染
gobreaker.Settings 关键参数怎么设才不误判
新手常设 Timeout: 5 * time.Second、ReadyToTrip 判断 ConsecutiveFailures > 3，结果网络抖动就熔断，恢复期又太短，形成“开-关-开”震荡。
-
Timeout是“单次调用超时后才计入失败计数”，不是熔断持续时间；建议从30 * time.Second起步，再根据下游 P95 延迟 ×1.2～1.3 调整 -
ReadyToTrip必须基于错误率而非次数，例如：counts.Requests >= 20 && float64(counts.TotalFailures)/float64(counts.Requests) > 0.6 -
Interval控制滑动窗口重置周期，设30 * time.Second～2 * time.Minute；太短（如5 * time.Second）会把抖动当持续故障 -
MaxRequests半开试探数设为1最安全；设3时若前两个失败，状态切回Open但计数器不重置，容易锁死
cb.Execute 里只包真实调用，且 fallback 必须纯内存无副作用
cb.Execute 不是包裹整个 client，也不是整个 HTTP handler——它只该包住真正发起请求的那一行，比如 client.Do(req) 或 stub.GetUser(ctx, req)。
立即学习“go语言免费学习笔记（深入）”；
- fallback 函数签名必须匹配主函数：
func() (interface{}, error)，内部禁止再发 HTTP/DB 请求 - 推荐返回本地缓存数据、静态默认值、或预计算兜底结果（如“热门商品列表”替代实时推荐）
- fallback 本身必须配合
context.WithTimeout，否则熔断开了，fallback 卡住照样拖垮服务 - 主动将 5xx 响应转成
error，否则gobreaker不会计入失败统计
最容易被忽略的是监控：没暴露 gobreaker.Metrics 到 Prometheus 的熔断器，等于黑盒拉闸。重点盯 circuit_breaker_state、circuit_breaker_requests_total 和 circuit_breaker_fallback_total ——状态切换是否合理、fallback 是否高频触发，这些才是调参的真实依据。
