Context.Value 可传结构体指针但不推荐，因其设计用于传递轻量、只读的请求元数据（如requestID），传指针易引发并发竞争与值被意外修改；应优先使用不可变类型或封装后安全传递。
Context.Value 不能传结构体指针？
能传，但不推荐——Context.Value 设计初衷是传「请求范围的元数据」，比如 requestID、userID、traceID 这类轻量、只读、全局唯一标识。传结构体指针容易引发并发读写竞争，且一旦下游协程修改了该结构体字段，上游无法感知，调试时会发现值“莫名其妙变了”。
常见错误现象：data race 报告、某个中间件读到的 User 字段是空或旧值、测试通过但压测时偶发 panic。
- 只传不可变类型：如
string、int64、自定义的type userID string - 若必须传对象，用
sync.Map或atomic.Value封装后存入，再通过Value传其指针（但已偏离原意） - 更稳妥的做法：把结构体转为只读接口（如
interface{ GetID() string }），实现方内部锁定
为什么 Context.WithValue 返回新 context 而不是修改原 context？
因为 context.Context 是不可变的（immutable）。每次调用 context.WithValue 实际返回一个带链表结构的新 context，它持有一个父 context 引用和当前键值对。这种设计保证了并发安全：多个 goroutine 可以同时从同一个父 context 派生子 context，互不影响。
性能影响明显：链表深度过大（比如中间件层层套娃 10+ 层）会导致 Value 查找变慢（O(n) 时间），尤其在高频路径上（如日志打点、鉴权检查）。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 避免在循环里反复
WithValue，提前构造好所需 context - 不要用
map[interface{}]interface{}当 key，用自定义类型（如type userKey struct{}）防止键冲突 - 如果只是临时透传，考虑用函数参数代替——不是所有场景都非得塞进 context
HTTP handler 中如何安全提取 context.Value？
Go 的 http.Handler 默认把 request context 传给 ServeHTTP，但直接在 handler 函数里写 r.Context().Value(key) 很容易漏掉类型断言失败或 key 不存在的情况。
典型错误：没判空就强转，导致 panic；或者用 interface{} 接收后忘记类型检查，后续调用方法时报 nil pointer dereference。
- 始终用双返回值断言：
v, ok := r.Context().Value(myKey).(string)，!ok时走默认逻辑或返回 error - 封装提取函数，统一处理缺失逻辑，例如：
func UserIDFromCtx(ctx context.Context) (string, bool) { v, ok := ctx.Value(userKey{}).(string) return v, ok && v != "" } - 别在 middleware 外层覆盖同名 key，否则下游取到的是最近一次 set 的值，而非最初来源
Value 传递的数据生命周期到哪为止？
到对应 context 被 cancel 或 deadline 到期为止。这意味着：一旦父 context 被取消，所有派生出的子 context（包括它们的 Value）都失效；哪怕你保存了那个 Value 的副本，只要它引用了 context 内部结构（比如 valueCtx 链），GC 就无法回收整条链。
容易被忽略的一点：用 context.WithTimeout 启动一个 goroutine，里面又调用了 WithValue，这个 value 的生命周期**不延长** context 的存活时间——超时后整个链仍会被清理。
- 不要把需要长期持有的数据塞进 context，改用依赖注入或全局 registry
- 若需跨 context 生命周期保留，应显式拷贝值（如
copy([]byte, src)），而不是保留对 context.Value 的引用 - debug 时可用
fmt.Printf("%#v", ctx)看 context 类型，但生产环境禁用——可能泄露敏感信息
