http handler 中 context.value 拿不到值，是因为 context.withvalue 返回新 context 而非修改原对象，且未通过 r = r.withcontext(newctx) 将新 context 注入 *http.request，导致下游仍读取旧 context；key 必须用私有不可比较类型（如 type key struct{}）避免字符串冲突覆盖，取值须用 v, ok := ctx.value(k).(t) 双返回值断言防 panic。
为什么 HTTP handler 里 context.Value 拿不到值
因为 context.WithValue 返回的是新 context，原 context 不变；没把新 context 注入到 *http.Request 就直接调下游，r.Context() 还是旧的。
- 中间件中写了
ctx = context.WithValue(r.Context(), key, val)，但没执行r = r.WithContext(ctx)，下游 handler 调用r.Context().Value(key)必然返回nil - HTTP handler 签名固定为
func(http.ResponseWriter, *http.Request)，你无法改参数传 ctx，只能靠r.WithContext()替换 request 实例 - 框架如 Gin/Echo 内部也走这套逻辑：中间件修改 context 后必须透传给下一个 handler，否则链路断裂
key 用 string 为什么线上 panic
因为不同包定义同名字符串 key（比如都用 "user_id"）会互相覆盖，且编译器无法检查类型安全，运行时断言失败直接 panic。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 正确做法是定义私有未导出类型：
type userIDKey struct{}，然后用userIDKey{}当 key - key 类型必须满足 Go 的
comparable约束，所以不能是map、slice、func或含这些字段的 struct - 别导出 key 类型（如
type UserKey struct{}），否则跨包使用时可能被误复用，引发静默覆盖
goroutine 启动后 context.Done() 不触发取消
因为子 goroutine 拿到的是 context.Background() 或没传入的旧 context，和请求生命周期完全脱钩。
- 错误写法：
go doWork()（doWork内部自己调context.Background()） - 正确写法：
go doWork(ctx)，且doWork函数签名必须是func(ctx context.Context) - 如果子 goroutine 还要加超时，必须基于传入的
ctx派生：ctx, cancel := context.WithTimeout(ctx, time.Second)，不是从Background()新建
context.Value 该传什么、不该传什么
context.Value 只适合传请求生命周期内不变的只读元数据，不是通用状态容器——传错类型或用途，轻则性能下降，重则竞态 panic。
- 推荐传：
string、int64、time.Time、小 struct（所有字段可比较，零值明确） - 禁止传：
map[string]interface{}、[]byte、*sql.Tx、函数或通道——它们不可比较，且可能被并发修改 - 高频调用场景（如日志打点）别在循环里反复调
ctx.Value(key)，提前提取到局部变量更安全 - 取值永远用双返回值断言：
v, ok := ctx.Value(key).(string)，并检查ok和非空，否则nil或类型不匹配时直接 panic
context 才真正可控。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
