GoLand中仅import _ "net/http/pprof"不足以访问/debug/pprof/，因pprof默认注册到http.DefaultServeMux，而Gin/Echo等框架或自定义mux需手动挂载路由，且必须单独监听非业务端口（如:6060），否则404。
GoLand 启动项里加 net/http/pprof 不等于 pprof 就能访问
只在 main.go 里写 import _ "net/http/pprof"，再配个 Run Configuration，服务跑起来后访问 /debug/pprof/ 依然 404——因为 pprof 的 handler 默认注册到 http.DefaultServeMux，而你的项目大概率没用它（比如用了 Gin/Echo/Chi，或自定义了 http.ServeMux）。GoLand 只管启动进程，不帮你挂路由。
实操建议：
- 确认你用的是标准
http.ListenAndServe：如果是，加import _ "net/http/pprof"+ 单独启一个端口（如:6060）就足够 - 若用 Gin：必须在路由注册阶段显式桥接，例如
r.Any("/debug/pprof/*pprof", gin.WrapH(http.DefaultServeMux))；路径末尾的*pprof通配符不能少，否则子路径重定向失败 - 若用 Chi：必须用
mx.Mount("/debug/pprof", http.HandlerFunc(pprof.Index))，不能用mx.Handle，否则/debug/pprof/heap这类子路径 404 - GoLand Run Configuration 中，确保程序确实运行起来了，并监听了可访问地址（别只绑
127.0.0.1:6060，本地调试可以，但容器或远程调试需用0.0.0.0:6060）
GoLand 调试时 CPU profile 抓不到样本？不是工具问题，是没“活干”
go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30 返回空或全是 runtime.idle，常见于 GoLand 启动后没发请求、没定时任务、没后台 goroutine。pprof CPU 采样依赖真实执行流，空闲状态自然没数据。
实操建议：
- 在 GoLand 启动服务后，立刻用终端执行
curl -X GET "http://localhost:6060/debug/pprof/profile?seconds=30"，同时另起 terminal 发压（哪怕只是循环curl http://localhost:8080/health） - 避免在 Run Configuration 里勾选 “Allow parallel run”，防止多个实例争抢端口导致采集失败
- 检查 GoLand 的 “Run with coverage” 或 “Debug” 模式是否意外禁用了 runtime 采样（Debug 模式下部分采样频率会降级，建议用 Run 模式采集）
- 若用 GoLand 自带 Terminal，注意 shell 环境变量（如
GOOS/GOARCH）是否污染了go tool pprof调用
GoLand 启动项配置 pprof 端口冲突或访问不了
GoLand 默认 Run Configuration 启动的服务监听 :8080，但 pprof 必须单独开一个端口（如 :6060），否则业务中间件（鉴权、CORS、gzip）可能拦截或改写 /debug/pprof/ 请求，返回 404 或 401。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
实操建议：
- 在
main()里另起 goroutine 启http.ListenAndServe(":6060", nil)，不要复用主服务 mux - 生产或容器环境务必改用
http.ListenAndServe("0.0.0.0:6060", nil)，而非"127.0.0.1:6060"，否则 Docker 内部或 Kubernetes Pod 无法从外部 curl - GoLand Run Configuration 的 “Environment variables” 里可加
PPROF_PORT=6060，然后代码中读取并动态绑定，方便多环境切换 - 若用 Docker Compose，记得在
ports:下暴露6060，且别和主服务端口写反（常见错误：写了- "8080:6060"导致本地访问错乱）
内存 profile 在 GoLand 里抓出来全是 runtime.mallocgc
直接访问 /debug/pprof/heap 看到顶部永远是 runtime.mallocgc，不是 pprof 失效，而是你查错了 profile 类型：/debug/pprof/heap 默认返回“当前存活对象”（inuse_space），但顶层函数显示的是分配入口；真正要定位业务代码，得看调用栈展开后的真实叶子函数。
实操建议：
- 用
go tool pprof -http=":8081" http://localhost:6060/debug/pprof/heap启 Web 界面，点函数名钻进调用栈，重点看flat值高的业务函数（不是cum） - 怀疑高频分配但对象很快被 GC？改用
/debug/pprof/heap?alloc_objects查分配次数，或/debug/pprof/heap?alloc_space查累计字节数 - 启动时加
runtime.MemProfileRate = 512 * 1024提高内存采样精度，但别设为 1（开销太大），本地调试够用即可 - GoLand 的 Terminal 里执行
curl "http://localhost:6060/debug/pprof/heap?gc=1"（Go 1.19+），强制 GC 后再采，避免旧对象干扰
GoLand 配置 pprof 最容易忽略的点：它不干涉 HTTP 路由逻辑，也不自动处理框架兼容性。所有“为什么访问不到”的问题，根源都在 handler 是否真正挂载成功、端口是否可访问、以及 profile 类型是否匹配分析目标——而不是 IDE 设置本身。
