Go语言降级必须严格区分transient错误（如超时、连接拒绝）与permanent错误（如用户不存在），仅对前者触发；降级函数须类型匹配、无副作用、零延迟，且自身需加超时控制，不可塞入defer或recover。
Go 语言没有自动降级机制，加个 fallback 函数不等于完成降级——它可能根本不会被调用，或者调用时已破坏一致性。
如何正确判断该不该触发降级
降级只应对 transient 错误（如超时、连接拒绝、服务不可用），而非 permanent 错误（如用户不存在、参数校验失败）。关键在于区分错误语义，而不是统一捕获所有 err != nil。
-
errors.Is(err, context.DeadlineExceeded)和errors.Is(err, context.Canceled)必须同时检查——漏掉context.Canceled会导致上游主动中断时直接返回 500 - 对 gRPC 调用，别依赖
status.FromError(err).Code()单独判断；底层仍是 context 错误包装，仍要走errors.Is路径 - HTTP 客户端错误中，
"dial tcp: i/o timeout"可降级，但404 Not Found或sql.ErrNoRows是业务正常态，不应进降级分支 - 避免用
strings.Contains(err.Error(), "timeout")——不同 transport 返回文本不一致，不可靠
降级函数必须满足的硬约束
降级不是“兜底容错”，而是“主动切换路径”。它的行为边界比主流程更严格，否则会放大故障。
- 返回值类型必须严格匹配主逻辑，例如
func GetUser(id string) (*User, error)的降级函数也必须返回(*User, error)，哪怕error是nil - 禁止返回零值结构体（如
&User{}），前端可能当成真实空数据；改用DefaultUser()显式构造 - 降级里禁止起 goroutine 或调另一个远程服务——这会让降级链失控，雪崩风险翻倍
- 不能塞入
defer或recover：defer在函数退出才执行，而降级必须在每次下游调用后立刻判断；recover只捕获 panic，对context.DeadlineExceeded完全无感
为什么不能把降级逻辑塞进 defer 或 recover
defer 和 recover 拦不住 context 超时或 net.Error 这类错误，它们是正常返回的 err，不是 panic。强行塞进去只会让降级失效或掩盖真实问题。
立即学习“go语言免费学习笔记（深入）”；
- 典型错误写法：
if err != nil { return fallback() }写在函数末尾，但中间已有其他逻辑依赖user，此时user是nil，panic风险更高 -
defer cancel()是必须的，但它和降级无关；取消上下文 ≠ 触发降级 - 真正降级入口必须紧贴调用之后，比如
user, err := callUserService(ctx, id)后立刻判断
动态开关和可观测性不是可选项
硬编码的降级等于没开关。生产环境必须支持运行时启停、指标打点、配置联动。
- 降级开关必须从配置中心（如 etcd/Nacos）加载，并定期刷新，避免重启生效
- 每个降级分支必须打日志 + 打点：
metrics.Counter("user_service_fallback_total").Inc()，否则无法感知是否被误触发 - 熔断器（如
sony/gobreaker）打开时，应联动关闭对应降级——否则熔断后还在返回默认值，下游恢复了你也收不到流量 - 提供管理接口（如
/admin/degrade/enable?service=user&mode=cache），方便人工干预
最容易被忽略的一点：降级逻辑本身没有超时控制。如果 fallbackUser() 里偷偷查了本地缓存但缓存驱动卡住，整个请求就卡死了——所以兜底也得带 context.WithTimeout，哪怕只有 5ms。
