ns/op 更关键但需结合 B/op 判断：计算密集型以 ns/op 为首要指标，内存分配密集型则 B/op 更能暴露 GC 隐患；B/op 高常因循环中反复 make 或字符串拼接，应预分配或用 strings.Builder。
ns/op 和 B/op 哪个更关键？
看 Go 基准测试结果，ns/op（纳秒/操作）和 B/op（字节/操作）必须一起看，但优先级不同：对计算密集型函数（比如加法、哈希），ns/op 是第一指标；对涉及字符串、切片、结构体构造的逻辑，B/op 往往暴露更大问题——因为内存分配会触发 GC，间接拖慢后续所有操作。
-
ns/op低但B/op高（比如 200 ns/op + 128 B/op），大概率在循环里反复make([]byte, ...)或拼接字符串，应改用预分配或strings.Builder -
allocs/op> 0 且值稳定（如1600006 allocs/op），说明每次调用都固定分配对象，不是偶然现象，值得深挖逃逸分析（go tool compile -gcflags="-m" *.go） - 若
ns/op波动极大（比如两次运行差 3×），可能受 CPU 频率调节、后台进程干扰，需加-count=5多次取平均，或用taskset -c 0 go test -bench=.绑定单核排除干扰
为什么 BenchmarkSum-4 后面带数字？
这个后缀（如 BenchmarkSum-4 中的 -4）表示测试时使用的逻辑 CPU 核心数，由 GOMAXPROCS 或 -cpu 参数控制。它不直接代表“用了 4 个线程”，而是基准测试框架在该并发度下调度 b.N 次调用——这对并发安全代码（如 sync.Map）尤其重要。
- 默认行为：Go 自动设为当前机器逻辑核数（
runtime.NumCPU()），所以笔记本上常看到-8或-12 - 想对比单核 vs 多核性能：显式传
-cpu=1,4,8，命令形如go test -bench=. -cpu=1,4 -benchmem，输出会列出BenchmarkSum-1和BenchmarkSum-4两行 - 注意陷阱：如果被测函数本身无并发逻辑（如纯计算），
-4只是让 4 个 goroutine 轮流跑，不代表并行加速；盲目提高核心数反而因调度开销拉高ns/op
MB/s 是怎么算出来的？什么时候会出现？
MB/s 不是 Go 基准测试原生字段，而是当你在 Benchmark 函数中显式调用 b.SetBytes(N) 后，框架自动补算的吞吐量指标。它只在你告诉测试框架“本次操作处理了 N 字节数据”时才出现。
func BenchmarkCopy1K(b *testing.B) {
data := make([]byte, 1024)
b.SetBytes(1024) // ← 关键！告诉框架：每次循环处理 1KB
for i := 0; i < b.N; i++ {
_ = copy(data, data) // 实际被测操作
}
}
- 没调用
b.SetBytes()→ 输出只有ns/op、B/op，没有MB/s -
b.SetBytes(1024)且测得1200 ns/op→MB/s = 1024 / 1200e-9 / 1e6 ≈ 853.3，输出显示853.30 MB/s - 常见误用：对非 IO/非数据搬运类函数（比如 JSON 解析单个 struct）也硬塞
b.SetBytes(len(jsonBytes))，此时MB/s数值有误导性，因主要耗时不在字节搬运上
如何避免“假优化”导致的 benchmark 失真？
最典型的失真是编译器把未使用的计算结果整个优化掉，导致 ns/op 虚低——比如你测字符串截取，却没把结果赋给变量或返回，Go 编译器直接删掉整行。
- 必须让结果“逃逸”出测试循环：用
_ = result或b.ReportMetric(0, "unit")等方式锚定副作用 - 前置初始化不能写在循环里：
buf := make([]byte, 100)必须放在for i := 0; i 外面，否则B/op会把分配也算进去 - 需要重置计时器？只在真正耗时的 setup 后调
b.ResetTimer()（例如打开文件、构建大 map），别滥用——它会让b.N重新从 1 开始计数，扭曲统计基数 - 真实场景模拟不足：比如测 HTTP 客户端，却用
http.DefaultClient（含连接池复用），而生产环境是短连接，这时应手动禁用复用或 mock transport
真正难的不是跑出数字，而是让数字反映线上真实负载。哪怕 ns/op 降了 50%，如果 allocs/op 从 0 升到 1000，GC 压力可能让整体吞吐反降——这种权衡，光看一行输出永远看不出来。