go基准测试出现0 ns/op是因死代码消除（dce）删除了未产生副作用的计算逻辑；必须通过resultsink赋值或runtime.keepalive强制保留结果，并确保b.resettimer()位置正确、初始化在循环外。
Go基准测试结果为0 ns/op？Dead Code Elimination在捣鬼
Go的go test -bench跑出来BenchmarkXxx-8 0 0 ns/op，不是代码快，是编译器直接把你的待测逻辑整个删了。根本没执行，自然测不出耗时。
典型诱因：你写的计算没产生任何可观察的副作用——没赋值给全局变量、没返回、没传给函数、没打印。编译器判定“这段代码对程序行为无影响”，优化阶段直接剔除。
- 常见错误现象：
result := expensiveComputation()但result后续完全没用；或只调用fmt.Println()但被-bench默认屏蔽输出 - 使用场景：所有纯计算型基准测试，比如加密、哈希、序列化、数值算法
- 关键动作：必须让结果“逃逸”出函数作用域，且不能被编译器静态推断为无用
强制保留计算结果：用blackhole或global sink
最稳妥的做法是把结果写入一个编译器无法证明“不会被读取”的地方。Go标准库测试中常用blackhole变量，本质是绕过内联和死码分析。
别用fmt.print或log.printf——它们开销大、干扰真实耗时，且可能被优化掉（尤其当-ldflags="-s -w"时）。
立即学习“go语言免费学习笔记（深入）”；
- 推荐方式：声明一个包级
var resultSink Interface{}，在Benchmark末尾赋值resultSink = yourResult - 更轻量：用
runtime.KeepAlive(yourResult)（Go 1.14+），它不产生实际存储，但向编译器发出“此值存活到此处”的信号 - 注意：
runtime.KeepAlive必须放在计算之后、函数返回之前；且参数不能是常量或字面量（如runtime.KeepAlive(42)仍可能被优化）
Benchmark函数签名和b.ResetTimer()的位置很关键
很多同学把初始化逻辑（比如构造大数组、预热缓存）写在for循环里，或者误把b.ResetTimer()放在循环中间，导致计时范围错乱，甚至触发额外优化。
基准测试框架会在for循环外自动调用一次Benchmark函数做预热，若此时已触发死码消除，后续所有迭代都无效。
- 初始化代码（如
data := make([]byte, 1e6)）必须放在b.ResetTimer()之前，且不能依赖循环变量 -
b.ResetTimer()必须紧接在初始化之后、for循环之前——早了会把初始化时间算进去，晚了会让编译器看到“循环体为空”而优化整个循环 - 避免在循环内重复分配内存（如每次
make([]int, n)），这会掩盖真实计算开销，还可能触发GC干扰
验证是否真被优化：看汇编或加-gcflags="-S"
光看ns/op为0不够，得确认编译器到底干了什么。最直接的方法是生成汇编，检查待测函数体内是否还有目标指令。
运行go test -gcflags="-S" -bench=BenchmarkXxx，搜索你的函数名，再搜关键操作（比如CALL runtime.memmove或ADDQ）。如果整段计算逻辑消失，就是DCE生效了。
- 另一个快速验证：临时把待测函数改成
func() int并手动调用一次，打印返回值。如果能打印出合理结果，说明逻辑本身没被删；如果打印0或panic，大概率已在基准中被优化 - 注意：
-gcflags="-l"（禁用内联）有时能暴露问题，但不是解法——它只是让DCE更难发生，不代表你的基准写对了 - 复杂点在于：DCE可能跨函数发生。如果你的计算封装在另一个
inline函数里，而该函数返回值未被使用，整个调用链都会消失