gin.Context泄漏的本质是goroutine持有不必要引用，因误将*gin.Context传给后台goroutine且未切断其与请求生命周期绑定，导致上下文无法GC回收；典型表现为请求结束后续goroutine数不降反升，pprof显示大量goroutine卡在chan receive且调用栈含gin.Context字样。
gin.Context 泄漏的本质是 goroutine 持有不必要引用
这不是 Gin 特有的 bug，而是开发者误把 c（即 *gin.Context）传递给后台 goroutine 后，未切断其与请求生命周期的绑定，导致整个请求上下文（含 body、headers、params、甚至中间件注入的值）无法被 GC 回收。最典型表现是：单次请求结束后，runtime.NumGoroutine() 不降反升，pprof 显示大量 goroutine 卡在 chan receive 或 select 且调用栈含 gin.Context 字样。
禁止把 *gin.Context 传给异步 goroutine
只要你在 go func() { ... }() 里直接用了 c 或任何从 c 衍生的值（比如 c.Request.Body、c.Get("user_id")），就已埋下泄漏隐患。因为 *gin.Context 内部持有 *http.Request 和 http.ResponseWriter 引用，而后者又关联着底层连接缓冲区和 TLS state。
- 错误写法：
go processOrder(c, orderID)——c被闭包捕获，goroutine 存活期间它一直被强引用 - 正确做法：只传必要字段，如
go processOrder(orderID, userID, traceID) - 若必须传结构体，定义新类型（非指针）并显式拷贝所需字段，绝不嵌入
*gin.Context
需要用 context.Context 控制异步任务时，别混用 gin.Context
gin.Context 是框架封装，它实现了 context.Context 接口，但它的 Done() 仅在 HTTP 连接关闭或超时时触发——这太晚了。你真正需要的是一个独立、可控的 context.Context，用于限定后台任务本身的生命期。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 错误写法：
go func() { select { case —— 这等同于等客户端断连，可能几小时不退出 - 正确写法：
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second); defer cancel(); go func(ctx context.Context) { ... }(ctx) - 如果任务需关联请求 ID，用
c.GetString("trace_id")提取后传入，而非传整个c
中间件中启动 goroutine 必须配 cancel + timeout
日志上报、指标采集、审计记录等中间件常起 goroutine，这是泄漏高发区。关键不是“能不能起”，而是“起完怎么收”。
- 永远不用
context.Background()启动长期任务；改用context.WithTimeout()或context.WithCancel() - 在 handler 返回前显式调用
cancel()（通常用defer cancel()） - 避免在 goroutine 内部再调用
c.Abort()或c.JSON()—— 此时响应可能已写出，c.Writer已关闭，会 panic - 检查是否重复启动：比如在重试逻辑里没加锁或状态判断，导致同一请求触发多个相同 goroutine
实际泄漏往往藏在“看起来无害”的一行代码里：比如 go log.Info("req", "ctx", c) —— 这里 c 被序列化时可能触发反射遍历所有字段，间接延长其存活时间。真正安全的做法，是连日志字段都只传 c.GetString("user_id") 这类明确提取的字符串，而不是整个上下文对象。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
