Gin中熔断器不自动触发降级，因gobreaker仅管理状态，需显式传入签名匹配的fallback函数（func(error) error）并手动处理gobreaker.ErrOpen；fallback须纯内存、无副作用、类型一致，且必须与主调用共用同一cb实例。
熔断器中间件在 Gin 微服务中不会自动触发降级，必须显式把降级逻辑写进 cb.Execute 的第三个参数（fallback 函数），否则熔断后直接返回 error，前端看到的是 500 或连接拒绝。
为什么 Gin 中间件里配了熔断器却没走降级？
常见误区是把熔断器当成“自动兜底开关”——它只负责判断开/关/半开状态，不提供任何业务逻辑。Gin 中间件本身也不感知降级，它只负责调用 cb.Execute 并处理其返回值。
- 如果你的中间件只写了
err := cb.Execute(...)，没传 fallback 函数，那熔断或失败时就只是抛出 error，后续由 Gin 的c.AbortWithStatusJSON(500, ...)或 panic 捕获，根本不会执行任何降级响应 - fallback 必须是函数字面量或命名函数，签名必须为
func(error) error，且内部不能调外部服务、不能 sleep、不能 panic - 中间件里若提前做了
context.WithTimeout，但 fallback 函数里又去查缓存或 DB，那这个 timeout 对 fallback 无效——它只约束主调用路径
gobreaker.Execute 里 fallback 怎么写才安全？
fallback 是熔断器唯一能插手业务响应的地方，但它不是“万能替补”，而是“最小可行兜底”。错误写法会把降级变成新瓶颈。
- ✅ 正确做法：返回硬编码默认值、本地内存 map 查缓存、预生成的兜底结构体（如
defaultProds()） - ❌ 错误做法：在 fallback 里调
redis.Get(...)、db.QueryRow(...)、time.Sleep(100 * time.Millisecond) - ⚠️ 注意：fallback 返回的
error会被忽略（除非你手动检查），但它的第一个返回值（通常是interface{}）必须和主函数一致，否则类型断言失败会 panic - 示例中
hystrix.Do("user_service", ..., func(e error) error { result = "default_user"; return nil })，这里return nil表示降级成功，result变量才会被外层使用
Gin 路由层如何配合熔断降级不丢状态？
熔断器状态（Open/Closed/Half-Open）是实例级的，但 Gin 的每个请求都新建 context，所以必须确保：同一依赖服务的所有调用共用同一个 gobreaker.CircuitBreaker 实例，且命名带服务标识。
- 不要在 handler 里 new 一个 cb 实例——每次请求都新建，等于没熔断
- 推荐在
init()或服务启动时初始化，比如paymentCB := gobreaker.NewCircuitBreaker(gobreaker.Settings{Name: "payment-service-call", MaxRequests: 10, Timeout: 15 * time.Second, Interval: 60 * time.Second}) - Gin 中间件里通过
ctx.Set("cb", paymentCB)传递不可取；应作为包级变量或注入到 handler 闭包中，避免并发竞争 - 如果用了多个下游（user、order、payment），就必须有三个独立 cb 实例，共用一个会导致 A 故障拖垮 B
最容易被忽略的是 fallback 的执行上下文：它不在原始请求的 context.Context 里运行，所以 ctx.Value、ctx.Done() 全部失效。所有兜底数据必须提前准备好，或者从纯内存结构读取——别指望它还能读 request header 或 trace id。
