goland中pprof服务必须手动启用：需在代码中导入_ "net/http/pprof"并启动http.listenandserve("localhost:6060", nil)，否则访问/debug/pprof将404；抓goroutine阻塞堆栈必须用?debug=2，?debug=1仅返回统计数字。
GoLand里pprof服务必须手动启用，不是装完就自动开
GoLand本身不内置pprof采集能力，它只是个IDE界面；真正起作用的是你代码里是否注册了net/http/pprof并跑起了HTTP服务。很多人在GoLand里点“Run”后直接去访问http://localhost:6060/debug/pprof/，结果404——根本原因是没在代码里加那三行：
- 导入
_ "net/http/pprof"（注意下划线） - 起一个独立goroutine：
go http.ListenAndServe("localhost:6060", nil) - 确保这个监听地址没被其他进程占着（比如另一个Go服务正用着6060）
别依赖GoLand的“自动profiling”开关——它只对CPU、内存堆快照做轻量采样，不等价于完整pprof服务，也拿不到goroutine?debug=2这种关键堆栈。
抓goroutine阻塞堆栈必须用?debug=2，?debug=1完全没用
在GoLand Terminal里执行wget http://localhost:6060/debug/pprof/goroutine?debug=1 -O goroutine-summary.gor，得到的只是个数字统计（比如“total: 128”），看不出任何卡在哪。真要定位泄漏，必须用?debug=2：
wget http://localhost:6060/debug/pprof/goroutine?debug=2 -O goroutine-blocked.gor- 打开文件后重点搜
chan receive、select、time.Sleep、semacquire这些关键词 - 如果看到某业务文件行号（如
client.go:72）反复出现在上百个goroutine栈顶，基本就是泄漏源头
注意：?debug=2输出包含阻塞时长，若出现432000s（5天）这种量级，99%是goroutine卡死没退出。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
GoLand Profiler界面能快速聚焦，但得手动过滤调用链
GoLand菜单Run → Start Profiling → Goroutines确实能一键采集并生成火焰图，但它默认展示所有goroutine，噪音极大。关键操作是右键火焰图任意节点 → Filter by Stack Trace，然后输入：
-
chan receive：筛出所有卡在channel接收的goroutine -
runtime.selectgo：定位select未设default或done channel的死等逻辑 -
timerproc或timeSleep：查漏掉defer ticker.Stop()的地方
过滤后剩下的调用链，大概率就是泄漏路径。别信“Top Functions”排序——泄漏goroutine单个内存开销小，排不到前几，但数量一多就钉住大对象。
离线分析pprof文件必须带原始二进制，否则全是goph.newunknown
你在GoLand里导出的goroutine-blocked.gor或heap.pb.gz，拿到本地用go tool pprof分析时，命令里必须带上编译时的可执行文件路径：
- 错误写法：
go tool pprof goroutine-blocked.gor→ 函数名全变成runtime.mcall这类符号 - 正确写法：
go tool pprof ./myapp goroutine-blocked.gor→ 能准确定位到server.go:142 - 用Docker的话，构建阶段就得
COPY ./myapp /app/，不能只拷profile文件
线上环境更得小心：pprof暴露端口必须绑定127.0.0.1:6060，绝不能监听:6060——否则等于把goroutine堆栈白送给公网。
