Go基准测试必须用go test -bench，因其自动预热、多次执行并排除噪声；需以Benchmark开头、用b.N循环、开启-benchmem和b.ReportAllocs，并用benchstat做统计显著性对比。
用 go test -bench 跑函数基准测试是唯一靠谱方式
Go 没有运行时函数耗时监控 API，也不能靠 time.Now() 手动包两行来比性能——那测的是“单次调用+调度开销+GC干扰”，不是真实吞吐能力。必须用 Go 内置的基准测试框架，它会自动预热、多次执行、排除噪声，并输出纳秒级/操作的稳定指标。
实操要点：
- 基准测试函数名必须以
Benchmark开头，参数为*testing.B - 循环体必须放在
b.N控制的 for 中，不能写死次数（否则b.N不会被动态调整） - 被测逻辑里如果有分配内存或触发 GC 的操作，记得用
b.ReportAllocs()开启分配统计 - 避免在循环内做非目标操作（比如把日志、文件读写、随机数生成塞进去）
benchmem 和 -benchmem 参数决定你能不能看出内存问题
默认 go test -bench=. 只输出时间，但两个函数速度接近时，差异往往藏在内存分配上。比如一个函数少一次 make([]int, n)，可能快 15%，但不加内存统计就完全看不到。
正确姿势：
立即学习“go语言免费学习笔记（深入）”；
- 强制开启内存统计：
go test -bench=. -benchmem - 对比时重点关注
B/op（每次操作分配字节数）和ops/sec（每秒操作数），而非单纯看ns/op - 如果 A 函数
ns/op略高但B/op低很多，且你的场景是高频小对象，A 可能更优（减少 GC 压力）
用 benchcmp 或 benchstat 对比多次运行结果才可信
单次 go test -bench=. 输出只是某一轮采样，受 CPU 频率波动、后台进程、缓存预热程度影响极大。直接拿两次结果比数字，大概率得出错误结论。
推荐做法：
- 用
go install golang.org/x/perf/cmd/benchstat@latest安装benchstat - 分别跑多次（建议 ≥5 次），保存结果到文件：
go test -bench=. -benchmem 2>&1 | tee bench-old.txt - 用
benchstat bench-old.txt bench-new.txt输出带统计显著性的对比（含 p-value 和变化百分比） - 拒绝只看“平均值”的幻觉——
benchstat会告诉你差异是否真的可复现
别忽略 go test -gcflags="-m" 看逃逸分析
有时候两个函数 ns/op 差距不大，但其中一个总在堆上分配，另一个全程栈分配。这种差异不会立刻体现在基准数据里，却会在高并发下拖垮整体性能。
查法很简单：
- 加
-gcflags="-m -l"编译（-l关闭内联，让分析更准）：go test -gcflags="-m -l" -run=^$ - 搜关键词：
move to heap表示变量逃逸，can inline表示可能被内联优化 - 如果函数 A 被内联而 B 没有，即使基准数字接近，B 在实际调用链中也可能多一层 call overhead
真正卡点的从来不是单个函数的 ns/op，而是它在真实调用栈里的行为：是否逃逸、是否内联、是否触发 GC —— 这些得组合着看，缺一不可。
