GoLand中pprof不生效，大概率因未启用HTTP端点：需同时满足三条件——import _ "net/http/pprof"（下划线不可省）、go http.ListenAndServe("localhost:6060", nil)、端口必须为6060且地址写"localhost"。
GoLand 里 pprof 不生效，大概率是没开 HTTP 端点
GoLand 的 “Profile with pprof” 功能不是开箱即用的——它依赖你程序里显式暴露 /debug/pprof/ 接口。漏掉任意一环，IDE 就只会卡在 “Connecting…” 或直接显示 “No profiles found”，不报错也不提示。
必须同时满足这三点：
-
import _ "net/http/pprof"（下划线不能省，否则 init 不触发） - 在
main()里启动 goroutine：go http.ListenAndServe("localhost:6060", nil) - 端口必须是
6060，地址必须写"localhost"（不是"127.0.0.1"，macOS 下部分环境解析失败）
常见错误：把 ListenAndServe 放在 http.Handle 之后、或写成阻塞式调用（没加 go），导致主 goroutine 卡住，业务逻辑根本没跑起来。
采样时长不够，热点就“看不见”
GoLand 默认采样 30 秒，但很多高耗能代码是间歇性爆发的（比如某次大文件解析、某次异常重试循环），30 秒平均下来 flat% 很低，排不到 Top 函数里。
解决办法分场景：
- 如果是长周期服务（HTTP server），直接用 GoLand 右键 →
Edit Configurations→Run kind选Profile with pprof，让它跑满 30 秒以上 - 如果是短命 CLI 工具，
time.Sleep(35 * time.Second)强制延长生命周期，否则 profile 文件为空 - 更精准的做法：改用
runtime/pprof.StartCPUProfile()+defer pprof.StopCPUProfile()，在关键路径前后手动启停
注意：flat% 是函数自身执行耗时占比，不是调用链总和——双击后看到的行级耗时（ms）才是真实瓶颈所在，别只看函数名就去优化。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
火焰图里看到 os.ReadFile 占比高，但实际问题不在读文件
os.ReadFile 或 io.Copy 在火焰图里占比高，常被误判为“磁盘慢”，其实多数情况是缓冲策略或调用方式不对。
要区分真正瓶颈：
- 如果耗时集中在
runtime.mmap或syscall.Syscall，说明是 mmap 映射或系统调用层开销大，考虑换用bufio.NewReader或调整 buffer 大小 - 如果
os.ReadFile后紧跟大量json.Unmarshal或正则匹配，那真正瓶颈在反序列化或文本处理，文件读只是前置步骤 - 用
go tool trace查Syscall blocking时间：>1ms 是磁盘 I/O 延迟；频繁短阻塞（
别只盯着火焰图顶部函数，得顺着调用栈往下钻——从入口函数开始，逐层看 flat% 分布，才能确认哪一行真正吃 CPU。
goroutine 泄漏导致 CPU 持续升高，pprof 却不显示
pprof 的 goroutine profile 默认只抓状态为 running 或 chan receive 的 goroutine，大量泄漏的 goroutine 其实卡在 select、semacquire（锁）、或已退出但 channel 未关闭，它们不会出现在默认 profile 里。
必须加参数才能暴露全貌：
- 访问
http://localhost:6060/debug/pprof/goroutine?debug=2，拿到完整栈信息 - 重点关注状态含
select、semacquire、chan send的 goroutine，它们往往等不到 case、拿不到锁、或发不出消息 - 数量随请求线性增长？检查是否漏了
defer cancel()、channel 是否 close、context 是否超时
一个容易被忽略的细节：goroutine 数量稳定但 CPU 持续 100%，很可能是死循环 + 频繁 time.Now() 或日志拼接——这些操作本身不创建 goroutine，但会把单核打满。
