gobreaker降级需显式捕获gobreaker.erropen并调用匹配签名的零延迟降级函数，fallback参数仅处理熔断开启和panic，不覆盖http错误或超时；推荐roundtripper封装实现全局熔断。
gobreaker 的降级不是自动发生的，它只在两种情况下触发：熔断器处于 Open 状态（返回 gobreaker.ErrOpen），或主函数发生 panic。网络超时、HTTP 503、gRPC Unavailable 这类错误不会被 Execute 自动转为降级——你得自己判断、自己调。
如何正确捕获 gobreaker.ErrOpen 并走降级分支
很多人误以为把降级逻辑塞进 cb.Execute 的 fallback 参数里就万事大吉，结果线上出问题才发现降级根本没执行。
-
cb.Execute的 fallback 只对gobreaker.ErrOpen和panic生效，不处理context.DeadlineExceeded或net.OpError - 必须显式检查
errors.Is(err, gobreaker.ErrOpen)，再单独调用你的降级函数 - 降级函数签名必须和主函数完全一致，比如主函数是
func() (*User, error)，降级也得是这个类型，不能只返回*User - 别在降级里做任何耗时操作：查 DB、起 goroutine、调另一个
cb.Execute—— 它必须是纯本地、零延迟、无副作用的
为什么不能只靠 cb.Execute 的 fallback 参数
因为 gobreaker 的设计边界很清晰：它只管“是否允许执行”，不管“执行失败后怎么兜底”。它的 fallback 是个兜底中的兜底，仅覆盖熔断打开和 panic 场景。
- 如果下游服务返回 HTTP 503，
cb.Execute会原样返回这个 error，不会进 fallback - 如果 context 已 cancel，
cb.Execute仍会执行主函数（可能立刻失败），也不会触发 fallback - 真正的降级入口必须紧贴调用之后：
res, err := cb.Execute(...); if errors.Is(err, gobreaker.ErrOpen) { return fallback() } - 漏掉这层判断，等于把降级逻辑写在注释里——看着有，实际不存在
降级函数必须满足的三个硬性条件
降级不是“随便返回个值”，它是系统可用性的最后防线，行为比主流程更受约束。
-
类型严格匹配：返回值、error 类型必须和主函数一模一样；禁止返回零值结构体（如
&User{}），应显式构造默认值（如DefaultUser()） -
无外部依赖：不能发 HTTP 请求、不能查 Redis/DB、不能调其他 breaker；连
log.Printf都建议走异步 channel，避免阻塞主链路 -
自身加超时控制：降级函数也要带
ctx参数，并在内部做select超时判断；否则一个慢降级会拖垮整个请求
HTTP 客户端场景下，RoundTripper 封装比手动 wrap 更可靠
如果你的项目大量使用 http.Client 调第三方服务，逐个在每个 Do 外套 cb.Execute 极易遗漏、难维护、无法统一指标打点。
- 推荐实现自定义
RoundTripper，把熔断逻辑下沉到 transport 层，所有http.Client自动生效 - 全局复用一个
gobreaker.CircuitBreaker实例，别在每次请求里新建——否则统计失效，熔断形同虚设 - 在
RoundTripper.RoundTrip中，先判断状态，Open时直接返回预设响应（如&http.Response{StatusCode: 200, Body: io.NopCloser(strings.NewReader(`{"status":"fallback"}`))}），不走网络 - 注意：
RoundTripper里不能直接调用cb.Execute（它要求返回interface{}），需自行封装状态判断 + fallback 调用逻辑
真正容易被忽略的是：降级函数本身也需要可观测性。它不报错，不代表没问题——返回默认值但前端渲染异常、缓存过期数据导致业务逻辑错乱，这类问题往往在线上沉默爆发。上线前务必验证降级路径的完整链路，包括超时、日志、监控打点是否真实生效。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
