Go基准测试需严格满足四条件：文件名以_test.go结尾且同包、函数名以Benchmark开头、签名必须为func BenchmarkXxx(b *testing.B)、主体用b.N循环；b.N由框架动态调整确保总耗时约1秒，不可手动固定次数，初始化需放b.ResetTimer()前，内存统计须调b.ReportAllocs()且置于循环前。
Go 基准测试不是“测一次看时间”，而是自动拉满迭代次数、稳住总时长后算均值；耗时（ns/op）和内存（B/op、allocs/op）必须一起看，单看一个容易误判。
func BenchmarkXxx(b *testing.B) 的签名和循环结构怎么写
函数名必须以 Benchmark 开头，参数类型固定为 *testing.B，不能少星号或换类型。待测逻辑必须包在 b.N 控制的 for 循环里，框架靠它动态扩缩执行次数：
- 别把初始化放循环外又没调
b.ResetTimer()——比如data := make([]int, 1000)写在 for 前但没重置，那分配开销就全算进 ns/op 了 - 每次迭代需要干净状态？把初始化挪进循环里，比如排序测试要每次都用新切片副本，而不是复用同一份
- 函数体里别出现
fmt.Println、time.Now()、rand.Intn()这类非目标操作，它们会污染结果
go test -bench=. 输出里的 ns/op、B/op、allocs/op 各代表什么
ns/op 是单次操作平均耗时（纳秒），数值越小越好；B/op 是每次操作平均分配的字节数；allocs/op 是每次操作发生的堆内存分配次数：
-
allocs/op为 0 不等于没分配——小数组可能被逃逸分析优化到栈上，实际仍有开销 -
B/op高但allocs/op低，说明单次分配很大（比如切片底层数组扩容），该检查是否能预分配容量 - 对比不同实现时，输入规模必须一致，比如都用
make([]byte, 1024)，否则B/op失去可比性
如何让内存统计生效并定位真实分配来源
显式调用 b.ReportAllocs() 确保开启内存计数（新版 Go 默认开，但写上更稳妥）。想确认哪些变量真逃逸到堆上，加 -gcflags="-m" 看编译器输出：
- 运行
go test -bench=. -benchmem -gcflags="-m"，会打印类似&x escapes to heap的提示 - 常见逃逸点：局部变量取地址后传给接口、存进全局
map或slice、作为interface{}返回 - 若发现不该逃逸的变量跑了，优先改写法（比如传值代替传指针）、预分配容量、或用
sync.Pool缓存临时对象
为什么 b.N 每次跑都不一样，ns/op 却还能比
b.N 是动态调整的——框架先试跑几轮估算单次耗时，再放大 N 让总运行时间接近 1 秒（默认）。所以相同代码多次运行，b.N 可能差几倍，但 ns/op 应该收敛：
- 如果
ns/op波动超过 ±5%，大概率是外部干扰：CPU 被抢占、后台进程活动、或待测逻辑本身含不确定因素 - 典型陷阱：用了没设 seed 的
rand，或者依赖系统时间、未加锁的全局map，这些会让每次执行路径不一致 - 解决方法：用
rand.New(rand.NewSource(0))替代全局rand，所有随机行为固定可复现
真正难的是让测试逼近真实场景——比如处理不同长度输入时，B/op 是否随规模线性增长？有没有隐藏的扩容抖动？这些没法靠单次 benchmark 发现，得靠多组子测试 + 手动观察趋势。
