Gin项目易协程泄漏因框架不管理生命周期，开发者须自行负责；常见于HTTP handler异步未绑定context、中间件日志上报脱离请求上下文、下游调用缺超时控制、无缓冲channel发送端阻塞四类场景。
协程泄漏在 Gin 微服务中不会立即报错，但会导致 Goroutine 数量持续增长、内存缓慢上涨、最终触发 OOM 或响应延迟飙升——这是高并发下最隐蔽也最危险的问题之一。
为什么 Gin 项目容易出现协程泄漏？
Gin 本身不管理协程生命周期，所有 go 关键字启动的协程都由开发者全权负责。常见泄漏点集中在异步调用、中间件、超时控制缺失和 channel 阻塞这四类场景。
- HTTP handler 中直接
go func() { ... }()启动协程，但没做上下文取消或错误兜底，请求结束协程仍在运行 - 中间件里用了
go做日志上报、指标采集，却没绑定c.Request.Context()，导致协程脱离请求生命周期 - 调用下游服务（如
http.Get）未设置context.WithTimeout，下游卡住时协程永久挂起 - 向无缓冲
chan发送数据，但接收方未启动或已退出，发送协程永远阻塞在ch
用 pprof 快速定位泄漏的 Goroutine
net/http/pprof 是第一手排查工具，它能暴露正在运行、阻塞、休眠的协程堆栈，比日志更直接。
- 确保你的 Gin 路由已注册
/debug/pprof/：在main.go中加一行r.GET("/debug/pprof/*any", gin.WrapH(http.DefaultServeMux)) - 压测一段时间后，访问
http://localhost:8080/debug/pprof/goroutine?debug=2，查看完整堆栈 - 重点搜索关键词：
http.Get、select、chan send、io.Copy、time.Sleep—— 这些后面跟着长时间未返回的调用链，大概率就是泄漏点 - 对比两次 dump 的差异：先记下当前
Goroutine总数（页面顶部），压测 5 分钟后再刷一次，若数量稳定上升，说明存在泄漏
中间件和 Handler 中协程安全写法
不是不能用 go，而是必须让它“可终止、可追踪、有超时”。
- 永远用
c.Request.Context()启动协程：go func(ctx context.Context) { ... }(c.Request.Context())，并在内部监听ctx.Done() - 避免在中间件里直接
go上报日志；改用同步写入 + 异步批处理队列（如sync.Pool+ 定期 flush 的 goroutine） - 下游调用必须带超时：
ctx, cancel := context.WithTimeout(c.Request.Context(), 3*time.Second); defer cancel(); resp, err := http.DefaultClient.Do(req.WithContext(ctx)) - 使用带缓冲的
chan并设默认分支：select { case ch
容易被忽略的 Context 传递断点
协程泄漏常发生在“看起来没问题”的嵌套调用里，比如你传了 context，但某一层函数又新建了子 context 并丢弃了父级取消信号。
- 检查所有
context.WithCancel、context.WithTimeout、context.WithValue调用，确认返回的cancel函数是否被调用 - 特别注意
gorilla/sessions、viper.WatchConfig、zap的Sync方法等第三方库内部是否启用了长期运行的协程 - 用
runtime.NumGoroutine()在关键路径打点，比如在defer c.Request.Context().Done()处记录协程数变化，快速验证泄漏是否收敛
