ns/op 仅反映平均调用耗时，不体现耗时分布与内存分配；需用 b.ResetTimer() 隔离初始化、b.SetBytes() 启用 MB/s、-benchmem 查看 B/op 和 allocs/op，并通过 -count=10 与 benchstat 验证显著性。
ns/op 看起来快，但可能根本没测到真实逻辑
ns/op 是输出里最显眼的数字，但它只告诉你“平均每次调用耗时多少纳秒”，不说明这时间花在哪了。常见错误是忘记调用 b.ResetTimer()，导致初始化代码（比如 make([]byte, 1e6) 或读配置文件）被算进 ns/op —— 你优化了半天，其实只是把内存分配挪到了计时器外面。
- 必须把耗时准备动作写在
b.ResetTimer()之前，核心逻辑放之后 - 如果函数返回值没被使用，Go 编译器可能直接优化掉整段循环；用全局变量兜住结果：
var blackhole interface{}，然后blackhole = yourFunc() - 单次运行波动大，
ns/op差 5% 不代表真变快了——要跑go test -bench=. -count=10，再用benchstat看统计显著性
B/op 和 allocs/op 比 ns/op 更危险，因为 GC 不会喊疼
一个函数 ns/op 降了 20%，但 allocs/op 从 0 升到 3，上线后可能毛刺频发。GC 压力不会体现在 ns/op 里，却会在高并发下突然卡住整个服务。
- 默认不输出内存指标，必须加
-benchmem参数才能看到B/op和allocs/op - 循环中写
&MyStruct{}、make([]int, n)、字符串拼接用+=，都会触发堆分配；改用make([]int, 0, n)、strings.Builder或栈上结构体可归零allocs/op - 注意
B/op是字节数，allocs/op是次数——后者更敏感，一次分配 1KB 和一百次分配 10B，allocs/op差十倍，GC 压力可能差更多
MB/s 不是自动出来的，得手动告诉测试框架“这次处理多少数据”
MB/s 对 IO 或编解码类操作至关重要，但它不会自动计算。框架只负责计时和循环次数，你要显式调用 b.SetBytes() 告诉它“每次迭代处理多少字节”，否则输出里压根不会出现 MB/s。
- 适用场景：JSON 序列化、文件读写、网络包解析等吞吐敏感操作
- 写法：在
b.ResetTimer()前调用b.SetBytes(int64(len(data)))，其中data是每次处理的原始字节数（如 1MB JSON 就传1024*1024） - 别传错单位——
b.SetBytes(1024)和b.SetBytes(1024*1024)输出的MB/s差 1000 倍，但ns/op可能几乎一样
-8 不是用了 8 个 CPU 核心，而是 GOMAXPROCS=8
输出里的 BenchmarkXxx-8 中的 -8 表示当前 GOMAXPROCS 值，即 Go 运行时允许并行的系统线程上限，不是物理核心数，也不等于实际并发度。
立即学习“go语言免费学习笔记（深入）”；
- 想对比单核/多核表现，必须显式加
-cpu=1,4,8：运行go test -bench=. -cpu=1,4,8 -benchmem，会分别输出-1、-4、-8三行 - 如果函数本身没做任何并发（比如纯 for 循环求和），
-1和-8的ns/op几乎一样——这不是测试失败，是代码没并发潜力 - 容器或 CI 环境中，
GOMAXPROCS可能被自动设为 cgroup 可用 CPU 数，但真实并行能力受限于 quota，-8可能只是“允许最多 8 个线程”，实际调度不上
ns/op 数字跳动。 
