GoLand中直接运行pprof失败是因为程序未启动HTTP服务暴露/debug/pprof路由；需在代码中显式调用http.ListenAndServe(":6060", nil)并导入_ "net/http/pprof"，且运行配置应选Go Build而非pprof模板，分析时必须提供带符号表的二进制文件。
GoLand里直接跑pprof会失败，因为没启动HTTP服务
GoLand 的「Run with pprof」或「Debug with pprof」模板默认只执行 go run，不会自动监听 /debug/pprof/ 路由——你点开 http://localhost:6060/debug/pprof/ 会得到 404。关键不是 IDE 配置多复杂，而是得先让程序自己暴露接口。
- 必须在代码里显式启动一个独立 HTTP server，比如
http.ListenAndServe("localhost:6060", nil) - 不能复用主业务端口（如 :8080），否则可能被 Gin/echo 等框架的路由中间件拦截或过滤掉
/debug路径 - 导入
_ "net/http/pprof"是必要条件，但只是注册 handler，不启动服务就等于没通电
GoLand 运行配置要绕过默认 pprof 模板
GoLand 自带的 pprof 运行配置（Run → Edit Configurations → Add New → Go Tool → pprof）只适用于本地生成 cpu.out 或 mem.out 文件的场景，对 HTTP 服务无效。真要用 Web 接口分析，得手动配成普通 Go 程序运行模式。
- 新建 Run Configuration → 类型选
Go Build，不是pprof - Program arguments 留空，Working directory 设为项目根目录
- 勾选
Allow running in parallel（方便你一边跑服务一边用终端抓 profile） - 启动后，立刻在终端执行：
wget "http://localhost:6060/debug/pprof/profile?seconds=5" -O cpu.pprof
在 GoLand 里打开 pprof 报告需要二进制文件
用 go tool pprof 分析时，如果只传 cpu.pprof 文件，火焰图里全是地址（如 0x45a1b2），看不到函数名和行号——GoLand 的 pprof 插件也一样依赖符号表。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 必须提供编译后的可执行文件路径，例如：
go tool pprof ./myapp cpu.pprof - GoLand 中点击「Open Profile」时，它会提示你选 binary；如果没提示，说明 profile 是从远程 HTTP 抓的，但 binary 没放在当前目录或 GOPATH 下
- 确保没加
-ldflags="-s -w"或用upx压缩，否则符号丢失，pprof 解析不出源码位置
调试内存分配栈时 MemProfileRate 必须设为 1
你在 GoLand 里点开 /debug/pprof/heap，看到的 top 函数全是 runtime.mallocgc，业务函数压根不出现——这不是 GoLand 的问题，是 Go 默认采样率太高（512KB），小对象、逃逸变量全被跳过。
- 在
main()开头加一行：runtime.MemProfileRate = 1 - 仅限开发/测试环境，线上绝对不要长期开启：它会让 GC 压力飙升，程序明显变慢
- 配合
go build -gcflags="-l"关闭内联，否则调用栈会在中间断掉，pprof 显示不到你的业务函数行号
GoLand 本身不参与采样逻辑，它只是个 viewer 和 launcher。真正容易被忽略的是：pprof 的数据源头（是否启动服务、MemProfileRate 是否生效、binary 是否带符号）全在代码和构建阶段决定，IDE 只负责把它们串起来。
