写代码时遇到编译错误，很多人第一反应是检查语法、括号匹配、变量声明。但有时候，明明代码看起来没问题，却在不同环境下报错，这可能和编译器的“优化级别”有关。
什么是编译优化级别？
编译器在把源代码转成可执行程序时，会做一系列优化，比如删掉没用的代码、合并重复计算，让程序跑得更快。这些优化程度由“优化级别”控制，常见的有 -O0（不优化）、-O1、-O2 到 -O3（最高优化），还有 -Os（优化体积）等。
平时开发调试用 -O0 比较多，方便定位问题。但一到发布版本换成 -O2 或 -O3，突然冒出一堆之前没见过的警告甚至错误。
为什么优化会影响编译结果？
因为高优化级别下，编译器会大胆“猜测”你的意图。比如你写了未初始化的变量，在 -O0 下可能只是警告，运行时碰巧得到一个值。但在 -O2 下，编译器可能直接把它当成 0 处理，或者干脆删掉相关逻辑，导致行为异常。
更麻烦的是，有些代码依赖“副作用”，比如只为了执行某个函数里的打印或计数，却没有使用返回值。优化后，编译器发现这行代码“没用”，直接删了，结果功能就没了。
一个真实例子
有个嵌入式项目，主循环里加了一句调试用的空循环：
for (int i = 0; i < 1000; i++); // 延时一小会儿在 -O0 下一切正常。切到 -O2 后，整个延时不生效了——因为编译器认为这个循环什么都没做，直接优化掉了。最后只能改成带 volatile 的写法，告诉编译器“别动它”。
怎么避免这类坑？
开发时尽量在 -O2 下编译调试，而不是等到最后才切换。这样能早点暴露因优化引发的问题。另外，打开编译警告选项，比如 -Wall -Wextra，很多潜在问题会被提前揪出来。
还有，别依赖“未定义行为”或“巧合正确的运行结果”。比如数组越界访问，可能这次没崩溃，下次换了个优化级别就崩了。
家里的路由器固件更新后变卡，说不定就是厂商用了更高优化导致某些边界情况处理出错。虽然我们不都写代码，但理解这点，至少知道“不是所有 bug 都是代码写错了”，有时是“太聪明”的编译器惹的祸。