基准测试需用b.ResetTimer()排除初始化耗时，如prepareLargeDataset()等预处理操作；若每次迭代需新数据，则用b.StopTimer()+b.StartTimer()包裹生成逻辑。
计时器没重置，初始化时间全算进去了
基准测试默认从函数入口就开始计时，但像 prepareLargeDataset() 或 make([]byte, 1e6) 这类预处理操作耗时远超被测逻辑本身，结果就变成“测的是内存分配速度”，而不是函数性能。
- 用
b.ResetTimer()在准备完成后立即调用，把初始化阶段彻底排除在统计之外 - 如果每次迭代都需要新数据（比如随机输入），改用
b.StopTimer()+b.StartTimer()包裹生成逻辑 - 别在循环外做
defer b.ResetTimer()—— 它不会生效，ResetTimer()必须显式调用且只影响后续迭代
func BenchmarkProcessData(b *testing.B) {
data := createTestData() // 耗时操作
b.ResetTimer() // ✅ 关键：从此处开始计时
for i := 0; i < b.N; i++ {
Process(data)
}
}
编译器把你的函数优化没了
Go 编译器发现 calculateSum(data) 的返回值没被使用，可能直接删掉整条调用，最终测出来是 0 ns/op —— 不是快，是没跑。
- 必须把结果赋给一个包级变量（
var result int64），或至少是函数外可逃逸的变量 - 避免用
_ = calculateSum(data)，部分版本仍可能被优化；用result = calculateSum(data)更稳妥 - 如果函数返回结构体或指针，确保字段被读取（比如
result.Field），否则字段级优化仍可能发生
var result int64
func BenchmarkCalculateSum(b *testing.B) {
data := make([]int, 1000)
b.ResetTimer()
for i := 0; i < b.N; i++ {
result = calculateSum(data) // ✅ 防止死代码消除
}
}
GC 和系统负载让数据跳变不止
一次 go test -bench=. 跑出 1200 ns/op，下一次变成 1800 ns/op，不是代码变了，是 GC 恰好在某次迭代中触发，或者后台 Chrome 占了 CPU。
- 短时低内存测试可用
debug.SetGCPercent(-1)暂停 GC，但记得defer debug.SetGCPercent(100)恢复 - 加
-benchmem看Allocs/op和Bytes/op，若这两项偏高，说明 GC 干扰大概率来自你自己的分配，不是环境问题 - 用
-cpu=1 -count=5 -benchtime=3s组合：单核运行、5 次重复、每次 3 秒，比默认参数稳定得多 - 测试前执行
runtime.GC()强制清理，避免上一轮残留影响
并行测试不加控制，结果完全不可比
b.RunParallel 看似简单，但默认会启动 GOMAXPROCS 个 goroutine，若被测函数访问共享资源（如全局 map、文件句柄），就会出现竞争、锁等待甚至 panic，测出来的不是吞吐量，是调度开销。
立即学习“go语言免费学习笔记（深入）”；
- 并行测试前先确认函数是线程安全的；否则得自己加锁或改用局部状态
- 用
GOMAXPROCS(1)或-cpu=1先跑单核 baseline，再逐步放开并发数对比 -
b.RunParallel内部的pb.Next()循环不能包含任何阻塞操作（如time.Sleep、网络调用），否则会卡住整个并行组
func BenchmarkProcessParallel(b *testing.B) {
b.RunParallel(func(pb *testing.PB) {
for pb.Next() {
ProcessOneItem() // ✅ 必须无状态、无共享、无阻塞
}
})
}
真实项目里最常被忽略的，其实是「测试数据是否每次都一样」——用固定 seed 的 rand、预生成切片、禁用 time.Now()，否则连结果都不可复现，更谈不上优化。 
