用Keil MDK做嵌入式开发，很多人装好环境后的第一件事就是直接编译下载，优化等级这个东西默认是 -O0，也就是不优化，一路用到底也没什么感觉。等哪天系统跑起来不对劲、代码执行顺序跟想象的不一样、或者想在发布版上调试却发现变量全没了，才会回头琢磨“编译器到底对我的代码做了什么”。
我自己也是踩了不少坑之后，才把Keil MDK的优化等级机制真正搞清楚。这篇文章就把我在这上面的理解完整梳理一遍，从编译器工作方式、AC5/AC6差异、调试与发布的最优组合，到实际工程里遇到过的“优化引发的bug”，一次说清楚。
先说一句最重要的话：Keil MDK的优化，本质是ARM编译器对C/C++源码做各种变换。芯片性能不会变，编译器能做的是让程序占更少Flash、跑得更快，或者两者兼顾。你选择不同的优化等级，实际上就是告诉编译器“你可以多大胆地去改我的代码”。
1. 为什么说优化是一把双刃剑
1.1 优化等级在Keil里的具体位置
先记住入口：打开一个MDK工程，菜单栏Project -> Options for Target（快捷键Alt+F7），在弹出窗口里选择C/C++（AC5）或C/C++（AC6）标签页，右上角就是Optimize下拉框。ARM Compiler 5和ARM Compiler 6的优化选项不一样，后面我会分别展开。
很多人平时不看这个下拉框，因为默认-O0编译快、调试爽，一点问题都没有。只有当程序体积超过Flash、或者运行速度不够、或者现场出现诡异bug的时候，才会想起调优化等级。但这时候如果对编译器行为不熟悉，就会陷入“调了优化出bug、不调优化容量爆”的两难。
我个人的建议是：从建工程第一天起，就应该明确“开发期用什么优化、发布期用什么优化”，而不是等到最后再临时调。优化等级不是“越高越好”，也不完全是“调试期必须最低”，它更像一个工具，用得好能让开发效率和最终产品品质同时提升。
1.2 优化本质：编译器如何“动”你的代码
优化并不是简单“删多余代码”这么简单。编译器在优化时，会做大量变换，常见的至少有这几类：
- 常量折叠与传播：你写
a = 3; b = a + 1;，如果a后面没有被改变，编译器可能直接把b变成4，后续代码里所有用到b的地方都用4代替，真正的b变量根本不会存在。 - 死代码消除：
if (0)里那段永远不会执行的代码被直接删除；一个函数调用结果没人用，这个调用也可能被删掉。 - 指令重排：为了匹配CPU流水线，编译器可能打乱C语句的执行顺序，只要它认为这样不会改变“可见行为”。
- 函数内联：小函数被直接展开到调用处，减少call/ret的开销。调试时调用栈看不见这个函数，就是这个原因。
- 循环展开、软件流水：for循环被拆成多个副本，减少跳转次数，以代码体积换执行速度。
听起来是不是头皮发麻？对，这就是为什么高优化等级下调试器经常会“撒谎”——它展示的确实是当前指令对应的源码位置，可实际执行顺序已经被编译器打乱了。
我用一个很简单的例子说明。比如你写了一个函数：
int calc(int x) { int a = x * 2; int b = a + 1; return b; }-O0下，反汇编能看到完整的栈操作：a和b都有各自的存储位置，一步步算完再返回。但到了-O2，编译器会直接把它变成return x * 2 + 1，甚至如果把返回值转成更简单的指令序列，那就是ADD x, x之后ADD result, #1，a和b两个变量彻底消失。代码确实更快更小了，但如果你在调试器里想在int b = a + 1;这一行打条件断点，看b的值，那基本是看不到了。
我把优化等级理解成文件压缩包的“压缩强度”滑块：越高的优化等级，编译器越“无所不用其极”地榨干代码的余地，代价是编译时间变长、调试信息失真、甚至在某些边界情况下触发编译器自身的bug。
2. AC5与AC6：两代编译器，优化逻辑完全不同
2.1 ARM Compiler 5（armcc）的优化等级
用Keil MDK时，如果用的是经典的AC5编译器，它的优化等级选项有这些：
| 选项 | 含义 | 典型适用场景 |
|---|---|---|
| -O0 | 不优化 | 开发调试、断点跟踪 |
| -O1 | 有限优化，消除未引用的内联和静态函数 | 兼顾一点体积和调试 |
| -O2 | 高度优化，倾向更小的代码体积 | 发布常用 |
| -O3 | 最大优化，倾向更高性能 | 对速度敏感的功能 |
| -Os | 优化代码大小（比-O2更极端压缩体积） | Flash紧张 |
| -Oz | 最大程度减小代码大小 | 极小Flash的MCU |
| -Otime | 优化执行时间 | 高性能要求 |
| -Ospace | 优化代码空间 | 容量紧张 |
这里需要特别注意：AC5里-O2和-O3的区别不是简单的“更高级”。-O2更偏向体积小，-O3更偏向速度快，这两者在某些场景下是有冲突的。有的场合-O3产生的代码反而比-O2大，因为它为了速度做了更多循环展开和函数内联。
很多从其他编译器转过来的朋友会习惯性认为“O3一定比O2强”，在AC5上这是个误区。如果你的产品Flash余量很紧张，-O3反而可能让你编出来的固件变大；反过来，如果跑一个算法觉得慢，单纯把-O2改成-O3也不一定有效，有时候还更慢，因为更大的代码意味着更多的Flash取指，而Cortex-M系列的Flash访问是有等待周期的，代码太散反而拖慢整体速度。
2.2 ARM Compiler 6（armclang）的优化等级
AC6是ARM基于LLVM/Clang构建的新一代编译器，优化等级设计和GCC保持了一致风格：
| 选项 | 含义 |
|---|---|
| -O0 | 无优化，快速编译，调试体验最好 |
| -O1 | 基本优化，编译快，代码体量略增 |
| -O2 | 推荐的优化等级，性能与体积均衡 |
| -O3 | 激进优化，性能优先，代码体积可能明显变大 |
| -Os | 优化代码体积，接近-O2但牺牲少量性能 |
| -Oz | 比-Os更保守地压缩体积 |
| -Ofast | 启用更多浮点近似等“非标准”优化，嵌入式一般不推荐 |
AC6与AC5一个显著差异是：AC6在-O0下也会做一些变换，因为它底层用的是LLVM的中间表示（IR），编译器前端解析完源码后，IR层面的某些规范化处理天然存在，所以哪怕选了-O0，局部变量也不一定百分百能在调试器里看到。这是很多人从AC5迁移到AC6后最不习惯的一点。
我打个比方：AC5的-O0像是一个“完全手动的车”，你写什么它编译什么，所有中间变量都放到栈上，调试器能完美对照；AC6的-O0则像是在“手动模式”下还带了一点轻微的辅助系统，你踩离合换挡，它可能偷偷帮你补了一点油，整体行为没问题，但你盯着仪表盘看会发现细微差别。
另外，AC6自带基于LLVM的链接时优化（LTO），可以在链接阶段跨编译单元做优化。这个功能在大工程里能压缩不少代码量，但对编译时间影响比较大，而且如果代码不规范，LTO也可能引入一些奇怪问题，建议先评估再开。
2.3 实际工程里的选择策略
我在实际工程里一般这么选：
- 开发调试阶段：AC5用-O0，AC6用-O0。这个阶段不要做任何优化，稳定复现bug才是第一要务。少数对时序要求极严的代码，比如软件模拟I2C、精确延时，单独用#pragma或局部优化关掉。
- 功能测试阶段：AC5用-O1或-O2，AC6用-O1或-O2。跑一轮稳定性测试、老化测试，重点观察是否出现调试版没有的bug。这个阶段最容易暴露“只有优化了才出现”的隐患。
- 发布编译：AC5用-O2或-Os，AC6用-O2或-Os。如果Flash容量允许，我倾向于-O2；如果容量吃紧，AC6用-Os，AC5用-Os也能有不错的效果。
- 极端Flash紧张：用-Oz，同时配合
--split_sections（AC5）或-ffunction-sections -fdata-sections（AC6），再在Linker标签页勾选--gc-sections，把没用到的函数和段全部丢弃。
要提醒的是：不同芯片、不同工程，最优优化等级可能不一样。不能只看网上有人说“我一直用-O2没问题”就直接套用，最好用实际工程编一版，对比一下Flash占用和运行表现，再做决定。
3. 优化等级对调试的影响：变量消失、断点乱跳、调用栈错乱
3.1 高优化下的几种典型“灵异现象”
我在-O2下调试时遇到过的现象，基本分成三类。
第一类是变量被优化掉。一个局部变量赋值后，后面代码再也没用到它，编译器就把变量本身连同赋值语句一起删了。调试器里Watch窗口可能显示“not in scope”或者根本不显示。这一条最容易被新手误判成“芯片坏了”“寄存器被改了”。
第二类是断点无法命中。优化后，某些源代码行没有生成对应指令，断点自然打不到。或者一个断点同时对应多个源码位置，触发时机跟想象完全不同。更烦人的是单步执行时会看到代码“跳来跳去”，跟鼠标点到的行对不上。这不是调试器坏了，而是指令重排的后果。
第三类是调用栈错乱。函数内联后，被调用的函数在汇编层面不存在了，调用栈里自然也看不到它。想反向追踪“这个变量到底是谁改的”，在高优化下会非常痛苦。比如你怀疑一个全局变量被某个中断改了，但在-O2下跟踪时，可能根本看不清是哪个函数写进去的。
3.2 开发期如何享受优化又不丢调试能力
有人会问：我就是想在优化模式下调试怎么办？几个办法：
第一，针对局部关优化。Keil里可以对单个函数或代码段关闭优化。AC5用#pragma push/pop配合#pragma O0，AC6用__attribute__((optnone))。比如延时函数就适合强制关优化：
/* AC5 写法 */ #pragma push #pragma O0 void delay_us(uint32_t us) { volatile uint32_t i; for (i = 0; i < (SystemCoreClock / 1000000) * us; i++); } #pragma pop/* AC6 写法 */ __attribute__((optnone)) void delay_us(uint32_t us) { volatile uint32_t i; for (i = 0; i < (SystemCoreClock / 1000000) * us; i++); }第二，利用“调试信息”的开关。MDK里可以同时开优化等级和Debug Information（-g），这样优化后的代码也能生成部分本地变量符号，虽然不如-O0完整，但比完全没有强。我给客户做售后分析时，就靠这种带调试信息的axf文件配合离线反汇编定位问题。
第三，实在要在-O2下跟踪逻辑，就多依赖硬件层面的调试手段：逻辑分析仪、串口日志、GPIO翻转。用示波器确认时序是否满足预期，比在调试器里看变量更可靠。优化等级越高，“调试器还原现场”的能力越弱，这时候就该让逻辑分析仪顶上。
4. 优化引发的典型Bug与排查实录
4.1 volatile关键字：优化时代的第一课
最容易踩的坑，就是变量被优化后，读取到的值不是最新的。典型场景：中断里置一个标志位，主循环里判断这个标志位。
uint8_t flag = 0; void EXTI_IRQHandler(void) { flag = 1; } int main(void) { while (1) { if (flag == 1) { /* 做某件事 */ flag = 0; } } }-O0下一切正常。调到-O2之后，主循环里flag被编译器优化成寄存器里的值，每次都只在寄存器里比较，而中断里对内存变量的修改不会再被“感知”。表现就是主循环永远进不了if分支，或者进了if之后，flag清0又被优化掉，导致循环反复触发。这就是典型的缺少volatile的案例。
解决办法很直接：给flag加volatile：
volatile uint8_t flag = 0;volatile的含义是告诉编译器“这个变量可能在当前代码流之外被修改，每次访问都必须从内存里读，不能把它优化到寄存器”。简单理解：volatile实际上是对单个变量的“反优化”指令。优化等级是工程级的，volatile是变量级的，两者配合使用才能真正控制好“哪里可以优化、哪里必须原样执行”。
4.2 延时函数被整体删除
另一个高频问题是延时。很多人写延时：
void delay_ms(uint32_t ms) { for (uint32_t i = 0; i < ms * 1000; i++); }空循环体对编译器来说没有任何“可见效果”，到了-O2或-O3，编译器直接把这个循环删掉，延时函数变成空壳，整个程序跑得飞快，外设还没准备好你就去读寄存器，结果全读错。解决方式除了上面的局部关优化，就是在循环体里放一个volatile变量去“消耗”那些操作：
void delay_ms(uint32_t ms) { volatile uint32_t n = ms * 1000; while (n--) ; }volatile变量让编译器不敢把它优化掉。但也要提醒，这种方法在高主频下延时精度取决于CPU周期，并不适合做精密时序。真要精确延时，直接上定时器外设，用硬件定时比软件空转可靠得多。
4.3 严格别名与指针带来的坑
AC6（LLVM）对指针别名的分析比AC5更激进，如果代码里违反了strict aliasing规则，优化一开就会出现莫名其妙的行为。比如用强制类型转换去访问同一个内存区域，在某些优化下结果不符合直觉。
实践中最容易踩的是这种代码：
uint32_t buf32[4]; uint16_t *p16 = (uint16_t *)buf32; p16[0] = 0x1234;如果后续再通过buf32读取数据，编译器在-O2下可能假设“uint16_t指针和uint32_t指针不会指向同一块内存”，于是对buf32的访问和对p16的写入做重排，导致你读到的是旧值。
处理这类问题，办法有几个：一是尽量不用指针强制转换去做内存reinterpret；二是如果非转不可，用memcpy；三是可以统一数据类型，避免混用uint8_t、uint16_t指针指向同一块地址。高优化等级对代码规范性要求更高，这是现代编译器的大趋势，不是Keil独有的问题。
4.4 发布版与调试版行为不一致
调试版（-O0）一切正常，一编译成发布版（-O2/-Os）就不工作，这个现象我见得太多了。大多数情况下，背后原因是代码里存在依赖“未定义行为（UB）”的地方，比如有符号整数溢出、数组越界、对同一个变量一边写一边读的竞态，这些在-O0下因为是“逐字执行”，碰巧能跑；优化一开，编译器会依据标准定义的语义去变换代码，UB处的行为完全不受保证，自然就炸了。
遇到这种情况，我的排查顺序是：
- 先打开编译器警告，逐条清掉warning，尤其是未初始化变量、strict-aliasing这类。
- 用二分法：把优化等级从-O2一路降到-O1、-O0，看问题在哪个等级消失，缩小范围。
- 对嫌疑代码用局部关优化做验证。如果是某个函数的问题，单独给它加optnone，确认之后再去查它的实现逻辑。
- 看map文件和反汇编，确认被优化掉的是哪部分代码，结合它周边的逻辑去推断原因。
这个流程听着麻烦，但实际排查效率非常高。比起在-О2下对着调试器瞎猜，先花10分钟做一次“等级二分”，能让问题范围缩小一个数量级。
5. 更精细的优化控制：按函数、按文件调整优化等级
5.1 单文件优化配置
有些场景下，整个工程大部分模块可以高优化，但个别文件必须低优化。比如某些驱动文件、协议栈移植代码，不想因为优化而改变行为。Keil的解决方案是在工程树里选中特定.c文件，右键Options for File，然后在C/C++选项卡里单独设置这个文件的Optimize等级。这样构建时，只有这个文件用你指定的优化等级，其他文件仍然走工程全局设置。
不过有这个能力不代表可以滥用。我见过一个工程，几十个文件各设各的优化等级，最后谁也说不清到底哪个文件在什么等级下编译的。出了问题排查起来极痛苦。建议只在少数必须的驱动文件上用局部设置，其他文件保持全局统一，并且把编译前后的build log保存一份，方便追溯。
5.2 用pragma对函数级优化进行控制
如果只想针对单个函数关优化，AC5和AC6都提供了更细的手段。AC5的写法是：
#pragma push #pragma O0 static void critical_routine(void) { /* 不优化区域 */ } #pragma popAC6是用attribute：
__attribute__((optnone)) static void critical_routine(void) { /* 不优化区域 */ }我的习惯是：函数级关优化只用于三件事——延时函数、软件模拟时序协议（I2C/SPI/one-wire这类）、以及中断处理里对时序极端敏感的临界区。其他场景尽量通过代码本身去适配优化，而不是靠关优化来“掩盖”问题。因为每多一处关优化，就多一个“这条路径不走优化”的例外，工程越到后期，这种例外越难维护。
5.3 不要依赖编译器bug或未定义行为
这里要特别提醒一句：高优化等级下遇到的“怪问题”，有些确实是编译器bug，但绝大多数其实是代码里隐藏的未定义行为。不要一看到优化出问题就骂编译器，先用最笨的方法——-O0对照、局部关优化、加volatile、清警告——把问题定位到具体代码上，然后再判断到底是谁的锅。真遇到跨版本稳定复现的编译器bug，也可以考虑换一个编译器版本或用workaround，但那是极少数情况。
判断是不是编译器bug，有一个土办法：把同一个工程用AC5和AC6各编一遍，如果两个编译器在相同优化等级下行为一致，那基本可以断定问题在代码本身；如果只有某一个编译器出错，而且你把代码简化成最小复现用例后依然出错，那才有理由怀疑编译器问题。这种方法我用了好几年，准确率很高。
6. 我对Keil MDK优化等级的心得总结
先给一个最实用的组合参考，这个是我在STM32、GD32、NXP等平台上的默认配置：
| 阶段 | AC5 | AC6 |
|---|---|---|
| 日常开发调试 | -O0 | -O0 |
| 功能自测 | -O1或-O2 | -O1或-O2 |
| 发布编译 | -O2或-Os | -O2或-Os |
| Flash极度紧张 | -Oz + 段裁剪 | -Oz + 段裁剪 |
最后再分享一个小技巧：发布固件时，一定要把“Generate Debug Information”也勾上，即使你用的是高优化等级，也保留一个带调试信息的axf文件。这样后期客户现场出了问题，可以用这个axf文件配合PC指针离线还原崩溃现场，通过反汇编反查函数和行号，排查效率会高很多。哪怕不是自己维护的代码，留一份调试信息也是以后排查问题的退路。这个习惯帮我解决过好几个售后问题，强烈建议写进你的发布检查清单。
