go基准测试需用go test -bench配合testing.b定位性能瓶颈，关键在正确编写benchmarkxxx函数、避免干扰操作、关注b/op和allocs/op，并结合pprof深入分析cpu与内存热点。
用 go test -bench 快速跑出基准测试结果
Go 自带的 testing.B 是定位性能瓶颈的第一步，不是为了“证明快”，而是为了“看出哪里慢”。直接在测试文件里写 BenchmarkXXX 函数，函数签名必须是 func BenchmarkXxx(b *testing.B)，且内部要调用 b.ResetTimer()（如果初始化耗时长）和 b.ReportAllocs()（看内存分配）。
常见错误：把业务逻辑写在 b.N 循环外，导致只执行一次；或循环内做了不该做的 IO、随机数生成、时间获取等非纯计算操作，干扰结果。
- 运行命令：
go test -bench=^BenchmarkParseJSON$ -benchmem -count=5（-count=5跑 5 次取中位数更稳） - 注意
-benchmem会显示每次操作的平均分配字节数和对象数，比单纯看 ns/op 更能暴露逃逸或冗余构造问题 - 避免在
Benchmark函数里用fmt.Println或log，它们会严重拖慢结果且污染输出
用 pprof 定位 CPU 和内存热点
go test -bench 只告诉你“整体变快/慢了”，但不知道哪一行吃掉了 70% 时间。这时候得靠 pprof —— 它不是独立工具，是 Go 运行时内置的采样能力。
实操方式有两种：
立即学习“go语言免费学习笔记（深入）”；
- 在
Benchmark函数里加：runtime.SetMutexProfileFraction(1); runtime.SetBlockProfileRate(1)（仅调试时开，影响精度），然后用go test -cpuprofile=cpu.out -bench=.生成 profile 文件，再go tool pprof cpu.out进入交互式分析 - 更推荐：把待测逻辑封装成一个可执行程序，用
http://localhost:6060/debug/pprof/（需注册net/http/pprof）实时抓取，适合长时间运行或复现困难的场景 - 关键命令：
top10看耗时 top 函数，list ParseJSON看具体哪行代码占 CPU，web生成火焰图（需安装 graphviz）
别只盯着 ns/op，重点关注 B/op 和 allocs/op
很多优化失败，是因为只改了执行时间，却让 GC 压力翻倍。比如把 slice 预分配改成每次都 make([]int, 0)，ns/op 可能不变甚至略升，但 allocs/op 从 1 变成 100，实际压测时 QPS 会断崖下跌。
-
B/op高 → 检查是否频繁分配小对象、字符串拼接是否用了+而非strings.Builder -
allocs/op高 → 看是否无意中触发了堆分配（比如返回局部变量地址、传指针给 map、闭包捕获大结构体） - 用
go build -gcflags="-m -m"查看逃逸分析，确认关键变量是否真的栈上分配
小心编译器优化带来的假象
Go 编译器会在 go test -bench 时做常量折叠、死代码消除，甚至整个循环被干掉。如果你看到某个 Benchmark 的 ns/op = 0.24 且 B/op = 0，大概率是逻辑被优化掉了。
- 强制阻止优化：把关键输入设为全局变量、用
blackhole（如runtime.KeepAlive(x)或赋值给var result = xxx再在函数末尾_ = result） - 验证是否被优化：加
b.ReportMetric(0, "ignored")后再跑，看结果是否突变；或用go tool compile -S看汇编输出里有没有对应逻辑 - 生产环境的表现 ≠ Benchmark 表现，尤其涉及缓存行对齐、CPU 分支预测、系统调用调度时，真实压测不可替代
真正卡住性能的，往往不是算法复杂度，而是内存布局错乱、GC 频繁触发、或锁竞争被忽略。pprof 火焰图里那一根横跨整个宽度的扁平长条，比任何 ns/op 数字都值得你停下来看三分钟。
