pprof是Go内存泄漏排查的核心工具，需配合?gc=1强制GC采样、对比inuse_space快照差值，并结合/debug/pprof/goroutine?debug=2定位goroutine阻塞与隐式引用，GoLand仅提供图形化封装，不替代pprof本身能力。
pprof 是唯一需要的工具，GoLand 只是辅助界面
GoLand 本身不提供内存泄漏检测能力，它只是把 net/http/pprof 和 runtime/pprof 的能力做了图形化封装。真正起作用的是 Go 标准库的 pprof，不是 IDE 插件或额外安装包。
启动时只需三行代码：_ "net/http/pprof" + http.ListenAndServe("localhost:6060", nil)（跑在独立 goroutine）+ 确保 handler 里有疑似泄漏逻辑（比如往全局 sync.Map 写不删的数据）。访问 http://localhost:6060/debug/pprof/ 能打开，就说明 pprof 已就绪。
- 别依赖 GoLand 的“Profiler”菜单启动采样——它默认抓的是 CPU profile，不是 heap；选错类型会白忙一场
- GoLand 的火焰图对 goroutine 分析帮助有限，
?debug=2输出的文本堆栈更可靠 - 如果服务没开 HTTP server，用
runtime/pprof.Lookup("heap").WriteTo(f, 0)或runtime/pprof.Lookup("goroutine").WriteTo(f, 2)手动 dump，第二个参数必须是2才能拿到完整调用链
抓 heap profile 必须盯 inuse_space，别被 allocs 带偏
内存泄漏的本质是对象长期存活、GC 不回收，所以只看 allocs 毫无意义——它高只说明分配频繁，GC 后就没了；inuse_space 持续上涨才可疑。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 采样命令必须带
-base before.heap after.heap，单次快照看不出趋势 - 浏览器里打开 pprof 后，右上角 SAMPLE 切到
inuse_space，再点 View → Difference - 文件名必须含
.heap或.pb.gz后缀，否则go tool pprof报错"unrecognized profile format" - 别在
MemStats.NextGC接近MemStats.HeapAlloc时采样——GC 正 sweep，快照全是待回收垃圾，数据失真
?debug=2 是定位 goroutine 泄漏的生死线
?debug=1 只返回 goroutine 总数和状态统计，看不出卡在哪；?debug=2 才输出完整堆栈和阻塞时长，432000s 这种量级基本就是泄漏。
- 重点搜
chan receive、select、time.Sleep、semacquire——尤其是重复出现的业务文件行号（如client.go:72） - 若发现某函数启动上千 goroutine 且状态全是
IO wait，大概率是未关闭 channel 或 HTTP client 缺超时 - 堆栈末尾是
runtime.gopark或runtime.selectgo，但中间夹着(*ConnPool).reaper、context.WithCancel或timerproc，就是典型泄漏路径 - GoLand Profiler 界面里右键节点 → “Filter by Stack Trace”，输
chan receive能快速聚焦
goleak 是测试阶段唯一靠谱的守门员
线上靠 pprof，单元测试阶段靠 goleak。它不查内存，只比对测试前后 goroutine 数量是否“净增”，专治异步初始化、后台 ticker、未关闭 channel 这类问题。
- 测试函数末尾加
defer goleak.VerifyNone(t)，比每个TestXxx里重复写更稳妥 -
goleak.IgnoreTopFunction("testing.(*T).Run")没用——这是忽略框架自身，不是你的代码 - 真正要 ignore 的是已知“合法残留”，比如某些库的全局监控 goroutine，得用
goleak.IgnoreCurrent()在测试开头拍快照，或明确 ignore 函数名如goleak.IgnoreTopFunction("github.com/some/pkg.initBackgroundWorker") - 报
found unexpected goroutines时，先检查time.Ticker是否调了Stop()，再查go func() { ... }()里有没有死等信号
协程泄漏往往比内存泄漏更隐蔽：goroutine 本身只占 2KB，但它只要活着，就能“钉住”一个含 []byte 的 struct，让 GC 不敢动那几 MB。pprof heap 看不到源头，?debug=2 堆栈才是破局关键。
