ns/op 是单次操作平均耗时（纳秒），越小越好；B/op 是每次操作堆内存分配字节数，影响 GC 压力；二者需结合 allocs/op 和场景综合判断，不可孤立看待。
怎么看 go test -bench 输出的 ns/op 和 B/op
ns/op 是单次操作耗时纳秒数，数值越小越好；B/op 表示每次操作分配的堆内存字节数，影响 GC 压力。这两个是核心指标，但不能孤立看——比如 BenchmarkFoo-8 1000000 1250 ns/op 64 B/op 2 allocs/op 中，1250 ns/op 看似快，但如果它比对照版本多分配了 50 B/op 且 allocs/op 翻倍，实际在高并发下可能更慢。
注意：基准测试默认运行至少 1 秒，所以迭代次数（如 1000000）是动态调整的，不代表固定执行次数。别用它反推单次耗时精度。
- ns/op 是平均值，但底层用的是中位数算法（Go 1.21+ 默认启用
-benchmem并统计多次运行的中位数），对异常毛刺不敏感 - B/op 和 allocs/op 必须加
-benchmem才显示，漏掉这个参数就看不到内存分配行为 - 如果 B/op 为 0，不等于没分配——可能是逃逸分析让变量栈上分配，或编译器优化掉了临时对象
为什么 BenchmarkMapGet 在不同 CPU 核心数下结果差异很大
Go 的 testing.B 默认复用 goroutine，而 B.RunParallel 会启动多个 goroutine 并发执行，此时结果受锁竞争、缓存行伪共享、GC 干扰等影响。普通 B.N 循环是串行的，测的是单路径吞吐；并行模式测的是真实服务场景下的可扩展性。
例如 map 读操作本身无锁，但若 benchmark 中混入了写操作或使用了非线程安全结构（如未加锁的 sync.Map 替代品），RunParallel 下会出现性能断崖式下跌，而串行 B.N 完全看不出来。
立即学习“go语言免费学习笔记（深入）”；
- 用
go test -bench=. -cpu=1,2,4,8显式指定 GOMAXPROCS，观察是否线性增长——非线性说明存在争用或调度瓶颈 -
runtime.GC()在B.ResetTimer()前手动触发一次，能减少 GC 对多轮迭代的干扰 - 避免在
Benchmark函数里初始化全局 map/slice，否则首次运行会触发逃逸和扩容，污染后续轮次
如何用 pprof 定位 Benchmark 中的热点函数
单纯看 ns/op 只知道“慢”，但不知道“哪慢”。用 go test -bench=. -cpuprofile=cpu.out 生成 profile 后，go tool pprof cpu.out 进入交互式终端，输入 top 或 web 查看调用栈火焰图。
常见陷阱：profile 默认采样周期是 100Hz（即每 10ms 采一次），对 sub-100ns 级别的函数几乎无法捕获。此时要改用 -blockprofile 或 -memprofile，或者直接加 runtime.SetMutexProfileFraction(1) 拉高锁采样率。
- 确保
go test命令中不含-short或-race，它们会严重干扰性能数据真实性 -
pprof显示的“flat”时间是函数自身耗时，“cum”是包含子调用的累计时间；优先看 flat 高但 cum 不高的函数——说明它内部有可优化的计算密集逻辑 - 如果
runtime.mallocgc占比高，说明 B/op 数值虽小，但分配频次极高，考虑对象池（sync.Pool）复用
对比两个 Benchmark 版本时，benchstat 怎么用才不误导
benchstat 不是简单算百分比，它用 Welch’s t-test 判断差异是否统计显著。如果只跑一次 go test -bench=.，benchstat old.txt new.txt 会报 “no significant difference” —— 因为单次运行方差太大，t-test 无法置信。
正确做法是每组至少跑 10 轮（go test -bench=. -count=10 > result.txt），再用 benchstat 比较两组分布。否则你看到的 “-12%” 可能只是噪声波动。
- 用
benchstat -geomean强制几何平均，比默认算术平均更适合性能数据（避免极值拉偏） - 如果
benchstat输出中某行带~（如1250ns ± 3% ~ 1240ns ± 2%），说明差异在误差范围内，实际无改进 - 不要跨 Go 版本、跨机器、跨内核负载状态对比——CPU 频率降频、后台进程、thermal throttling 都会让结果失效
真正难的不是跑出数字，而是确认这些数字反映的是你要优化的那个问题。比如 bytes.Equal 在小 slice 上比 == 慢三倍，但如果你的业务里 99% 的输入长度都大于 64 字节，那这个 benchmark 就毫无指导意义。
