不能直接用 context.WithValue 传用户 ID 或 token，因为 key 必须是自定义私有类型（如 type userCtxKey struct{}），若用 string 或 int 字面量（如 "user_id"）作 key，会导致跨包冲突、值被覆盖、类型断言 panic；且值应为不可变对象，避免传 map/slice 引发竞态；HTTP 中间件必须显式更新 request.Context 才能透传，否则下游取不到值。
为什么不能直接用 context.WithValue 传用户 ID 或 token
因为 context.WithValue 的 key 必须是全局唯一、类型安全的标识符，而很多人随手传 string（比如 "user_id"）或 int，导致下游取值时类型断言失败、key 冲突、甚至被中间件覆盖。Go 官方文档明确说：「key 应该是自定义类型，避免不同包之间 accidental collisions」。
实操建议：
- 定义私有未导出类型作 key，例如
type userCtxKey struct{}，再用var userKey = userCtxKey{} - 永远不要用
string或int当 key —— 即使测试能过，上线后多个中间件都塞"token"就会互相覆盖 - value 值尽量只存不可变结构体或指针，避免传 map/slice 后被意外修改影响上游逻辑
HTTP handler 到 service 层怎么安全透传 auth credential
典型错误是 handler 解析完 JWT 就塞进 context.WithValue(r.Context(), userKey, user)，然后一路透传到 DAO；但更健壮的做法是：在 handler 中完成校验和转换，把业务身份对象（如 *User）注入 context，后续层只读不改。
示例片段：
立即学习“go语言免费学习笔记（深入）”；
// handler.go
func handleOrder(w http.ResponseWriter, r *http.Request) {
token := r.Header.Get("Authorization")
user, err := parseAndValidateToken(token)
if err != nil {
http.Error(w, "unauthorized", http.StatusUnauthorized)
return
}
// 注入强类型值，不是原始 token 字符串
ctx := context.WithValue(r.Context(), userKey, user)
order, err := orderService.Create(ctx, reqBody)
}
注意：orderService.Create 接收 context.Context，内部通过 ctx.Value(userKey) 取值并做类型断言 —— 断言失败必须 panic 或返回 error，不能静默忽略。
middleware 中修改 context value 的常见陷阱
很多框架（如 Gin、Echo）的 middleware 默认复用 request context，但若你在中间件里调用 ctx = context.WithValue(ctx, key, val) 却没把新 ctx 赋给 c.Request = c.Request.WithContext(ctx)（Gin）或等效操作，下游 handler 拿到的仍是原始 context，值根本没传下去。
关键点：
- Gin：必须显式调用
c.Request = c.Request.WithContext(newCtx) - Echo：用
c.SetRequest(c.Request().WithContext(newCtx)) - 原生 net/http：handler 签名是
func(http.ResponseWriter, *http.Request)，*http.Request是指针，可直接改r = r.WithContext(newCtx)再传给下一层 - 所有场景下，
WithValue返回的新 context 都必须被显式传递，它不会自动“污染”原始 context
什么时候该用 context.Value，什么时候该重构参数
如果某个值在整条调用链中每个函数都要用（比如 traceID、用户身份、租户 ID），且不参与业务逻辑计算（只是日志、鉴权、DB 分库路由），那 context.Value 是合理选择。但一旦出现以下情况，就该立刻停手、改用显式参数：
- service 方法需要根据这个值做分支逻辑（比如 “如果是 admin 就跳过校验”）—— 这说明它已是业务输入，不是上下文元数据
- 单元测试时不得不大量 mock context 和 Value 取值逻辑 —— 测试成本远高于加一个参数
- 同一个函数既从 context 取 user，又从 DB 查 user —— 明显职责混乱，应统一入口校验后传参
真正难的不是怎么塞值，而是判断哪些信息真的属于「请求生命周期的元数据」，哪些只是偷懒不改函数签名的借口。
