不测量就优化等于蒙眼调参，Go性能瓶颈常与直觉相反；pprof是轻量可信起点，需分层测量：先cpu profile定位热点，再trace或heap分析，所有优化决策必须基于数据。

不测量就优化，等于蒙眼调参

因为 Go 程序的性能瓶颈往往和直觉相反：你以为是 for 循环慢，实际是 json.Unmarshal 分配了 10 万次小对象；你以为是 GC 拖累，结果是 time.Now() 在高并发下成了锁争用热点。没有测量，所有“优化”都是在改随机变量。

Go 自带的 pprof 是最轻量、最可信的起点

它不需要第三方依赖，只要两行代码接入，就能拿到函数级 CPU/内存/阻塞/互斥锁的热力图。比加日志、打时间戳、猜 fmt.Printf 位置靠谱得多——后者容易干扰调度、掩盖真实问题，甚至让 bug 消失（Heisenbug）。

• HTTP 服务只需注册：

  import _ "net/http/pprof"
  http.ListenAndServe("localhost:6060", nil)

• 命令行工具可用 runtime.SetBlockProfileRate(1) + pprof.WriteHeapProfile
• 采样后用 go tool pprof http://localhost:6060/debug/pprof/profile 查 CPU 热点

常见误判场景：没测就动手，反而更慢

很多开发者看到 “goroutine 泄漏” 就急着加 sync.WaitGroup，结果发现真正问题是 context.WithTimeout 被漏传，导致协程永远卡在 select；或者一上来就用 sync.Pool 缓存结构体，却忽略了该结构体本身只分配一次、缓存反而增加逃逸和清理开销。

• 错误信号：goroutine 数持续上涨 → 实际可能是 channel 未关闭或 timer 未 stop
• 错误信号：GC 频繁 → 可能只是某处写了 strings.Repeat("", n) 生成超大临时字符串
• 错误信号：HTTP 响应慢 → 很可能卡在下游 HTTP client 的 DefaultTransport 连接池耗尽，而非本层逻辑

测量不是一步到位，而是分层收敛

Go 的性能分析必须按层推进：先看整体 pprof/cpu 找出 top3 函数，再进到该函数里用 go tool trace 看 goroutine 阻塞、网络等待、GC STW；如果涉及内存，再用 pprof/heap 看对象分配源头。跳过任何一层，都可能把 IO 瓶颈当成计算瓶颈来重写算法。

• 第一步永远不是写代码，而是跑 go test -bench=. -cpuprofile=cpu.out
• 第二步不是看数字，而是用 go tool pprof -http=:8080 cpu.out 点开火焰图，找“宽而高”的函数块
• 第三步才决定动哪里：是改算法？换数据结构？还是加缓存？——每个决策都得有 pprof 数据支撑