必须用sony/gobreaker而非hystrix-go——后者已归档、存在原子计数竞争致熔断失效、不支持context.Context透传；每个下游服务须配独立CircuitBreaker实例以防故障污染，MaxRequests≥10、Timeout设15s（非调用超时）、fallback仅在ErrOpenState或panic时触发且须纯内存无副作用。
直接用 sony/gobreaker，别碰 hystrix-go——它已归档、原子计数竞争、不支持 context 透传，2026 年生产环境继续用等于埋雷。
为什么必须每个下游服务配独立 gobreaker.CircuitBreaker 实例
熔断器不是全局开关，而是按依赖隔离的“保险丝”。共用一个实例会让 user-service 故障直接拖垮 payment-service，造成故障污染。
- HTTP 客户端、gRPC stub、DB 连接池，每个都该有自己命名的实例，比如
Name: "user-service-http-call" -
MaxRequests建议 ≥10：设成 1 或 5 容易把瞬时抖动当持续故障，半开刚进就因单次失败又切回 Open -
Timeout是熔断后多久尝试半开（推荐 15s），不是调用超时；单次超时必须由context.WithTimeout控制 -
Interval控制滑动窗口重置周期，30s～2m 之间选；太短（如 5s）会把网络毛刺当持续异常
cb.Execute 只能包住真实调用那一行，不是整个 client
常见错误是把 http.Client 或 grpc.ClientConn 整个塞进 Execute，其实它只该包裹发起请求的动作，比如 client.Do(req) 或 stub.GetUser(ctx, req)。
- 主函数返回
error（如net/http: request canceled、503）→ 计入失败统计，但不触发fallback - 主函数
panic→ 触发fallback - 熔断器状态为
Open→ 直接返回gobreaker.ErrOpenState，才走fallback - HTTP 调用中，
resp.StatusCode >= 500必须主动转成error，否则熔断器无法识别业务失败
降级函数必须纯内存、无副作用、类型严格匹配
fallback 不是兜底万金油，而是受限路径：它只在 ErrOpenState 或 panic 时执行，且签名必须和主函数完全一致（比如 func() (*User, error)）。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 禁止查 Redis、连 DB、调其他 breaker，连
log.Printf都建议走异步 channel - 推荐方案：从
sync.Map或本地 LRU cache 读缓存数据；用DefaultUser()构造显式默认值，而非&User{} - 强一致性操作（如扣库存）不能降级，该熔断或重试，不该返回默认值
- 降级响应要带语义：价格服务不可用 → 返回快照价 + “价格可能有延迟”提示
没监控的熔断等于黑盒拉闸
gobreaker.Metrics 必须接入 Prometheus，重点盯三个指标：circuit_breaker_state、circuit_breaker_requests_total、circuit_breaker_fallback_total。
- 监听
OnStateChange回调，记录状态切换时间戳和当时失败率，便于排查突增失败是否真触发了熔断 - 提供
/health/circuit接口实时查看各依赖熔断器状态 - 上线前必须压测验证：用 goroutine 打满失败请求看是否跳闸，再模拟恢复流量看 Half-Open 是否生效
最容易被忽略的是 fallback 的可观测性与可取消性——它本身也是关键路径一环，得带超时、能被 context 取消、失败时要打点上报，否则降级链路自己就成了新故障点。
