pprof cpu性能分析核心是采样+交互诊断；启动http服务只需导入_net/http/pprof_并后台运行http.listenandserve；采样通过/debug/pprof/profile?seconds=n获取二进制profile文件；用go tool pprof需带可执行文件以解析符号，支持top、top-cum、list、web等命令；10ms采样间隔导致短于该时长的操作易被低估。
pprof 分析 CPU 性能，核心就两步：采样 + 交互式诊断；不是看“哪个函数写了多少行”，而是看“哪个调用路径在 10ms 采样窗口里反复出现”。
怎么启动 HTTP 方式的 CPU 采样
服务跑起来后，只要导入 _ "net/http/pprof" 并启一个 HTTP server，就自动注册了 /debug/pprof/ 路由。不需要额外写 handler。
- 必须确保
http.ListenAndServe是在后台 goroutine 启动的（比如用go http.ListenAndServe(...)），否则会阻塞 main - 端口别选 80 或 443 —— 这些常被其他服务占着；
localhost:6060是惯例，但生产环境建议绑定127.0.0.1而非0.0.0.0防暴露 - 访问
http://localhost:6060/debug/pprof/profile?seconds=30就开始采样；页面不会刷新，30 秒后自动下载profile文件（注意不是 JSON，是二进制 profile.proto 格式）
go tool pprof 交互命令怎么用才不懵
拿到 profile 文件后，运行 go tool pprof cpu.pprof 进入交互模式——这里最容易卡住的是不知道下一步该敲什么。
-
top：列出耗时占比最高的前 10 个函数（按“采样次数”算，不是执行时间秒数） -
top -cum：看整个调用链累计耗时，能发现“看似不重的函数，因为被高频调用而变热” -
list 函数名：显示该函数内部每行代码的采样分布，帮你定位是不是某次for循环或json.Marshal拖慢了整体 -
web：生成 SVG 火焰图（需提前装graphviz）；火焰图里宽的函数块 ≠ 写得长，而是“被采样到的次数多”
为什么本地分析要带可执行文件
如果你用 go test -cpuprofile=cpu.pprof 生成的 profile，直接 go tool pprof cpu.pprof 会报 failed to fetch binary —— 因为 pprof 需要符号表来把地址映射回函数名。
- 正确做法是：
go tool pprof your_binary_name cpu.pprof，其中your_binary_name是编译出的二进制（如./main）或测试生成的xxx.test文件 - HTTP 方式采集的 profile 默认自带二进制路径信息，所以通常不用手动指定；但若程序是交叉编译、或部署在容器里，符号路径可能失效，就得用
-inuse_space或-alloc_space等 flag 绕过 - 别用
go tool pprof -http=:8080 cpu.pprof就以为万事大吉——它只渲染，不校验符号，点进去函数名可能是???
真正难的不是跑通命令，而是理解“10ms 一次采样”意味着：短于 10ms 的函数调用大概率不会被记录，而频繁小开销操作（比如空 select、无缓冲 channel ping-pong）可能被严重低估。这时候得配合 block 或 trace 补充看。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
