goland 仅可视化调用栈追踪，不生成数据；真正生成 trace 数据的是 go tool trace 和 runtime/trace，需手动启动采样并用浏览器打开 http 地址查看，goland 无法直接解析 trace.out。
GoLand 本身不生成调用栈追踪（stack trace profiling），它只是可视化工具；真正生成和采集调用栈数据的是 go tool trace 和 runtime/trace，必须靠你主动启动、采样、导出。指望在 GoLand 界面点几下就拿到完整调用栈热力图，会卡在“没数据”这一步。
go tool trace 是唯一能生成 goroutine 调度级调用栈追踪的工具
Go 运行时只在两种场景下记录足够细粒度的执行事件：goroutine 创建/阻塞/唤醒、系统调用、GC、网络轮询、定时器触发。这些事件组合起来才能还原出真实调度行为和阻塞根源。go tool trace 是唯一消费这些事件并生成交互式时间线视图的官方工具。
- 启动方式固定：
go run -trace=trace.out main.go或go build && ./app -trace=trace.out（程序需运行足够久，至少几百毫秒） - 生成的
trace.out是二进制格式，不能直接读，必须用go tool trace trace.out打开 - GoLand 的 “Open Profile Result” 不支持
.out文件 —— 它只认.pprof，所以别拖进 IDE 里等渲染 - 关键操作在终端：
go tool trace启动后会打印一个本地 HTTP 地址（如http://127.0.0.1:55555），必须用浏览器打开才能看到火焰图、Goroutine 分析、网络阻塞点等
GoLand 只能辅助查看 trace 中的源码上下文，不能替代 trace 启动
你可以在 GoLand 中打开 trace.out 文件，但它只会当普通二进制文件处理，不会解析。真正有用的联动是：在浏览器中打开 go tool trace 的 Web 界面 → 点击某个长时间运行的 goroutine → 查看其 stack → 复制函数名或文件行号 → 回 GoLand 用 Ctrl+Click（macOS 是 Cmd+Click）跳转到对应源码行。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 确保编译时加
-gcflags="-l -N"，否则 trace 中显示的行号会错位或缺失 - trace 里点击 “View trace” → “Goroutines” → 找到状态为
running或syscall的长条，右键 “View stack trace”，里面能看到完整调用链 - 如果 stack 里出现
runtime.gopark、netpollblock、selectgo，说明是阻塞点，不是 CPU 热点 —— 这类问题pprof cpu基本抓不到
别混淆 trace 和 pprof：它们解决完全不同的性能问题
go tool trace 关注“谁在什么时候被调度/阻塞”，pprof 关注“谁在消耗 CPU 或分配内存”。同一个慢请求，可能 trace 显示 90% 时间卡在 http.Read（I/O 阻塞），而 pprof cpu 显示 0% CPU 占用 —— 这恰恰说明问题不在代码逻辑，而在外部依赖或连接池配置。
- 高频小对象分配？用
go tool pprof -alloc_space，不是 trace - goroutine 泄漏？用
go tool pprof http://localhost:6060/debug/pprof/goroutine?debug=2，不是 trace - HTTP handler 响应慢且不确定是 CPU 还是 I/O？先跑
go tool trace，看 timeline 上是否密集出现 “blocking on network” 或 “scheduling delay” - trace 中的 “Synchronization” 视图能暴露 mutex 争用，但前提是你的锁操作足够频繁、持续时间够长（微秒级争用 trace 捕捉不到）
最常被忽略的一点：trace 数据体积大、采样开销高，不适合长期开启或线上全量采集。它是一次性诊断工具，不是监控探针。想长期观察，得用 pprof + Prometheus + Grafana 这套组合，而不是反复导出 trace.out。
