CPU占用高90%非业务算法慢，而是goroutine泄漏、channel阻塞、锁争用或频繁系统调用；pprof可定位，但需足够采样时长、带符号表的二进制文件，并避开runtime假热点，否则显示runtime.futex或地址乱码。
热路径（hot path）CPU占用率高，90%不是“算法慢”，而是 goroutine 泄漏、channel 阻塞、锁争用或频繁系统调用；pprof 能定位，但必须采样够久、带符号表二进制、避开 runtime.futex 假热点，否则看到的全是地址乱码或调度器函数。
怎么抓一份真正有用的 cpu.pprof 文件
浏览器直接打开 /debug/pprof/profile 得到的是 HTML 页面，不是可分析的 profile 二进制——这是最常踩的坑。
- 正确方式是用
curl -s或wget显式下载：wget "http://localhost:6060/debug/pprof/profile?seconds=30" -O cpu.pprof - 容器内执行：
kubectl exec -it <pod> -- curl -s "http://localhost:6060/debug/pprof/profile?seconds=30" > cpu.pprof</pod> - 时间不能太短：
?seconds=5容易错过间歇性热点；也不建议盲目拉长到 300 秒，混入空闲期噪声反而干扰判断 - 验证是否成功：运行
go tool pprof -top cpu.pprof，第一行应显示类似Showing nodes accounting for 28.41s, 99.97% of 28.42s total，且能列出具体函数名（如encoding/json.(*decodeState).object）
为什么 go tool pprof ./myapp cpu.pprof 里全是 [unknown] 或 0x 地址
pprof 需要可执行文件里的 DWARF 符号表做地址映射，只传 cpu.pprof 就等于给它一张没坐标的地图。
- 必须同时提供二进制：
go tool pprof ./myapp cpu.pprof（./myapp是你用go build生成的，默认带符号） - 禁用
-ldflags="-s -w"：这个参数会剥离符号表，发布版常用，但分析阶段绝对不能用 - 验证符号是否存在：
readelf -S ./myapp | grep debug有输出，或file ./myapp显示with debug_info - 已
strip的二进制无法补救，只能重编译；CI/CD 中建议 dev/test 环境保留符号，prod 留一份带符号 debug 版归档备用
火焰图里 runtime.futex 占比超高，是不是要优化锁
不一定。runtime.futex、runtime.netpoll 或 syscall.Syscall 占比高通常是表象，背后大概率是 goroutine 泄漏或阻塞资源等待。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 先查 goroutine 数量趋势：
curl "http://localhost:6060/debug/pprof/goroutine?debug=2" > goroutines.txt，搜索chan receive、semacquire、selectgo，看是否有重复堆栈大量堆积 - 对比
debug=1和debug=2输出，观察 goroutine 总数是否持续增长（如 5 分钟内从 2k 涨到 15k） - 典型诱因：未缓冲 channel 单侧读/写、
defer cancel()忘记调用、time.After在循环中高频创建、time.Now()或日志拼接在 hot path 中被反复调用
如何确认是不是热路径本身的问题
别急着改业务代码——先排除 runtime 干扰和采样偏差。
- 检查 GC CPU 占比：
go tool pprof http://localhost:6060/debug/pprof/profile?seconds=60进入后执行top -cum，若runtime.gc或runtime.mallocgc占比 >30%，说明是内存分配压力引发的假性 CPU 高 - 用
go tool pprof -http=:8080 ./myapp cpu.pprof启动 Web UI，重点看flat%高但cum%低的函数（纯计算型 hot path），和cum%高但flat%低的调用链（下游阻塞或同步开销） - 对疑似函数做逃逸分析：
go build -gcflags="-m -l" main.go，确认是否因频繁堆分配触发 GC，进而拉升 CPU - 若
list函数名 显示某几行反复命中，且含chan send、sync.(*Mutex).Lock或正则regexp.(*Regexp).FindStringSubmatch，基本可锁定热路径根因
真正难的不是拿到火焰图，而是区分「CPU真在干活」和「CPU在等」——goroutine 数量、block profile、trace 三者交叉验证，才能避开 runtime.futex 的幻觉。
