不应使用 context.withvalue 传业务参数，它仅适用于传递请求范围内的不可变元数据（如用户身份、追踪 id），且 key 必须为自定义类型以避免冲突。
不要用 context.WithValue 传业务参数，它不是为这个设计的。 它只适合传递请求范围内的、不可变的元数据（比如用户身份、追踪 ID、超时控制），且必须用自定义类型做 key，否则极易引发冲突和难以调试的问题。
为什么 context.WithValue 常被误用
很多人看到 “上下文传值” 就直接往里塞 user.ID、reqID、甚至整个 *User 结构体——这会让调用链变得隐式依赖、类型不安全、GC 压力增大，而且一旦 key 冲突（比如两个包都用了 "user" 字符串当 key），值会被覆盖且毫无提示。
常见错误现象：
• 某个中间件取不到预期的 user，但打印 context 发现 key 存在 —— 实际是被上游同名 key 覆盖了
• 单元测试里 context 传参正常，集成后突然 nil —— 因为某处漏了 WithValue 或用了不同 key 类型
• go vet 不报错，但 runtime panic 在 value.(MyType) 断言失败
- key 必须是自定义类型（哪怕空 struct），禁止用字符串或 int 直接当 key
- value 应该是只读的；如果需要修改，应重新
WithValue替换，而非原地 mutate - 不要把 context 当成“万能参数包”，业务逻辑参数请显式传参
正确写法：用私有类型做 key + 显式类型断言
核心是隔离 key 的作用域。哪怕只是临时用，也该定义在包内不可导出的类型：
type ctxKey string
const userCtxKey ctxKey = "user"
// 或更安全的：
type userKey struct{}
var userKeyKey = userKey{} // 包级变量，唯一实例
赋值和取值必须成对使用同一 key 实例：
ctx := context.WithValue(parent, userKeyKey, &User{ID: 123})
...
user, ok := ctx.Value(userKeyKey).(*User)
if !ok {
// 处理缺失或类型不符
return errors.New("missing or invalid user in context")
}
- key 类型不能导出（避免外部包复用），也不要用
string等内置类型 - 取值后务必做类型断言 +
ok判断，不能假设一定存在 - 如果 value 是指针，确保它生命周期覆盖整个请求；不要传栈上局部变量地址
什么场景下才该用 WithValue
它存在的唯一合理理由，是让深层调用链能访问到“当前请求的上下文元信息”，而无需层层手动透传。典型场景包括：
- HTTP 中间件注入
requestID，日志库自动从 context 提取并打标 - RPC 框架注入
deadline和cancel，底层 transport 自动响应超时 - 权限中间件注入
auth.User，后续 handler 可安全读取，但不用于修改状态 - 分布式追踪注入
trace.Span，各层埋点自动关联
注意：WithValue 不提升性能，反而有内存开销（每个键值对都会增加 context 树节点）。高频路径中避免嵌套多层 WithValue。
替代方案比硬塞 WithValue 更可靠
多数所谓“需要传参”的场景，其实有更清晰的解法：
- 函数签名加参数：比如
func Handle(ctx context.Context, userID int64)—— 显式、可测、IDE 友好 - 封装结构体：定义
type Handler struct { DB *sql.DB; Cache *redis.Client }，把依赖注入实例 - 用 middleware 接口统一处理：如
func WithUser(next http.Handler) http.Handler，把 user 注入 request.Context 同时也完成校验 - 需要跨 goroutine 传递？优先考虑 channel 或显式参数，context 仅用于取消和超时
真正难的是判断“这算不算元数据”。一个简单检验：如果去掉这个值，函数逻辑是否还能编译通过、是否仍具备完整语义？如果答案是否定的，那它就不该进 context。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
