pprof 是定位真实性能瓶颈的必备工具，需通过 HTTP 接口采集 CPU/内存数据，结合逃逸分析、避免反射、慎用 goroutine 等手段系统优化。
用 pprof 定位真实瓶颈，别猜
90% 的性能优化失败，是因为没搞清哪段代码真正拖慢了系统。pprof 不是可选项，是必选项。直接在 HTTP 服务里加 import _ "net/http/pprof"，然后用 go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30 抓 30 秒 CPU 样本；内存则用 http://localhost:6060/debug/pprof/heap。
常见误操作：
- 只看 top 函数名，忽略调用栈深度 ——
runtime.mallocgc高不等于你要改内存分配，可能是某层循环里反复make([]int, n) - 用
go test -bench测微基准，但线上是并发 + GC + 网络 IO 的混合负载，结果偏差大 - 没设
GODEBUG=gctrace=1观察 GC 频率，GC 次数暴涨常比单次耗时更伤吞吐
避免逃逸，控制变量生命周期在栈上
Go 编译器会把可能逃逸到堆上的变量自动分配到堆，而堆分配 + GC 是性能隐形杀手。用 go build -gcflags="-m -l" 查逃逸分析结果，重点关注带 ... escapes to heap 的行。
典型修复方式：
- 函数参数传
[]byte而非*[]byte或string（后者底层数据不可变，拼接易触发新分配） - 循环内不要反复
new(T)或&T{}，改用对象池sync.Pool复用结构体实例 - 小数组优先用
[32]byte而非[]byte，编译器更可能将其留在栈上
减少反射和 interface{} 动态调度开销
json.Marshal、fmt.Printf、map[interface{}]interface{} 这类泛化操作，在高频路径中代价极高。反射需运行时遍历类型信息，interface{} 调用会引入动态分发（类似虚函数表查找）。
