真实泄漏需满足：稳定负载下HeapInuse/HeapAlloc线性增长且重启归零复现；避免刚启动或GC高频时采样，用两次HTTP快照对比diff，关注inuse_space净增长及goroutine泄漏。
怎么确认抓到的是真实泄漏，不是GC假象
pprof 显示内存上涨 ≠ 真泄漏，关键看采样时机和指标选择。如果 heap_inuse 在稳定负载下线性增长、重启后归零复现，才值得深挖。别在程序刚启动或 MemStats.NextGC 接近 MemStats.HeapAlloc 时抓 profile——这时 GC 正高频运行，快照里全是临时对象，干扰判断。
线上必须用 HTTP 接口抓：wget http://localhost:6060/debug/pprof/heap -O before.heap，等至少 30 秒再抓一次：wget http://localhost:6060/debug/pprof/heap -O after.heap。文件名务必带 .heap 或 .pb.gz 后缀，否则 go tool pprof 可能识别失败。
- 绝对不要加
?gc=1参数——它强制 GC 后采样，会把本该存活的对象“刷掉”，掩盖真实泄漏 - 本地复现时，用
pprof.WriteHeapProfile(f)比 HTTP 更可控，但必须在逻辑关键点前后调用（比如 handler 入口/出口、goroutine 启动前后） - 验证快照有效性：打开后切到 View → Sample，选
inuse_space；如果alloc_space远高于inuse_space，说明分配多、释放快，大概率不是泄漏
为什么 top 看到 *UserConfig 占 150MB，list 却找不到分配点
因为 top 统计的是当前驻留内存总和，list 显示的是函数内所有分配（含已 GC 的），两者口径不同。你代码里可能根本没写 &UserConfig{}，而是通过第三方库间接创建并持久化了指针。
典型场景包括：
立即学习“go语言免费学习笔记（深入）”；
-
json.Unmarshal解析进全局map[string]*UserConfig，key 永远不删 -
sync.Map.LoadOrStore("id", cfg)后忘记清理过期项 - slice 截取后赋给全局变量：
globalBuf = b[:n]，底层数组仍被引用 - HTTP handler 闭包捕获了大结构体：
http.HandleFunc("/api", func(w, r) { data := loadBigData(); handle(r, data) })——data被闭包持有，随每次请求累积
此时 go tool pprof -http=:8080 binary before.heap after.heap 打开后，点 View → Difference，再 Focus *UserConfig，才能看到谁在 new 它且没释放。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
调用栈里全是 runtime.selectgo 和 goroutine，怎么定位业务代码
pprof 默认只显示顶层调用栈，而泄漏往往藏在中间层。比如你看到 *model.Order 占用 80% inuse_space，但调用栈只显示 http.HandlerFunc.ServeHTTP，说明它被 handler 闭包意外捕获了。
重点盯这些 runtime 符号：
-
runtime.gopark或runtime.selectgo：优先检查它们上层是否是你的 handler、ticker 回调或 channel receive 语句 - 如果大量
runtime.mallocgc直接连到main.main或某个初始化函数，说明主 goroutine 在启动期就建了一堆对象并长期持有，比如未关闭的http.Client.Transport、未清理的time.Ticker - 执行
pprof -symbolize=none可绕过符号解析失败问题，避免因缺少 debug info 导致调用栈显示为???
goroutine 数暴涨但 heap 不涨？那是“钉子户”在作祟
每个 goroutine 栈初始仅 2KB，本身不占多少内存。但它只要活着，就能 hold 住任意大的对象——比如一个闭包捕获了含 []byte 的 struct，或一个后台 goroutine 持有数据库连接池的引用。这时 /debug/pprof/heap 看不到泄漏源头，因为内存是被活跃 goroutine “钉住”了，GC 不敢回收。
验证方法：
- 对比
/debug/pprof/goroutine?debug=2和/debug/pprof/heap：如果 goroutine 数持续上升、heap_inuse同步爬升，基本可断定是 goroutine 泄漏连带堆泄漏 - 检查
runtime.NumGoroutine()是否随时间单向增长；若稳定负载下每分钟新增几十个，就是强信号 - 常见陷阱：日志打太勤、
time.AfterFunc传了闭包却没清引用、select漏写default导致永久阻塞
真正难啃的点从来不是 profile 怎么抓，而是那些没显式 new、没直接赋值、却通过 map/sync.Map/json/unmarshal/闭包层层传递后悄悄扎根的引用——它们不会报错，只会在某次 GC 周期后，让 inuse_space 多抬高几 MB。
