go test -bench 仅提供平均耗时，无法定位瓶颈根源；需配合 -cpuprofile、-memprofile 等诊断工具归因，否则只能横向对比而无法分析为何快/慢。
只跑 go test -bench 为什么定位不了真实瓶颈？
因为 go test -bench 默认只告诉你“平均每次调用耗时多少”，不告诉你时间花在哪——它不是诊断工具，只是计时器。你看到 BenchmarkParseJSON-8 10000 124567 ns/op，但完全不知道这 124μs 是卡在 JSON 解析、字符串拼接、还是逃逸导致的堆分配上。
- 不加
-cpuprofile或-memprofile，benchmark 就等于盲测：只能横向对比（改前后快了多少），无法归因（为什么快/慢） -
ns/op数值稳定 ≠ 没问题：高频调用time.Now()或log.Printf可能让ns/op看似正常，实则压测时瞬间崩盘 - 忘记
b.ReportAllocs()？B/op和allocs/op字段直接不显示，而这两个数字往往比ns/op更早暴露设计缺陷（比如每次请求 new 92 个对象）
怎么用 pprof 真正看出「哪一行在拖慢程序」？
关键不是“开 pprof”，而是“在对的时间、用对的方式采集对的数据”。CPU profile 要采样够久，heap profile 要强制 GC 后抓，goroutine profile 必须加 ?debug=2 才能看到完整栈。
- CPU 采样至少 30 秒：
go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30，太短容易错过间歇性热点 - 看内存泄漏别只盯
/heap，要加?gc=1：http://localhost:6060/debug/pprof/heap?gc=1，否则看到的是“累计分配量”，不是“当前存活对象” - 查 goroutine 泄漏必须用
debug=2：go tool pprof http://localhost:6060/debug/pprof/goroutine?debug=2，否则看不到卡在chan receive或select的静默 goroutine - 生成火焰图前确认已装
graphviz，否则web命令报错；本地分析 profile 文件时，用go tool pprof -http=:8080 cpu.prof最直观
并发 benchmark 中 b.RunParallel 容易踩哪些坑？
b.RunParallel 不是简单加 goroutine，而是模拟真实竞争场景。写错一句，测出来的就是锁争用假象，不是业务瓶颈。
