91、编译器优化：-O0、-O1、-O2、-O3 的区别

说实话，很多嵌入式工程师写了几年代码，对编译器优化选项还是一知半解。我见过有人不管三七二十一，上来就开 -O3，结果程序跑飞了都不知道怎么回事。也有人一辈子只用 -O0，觉得优化会改坏他的代码。

这两种极端，我都踩过坑。今天咱们就把这几个优化级别彻底聊透。

优化级别到底在干什么？

编译器优化，说白了就是帮你把代码“翻译”得更聪明。它会在不改变程序语义的前提下，调整指令顺序、删掉无用代码、甚至把变量直接塞进寄存器里。

但问题是——“不改变语义”这个前提，在嵌入式世界里有时候是站不住脚的。比如你写了个空循环做延时，编译器一看：“这循环啥也没干，删掉！” 然后你的延时就没了。

嗯，这就是优化的“副作用”。

四个级别的核心区别

级别	核心策略	编译速度	代码体积	执行速度	调试友好度
-O0	不做任何优化，忠实翻译	最快	最大	最慢	★★★★★
-O1	轻度优化，基本不改变代码结构	较快	略小	较快	★★★★
-O2	中度优化，开启大部分常用优化	较慢	较小	很快	★★★
-O3	激进优化，不惜代价提升速度	最慢	可能变大	最快（但可能不稳定）	★★

逐级拆解

-O0：原汁原味

这个级别下，编译器就是个“翻译机器”。你写什么，它生成什么。每条 C 语句几乎都能对应到固定的汇编指令。变量一定在内存里，循环一定老老实实跑完。

什么时候用？ 调试阶段。我个人的习惯是：开发期间一直用 -O0，等所有功能调通了，再切到 -O2 做最终验证。

-O1：轻装上阵

-O1 会做一些“安全”的优化。比如：

• 删除死代码（永远不会执行到的代码）
• 常量折叠（比如 a = 3 + 5 直接变成 a = 8）
• 跳转优化（减少不必要的跳转指令）

这些优化基本不会破坏你的逻辑。我建议在硬件调试阶段可以用 -O1，既能保留大部分调试信息，又能让代码跑得稍微快一点。

-O2：生产级标准

这是大多数嵌入式项目的“出厂设置”。-O2 会开启几乎所有不涉及“空间换时间”的优化。包括：

• 函数内联（小函数直接展开到调用处）
• 循环展开（减少循环控制开销）
• 寄存器分配优化（尽量把变量放寄存器里）
• 指令重排（利用 CPU 流水线）

我在项目中遇到过一个问题：-O2 下，一个全局变量的值在中断里被修改，但主循环里读到的却是旧值。为什么？因为编译器把变量优化到寄存器里了，根本没去内存读。后来加了 volatile 才解决。

-O3：双刃剑

-O3 在 -O2 的基础上，又加了一些“激进”的优化。比如：

• 更激进的函数内联（不管函数大小）
• 向量化（把循环转换成 SIMD 指令）
• 更激进的循环变换

你想想看，这些优化听起来很美好，但代价是什么？

• 代码体积可能暴增——函数内联太多，Flash 不够用
• 调试几乎不可能——代码被改得面目全非，断点都不知道断在哪
• 潜在的 bug——某些优化假设在嵌入式环境下不成立

我个人几乎不用 -O3。除非是纯计算密集型任务，而且我有足够的 Flash 空间和测试覆盖。

一张图看懂优化决策

实际项目中的选择建议

1. 开发调试阶段：-O0，没得商量。别为了“跑快点”开优化，否则你会在调试器里怀疑人生。
2. 单元测试阶段：-O1 或 -O2。我建议至少用 -O1 跑一遍测试，因为有些 bug 只在优化后才暴露。
3. 发布版本：-O2 是首选。除非你有非常特殊的需求（比如 Flash 只剩 2KB），否则别碰 -O3。
4. 极端性能场景：-O3 可以试，但必须做充分的回归测试。我曾经在 -O3 下遇到过浮点运算结果不对的情况，后来发现是编译器的一个已知 bug。

总结

优化级别这事儿，说白了就是“时间换空间”和“空间换时间”的博弈。-O0 给你调试时间，-O2 给你运行时间，-O3 给你……可能是个坑。

我个人在嵌入式项目里，90% 的情况用 -O2。剩下的 10%，要么是调试阶段用 -O0，要么是某些特定模块需要单独用 -O3 做性能优化。

记住一句话：优化不是越激进越好，稳定才是第一位的。你想想看，一个跑得飞快但偶尔出错的系统，跟一个跑得慢但永远可靠的系统，客户会选哪个？

---

公众号:蓝海资料掘金营，微信deep3321