高并发下内存泄漏更难被发现是因为小泄漏被放大且GC不及时回收；真正危险的是引用链未断，如context.WithValue存*bytes.Buffer又被传入未监听ctx.Done()的后台goroutine，导致Buffer滞留堆中。
为什么高并发下内存泄漏更难被发现
因为泄漏对象往往被短期 goroutine 持有，GC 能回收但不及时；而高并发放大了“小泄漏”的累积效应——比如每次请求多分配 1KB，QPS 5000 就是每秒 5MB，10 分钟就堆出 3GB。真正危险的不是单次分配，而是引用链没断：一个 context.WithValue 存了 *bytes.Buffer，又被传进后台 goroutine，该 goroutine 却没监听 ctx.Done()，Buffer 就卡在堆里不动。
pprof 抓 heap 快照必须带 gc=1 参数
默认 /debug/pprof/heap 返回的是当前存活对象（inuse_space），但若 GC 还没触发，它可能显示很低，误判为“没泄漏”。必须强制 GC 后采样：
- 第一次：
curl "http://localhost:6060/debug/pprof/heap?gc=1" > heap1.pb.gz - 等 30 秒，业务空闲期再抓一次：
curl "http://localhost:6060/debug/pprof/heap?gc=1" > heap2.pb.gz - 对比：
go tool pprof --base heap1.pb.gz heap2.pb.gz，看 diff 中增长最多的类型
如果 gin.(*Context).Set 或 context.withValue 出现在 top，基本就是上下文滥用导致的引用滞留。
goroutine 泄漏比内存泄漏更常发生
查 /debug/pprof/goroutine?debug=2，重点搜这些状态：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
-
select（尤其带无超时 channel 操作） -
chan receive或chan send（说明在等没人发/收的 channel） - 长时间运行的
for {}且没检查ctx.Done()
常见错误：把 c.Request.Context() 直接传给异步 goroutine，却不加 context.WithTimeout 或 context.WithCancel；或用 c.Copy() 后在 goroutine 里长期持有，结果 body 数据一直被引用。
context.WithValue 只能存轻量数据
别存结构体、切片、map、*sql.DB、*http.Client 这类东西。正确做法：
- 只存
int64、string、*User（且User本身不能含大字段或未关闭资源） - 自定义 key 类型：
type ctxUserIDKey struct{}，避免字符串 key 冲突和反射开销 - 异步场景一律用
context.WithTimeout(c.Request.Context(), 5*time.Second)，而不是裸传
最易被忽略的一点：c.Set("key", bigStruct) 看似只是存个值，但 Gin 内部会把它塞进 context，而 context 链式引用会把整个 request 生命周期的数据都拖住——哪怕 handler 已返回，只要 goroutine 没退出，GC 就不敢动。
