合法的benchmark函数需以benchmark开头、接收testing.b参数，如func benchmarkfibonacci(b testing.b)；必须用b.stoptimer()和b.resettimer()分离初始化与计时，避免编译器优化需强制使用返回值，结果对比应多轮运行并关注-benchmem指标。
怎么写一个合法的 Benchmark 函数
Go 的 go test 只识别以 Benchmark 开头、参数为 *testing.B 的函数。名字不规范或签名不对，go test -bench=. 就直接忽略——不会报错，也不会提示，这是新手最常卡住的地方。
实操建议：
- 函数名必须是
BenchmarkXXX（首字母大写，驼峰），比如BenchmarkFibonacci，不能是benchmark_fib或TestBenchmarkFib - 签名必须严格为
func BenchmarkXXX(b *testing.B)，多一个参数、少一个星号、类型写成testing.B（漏指针）都会静默失效 - 别在函数里用
log.Fatal或 panic，否则基准测试中途退出，b.N会异常，结果不可信
为什么 b.ResetTimer() 和 b.StopTimer() 不可少
基准测试默认从函数入口开始计时，但初始化开销（如建 map、读文件、预热缓存）不该计入性能数据。不手动控制计时器，测出来的其实是“初始化 + N 次调用”的总耗时，尤其当初始化很重时，结果完全失真。
常见错误现象：同一函数多次运行，ns/op 差几倍，且每次 b.N 值不稳定——大概率是 setup 代码混在计时区内。
实操建议：
- 耗时 setup 放在
b.StopTimer()后，再b.ResetTimer()重启计时，例如：b.StopTimer() cache := make(map[int]int) b.ResetTimer()
- 如果函数本身有副作用（比如修改全局状态），每次迭代前需重置，也应放在
b.StopTimer()区块内 -
b.ReportAllocs()要放在ResetTimer()之后才生效，否则内存分配统计可能包含 setup 阶段
如何避免编译器优化导致的假阳性结果
Go 编译器可能把未被使用的返回值、无副作用的循环整个删掉，导致 Benchmark 测出“0 ns/op”。这不是函数快，是根本没跑。
典型错误场景：测一个纯计算函数，但没用它的返回值，也没让它影响任何变量——go tool compile -S 看汇编就能发现对应逻辑消失了。
实操建议：
- 强制使用结果：用
blackhole := yourFunc(...)，然后在循环末尾加blackhole = blackhole（防止被进一步优化） - 更稳妥的做法是调用
testing.Benchmark提供的b.ReportMetric或直接输出到全局变量（如var result int; result = yourFunc(...)），但注意别引入同步开销 - 用
go test -gcflags="-l" -bench=.关闭内联，可辅助验证是否被优化；不过日常测试不必总关，重点是确保结果被消费
怎么让 Benchmark 结果真正可比
单次 go test -bench=. 的 ns/op 是平均值，但受系统负载、GC 干扰、CPU 频率波动影响很大。直接比两个数字，容易得出错误结论。
实操建议：
- 至少跑 3 轮，用
go test -bench=. -count=3，观察ns/op的标准差；如果某次偏离均值 >10%，要检查是否被其他进程干扰 - 关键对比务必用
-benchmem，关注B/op和allocs/op—— 内存分配次数突增往往比耗时更早暴露设计问题 - 不同机器间横向比较？别只看
ns/op。记下go version、GOOS/GOARCH、CPU 型号，最好在同一台机器上做 A/B 对比；跨架构（如 arm64 vs amd64）直接比数字意义不大
真实项目里，最容易被忽略的是 GC 对长时 Benchmark 的扰动。如果函数触发频繁小对象分配，b.N 很大时 GC 可能介入多次，而 ns/op 会把这部分也摊进去——这时候得结合 runtime.ReadMemStats 手动采样，而不是只信默认输出。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
