先确认泄漏存在再开GoLand：用runtime.ReadMemStats验证HeapInuse线性增长且重启归零，避免GC干扰；优先排查goroutine泄漏（NumGoroutine暴涨），用/debug/pprof/goroutine?debug=2定位chan receive/select卡点；heap差分需go tool pprof -base生成后再导入GoLand，聚焦inuse_space和Call graph；离线分析必须携带原始二进制，否则符号丢失。
确认泄漏存在再开GoLand，别一上来就点Start Profiling
GoLand的Profiler不是万能放大镜，它只帮你可视化数据，不替你做判断。内存“看起来在涨”不等于泄漏——得先用 runtime.ReadMemStats 确认 HeapInuse 在稳定负载下线性增长，且重启后归零复现。如果刚压测完就抓 profile，快照里全是 GC 暂时没来得及 sweep 的临时对象，inuse_space 可能虚高，GoLand 画出来的火焰图也跟着失真。
实操建议：
- 写个简单 HTTP handler，在入口和出口各调一次
runtime.ReadMemStats，打印HeapInuse和NumGoroutine - 单次请求后等 30 秒，看数字是否回落；持续压测 5 分钟，观察曲线是否呈 30 度斜线爬升
- 若
NumGoroutine同步暴涨（比如从 42 → 1867），优先查 goroutine 泄漏，它常是内存泄漏的真正推手
用GoLand内置pprof采集goroutine阻塞堆栈，重点筛chan receive和select
协程泄漏本身内存开销小，但它会“钉住”大对象（比如闭包捕获的 []byte、未消费的 channel 缓冲区、全局 sync.Map 里的指针）。这时 heap profile 看不出问题，但 /debug/pprof/goroutine?debug=2 会暴露所有卡死点。
GoLand 提供两种方式获取这个关键堆栈：
- 终端执行：
wget http://localhost:6060/debug/pprof/goroutine?debug=2 -O goroutine-blocked.gor，然后拖进 GoLand，它会自动解析并跳转源码 - 菜单栏 Run → Start Profiling → Goroutines → Start，采样 10 秒后 Stop，直接看到 goroutine 列表和火焰图
- 在火焰图中右键任意节点 → “Filter by Stack Trace”，输入
chan receive或select，立刻聚焦泄漏高发路径
注意：必须用 ?debug=2，?debug=1 只返回统计摘要，看不到具体卡在哪行，比如 client.go:72 这种定位信息就丢了。
用GoLand分析heap profile差分，Focus可疑类型后查Call graph
单次 heap profile 没意义，必须比对两次快照的净增长。GoLand 不支持直接加载 -base 差分参数，所以得先用命令行生成可加载文件，再交给 GoLand 渲染。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
正确流程：
- 确保服务已导入
_ "net/http/pprof"，并起独立 goroutine 运行http.ListenAndServe("localhost:6060", nil) - 等服务稳定 5 分钟后，执行：
wget http://localhost:6060/debug/pprof/heap -O before.heap - 等 30 秒以上，再执行：
wget http://localhost:6060/debug/pprof/heap -O after.heap - 命令行运行：
go tool pprof -base before.heap after.heap，它会生成一个差分 profile 文件（如profile001.pb.gz） - 把该文件拖进 GoLand，或用
go tool pprof -http=:8080 profile001.pb.gz打开浏览器查看
打开后务必三步操作：
- SAMPLE 切到
inuse_space（不是alloc_space） - View → Difference（不是 Top）
- 搜索框输入你的可疑类型，比如
*UserConfig，再点 Call graph，看谁在 new 它且没释放
离线分析必须带原始二进制，否则函数名全变成goph.newunknown
GoLand 的 profiler 界面再方便，一旦脱离原始可执行文件，符号就全崩了。你看到的 top 占比再高，调用栈里全是 runtime.mcall、goph.newunknown 这种名字，根本没法定位到 worker.go:45 这一行。
这意味着：
- 线上抓的
.heap文件，必须和当时编译出的那个二进制文件一起保存，缺一不可 - CI/CD 打包时要存档 binary + build id，别只留 Docker 镜像
- 本地复现时，别用
go run main.go，必须go build -o service后再跑，确保 profile 能对上符号
最易被忽略的一点：go tool pprof 默认找当前目录下的 binary，如果你把 profile 拷到另一台机器分析，又没指定 -binary=<path></path>，它就彻底瞎了。
