降级标识应使用 ctxport 库实现类型安全传递，避免 context.WithValue 的 interface{} 键冲突与运行时 panic；需协同超时/取消错误判断降级时机，并区分全局开关与请求级标识语义。
降级标识不能塞进 context.WithValue 的 interface{} 键值对里
原生 context.WithValue 允许任意 interface{} 作 key，但这是隐患源头：不同模块用相同字符串或相同 struct 字面量当 key，值会被覆盖；取值时 ctx.Value(key) 返回 interface{}，必须类型断言，写错就 panic。比如 ctx.Value("fallback_enabled") 和 ctx.Value(struct{Fallback bool}{true}) 在 runtime 都是不同 key，但没人能保证团队所有人不重复定义。
- 别用字符串字面量当 key，哪怕加了 package 前缀（如
"user.fallback"）也不保险——编译器不校验，运行时冲突难排查 - 别用匿名 struct 或 map 当 key，它们每次构造都是新地址，
ctx.Value查不到旧值 - 真正安全的 key 是全局唯一、类型固定、不可导出的变量，例如
var fallbackKey = struct{}{}，但这样仍需手动类型断言
用 ctxport 库实现类型安全的降级标识传递
ctxport 把“存/取”操作封装成强类型函数，key 和 value 类型在编译期绑定。它不替换 context.Context，而是在其上叠加一层泛型抽象。
安装后定义降级标识类型：
type FallbackFlag bool
func WithFallback(ctx context.Context, enabled FallbackFlag) context.Context {
return ctxport.Set(ctx, fallbackKey{}, enabled)
}
func GetFallback(ctx context.Context) (FallbackFlag, bool) {
return ctxport.Get[FallbackFlag](ctx, fallbackKey{})
}
其中 fallbackKey{} 是一个空结构体，仅作类型占位，编译器靠它区分不同字段；ctxport.Get[FallbackFlag] 返回的是具体类型，无需断言，传错类型直接编译失败。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 跨中间件、HTTP handler、gRPC interceptor、异步 goroutine 都能复用同一套
WithFallback/GetFallback - 如果某层想强制启用降级，调用
WithFallback(ctx, true)；下游调用GetFallback(ctx)就拿到true，不用再层层透传 flag 参数 - 多个标识（如
TraceID、UserID、FallbackFlag）各自定义独立 key 类型，彻底隔离
降级标识和 context 超时状态必须协同判断
只靠 GetFallback(ctx) == true 不足以触发降级逻辑——它只是开关，不是错误信号。真实场景中，降级应发生在“调用失败 + 开关允许”时，且需区分错误类型。
典型误判：
- 把
sql.ErrNoRows当 transient error 触发降级：这是业务正常态，不该兜底 - 只检查
errors.Is(err, context.DeadlineExceeded)，漏掉context.Canceled：上游主动 cancel 时也该走降级路径 - 在熔断器打开状态下还发起 RPC 调用：
gobreaker的Execute已返回 error，此时GetFallback为true才该返回默认值，而不是重试或继续调用
正确姿势：
if err != nil {
if (errors.Is(err, context.DeadlineExceeded) || errors.Is(err, context.Canceled)) &&
fallbackEnabled {
return fallbackUser(), nil
}
if status.Code(err) == codes.Unavailable && fallbackEnabled {
return fallbackUser(), nil
}
return nil, err
}
动态降级开关不能只靠 context 传递
context 是请求生命周期内的一次性载体，适合传递“本次请求是否允许降级”的决策结果，但不适合承载“全局开关状态”。比如运维在 etcd 里把 /config/fallback/enabled 改成 false，所有正在处理的请求不应立刻失效——它们已进入 pipeline，context 里的标识应保持不变。
- 全局开关读取应在 handler 入口或中间件初始化阶段完成，缓存到内存变量或 sync.Map 中，避免每次请求都查配置中心
- context 中的
FallbackFlag只表示“当前请求是否被授权执行降级”，由入口中间件根据全局开关 + 请求特征（如 path、header、用户等级）决定是否置true - 不要在降级函数里再去读配置中心——那会引入网络依赖，违背降级“轻量、快速”的原则
真正容易被忽略的点是：降级标识的语义必须清晰区分“能力开关”和“执行指令”。前者是策略配置，后者是单次请求上下文状态，混用会导致行为不可预测。
