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

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 堆栈才是破局关键。