ns/op不是越小越好，需结合操作实质、输入规模、初始化位置、返回值使用及内存分配综合评估；allocs/op和B/op反映GC压力，MB/s需手动调用b.SetBytes()计算，-8表示GOMAXPROCS而非物理核心数。
ns/op 不是“越小越好”，得看它在比谁
ns/op 是基准测试输出里最显眼的数字，但它只告诉你“单次操作平均耗时”，不说明这个“操作”干了什么。比如 BenchmarkHTTPHandler-8 耗时 85000 ns/op，BenchmarkSum-8 只有 1250 ns/op——直接比毫无意义，前者包含网络栈、TLS握手、序列化等完整链路，后者只是纯 CPU 加法。
- 不同输入规模下，
ns/op可能失真：递归函数用固定深度（如fib(30)）测出的值，换到真实业务数据（比如动态长度切片）可能完全不具参考性 - 没调用
b.ResetTimer()就做初始化（如读配置、构建大 map），这部分时间会被算进ns/op，导致结果虚高 - 函数返回值没被使用，编译器可能整个优化掉逻辑——必须用
blackhole或runtime.KeepAlive拦住，否则你测的其实是空循环
allocs/op 和 B/op 才是线上服务真正的“血压计”
GC 压力不会体现在 ns/op 里，却会在高并发时突然让 P99 延迟飙升、STW 时间拉长。而 allocs/op（每次分配次数）和 B/op（每次分配字节数）才是反映 GC 压力的核心指标。
- 默认不加
-benchmem，allocs/op显示为 0——不是没分配，是没统计；必须显式加上才能看到真实内存行为 - 循环中写
&MyStruct{}看似轻量，但强制堆分配，allocs/op立刻涨；改用栈上变量或对象池可归零 - 字符串拼接用
s += "x"，每轮都 new 底层数组，B/op随长度线性增长；换成strings.Builder后常能降到 0 B/op
MB/s 不是自动出来的，得自己算、自己设
MB/s 是 IO 密集型场景（JSON 编解码、文件读写、网络包处理）的关键吞吐指标，但 Go 测试框架**不会自动计算它**——你必须手动调用 b.SetBytes() 告诉它“这次处理了多少字节”。
- 漏掉
b.SetBytes()，输出里就不会出现MB/s，哪怕你测的是 1MB JSON 的json.Unmarshal - 值要设对：比如处理一个 1024×1024 字节的 slice，就得写
b.SetBytes(1024 * 1024)；设成len(data)却忘了是int64类型，会因类型截断导致 MB/s 错乱 - 只在数据规模稳定、可复现的场景下看
MB/s：比如固定大小 buffer 的编解码；若每次处理数据量随机，这个指标就失去横向比较价值
-8 到底代表什么？别再当成“用了 8 个 CPU 核心”了
输出里的 BenchmarkXxx-8 后缀中的 -8 是 GOMAXPROCS 值，即 Go 运行时允许并行的系统线程上限，**不是物理核心数，也不等于实际并发度**。
- 纯单循环计算函数（如遍历求和），
-1和-8的ns/op几乎一样——因为没可并行逻辑，多线程根本派不上用场 - 用
go test -bench=. -cpu=1,4,8才能真正对比扩展性；如果ns/op随核数增加不降反升，大概率存在锁争用或共享 map 写竞争 - 容器环境里，cgroup 的 CPU quota 可能让
GOMAXPROCS=8实际只跑出 2 个线程的并发效果，此时看ns/op下降幅度会严重误判
真正难的不是跑出数字，而是让每次 go test -bench 的结果可比——同一台机器上，电源模式切换、后台更新、甚至 Docker 守护进程调度，都可能让 ns/op 波动 ±30%。想定位一次真实回归，得关掉频率缩放、禁用无关进程、跑够 5 轮再用 benchstat 看 p-value，否则你优化的很可能只是噪声。
