go基准测试函数必须以benchmark开头、接收*testing.b参数、置于_test.go文件中；命名如benchmarkmapaccess，并在b.n循环中编写被测逻辑，否则go test -bench会提示no benchmarks to run。
怎么写一个能跑起来的 Benchmark 函数
Go 的基准测试函数必须以 Benchmark 开头，接收 *testing.B 参数，且放在 _test.go 文件里——否则 go test -bench 根本不会识别它。
常见错误是直接写成普通函数、或者忘了加 *testing.B 参数，结果运行时提示 no benchmarks to run 或直接跳过。
- 函数名必须是
BenchmarkXXX（首字母大写），比如BenchmarkMapAccess - 必须在
for i := 0; i 循环里执行被测逻辑，<code>b.N是框架自动调整的迭代次数 - 别在循环外做初始化；如果需要预热或一次性 setup，用
b.ResetTimer()或b.StopTimer()控制计时范围
func BenchmarkMapRead(b *testing.B) { m := make(map[int]int) for i := 0; i < 1000; i++ { m[i] = i * 2 } b.ResetTimer() // 确保只测读操作，不包含建 map 的开销 for i := 0; i < b.N; i++ { _ = m[i%1000] } } go test -bench 的关键参数和输出怎么看
基准测试不是跑一次就完事，go test -bench 默认会动态调整 b.N 直到耗时稳定，所以输出里的 ns/op 才是核心指标：每次操作平均纳秒数，越小越好。
容易忽略的是默认只跑 1 秒，小函数可能被压到几百万次，大函数可能只跑几十次——导致统计抖动大。这时候得手动控制时间或最小样本数。
立即学习“go语言免费学习笔记（深入）”；
-
-bench=.运行所有 benchmark（注意是英文点，不是星号） -
-benchmem显示内存分配：关注B/op和allocs/op，突然多出几百次分配往往意味着逃逸或重复 new -
-benchtime=5s延长单轮测试时间，让结果更稳；-count=3跑 3 轮取中位数（推荐） - 输出里
1000000 1245 ns/op表示跑了 100 万次，每次 1245 纳秒；若出现100 12456789 ns/op，说明单次太慢，b.N 太小，可加-benchmem看是否卡在 GC 或分配上
为什么 b.ReportAllocs() 和内存逃逸分析要一起看
光看 B/op 数字没用——它只告诉你“分配了多少字节”，但不知道这些内存是不是逃逸到了堆上，进而拖慢后续 GC 周期。
比如一个函数返回 []byte，Benchmark 显示 16 B/op，看起来很轻，但如果用 go build -gcflags="-m" 发现底层数组逃逸了，那在高频调用场景下，实际压力远不止这 16 字节。
- 在 benchmark 函数开头调用
b.ReportAllocs()，才能让-benchmem生效 - 对疑似逃逸的代码，用
go tool compile -S -l或go build -gcflags="-m -m"检查变量是否逃逸 - 字符串转
[]byte、闭包捕获大对象、接口赋值都容易触发隐式逃逸，这类操作在 benchmark 里会放大副作用
多个实现对比时，怎么避免干扰和误判
直接写几个 BenchmarkXxx 并列跑，看似公平，但 Go 测试框架默认串行执行，前面 benchmark 的内存残留（比如未释放的大 map）可能影响后面 benchmark 的 GC 压力，导致数据偏差。
更隐蔽的问题是编译器优化：如果两个 benchmark 逻辑高度相似，Go 可能复用中间结果或内联路径，让第二组数据看起来异常好。
- 每个
Benchmark函数保持独立状态，不要共用全局变量或缓存 - 用
-run=^$排除所有单元测试干扰，只跑 benchmark：go test -bench=. -run=^$ - 想横向比 A/B 版本，最好拆成两个独立包（或临时改名），避免编译器跨函数优化
- 如果某次结果离群（比如某轮快 3 倍），别急着下结论——先关掉 CPU 频率调节（
sudo cpupower frequency-set -g performance），再重跑 3–5 轮看分布
真正难的不是跑出数字，而是确认这个 ns/op 在真实服务里是否可复现——本地空载环境永远比线上少一堆干扰项，比如网络延迟、锁竞争、GC STW 时间。把 benchmark 当作探测探针，而不是最终判决书。