context.withvalue易致内存泄漏，因其返回的新context持有旧context引用，若存入大对象、未关闭资源或误传给长期goroutine且未cancel，会阻断gc；应只存轻量元数据并严格管控生命周期。
Go 中 Context 本身不直接导致内存泄漏，但 context.WithValue 和错误的生命周期管理会让它变成“泄漏放大器”——尤其在 Gin、HTTP handler 或长期 goroutine 场景下。
为什么 context.WithValue 容易引发泄漏
每次调用 context.WithValue 都会返回一个新 context，它内部持有一个指向父 context 的指针。如果存入的 value 是大对象（比如一个未关闭的 *sql.DB、含闭包的函数、或几百 KB 的 struct），而这个 context 又被意外长期持有（例如传给后台 goroutine 后没 cancel），GC 就无法回收整个链路上的 parent context 和它引用的所有值。
- 常见错误：在中间件里写
c.Set("user", hugeStruct)，但 handler 没调用c.Get("user")，也没显式丢弃引用 - Gin 的
*gin.Context底层是http.Request封装，c.Request.Context()默认就是 request 生命周期的 context；一旦你用WithValue往里塞东西，就等于延长了该 request context 的存活时间 - 更隐蔽的是：value 本身可能间接持有其他资源（比如一个 struct 里有
io.ReadCloser字段），这些都不会被自动清理
传递 Context 时必须做的三件事
不是“用了 Context 就安全”，而是必须主动约束它的传播路径和存活边界。
- 只传
ctx.Value(key)，别用c.Get("key")—— 后者会做类型断言并可能触发隐式拷贝，增加逃逸风险 - 所有异步操作（goroutine、定时任务、后台 job）必须接收
context.Context参数，且第一个参数传入；阻塞操作（ch 、<code>db.QueryContext、http.Do）必须放进select并监听 - 用
context.WithTimeout或context.WithCancel显式约束，而不是直接传c.Request.Context()—— 特别是下游调用数据库、第三方 API 时，超时要短于上游 HTTP 超时（比如 HTTP 是 30s，DB 查询设为 5s）
哪些 key 类型能避免冲突和泄漏
字符串 key 看似方便，但极易因拼写错误或跨包重复导致覆盖或 panic；更严重的是，反射式 key 查找会阻止编译器优化，间接影响 GC 效率。
- 定义私有空 struct 类型作为 key：
type ctxUserIDKey struct{}，然后用ctx = context.WithValue(ctx, ctxUserIDKey{}, userID) - 绝对不要用全局字符串变量当 key，哪怕加了注释也不行（比如
const UserKey = "user_id"） - 如果必须复用 key，用包级私有变量 +
func CtxUser(ctx context.Context) *User封装取值逻辑，避免裸调ctx.Value
最常被忽略的一点：cancel 函数的调用时机比是否调用更重要。子 context 的 cancel() 必须在父 context 的 cancel() 之前执行，否则可能死锁；而 goroutine 内部监听 ctx.Done() 时，若 select 中其他 case 先就绪，取消信号就会被跳过 —— 所以监听必须放在 select 的第一个 case。
