合法基准测试函数需命名为BenchmarkXxx，签名固定为func BenchmarkXxx(b *testing.B)，被测逻辑置于b.ResetTimer()之后，用b.ReportAllocs()统计内存分配，避免循环内非必要操作。
Go 的 testing 包自带基准测试能力，无需第三方库，但必须用 go test -bench 运行，且函数名必须是 BenchmarkXxx 形式，否则会被忽略。
如何写一个合法的基准测试函数
基准测试函数签名固定为 func BenchmarkXxx(b *testing.B)，b.N 是框架自动调整的循环次数，你不能手动设初值或 break —— 必须让 b.ResetTimer() 和 b.ReportAllocs() 配合实际被测逻辑。
- 被测代码必须放在
b.ResetTimer()之后，否则初始化开销会混入结果 - 若函数有 setup 开销（如构建 map、解析 JSON），应放在
b.ResetTimer()前 - 调用
b.ReportAllocs()才能显示内存分配统计（B/op和allocs/op） - 避免在循环体内做非被测操作（比如拼接字符串再丢弃），这会污染性能数据
func BenchmarkFindInSlice(b *testing.B) {
data := make([]int, 1000)
for i := range data {
data[i] = i
}
b.ResetTimer() // 计时从此开始
b.ReportAllocs()
for i := 0; i < b.N; i++ {
_ = findInSlice(data, 500) // 只测这个函数调用
}
}
为什么 go test -bench=. 跑不出结果
常见原因不是代码写错，而是文件命名或运行方式不对：基准测试必须写在 _test.go 文件里，且该文件不能带 //go:build 约束（除非显式启用），同时要确保当前目录下有对应包的源码（不能只留 test 文件）。
- 文件名不以
_test.go结尾 → 不被识别为测试文件 - 用了
//go:build ignore或//go:build !test→ 编译时被跳过 - 执行命令时不在模块根目录，或
go.mod缺失 →go test找不到包 - 函数名是
TestXxx或benchXxx（大小写/前缀错误）→ 不匹配Benchmark前缀规则
怎么对比两个函数的性能差异
用 -benchmem + -count=N 多次运行取中位数更可靠；想横向比对多个实现，直接在同一个 _test.go 里写多个 BenchmarkXxx 函数，go test -bench=^Benchmark(Linear|Binary)Search$ -benchmem 就能只跑指定几个。
立即学习“go语言免费学习笔记（深入）”；
-
-count=3会跑三次并报告最小/平均/最大耗时，比单次更有参考性 - 用正则匹配函数名（如
^BenchmarkMapGet$）可避免误跑其他 benchmark - 不同实现间注意控制变量：输入数据复用同一份切片，不要每次 new
- 如果某次结果异常（如 GC 恰好触发），
-benchtime=5s可延长总运行时间，摊平抖动
哪些优化手段在基准测试里容易失效
编译器可能内联、消除死代码，甚至把整个循环优化掉——尤其当返回值没被使用、且函数无副作用时。这时 go test 报出的纳秒级结果可能接近 0，不代表真实性能好，而是被“优化没了”。
- 强制阻止优化：用
blackhole := result; _ = blackhole或runtime.KeepAlive(result) - 对 map 操作类测试，记得用
len(m) > 0等不可省略的检查来保活 - 避免测纯计算型函数却不读取结果（比如只调
sha256.Sum256()但不取.Sum(nil)） - 并发 benchmark（
b.RunParallel）需注意数据竞争，共享状态必须加锁或分片
真实压测和基准测试不是一回事：前者看吞吐与长稳，后者只反映单次调用的纯净开销。别拿 BenchmarkJSONMarshal 的结果直接推断 HTTP 接口 QPS 上限。
