pprof 是 Go 官方推荐的 CPU 耗时路径分析工具，通过调用图和火焰图直观展示整条调用链（如 http.HandlerFunc → service.Process → db.QueryRow）的累计耗时，强调路径而非单个函数；需启用 /debug/pprof/ 端点，采集 30 秒样本后用 top -cum 和 web 命令分析。
用 pprof 分析 CPU 耗时路径最直接
Go 自带的 pprof 是定位耗时函数路径的首选，它能生成调用图（callgraph）和火焰图（flame graph），直观显示哪条调用链最深、哪段函数累计耗时最多。关键不是“找单个函数”，而是看「调用路径」——比如 http.HandlerFunc → service.Process → db.QueryRow 这整条链是否拖慢了响应。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 在服务启动时加一行：
go func() { log.Println(http.ListenAndServe("localhost:6060", nil)) }()，确保/debug/pprof/端点可用 - 压测期间执行：
go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30，采集 30 秒 CPU 样本 - 进入交互式界面后，用
top -cum看累积耗时路径，用web生成 SVG 火焰图（需安装 graphviz） - 注意：默认采样频率是 100Hz，对极短函数（runtime.SetCPUProfileRate(1000)（仅限开发环境）
用 trace 工具抓取单次请求的完整调用树
当你要分析某一次具体请求（比如某个慢 API）的函数路径，net/http/pprof 的 profile 太笼统，而 runtime/trace 能记录 goroutine 调度、阻塞、GC 和用户标记事件，还原出精确到微秒级的调用时序。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 在 handler 开头加：
trace.Start(os.Stderr); defer trace.Stop()，或更稳妥地写入文件：f, _ := os.Create("trace.out"); trace.Start(f); defer f.Close(); defer trace.Stop() - 触发一次慢请求后，运行：
go tool trace trace.out，浏览器打开生成的地址，点「View trace」看时间线，点「Flame Graph」看函数耗时分布 - 容易踩的坑：trace 文件体积大（尤其高并发时），别在生产长期开启；且它不自动关联源码行号，需确保编译时未 strip（即不用
-ldflags="-s -w"） - 若想按 HTTP 请求维度过滤，可配合
trace.WithRegion(ctx, "handler-login")手动打标记
用 go-callvis 可视化模块级函数调用关系
当你还没跑起来服务，只是想静态看清某个包里哪些函数被谁调、调用深度如何，go-callvis 是个轻量选择。它不测耗时，但能快速暴露设计隐患：比如 utils.Helper 被 20 个地方调用，又深层调了 crypto/rand.Read，那它很可能成为性能瓶颈点。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 安装：
go install github.com/TrueFurby/go-callvis@latest - 生成图：
go-callvis -group pkg -focus mymodule -no-src -file callgraph.svg ./...，其中-focus锁定目标模块，-no-src跳过标准库干扰 - 注意：它只解析 AST，不执行代码，所以无法识别 interface 动态调用或反射调用（比如
json.Unmarshal内部的字段 setter 就不会出现在图中） - 适合阶段：代码审查期、重构前摸底，不适合代替 runtime profiling
别忽略编译器内联和逃逸分析的影响
你看到的「耗时函数」有时根本没上栈——因为被编译器内联了。比如 strings.TrimSpace 在小字符串场景下常被内联，pprof 里就看不到它，只看到它的调用方耗时突增。这时候单看火焰图会误判。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 检查内联情况：
go build -gcflags="-m -l" main.go，-l 关闭内联，对比前后 pprof 结果差异 - 看逃逸：
go build -gcflags="-m" main.go，如果一个本该栈分配的小结构体总显示... escapes to heap，那 GC 压力可能掩盖了真实 CPU 瓶颈 - 一个典型陷阱：用
fmt.Sprintf拼接日志，即使函数本身快，但频繁堆分配 + GC 会让整条路径变慢，而 pprof 的 CPU profile 不会标出内存分配开销
真正难的不是生成火焰图，而是判断那个占 12% 的 runtime.mallocgc 是谁逼出来的——得倒查逃逸分析+分配热点，再结合 trace 时间线交叉验证。
