Go基准测试必须加-bench参数，否则不执行；-bench=.匹配所有Benchmark函数，-bench=BenchmarkFoo聚焦单个函数；需搭配-benchmem和-benchtime以获取准确内存与时间数据；b.ResetTimer()必写以排除初始化开销。
直接运行基准测试：必须加 -bench，否则什么都不会执行
Go 的基准测试不会随 go test 默认运行——这是和单元测试最根本的区别。不加 -bench 参数，哪怕文件里有 BenchmarkXXX 函数，go test 也完全无视它，只跑 TestXXX 函数（如果有）。
最简启动命令是：
go test -bench=.
其中 . 是正则表达式，表示匹配所有以 Benchmark 开头的函数。常见误操作包括：
- 写成
go test -bench（漏掉等号和值）→ 报错flag provided but not defined: -bench - 写成
go test -bench="BenchmarkAdd"（加了引号且未转义）→ 在某些 shell 下可能被截断或报错，推荐不加引号或用单引号 - 忘记加
-run=none→ 单元测试输出混在结果里，干扰阅读（尤其当包里有大量TestXXX时）
-bench=. 和 -bench=BenchmarkFoo 的行为差异
表面上只是匹配范围不同，但实际影响测试稳定性与可比性：
-
-bench=.运行全部基准函数，适合快速摸底，但容易因某个慢函数拖长总耗时，导致其他函数的b.N被压低（因为默认每函数限 1 秒） -
-bench=BenchmarkFoo精准聚焦单个函数，保证它独占资源、获得足够高的b.N，数据更稳定；适合验证优化、CI 中做性能门禁 - 正则支持分组，比如
-bench=^BenchmarkMap只匹配开头为BenchmarkMap的函数（^表示行首），避免误中BenchmarkMapReduce
注意：-bench 不支持通配符 *，只认 Go 正则语法。
必须搭配的参数：-benchmem 和 -benchtime
只看 ns/op 是危险的——内存分配开销常是性能瓶颈的真正来源，而默认不显示。
-benchmem 会补全两列关键指标：
-
112 B/op：每次操作平均分配多少字节内存 -
3 allocs/op：每次操作触发几次堆上内存分配（allocs 高往往意味着 GC 压力大）
-benchtime 解决的是“样本太少、抖动太大”问题。默认 1 秒太短，尤其对快函数（如纳秒级计算），b.N 可能只有几万次，统计意义弱。建议：
- 调试阶段用
-benchtime=5s或-benchtime=10s提高置信度 - CI 中固定为
-benchtime=3s，兼顾速度与稳定性 - 避免设过长（如
60s），既拖慢流程，又可能因系统负载波动引入噪声
进阶控制：为什么 b.ResetTimer() 不是可选，而是必写项？
很多初学者把初始化代码（如切片预分配、map 构建、随机数种子设置）写在循环外，却忘了调用 b.ResetTimer()，结果测出来的是“初始化+逻辑”的混合耗时，完全失真。
正确模式必须是：
func BenchmarkSum(b *testing.B) {
nums := make([]int, 1000) // 初始化放这里
for i := range nums {
nums[i] = i
}
b.ResetTimer() // ⚠️ 关键！从此刻开始计时
for i := 0; i < b.N; i++ {
sum := 0
for _, v := range nums {
sum += v
}
}
}
不写 b.ResetTimer() 的后果：
- 初始化耗时被计入
ns/op，数值虚高，且随输入规模增大而恶化 - 不同规模的 benchmark（如
BenchmarkSum100vsBenchmarkSum10000）无法横向对比，因为初始化占比差异巨大 - 并发测试
b.RunParallel中更易出错——预热逻辑若没重置，会导致首次迭代严重拖慢整体结果
真正要小心的，不是“会不会写”，而是“有没有意识到初始化本身也是性能变量”。有时候，你该测的恰恰就是初始化成本——那就另写一个 BenchmarkInitOnly，并显式控制计时启停。
