goland 不自动采集内存 profile，必须手动启用 http pprof 端点并触发 heap 采样；直接点击 “profile with pprof” 只能抓 cpu，抓内存必须走终端命令或手动导出文件——否则你看到的只是空 profile 或 runtime 函数堆栈。
GoLand 本身不自动采集内存 profile，必须手动启用 HTTP pprof 端点并触发 heap 采样；直接点击 “Profile with pprof” 只能抓 CPU，抓内存必须走终端命令或手动导出文件——否则你看到的只是空 profile 或 runtime 函数堆栈。
GoLand 中启用 heap profile 的必要前提
GoLand 不支持一键启动 heap profiling，它只监听 localhost:6060/debug/pprof/profile（CPU）和 /debug/pprof/trace。要分析内存，你得自己让程序暴露 /debug/pprof/heap，且必须满足三点：
-
import _ "net/http/pprof"已加入main.go的 import 块（下划线不能省） - 业务启动后、主 goroutine 退出前，已执行
go http.ListenAndServe("localhost:6060", nil) - 程序正在运行中，且有真实内存压力（比如持续处理请求、反复构造对象），否则
?gc=1采不到存活对象
正确采集 heap profile 的命令与参数
GoLand 不会帮你发 curl，你得在终端手动执行。关键不是“要不要加 ?gc=1”，而是“不加它就等于白采”——默认 /heap 返回的是累计分配量，不是当前存活对象。
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 强制 GC 后抓存活堆：
curl -s "http://localhost:6060/debug/pprof/heap?gc=1" -o heap.pb.gz - 必须指定二进制文件路径，否则函数名全是
runtime.mcall或地址：go tool pprof ./myapp heap.pb.gz（./myapp是你go build出的可执行文件） - 想对比两次快照找泄漏源头：
go tool pprof -base heap0.pb.gz heap1.pb.gz（两次采样间隔 ≥30 秒，且中间有稳定内存增长）
pprof 分析时最易忽略的三个坑
即使命令写对，也常因细节错失关键线索：
-
go run main.go启动的程序无法用二进制关联符号表——必须先go build -o myapp .，再./myapp &，最后用./myapp分析 profile 文件 - 看到
inuse_space高的函数，别急着优化；先确认是不是sync.Pool.Get后没Reset()，导致缓存对象残留字段，被误判为“新分配” - goroutine 泄漏常伪装成内存上涨：如果
heap里找不到高分配函数，但goroutine?debug=2显示大量chan receive或select，说明是 goroutine 钉住了对象，GC 不敢回收
真正卡住内存的，往往不是某次 make([]byte, 1MB)，而是几十个 goroutine 各自持有一个未关闭的 http.Response.Body，或者一个全局 map 不断塞入未清理的 key-value。pprof 给你数据，但判断哪条调用链该砍、哪处 defer 忘了关，得靠你盯紧 ?debug=2 栈帧里的行号和状态。
