context.WithValue不能传指针，因其设计用于传递不可变、可比较、轻量的请求元数据；指针可变且易引发内存错误与竞态，违反context只读语义。
为什么 context.WithValue 不能传指针？
因为 context.WithValue 的设计初衷是传递「请求范围的元数据」，比如用户 ID、请求追踪 ID、超时标识——这些必须是可比较、不可变、轻量的值。指针本身可变，且指向内容可能在 goroutine 间被并发修改，破坏 context 的只读语义。
常见错误现象：context.WithValue(ctx, key, &user) 看似能跑通，但后续从 context 取出的指针可能指向已释放内存（如 user 是栈变量），或多个 handler 意外共享并修改同一结构体字段，导致竞态。
- 永远用不可变类型作 value：
string、int、自定义的struct{}（所有字段都是导出且不可变） - 若必须传结构体，定义新类型并禁用指针赋值：
type UserID string
而不是*User - 不要把数据库连接、HTTP client、logger 实例塞进 context——它们该通过依赖注入传入 handler，而非靠 context 查找
Web handler 中怎么安全地用 context.WithValue 传用户信息？
典型场景：中间件解析 JWT 后，想把用户 ID 和角色透传给下游 handler，又不想改函数签名。这时 context.WithValue 是合理选择，但 key 必须是私有类型，避免冲突。
关键点在于 key 不能是 string 或 int 字面量——否则不同包之间极易撞 key。Go 官方文档明确要求 key 是未导出类型。
立即学习“go语言免费学习笔记（深入）”；
- 定义 key：
type userKey struct{}，然后用ctx = context.WithValue(ctx, userKey{}, userID) - 取值时类型断言要带检查：
if userID, ok := ctx.Value(userKey{}).(string); ok { ... } - 别在循环里反复调用
WithValue：每次调用都新建 context，累积开销；应由中间件一次性注入，handler 只读取
用指针做 context key 会怎样？
有人试过 context.WithValue(ctx, &key, value)，以为能绕过类型限制——结果运行时报 panic: invalid key type *main.key。因为 context 包内部做了类型检查，只允许比较型（comparable）类型作 key，而指针虽可比较，但 runtime 认为它「不安全」，直接拒绝。
错误信息很明确：context: key must be comparable。注意这不是编译错误，是运行时 panic，容易漏测。
- key 类型必须满足 Go 的 comparable 约束：不能含 slice、map、func、chan、包含这些字段的 struct
- 最稳妥的 key 定义方式就是空 struct：
type userIDKey struct{}，它占 0 字节、可比较、不可外部构造 - 别用
uintptr或unsafe.Pointer模拟 key——这会绕过类型系统，让代码无法维护
真正需要传结构体时，指针和值传递哪个更合适？
如果你非得传一个 User 结构体，答案是：既不要指针，也不要值拷贝，而是传 ID，再在 handler 内部查库。Web 请求生命周期短，context 不是对象池。
性能影响很实际：一个 2KB 的结构体，每秒 1 万请求，仅 context 就多分配 20MB/s 内存，GC 压力陡增。而传 string ID 几乎零开销。
- 值传递结构体：小结构体（
- 指针传递：规避拷贝，但引入共享状态风险；且 context 本意是「只读视图」，你传了指针，就等于默许下游修改原始数据
- 真正的解耦做法：把
User查询逻辑封装成函数，作为参数传入 handler，或通过 interface 注入，而不是塞进 context
复杂点在于，很多人把 context 当成全局变量的替代品，其实它只是请求链路的「上下文快照」。一旦开始往里塞业务对象，就说明接口设计该重构了。
