基准测试被优化是因为go编译器会删除无副作用的代码。1. 编译器认为未使用或无变化的变量和计算是无效代码并删除；2. 导致基准测试中实际逻辑未执行，结果失真；3. 使用runtime.keepalive可阻止变量被优化，确保代码真实运行；4. keepalive应放在循环外，仅在必要变量上使用；5. 查看汇编代码可确认是否被优化，对比加与不加keepalive的执行差异。
在写基准测试时，我们最怕的就是编译器优化掉我们真正想测的代码。Golang的编译器非常聪明，它会自动删掉一些看起来“没用”的计算或变量赋值，结果就是你的基准测试跑得飞快，但其实什么都没测到。
要解决这个问题，就得用到runtime.KeepAlive这个工具。它能阻止编译器把某些变量提前回收或者优化掉，从而保证你写的测试逻辑是真实执行的。
为什么基准测试会被优化？
Go的编译器会对无副作用的代码进行删除。比如你在函数里算了个值，但没返回也没打印，编译器就会认为这段代码没意义，直接跳过。这在正常程序中没问题，但在做性能测试的时候就坏事了。
立即学习“go语言免费学习笔记（深入）”；
举个简单的例子：
func BenchmarkAdd(b *testing.B) {
var x int
for i := 0; i < b.N; i++ {
x = 1 + 2
}
}上面这段代码，理论上应该每次循环都做一次加法。但如果编译器发现x没被使用，可能就会把整个循环优化成一个空操作，导致测试结果失真。
KeepAlive的作用和使用方法
runtime.KeepAlive的作用是告诉编译器：“这个变量我后面还会用，别动它。”这样就能防止变量被提前回收或优化掉。
正确使用方式是在关键变量后面加上runtime.KeepAlive，确保变量不会被忽略。例如：
func BenchmarkAdd(b *testing.B) {
var x int
for i := 0; i < b.N; i++ {
x = 1 + 2
}
runtime.KeepAlive(x)
}这里加了一个KeepAlive(x)，编译器就不会再轻易地把循环里的加法优化掉了。
几个注意事项：
-
KeepAlive必须放在循环外面，否则可能起不到作用。 - 它不是用来测量变量的值的，只是为了让变量不被优化。
- 不是每个变量都需要加，只有那些可能被编译器判断为“无用”的变量才需要。
常见误用场景
有些人会在循环里频繁调用KeepAlive，比如这样：
for i := 0; i < b.N; i++ {
x = 1 + 2
runtime.KeepAlive(x)
}这种写法其实没啥用，因为每次循环都调用一次并不会影响编译器对整体变量生命周期的判断。正确的做法还是只在最后调用一次，让变量在整个循环期间都被保留下来。
还有人会忘记加这个语句，导致测试数据完全不准。尤其是当你测试的是某个中间结果、局部变量或者结构体字段时，更要注意是否被优化。
如何确认是否被优化？
你可以通过查看生成的汇编代码来确认是否真的执行了你要测的逻辑。
命令如下：
go tool compile -S -N -l main.go
-
-S输出汇编代码 -
-N关闭优化 -
-l关闭内联
如果你发现你的测试函数中根本没有你想测的指令，那大概率就是被优化掉了。
当然，也可以尝试对比加了KeepAlive前后的运行时间。如果差异巨大，说明之前的测试很可能没有真实执行你的逻辑。
总的来说，避免编译器优化的关键在于理解变量的生命周期，并合理使用runtime.KeepAlive。这个技巧不复杂，但很容易被忽略。基本上就这些。
