为什么不能靠”猜”做性能优化
性能优化的第一原则：先测量，再动手。很多”慢”是直觉骗了你——你以为的热点函数实际只占 5% CPU，真正耗时的却是某个不起眼的序列化逻辑和锁竞争。Go 标准库自带 runtime/pprof 与 net/http/pprof，无需引入第三方依赖，就能采集 CPU、内存、goroutine、阻塞、锁等多维度数据，是定位性能瓶颈最直接的工具。
两种接入方式
运行时采样（线上服务）
只要在 Web 服务里匿名导入 net/http/pprof，标准库的 init 函数会自动在 /debug/pprof/ 下注册一系列端点，零业务侵入：
import _ "net/http/pprof"
func main() {
go func() {
// 通常绑定内网端口，避免对外暴露调试接口
http.ListenAndServe("127.0.0.1:6060", nil)
}()
// ... 业务服务照常运行
}
这样无需改动任何业务代码，就能在运行时按需采样。
离线采集（单次程序 / 压测脚本）
对于命令行程序或压测脚本，用 runtime/pprof 把 Profile 数据写进文件，事后再用官方工具分析：
f, _ := os.Create("cpu.prof")
pprof.StartCPUProfile(f)
defer pprof.StopCPUProfile()
// ... 执行业务逻辑 ...
CPU Profile 实战
拿到 Profile 后，用官方工具进入交互式分析：
go tool pprof cpu.prof
(pprof) top10 # 按 flat 时间排序前 10 个函数
(pprof) web # 生成火焰图（需安装 graphviz）
(pprof) list 函数名 # 看函数内逐行耗时
关键指标是两个：flat 表示函数自身消耗（不含它调用的下游函数），cum 表示累计消耗（含整条调用链）。定位热点时，先看 cum 找到调用链入口，再看 flat 找到真正烧 CPU 的那一行。
优化 CPU 不要盯着 flat 最高的小函数死磕，要从 cum 最高的调用路径整体看——瓶颈常常在”谁调用了它”，而非函数本身。
内存 Profile：别只看总量
内存采样有两个视角，二者容易混淆：
inuse_space：当前仍被占用、尚未释放的内存——定位内存泄漏看它。alloc_space：累计分配过的总量——定位”分配过于频繁”的临时对象看它。
go tool pprof -http=:8080 \
http://127.0.0.1:6060/debug/pprof/heap
如果 inuse_space 随时间只涨不跌，八成是 slice/map 没及时释放，或 goroutine 泄漏导致闭包引用的对象无法被回收。
Profile 类型一览
| 类型 | 端点 / 来源 | 主要用途 |
|---|---|---|
| cpu | /debug/pprof/profile | 找 CPU 热点函数 |
| heap | /debug/pprof/heap | 内存占用与泄漏 |
| goroutine | /debug/pprof/goroutine | 协程数量与阻塞 |
| block | /debug/pprof/block | 同步原语阻塞耗时 |
| mutex | /debug/pprof/mutex | 锁竞争热点 |
实战要点与陷阱
- 采样要压够量：CPU Profile 默认采样 30 秒，负载太低会采不到真实热点，建议用压测工具把 QPS 打上去再采。
- 开关默认关闭：
runtime.SetMutexProfileFraction与runtime.SetBlockProfileRate默认不采集，需要显式开启才能拿到数据。 - 生产环境注意开销：heap 采样几乎零成本，但高频 CPU Profile 会拖慢服务，建议只在排查问题时段开启，并限定内网访问。
- 对照基线：优化前后各采一份，用
pprof -base old.prof new.prof做差分，避免被噪声误导。
结语
pprof 的价值不在”会用几个命令”，而在养成”先量后改”的习惯。把一个 pprof.StartCPUProfile 加进压测脚本、把 net/http/pprof 挂在内网端口，下次遇到性能问题，你拿到的就不是猜测，而是可以直接点名的函数和行号。