pprof抓CPU火焰图需合理启用：本地复现用go tool pprof http://localhost:8080/debug/pprof/profile?seconds=15，线上避免长期开启；注意采样偏差、短goroutine丢失及内联函数折叠问题，优先调持续时间而非采样率。
怎么用 pprof 抓 CPU 火焰图
Go 自带的 pprof 是最直接、开销最小的 CPU 分析手段，不用改代码，只要启动时加个 HTTP handler 就行。关键不是“能不能”，而是“什么时候开”和“开多久”。
- 线上服务别长期开着
/debug/pprof/profile，默认采样 30 秒，CPU 高峰期会加重负载 - 本地复现问题时，用
go tool pprof http://localhost:8080/debug/pprof/profile?seconds=15，15 秒足够捕获多数热点 - 如果程序没开 HTTP server，可以用
runtime/pprof手动启停：pprof.StartCPUProfile(f)+pprof.StopCPUProfile()，但记得 defer 关闭，否则文件句柄泄漏 - 火焰图不是越“高”越危险，要看底部宽、顶部尖的“胖栈”——说明某条调用路径被反复执行，比如
json.Unmarshal在循环里反复调用
go tool pprof 常见报错和绕过方法
跑完 pprof 命令经常卡在 “Fetching profile…” 或报 net/http: request canceled，本质是超时或服务没响应，不是工具坏了。
- 加
-http=localhost:8081启交互式界面，避免命令行直接渲染失败；再用浏览器打开http://localhost:8081 - 如果服务监听在非 localhost（比如 Docker 容器），HTTP handler 必须绑定到
0.0.0.0:8080，不能只写localhost:8080 - 遇到
failed to fetch any profiles，先 curl 测试：curl http://localhost:8080/debug/pprof/，看是否返回 HTML 列表；没返回说明 handler 没注册或路由冲突 - Mac 上用 Chrome 打不开火焰图？换 Firefox 或用
pprof -http=:启本地服务，别依赖默认浏览器
CPU profile 数据不准的三个隐藏原因
pprof 显示某个函数占 60% CPU，但实际逻辑很简单——大概率是采样偏差或运行时干扰，不是代码真有问题。
- Go 的 CPU profile 基于操作系统信号（
SIGPROF），在 GC STW 阶段、系统调用阻塞、或者 goroutine 频繁调度时，采样会失真；此时看pprof -top里出现大量runtime.mcall或runtime.gopark就是信号被“吃掉”了 - 短生命周期 goroutine（比如
go fn()后立刻退出）极难被捕获，profile 里几乎不显示；想分析这类，得用trace工具：go run -trace=trace.out main.go - 内联函数（
//go:noinline以外的）会被折叠进调用方，导致父函数“背锅”；用pprof -list=函数名看具体行号，比总占比更有用
要不要用 runtime.SetCPUProfileRate
绝大多数情况——不要碰。Go 1.10+ 默认采样率是 100Hz（每 10ms 一次），已经平衡了精度和开销。手动调高只会让 profile 更重，还可能掩盖真实瓶颈。
立即学习“go语言免费学习笔记（深入）”；
- 设成 0 表示关闭 CPU profiling（但 HTTP handler 还在，只是不采样）
- 设成负数（比如
-1）会让 runtime 用更高精度的时钟源（CLOCK_MONOTONIC），但仅对极少数需要亚毫秒级定位的场景有用，日常完全没必要 - 真正该调的是持续时间，不是频率：30 秒 profile 跑出来全是 GC，就说明你该在 GC 间隙（比如
debug.ReadGCStats后）再抓一次
profile 不是拍快照，是看模式。同一段代码在不同负载下热点可能完全不同，别信单次结果。另外，pprof 看不到锁竞争、内存分配毛刺、syscall 阻塞细节——那些得靠 go tool trace 或 perf 补位。
