go 中 gobreaker 不自动降级，fallback 仅在 erropen 或 panic 时触发，不处理 http 5xx、超时等错误；需手动判断状态、转换错误、实现无依赖本地 fallback，并配独立超时控制。
Go 里没有“自动降级断路器”这回事——gobreaker 只管开关状态，不拦截错误、不转换超时、不触发 fallback，所有降级逻辑必须你手动写、手动判、手动调。漏掉任一环节，服务就直接返回 500 或卡死。
为什么 cb.Execute 的 fallback 几乎不会被调用
gobreaker.Execute 的第三个参数（fallback 函数）只在两种情况下执行：gobreaker.ErrOpen（熔断器处于 Open 状态）或主函数 panic。它**完全不处理**以下常见失败：
- HTTP 5xx 响应（比如
503 Service Unavailable） - 网络超时（
dial tcp: i/o timeout） - gRPC
codes.Unavailable错误 - context 超时（
context.DeadlineExceeded）
错误写法：cb.Execute(func() {}, func(e error) { return fallback() })——这个 fallback 永远不会被调用，除非主函数 panic。
正确流程是：
- 先调
res, err := cb.Execute(...) - 再显式判断
errors.Is(err, gobreaker.ErrOpen) - 命中后，单独调用你的降级函数（如
getFallbackUser()）
HTTP 调用必须主动把 5xx 转成 error
gobreaker 不解析 HTTP status code，它只认函数返回的 error 值。如果 http.Client.Do 返回 200 OK 但 body 是 {"code":503}，或者返回 503 却没转 error，熔断器就完全感知不到失败。
务必在 cb.Execute 包裹的函数里做这件事：
- 检查
resp.StatusCode >= 500，手动return nil, fmt.Errorf("http %d", resp.StatusCode) - 不要依赖
err != nil判断——很多 5xx 是err == nil的合法响应 - 对 gRPC 调用同理：用
status.Code(err) == codes.Unavailable显式转 error
本地降级函数必须满足三个硬约束
所谓“本地”，是指不发请求、不改状态、不依赖外部服务。它的唯一作用是快速返回确定结果。
- 签名必须和主函数严格一致，例如
func() (*User, error)，不能只返回*User - 禁止起 goroutine、查 DB、调 Redis、再套另一个
cb.Execute——这些都会拖慢主链路甚至引发死锁 - 推荐做法：
sync.Map读缓存旧数据、用DefaultUser()构造静态值、按 ID 取模做轻量排序替代 -
http.RoundTripper场景下，fallback 返回的*http.Response的Body字段不可为nil，否则上层io.Copy会 panic
超时控制必须由 context.WithTimeout 独立承担
gobreaker.Settings.Timeout 不是请求超时，而是“熔断打开后，多久尝试半开”。它不中断底层调用，goroutine 会一直挂着直到完成或被系统 kill。
- 所有
http.Client.Do必须传带超时的ctx，且超时时间建议比breaker.Timeout短 20%～30% - 例如：设
breaker.Timeout = 1.2s，则context.WithTimeout(ctx, 800ms) - 漏掉
ctx透传，会导致连接堆积、goroutine 泄漏、长尾请求拖垮整个 handler - 降级函数自己也要加超时：
ctx, cancel := context.WithTimeout(context.Background(), 50ms)，避免 fallback 成新瓶颈
最易被忽略的点：熔断器状态本身不可观测——gobreaker 不暴露指标，OnStateChange 是唯一埋点入口；没监控的熔断，等于黑盒拉闸。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
