Go原生支持基准测试，需定义BenchmarkXxx(*testing.B)函数并以xxx_test.go命名；用go test -bench=.运行，-benchmem输出内存统计，B.N动态调整循环次数，应避免初始化误计入耗时。
用 go test -bench 跑基础基准测试
Go 原生支持基准测试，不需要额外安装工具。只要在测试文件里写一个形如 BenchmarkXxx(*testing.B) 的函数，就能用 go test -bench 运行。
注意：函数名必须以 Benchmark 开头，参数类型必须是 *testing.B，且测试文件名需为 xxx_test.go。
常见错误是忘记在 B.ResetTimer() 前做初始化（比如预分配切片），导致 setup 时间被计入耗时；或者没调用 B.N 循环，直接写死次数——go test 会自动调整 B.N 使单次运行时间足够稳定。
-
go test -bench=.运行所有基准测试 -
go test -bench=^BenchmarkMapAccess$精确匹配单个函数 -
go test -bench=. -benchmem同时输出内存分配统计（allocs/op和B/op） - 默认只跑 1 秒，可用
-benchtime=5s延长采样时间提升稳定性
testing.B 的关键方法怎么用
B.N 不是固定值，而是框架根据实际耗时动态调整的循环次数，目的是让总运行时间接近目标（默认 1 秒）。你必须把待测逻辑放在 for i := 0; i 循环内，否则结果无效。
立即学习“go语言免费学习笔记（深入）”；
容易忽略的是资源复用和重置时机：B.ResetTimer() 应在初始化完成后、循环开始前调用；若循环中需避免 GC 干扰，可用 B.StopTimer() 和 B.StartTimer() 控制计时区间。
- 初始化开销大（如构建大 map）？放在循环外，再调
B.ResetTimer() - 想单独测某段子逻辑（比如序列化）？用
B.StopTimer()暂停，处理完再B.StartTimer() - 避免编译器优化掉无副作用代码：对结果变量调用
blackhole()（例如runtime.KeepAlive(x)或赋值给全局变量）
对比多个实现时如何避免干扰
在同一基准函数里测多个方案（比如 slice vs array vs sync.Pool），最容易出错的是变量逃逸或缓存局部性差异。Go 的 go test 默认串行执行每个 BenchmarkXxx，但同一函数内的不同分支共享 CPU 缓存状态和 GC 压力。
更可靠的做法是拆成独立函数：BenchmarkSliceAppend、BenchmarkPoolGetPut，再用 go test -bench=. 统一跑。这样每次运行都是干净的进程上下文。
- 不要用
if b.N == 1做一次性 setup ——B.N每次都可能不同 - 避免跨 benchmark 共享可变全局变量（如
var globalBuf []byte），否则结果互相污染 - 需要 warmup？手动加一轮预热循环（不计入计时），再调
B.ResetTimer()
什么时候该用 benchstat 而不是看单次输出
go test -bench 输出的数值本身波动较大，尤其在 CI 或笔记本上跑时。直接比较两行 245 ns/op 和 238 ns/op 没意义——得看多次运行的统计分布。
benchstat 是 Go 官方维护的分析工具（go install golang.org/x/perf/cmd/benchstat@latest），它读取多轮 go test -bench 的 JSON 或文本输出，计算中位数、delta、p-value，判断性能变化是否显著。
- 生成历史数据：
go test -bench=. -benchmem -count=5 > old.txt - 修改代码后重跑：
go test -bench=. -benchmem -count=5 > new.txt - 对比：
benchstat old.txt new.txt，它会标出哪些变化超过置信阈值 - CI 中建议固定
GOMAXPROCS=1和GOEXPERIMENT=nogc（谨慎）来减少噪音
真实项目里，单次 go test -bench 只能帮你发现数量级问题；微小优化是否有效，得靠 benchstat 的统计视角。而很多人卡在第一步：忘了跑够轮数，或者把不同机器、不同负载下的结果直接比。
