服务降级必须是纯本地、零延迟、无副作用的兜底逻辑，仅返回缓存旧数据、静态结构体或轻量计算结果；gobreaker.Execute的fallback仅在ErrOpen或panic时触发，须显式匹配主函数签名且禁止外部调用。
服务降级不是“随便返回个默认值”，而是当依赖不可用时，用有业务语义的轻量逻辑兜底，保证主流程不卡死、核心功能仍可用。
服务降级必须满足三个硬条件
降级逻辑要能立刻执行，不能引入新依赖、不能访问网络、不能查数据库。常见合规做法包括：
- 返回本地缓存的旧数据（比如
cache.Get("product-recommend")） - 返回预设静态结构体（如
DefaultUserProfile） - 退化为本地计算（例如按固定排序替代实时推荐）
- 跳过非核心环节（如关闭日志上报、异步消息投递）
一旦降级函数里出现 http.Get 或 redis.Client.Do，就等于把“保险丝”换成了“火药桶”。
gobreaker.Execute 的 fallback 参数怎么写才安全
gobreaker 本身不自动执行降级，它只在 ErrOpenState 或主函数 panic/return error 时，把控制权交给你——靠第三个参数显式传入的 fallback 函数。
这个函数签名必须严格匹配主函数：func() (interface{}, error)，且内部不能抛 panic。示例：
立即学习“go语言免费学习笔记（深入）”；
result, err := cb.Execute(
func() (interface{}, error) {
return callRemoteService(ctx, req)
},
func(err error) (interface{}, error) {
// ✅ 安全：纯内存、无副作用
return DefaultRecommendList, nil
// ❌ 危险：这里调用 redis 或 http 就会拖垮整个 fallback 流程
},
)
注意：fallback 不是 recover，也不是 defer；它是业务契约的一部分，必须和主逻辑并列设计、同等测试。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
为什么降级常和熔断、超时一起用，但三者职责完全不同
context.WithTimeout 是第一道防线，防止单次请求卡住；gobreaker 是第二道防线，感知失败趋势并切断调用流；fallback 是最后一道防线，提供可用但有损的结果。
它们容易混淆的点在于触发时机：
- 超时触发 → 主函数返回
context.DeadlineExceeded→ fallback 执行 - 熔断打开 →
gobreaker.ErrOpenState→ fallback 执行 - 主函数主动 return error（如 HTTP 503）→ fallback 执行
但 fallback 不该去判断 err 类型再分支处理——那会让逻辑耦合、难以测试。所有错误路径统一走 fallback，保持接口干净。
最容易被忽略的降级陷阱：状态不隔离 + 指标没暴露
多个下游服务共用一个 gobreaker.CircuitBreaker 实例，会导致 A 服务故障直接拖垮 B 服务的降级能力。每个依赖必须配独立实例，命名带标识，例如：Name: "payment-service-call"。
更隐蔽的问题是没暴露 circuit_breaker_fallback_total 和 circuit_breaker_state 这类 Prometheus 指标。没有这些，你根本不知道降级是不是真在起作用，还是 fallback 函数自己挂了却没人发现。
