go程序cpu性能分析需正确采样：设足够时长（生产30s+）、用信号或http接口控制启停、编译加-gcflags="-l -n"保符号、pprof用-symbolize=exec和-http服务化生成火焰图，并结合go tool trace验证热点。
Go 程序 CPU 性能瓶颈不靠猜，得看火焰图；但直接跑 go tool pprof 很容易拿到扁平、失真甚至空白的图——根本原因是没开对采样模式，也没等够时间。
用 runtime/pprof 抓 CPU profile 时必须设对持续时间
很多人写完 pprof.StartCPUProfile 就立刻 pprof.StopCPUProfile，结果文件里只有几帧，火焰图压成一条线。CPU profile 是**基于时间采样**的，不是调用追踪，太短就什么都看不到。
- 生产环境建议至少采集
30s，本地复现问题可从10s起步 - 不要在函数入口/出口硬编码启停，改用信号控制（比如收到
SIGUSR1开始，SIGUSR2停止） - 如果程序生命周期短（如 CLI 工具），用
net/http/pprof的 HTTP 接口更稳妥，避免提前退出丢数据
go tool pprof 生成火焰图前要确认是否含内联和符号信息
默认编译的二进制可能被优化掉函数名或内联展开，导致火焰图里全是 ??? 或扁平的 runtime.mcall 堆栈。这不是 pprof 问题，是构建环节没配好。
- 编译时加
-gcflags="-l -N"：禁用内联 + 关闭优化，保全调用栈语义 - 确保未 strip 符号表：
go build默认保留，但若用了upx或手动strip就会失效 - 用
pprof -symbolize=exec -http=:8080 cpu.pprof启服务后，在浏览器点「Flame Graph」，比命令行pprof -svg更准（自动做符号还原）
HTTP 方式采样时别忽略 /debug/pprof/profile 的 timeout 参数
直接访问 http://localhost:6060/debug/pprof/profile 默认只采 30 秒，但这个 30 秒是**服务端阻塞等待时间**，不是客户端能控制的。如果程序那段时间没活干，profile 就空。
- 显式传参：
curl "http://localhost:6060/debug/pprof/profile?seconds=60" -o cpu.pprof - 注意：该 endpoint 会阻塞 goroutine，别在高负载 API 路由旁直接调，最好单独起个 debug 端口（
http.ListenAndServe("127.0.0.1:6061", nil)） - 若看到
too many open files错误，是 pprof 默认用net/http/pprof注册了所有 handler，包括/debug/pprof/trace这种高频资源，按需 unregister
火焰图真正难的不是生成，而是读图时区分「真实热点」和「调度假象」：比如大量 runtime.futex 并不意味着锁有问题，可能是 GC STW 或 goroutine 频繁阻塞唤醒。得结合 go tool trace 的 goroutine 分析交叉验证，否则容易优化错方向。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
