Gin框架本身不会导致内存溢出，问题根源在于开发者代码：如handler闭包捕获大对象、中间件未清理context.Value、全局sync.Map堆积、json.Unmarshal后map不释放等。
Gin 框架本身不会导致内存溢出，真正出问题的是你用 Gin 时写的代码——比如 handler 里闭包捕获大对象、中间件没清理 context.Value、全局 sync.Map 堆积不清理、或者 json.Unmarshal 直接塞进 map 后永不删除。
确认是不是真泄漏，而不是 GC 滞后或缓存预热
别光看容器 RSS 或 top 里内存“一直在涨”。真泄漏必须同时满足：
-
runtime.ReadMemStats的HeapInuse和HeapAlloc在稳定负载下线性增长（画曲线看斜率） - 每次重启后归零，相同流量下再次复现
- GC 完成后
HeapInuse不回落，甚至越 GC 越高
如果刚启动时涨得猛、几分钟后就平稳，大概率是 http.Server 连接池预热或 Gin 内部缓存（如路由 trie 节点）在建热，不是泄漏。
抓 heap profile 必须绕开的三个硬坑
profile 抓错，pprof 就白看了。线上采样必须满足：
立即学习“go语言免费学习笔记（深入）”；
- 绝对不要加
?gc=1：它强制 GC 后快照，会把本该长期存活的对象“刷掉”，泄漏对象恰恰是 GC 也收不走的那些 - 文件名必须带
.heap或.pb.gz后缀，比如before.heap，否则go tool pprof报 “unrecognized profile format” - 两次采样间隔 ≥30 秒，且程序已运行 5 分钟以上、流量稳定；刚启动或
MemStats.NextGC接近HeapAlloc时采样，快照里全是待 sweep 的垃圾，失真
推荐命令：wget http://localhost:6060/debug/pprof/heap -O before.heap → 等 30 秒 → wget http://localhost:6060/debug/pprof/heap -O after.heap
用 pprof 差分定位泄漏源头
执行：go tool pprof -http=:8080 -base before.heap after.heap
浏览器打开后只做三件事：
- 右上角 SAMPLE 切到
inuse_space（不是alloc_objects或alloc_space） - 点 View → Difference（不是 Top 或 Flame Graph）——只有差分才能看到净增长部分
- 在搜索框 Focus 输入你的可疑类型，比如
*UserConfig或[]byte，再点 Call graph
重点盯调用链里夹着这些关键词的路径：(*ConnPool).reaper → 查数据库连接池没设 SetMaxOpen 或漏调 Closetimerproc、time.AfterFunc → 查 time.Ticker 没 Stopchan receive、select → 查 goroutine 卡在 channel 上，钉住整个闭包
别忽略 goroutine 泄漏这个“内存拖油瓶”
90% 的“内存缓慢上涨”背后不是对象没回收，而是 goroutine 卡死，死钉着一堆大对象。比如一个 handler 闭包捕获了含 []byte 的结构体，它活着，整个结构体就永远进不了 GC。
查法不是看 /debug/pprof/goroutine 默认页（只给总数），而是：curl "http://localhost:6060/debug/pprof/goroutine?debug=2"
搜索关键词：chan receive、select、time.Sleep、http.Transport、semacquire
特别注意重复出现的业务文件行号（如 handler.go:42），若某函数启动上千 goroutine 且状态全是 IO wait，大概率是未关闭 channel 或 HTTP client 缺超时。
真实泄漏往往藏在 goroutine 和 heap 的交界处：pprof 看不到 goroutine 钉住的对象，但 runtime.NumGoroutine() 打点监控突增就是强信号；测试阶段可用 goleak.VerifyNone(t) 捕获残留。
