必须全局复用同一个gobreaker.circuitbreaker实例，每个下游服务独占一个线程安全实例；http熔断应通过自定义roundtripper实现，降级需显式判断gobreaker.erropen并加超时控制。
直接用 github.com/sony/gobreaker，别手写状态机。它经过 Shopify、Sourcegraph 等高负载系统长期验证，覆盖滑动窗口计数、半开探测、超时重置、并发安全等全部细节；自己实现极易漏掉 onSuccess/onFailure 的竞态、半开试探失控、统计失真等问题。
为什么必须全局复用同一个 gobreaker.CircuitBreaker 实例
反复在函数里调用 gobreaker.NewCircuitBreaker，会导致每个调用都拥有独立计数器——熔断完全失效，形同虚设。
- 正确做法：初始化一次，存为包级变量或注入到结构体中（如
type UserService struct { cb *gobreaker.CircuitBreaker }） - 每个下游服务必须独占一个实例，比如
cbUserSvc和cbOrderSvc不能共用——否则 user-service 故障会误拖垮 order-service -
gobreaker.CircuitBreaker本身是线程安全的，但配置变更（如动态调整ReadyToTrip）需同步，不建议运行时频繁改
HTTP 调用怎么套熔断：别在 Do 外面硬包，用 RoundTripper 封装
逐个在 http.Client.Do 外套 cb.Execute，容易漏、难维护、丢失连接复用和上下文透传。
- 自定义
RoundTripper才是正解：把熔断逻辑嵌入RoundTrip方法，在发起请求前检查状态 - Open 状态下必须返回合法的
*http.Response，哪怕 Body 是io.NopCloser(bytes.NewReader(nil))，否则上层resp.Body.Read会 panic - 原始
*http.Request必须显式复制（req.Clone(req.Context())），避免修改影响后续中间件 - 这种封装对
net/http完全透明，不影响httptrace、Client.Timeout或 TLS 配置
怎么正确处理降级（fallback）和 gobreaker.ErrOpen
降级逻辑不是 Execute 自动触发的“兜底函数”，而是你必须显式判断并执行的独立分支。
-
gobreaker.ErrOpen是唯一可靠的熔断开启信号，只在 Open 状态下返回；其他 error（如网络超时、503）只是业务失败，不表示熔断 - 错误写法：
cb.Execute(func() {}, func(err) { return fallback() })—— 这个 fallback 只在 panic 或 ErrOpen 时进，但 5xx 返回 error 就不会触发，且 fallback 本身若再发 HTTP 请求，可能引发二次雪崩 - 正确写法：先
result, err := cb.Execute(...)，再if errors.Is(err, gobreaker.ErrOpen) { return getFallbackData() } - 降级逻辑自己也要加超时控制（如
context.WithTimeout(ctx, 100*time.Millisecond)），避免拖慢整个链路
ReadyToTrip 和 Timeout 怎么设才不误熔断也不放任失败
默认策略（连续 6 次失败就跳闸）在真实服务中极易被偶发抖动触发，必须按依赖 SLA 调整。
-
ReadyToTrip推荐用错误率 + 时间窗口组合判断，例如：最近 100 次调用中失败率 ≥ 30%，而不是只看连续失败次数 -
Timeout（Open 状态持续时间）应设为下游平均恢复时间的 2～3 倍，比如对方通常 30s 自愈，这里设90 * time.Second -
Settings.StandbyTimeout（Half-Open 单次试探超时）必须小于Timeout，且略大于该依赖的 P95 延迟，否则试探请求总失败，永远卡在 Open - 所有超时必须分层：HTTP 层用
context.WithTimeout做第一道防线，gobreaker.Timeout是第二道——前者负责中断连接，后者防止 Execute 长时间阻塞
真正难的不是配参数，而是把降级逻辑写出业务语义：返回 “default_user” 不等于容错，得是 “最近缓存的用户信息” 或 “降级为游客权限”。这一步没人能替你设计，得贴着你的用户场景来。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
