Go基准测试需确保条件一致：相同Go版本、构建参数、禁用CPU频率缩放、-benchmem统计内存、-count=5取中位数；Benchmark函数须防优化干扰、固定输入、正确使用b.ResetTimer和//go:noinline；用benchstat比对并关注p值与geomean提升。
用 go test -bench 跑出可比的基准测试结果
Go 自带的 testing.B 是做性能对比最直接、最可信的方式。关键不是“跑一次”，而是让优化前后的测试在相同条件下运行，否则数字毫无意义。
- 必须用
-benchmem同时开启内存分配统计，避免只看耗时忽略 GC 压力 - 禁用 CPU 频率缩放（Linux 下执行
sudo cpupower frequency-set -g performance），否则BenchmarkFoo-8的结果波动可能达 ±20% - 确保两次测试使用完全相同的 Go 版本和构建参数（如
GOOS=linux GOARCH=amd64 go test），跨平台或跨版本对比无效 - 单次运行不足以定论，建议用
-count=5取中位数，例如：go test -bench=^BenchmarkParse$ -benchmem -count=5
写可复现的 Benchmark 函数要注意什么
很多初学者写的 benchmark 看似在测逻辑，实则测的是编译器优化或空循环——比如忘记调用 b.ReportAllocs() 或误用 b.N。
-
b.ResetTimer()必须放在初始化代码之后、主循环之前，否则把 setup 时间也算进耗时 - 被测函数不能是内联候选（加
//go:noinline注释），否则优化前后可能走不同路径 - 输入数据要固定（如从字节切片预生成，而非每次
fmt.Sprintf），否则引入非目标变量 - 避免在循环里做非目标操作：比如测 JSON 解析，就别在
for i := 0; i 里重复json.Unmarshal以外的 map 构造或日志打印
func BenchmarkParseJSON(b *testing.B) {
data := []byte(`{"name":"alice","age":30}`)
b.ResetTimer()
for i := 0; i < b.N; i++ {
var u User
json.Unmarshal(data, &u) // ← 这才是唯一被测行为
}
}
对比两版实现时，benchstat 比肉眼更可靠
直接看 12.42 ns/op → 9.11 ns/op 容易误判——得确认是否显著。Go 官方工具链提供了 benchstat（需 go install golang.org/x/perf/cmd/benchstat@latest）。
- 分别保存两组结果：
go test -bench=Parse -count=10 > old.txt和> new.txt - 执行
benchstat old.txt new.txt，它会自动做 t-test 并标出 p 值和提升百分比 - 输出中若出现
geomean: 1.37x faster且p=0.0002，才算可信提升；若写0.98x (±2.1%)就基本没变 - 注意：如果
old.txt和new.txt的BenchmarkXXX-8后缀不一致（比如一个跑在 8 核、一个跑在 4 核），benchstat会拒绝比较
容易被忽略的干扰项：GC、调度、缓存行伪共享
哪怕 benchmark 写对了，真实性能差异也可能被底层机制掩盖。
立即学习“go语言免费学习笔记（深入）”；
- 高频率小对象分配（如每轮新建
map[string]int）会让gc pause成为主因，此时看B/op比ns/op更关键 - 并发 benchmark（如
runtime.GOMAXPROCS(1)未锁定）可能因 goroutine 抢占导致抖动，建议显式设置runtime.GOMAXPROCS(1)再测单核场景 - 结构体字段顺序不当会导致多个 hot field 落在同一 cache line，引发伪共享；用
unsafe.Offsetof检查字段布局，必要时手动填充对齐 - 如果优化后
ns/op变差但B/op大幅下降，说明你用空间换时间成功了——这在内存受限服务里反而是正向收益
ns/op 数字稳定只是起点；真正要盯住的是 allocs/op 是否增长、GC 频次是否上升、以及在线上流量下 P99 延迟是否同步改善。 
