因为 c.request.context() 生命周期绑定 http 连接，请求结束即被 cancel，传给长期 goroutine 会导致 context 失效、gc 阻断及 panic；应显式派生带 timeout 或独立的 context，并避免长期持有 c.copy() 副本。
为什么 gin.Context 不能直接传给长期 goroutine
因为 c.Request.Context() 生命周期绑定 HTTP 连接，请求结束时该 context 会被 cancel，但若你把它传进一个没加 timeout 的后台 goroutine（比如发消息、写日志、调第三方），这个 goroutine 可能还在跑，而它持有的 context.Context 已失效——更糟的是，它可能还间接引用着 c.Request.Body、c.Keys 里的大对象，导致 GC 无法回收。
常见错误写法：
go func() {
// 错！c.Request.Context() 随请求结束被 cancel，这里可能 panic 或卡住
resp, err := http.DefaultClient.Do(req.WithContext(c.Request.Context()))
}()
正确做法是显式派生新 context：
- 用
context.WithTimeout(c.Request.Context(), 3*time.Second)控制最大执行时间 - 或用
context.WithCancel(context.Background())完全脱离请求生命周期（需自行管理 cancel） - 绝不要把
c.Copy()后的对象长期持有——它仍引用原始 request body 和 form cache
中间件里存数据，c.Set() 和 c.Request.Context().WithValue() 选哪个
优先用 c.Set()，但只存轻量数据；c.Request.Context().WithValue() 是高危操作，容易泄漏。
c.Set() 存在 c.Keys map[string]interface{} 里，随 c 被 engine.pool.Put(c) 归还到 sync.Pool，只要你不把它逃逸到全局变量或 goroutine，生命周期是安全的。但注意：
- 避免存大 struct、未关闭的 file、db.Conn 等资源型对象
- 不要存闭包或含指针的复杂结构，否则可能隐式延长所指向对象的生命周期
- 字符串 key 易冲突，建议定义私有 key 类型：
type userKey struct{}
context.WithValue() 返回的新 context 持有旧 context 引用，一旦误传给异步逻辑，就会阻断 GC——Gin 1.9.0 后的 pprof 堆分析里，gin.(*Context).Set 和 context.WithValue 是内存泄漏 top2 调用栈。
跨中间件和 handler 共享数据，怎么避免类型断言失败
用 c.Value(key) 替代 c.Get(key)，并配合私有 key 类型，不依赖字符串。
c.Get(key) 内部会做类型断言 + 拷贝，如果 key 对应值是 map/slice/struct，可能触发非预期的深拷贝或 panic；而 c.Value(key) 直接返回 interface{}，由调用方自己断言，更可控。
示例：
type userIDKey struct{}
func AuthMiddleware(c *gin.Context) {
uid := extractUID(c)
c.Set(userIDKey{}, uid) // 或 c.Request.Context() = context.WithValue(c.Request.Context(), userIDKey{}, uid)
}
func Handler(c *gin.Context) {
if uid, ok := c.Value(userIDKey{}).(int64); ok {
// 安全
}
}
关键点：
- 私有 struct key 能杜绝字符串 key 冲突（比如两个中间件都用
"user"） - 不依赖反射，性能略优，且 IDE 能跳转、编译期检查
- 避免在 handler 里反复调用
c.Get("xxx")——每次都是 map 查找 + interface{} 拆包
大并发下排查 context 相关内存泄漏，最该看哪三个地方
别看日志，直接抓运行时行为：堆增长趋势、分配热点、引用链。
第一步，启动时加 GODEBUG=gctrace=1，观察 heap_inuse 是否持续上涨且 GC 后不回落——这是泄漏的强信号。
第二步，用 pprof 抓 heap profile：
curl "http://localhost:8080/debug/pprof/heap?debug=1" > heap.pb.gz go tool pprof heap.pb.gz
进交互后输入 top -cum，重点关注三类调用栈：
-
gin.(*Context).Set—— 如果它出现在 top3，说明你在中间件里塞了不该塞的东西 -
context.WithValue—— 尤其是调用深度深、次数多的，大概率是误传给了 goroutine -
http.readRequest或net/textproto.MIMEHeader.Read—— 表明 request body 或 header 缓存没释放，常因c.ShouldBindJSON后又手动读c.Request.Body导致
真正难定位的不是“哪里泄漏”，而是“谁在长期持有 context 引用”——往往是一个忘了 cancel() 的子 context，或一个注册在全局 map 里却没清理的回调。
