cpu占用高90%非业务逻辑慢，而是goroutine泄漏、锁争用、channel阻塞或频繁系统调用；pprof需采样足够时长、带符号表二进制、避开runtime假热点，否则显示runtime.futex或地址乱码。
直接上结论：CPU 占用高，90% 不是业务逻辑“算得慢”，而是 goroutine 泄漏、锁争用、channel 阻塞或频繁系统调用；pprof 能定位，但必须采样够久、带符号表二进制、避开 runtime 假热点，否则看到的全是 runtime.futex 或地址乱码。
怎么抓到一份真正有用的 cpu.pprof
浏览器打开 /debug/pprof/profile 得到的是 HTML 页面，不是 profile 文件——这是最常踩的坑。
- 正确方式是用
wget或curl -s显式下载：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.out 就等于给它一张没坐标的地图。
- 必须同时提供二进制：
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 泄漏或阻塞资源等待。
- 先查 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 单侧使用、
time.After在 for 循环里反复创建、http.Client未设Timeout导致连接堆积 - 此时别盯着火焰图宽度，切到交互模式输
top -cum找调用链顶端，再用list 函数名定位到具体行号——比如发现是json.Marshal耗时高，就该换easyjson或预分配bytes.Buffer
怎么确认是不是内存分配导致的 CPU 高
火焰图顶部窄、底部宽的巨块（如大量 runtime.mallocgc）说明瓶颈在内存分配，不是计算逻辑。
- 用
go tool pprof -alloc_space http://localhost:6060/debug/pprof/heap查累计分配，top看前三是否是strings.Builder.Write或encoding/json.(*encodeState).marshal - 这类高频拼接或序列化会不断 new 对象，触发 GC 频繁，间接推高 CPU
-
sync.Pool缓存的对象不会出现在 heap profile 里，但如果Pool.New创建了大对象（如bytes.Buffer底层切片过大），仍会推高AllocSpace - 验证泄漏要两次采集对比：
/debug/pprof/heap?gc=1强制 GC 后记下InuseSpace，30 秒后再采一次，若持续上涨且无对应业务释放动作，基本可定性为泄漏
真正卡住人的从来不是命令怎么敲，而是看到 runtime.mcall 就以为要改调度器，或者花两小时调火焰图却忘了先确认 goroutine 是否在疯涨——问题不在工具，在解读信号时有没有跳过表层噪音，直奔资源等待的本质。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
