不测量就优化等于蒙眼调参，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语言免费学习笔记（深入）”；
- 第一步永远不是写代码，而是跑
go test -bench=. -cpuprofile=cpu.out - 第二步不是看数字，而是用
go tool pprof -http=:8080 cpu.out点开火焰图，找“宽而高”的函数块 - 第三步才决定动哪里：是改算法？换数据结构？还是加缓存？——每个决策都得有 pprof 数据支撑
pprof 里一眼就能定位到具体第 23 行；剩下 20% 需要 trace 或深入 runtime。但没人能绕过测量直接抵达那 20%。 
