应使用 sony/gobreaker 而非已归档的 hystrix-go；每个下游服务需独立 breaker 实例，按依赖维度初始化并复用；RequestVolumeThreshold 建议设为 6～10；fallback 仅在 ErrOpenState 或 panic 时触发，须显式处理；HTTP fallback 的 Response.Body 不可为 nil；超时必须由 context 控制，且 HTTP 超时应比 breaker.Timeout 短 20%～30%；可观测性依赖 OnStateChange 手动埋点并暴露 /health/circuit 接口。
直接用 sony/gobreaker，别碰 hystrix-go——它已归档、原子计数有竞态、不支持 context，2026 年生产环境踩坑率极高。
每个下游服务必须配独立 gobreaker.CircuitBreaker 实例
复用一个实例包多个依赖（比如 user-service 和 order-service 共用同一个 breaker），等于把故障面拉平：A 服务挂了，B 服务的调用也被拦住。这不是熔断，是误杀。
- 按依赖维度初始化：一个服务一个 breaker，存在包级变量或注入到 client 结构体里
- 别在函数内调用
gobreaker.NewCircuitBreaker—— 每次都新建 = 每次都从零统计，熔断失效 - 配置里
RequestVolumeThreshold建议设为 6～10，太小易误熔，太大响应迟钝
cb.Execute 的 fallback 不是自动触发的降级入口
很多人以为只要传了 fallback 函数，熔断或超时就会走它。实际只在两种情况触发：gobreaker.ErrOpenState（熔断器处于 Open）或主函数 panic。主函数返回 error（比如网络超时、5xx）不会进 fallback，但会记为失败。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 正确写法：显式捕获
err == gobreaker.ErrOpen，再手动调用降级逻辑 - fallback 函数本身不能发 HTTP、查 DB、调其他 breaker，必须快、无副作用、不 panic
- HTTP 场景下，fallback 返回的
*http.Response必须带非 nilBody字段，否则上层io.Copy会 panic
超时必须由 context.WithTimeout 控制，gobreaker.Settings.Timeout 只管熔断器等待时间
gobreaker.Settings.Timeout 是熔断器等 Execute 内部函数返回的最大时长，不是请求超时。它不中断底层 HTTP 连接，goroutine 会一直挂着直到真正完成或被系统 kill。
- 所有
http.Client.Do必须传入带超时的ctx，且超时时间建议比gobreaker.Timeout短 20%～30% - 例如：HTTP 超时设 800ms，breaker
Timeout设 1.2s，确保多数失败由超时捕获，而非填满窗口才响应 - 漏掉
ctx透传，会导致连接堆积、goroutine 泄漏、长尾请求拖垮整个 handler
可观测性只能靠 OnStateChange 手动埋点
gobreaker 没内置 metrics，也没有 WithMetrics 选项。Prometheus 或 Datadog 接入全靠你监听 OnStateChange 回调，并用原子变量维护瞬时指标（当前请求数、失败数、成功率）。
- 只记录状态切换（如 Closed→Open）远远不够；必须同步更新并上报实时成功率、被拒绝数、降级次数
- 暴露
/health/circuit接口返回各 breaker 的State()和自定义指标，比日志更利于排查 - 容易忽略的是：降级数据是否还有效？缓存过期没？结构体字段变了没？上线后要定期校验，否则降级成功=返回 panic
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
