Keil MDK优化等级全解析：从O0到Oz，避开编译优化暗坑

如果你调试过一个在 Debug 配置下走得好好的程序，一换成 Release 配置就乱飞，那你已经亲身体会到 Keil MDK 优化等级的威力了。我第一次被它“教育”，是在一个基于 STM32F103 的电机控制板上：开环测试一切正常，客户那边一烧最终固件，PWM 波形直接乱掉，电机嗡嗡响还发烫。查了两天才定位到，问题根源就是优化等级从 O0 切到 O2 后，一个软件延时函数被编译器“删除”了。那是我第一次意识到，优化等级不是一个随便选的下拉框，而是一整套编译器行为策略。这篇文章把我这些年对 Keil MDK 优化等级的理解完整梳理一遍，包括每个选项到底做了什么、为什么优化后程序会出现“灵异行为”、最常见的坑长什么样，以及怎么精准控制而不是盲目全局切换。

1. 为什么嵌入式工程师经常被优化等级“暗算”

1.1 从一次 Release 固件翻车现场说起

先说上面那个电机项目的细节。当时控制逻辑写在中断里，主循环只做保护和状态刷新。Debug 配置工程默认是 O0，我全程在线仿真，波形、电流、速度都完美。客户要量产固件，我把配置切成 Release，重新编译然后直接烧录，结果上电就异常。初步怀疑是时序问题，但代码一行没改，只是编译配置变了。后来把 Release 配置的优化等级临时改成 O0，flash 进去又正常了，这才锁定问题出在优化。

这类经历在嵌入式社区里太常见了。很多工程师调试的时候习惯用 O0，因为变量可以实时查看，单步执行不会乱跳，仿真体验非常友好。发版的时候切到 O2 或者 Os 去减小代码体积、提高运行速度。结果往往是功能不对、时序不对、甚至直接 HardFault。于是大家第一反应是“编译器有 bug”，但实际上绝大多数情况是我们写的 C 代码在抽象语义上没问题，在底层指令执行层面却留下了隐患，只是 O0 的低优化掩盖了这些隐患。

1.2 优化等级的本质：编译器在替你重写代码

要理解优化等级，先要建立一个底层认知：编译器不是逐行把你写的代码翻译成汇编，它把 C 代码看作一棵语法树，然后按照优化等级施加各种变换。这些变换包括删除无用代码、复用寄存器、交换指令顺序、把函数体直接展开到调用处、把循环展开、把多个内存访问合并成批量访问，等等。

编译器在做这些变换时，唯一坚持的准则是“程序的可观察行为不变”。这个“可观察行为”在 C 语言标准里有一整套定义，比较严格但也很机械。比如一个空循环for(i = 0; i < 1000; i++);，如果变量 i 在循环之外没有被使用，编译器会认为这个循环没有任何可观察效果，直接整体删除。从 C 标准的角度看，编译器确实没错；但从我们做嵌入式硬件的角度看，这个循环可能是为了磨掉几微秒的时间，让它保持外设时序。

可以打个比方：优化器像一个严格的文字编辑，看到你写了一整段“废话文学”，他会直接划掉，因为他认为语义没变。但自己读的时候可能觉得那段“废话”是有节奏感的，删了味道全变了。硬件工程师和编译器之间的矛盾，正是“纯逻辑语义”和“物理时间语义”之间的偏差。

1.3 到底哪些人需要把优化等级研究透彻

如果你只写纯计算类代码，比如跑算法、做滤波、算坐标转换，优化等级基本不伤脑筋，因为计算结果不依赖时间，优化越狠跑得越快。但以下这几类人请务必精读这篇文章：

• 做电机控制、无刷驱动、开关电源的人，代码里的延时、PWM 占空比更新、电流环采样时序都可能被优化改变。
• 做低功耗产品和电池供电设备的人，睡眠唤醒前后的寄存器操作顺序一旦被重排，可能永远醒不过来。
• 做通信协议栈、Bootloader、Flash 擦写的人，对地址对齐、内存访问宽度、擦写时序有硬性要求。
• 移植 RTOS 或者写驱动的人，任务切换、临界区保护、中断标志位这些操作非常容易和优化器“撞车”。

明白自己属于哪类，才能在接下来配置优化等级时有的放矢。

2. Keil MDK 优化等级面板：O0 到 Oz 的差异

2.1 入口与 Debug/Release 配置的关系

在 Keil MDK 里，优化等级的位置在Options for Target对话框中的C/C++标签页。点击Optimization后面的下拉框，会看到Level 0 (-O0)、Level 1 (-O1)、Level 2 (-O2)、Level 3 (-O3)，如果在 ARM Compiler 6 下还会多出-Os balanced、-Oz等选项。

这里有一个特别容易混淆的点：Keil 工程里的Debug和Release只是两个不同的构建配置，它们各自保存着一份 Target 选项。很多人全程只在 Debug 配置里改代码，到了发版时直接把 Output 里的Create HEX File勾上，编译的是哪个配置、用的什么优化等级自己都没搞清楚。建议在工程里维护两套配置：

• Debug 配置：优化等级固定为 O0，所有调试信息全开，只用来在线调试。
• Release 配置：优化等级视项目需求选择 O2 或 Os，关闭调试输出，用于产线烧录。

我见过不少项目只用一套配置，开发调试和量产固件是同一个东西。这样不是不行，但一旦后期想开优化，就得全局动一套配置，风险很大。用两套配置从一开始就把开发态和发布态分开是最省心的习惯。

2.2 ARM Compiler 5 与 ARM Compiler 6 的等级差异

Keil MDK 从 V5 开始默认编译器是 ARMCC，也就是 AC5；从 MDK 5.37 左右开始新版 Keil 已经转向 AC6，底层是 Clang 架构的 armclang。两套编译器对优化等级的处理逻辑差别很明显，很多老工程从 AC5 迁移到 AC6 后在相同等级下行为不同，原因就在这。

AC5 的-O2相对温和，它会做函数内联、循环优化、变量覆盖分析，但不会像 AC6 那样激进。AC5 的-O3才会比较大幅度地展开循环、做更激进的指令调度。而在 AC6 下，-O2已经包含相当多的优化手段，比如更积极的常量和指针分析，代码体积和运行效率往往比 AC5 的 O2 更好，但随之而来的问题也更多。

AC6 额外提供的-Os和-Oz值得单独说。-Os 的优化目标是在不过分牺牲性能的前提下把代码体积压到最小，-Oz 更极端，几乎是优先保证体积，哪怕会显著增加运行时间。做 Bootloader 或者把大应用塞进小 Flash 时，这两个选项非常有用，但千万别在电机驱动这类对实时性要求极高的代码里用 -Oz，否则性能可能断崖式下跌。

2.3 各等级对体积、速度、调试体验的影响

下面这个表是我根据自己的多个 STM32、GD32 工程实测下来的大概结论，可以用作选型参考：

注意，体积和速度不是绝对的。循环展开这类优化可能同时增加体积和加快速度；而让编译器把多次重复的子表达式合并，则可能体积速度双赢。最终还是要看代码本身。这个表的作用是帮你形成预期，而不是当作精确公式去套。

3. 优化背后编译器到底做了什么

3.1 死代码消除：你写的代码可能根本不产生指令

死代码消除是优化等级提高后第一个“暗算”你的手段，也是软件延时被优化成零的根本原因。编译器会分析变量的赋值和引用关系，如果一个值被计算出来之后没有任何外部接口消费它，这个计算就是“死”的，会被直接剔除。

典型的例子：

void delay_loop(uint32_t count) { while (count--) { } }

在 -O0 下，这个循环会老老实实地生成比较、自减、跳转指令，消耗几万个时钟周期。但在 -O2 下，编译器发现 count 是一个局部变量，循环体是空的，循环结束后 count 的值没有写入任何内存、没有传递给任何外部代码，于是整个循环被认为是无副作用的，直接删除。如果这个函数是被内联调用的，那连函数调用本身都可能消失，延时效果归零。

这种问题在程序里特别隐蔽，因为延时函数在另一个文件里，主逻辑代码看不出异常，只能从外设波形上发现时间不对。解决思路不是和编译器较劲，而是让延时函数具有“编译器无法删除的副作用”。最笨但有效的方法是：

volatile uint32_t delay_cnt; void delay_loop(uint32_t count) { delay_cnt = count; while (delay_cnt--) { } }

因为delay_cnt是 volatile 变量，编译器必须保留对它的每次读写，循环就无法被优化删除了。更好一点的做法是使用 ARM 内核的 DWT 循环计数器做精确延时，或者直接用__NOP()插入不可删除的空操作指令。总之，目的不是关掉优化，而是给编译器一个“这里有外部可见副作用”的信号。

3.2 指令重排与函数内联如何影响时序

优化等级提高后，编译器会把原本按源码顺序生成的指令重新排布。这么做通常是为了让处理器的流水线更流畅、让寄存器利用率更高，也可能是为了合并相邻内存访问。在纯 CPU 计算场景，指令重排完全合理；但在和外设寄存器打交道的场景，顺序往往就是生命线。

举个例子，操作 Flash 控制器时，通常需要先往某个寄存器写入命令，再等待状态寄存器位置位，最后解锁下一步操作。如果编译器在优化时认为这两次写入互不依赖，而且目标寄存器不是 volatile 类型，它可能会把后面的操作提到前面，或者把两次写合并成一次更宽的写操作。放在应用层看就是“程序逻辑明明没错，但硬件就是不按预期跑”。

函数内联同样会改变可观察行为。一个函数被内联后，局部变量的生命周期、栈帧的使用都会被重写，原本每次调用都有一份独立栈空间的代码，现在可能直接展开到调用者的栈上。如果这个函数内部有和中断处理共享的变量，又没有正确加 volatile，内联后编译器可能对整个展开区域做更激进的寄存器分配，进一步增加问题出现的概率。

所以，高优化等级下，不要把“源代码顺序”当作“执行顺序”。真正确保顺序的方式是使用 volatile 限定硬件寄存器，以及在必要时插入编译器屏障和内存屏障指令。CMSIS 里提供的__DMB()、__DSB()、__ISB()就是干这个的。

3.3 volatile 在不同优化等级下的真实表现

关于 volatile，很多人的理解停留在“加了 volatile 就能防止优化”。这个说法只对了一半。volatile 告诉编译器，每次访问该变量都必须真正从内存地址读取或写入，不能把它缓存在寄存器里。这是它可以防优化的核心机制，但它并没有规定多个 volatile 访问之间的顺序，也没有提供多线程或多核环境下的原子性保证。

一个很常见的中断标志位场景如下：

uint8_t g_flag = 0; void EXTI_IRQHandler(void) { g_flag = 1; } int main(void) { while (g_flag == 0) { // 等待中断置位 } }

在 -O0 下，每次循环都会重新从内存读取 g_flag，所以中断来了以后程序能正常跳出去。但在 -O2 下，编译器认为 g_flag 在循环体内没有发生变化，会把这个值加载到寄存器里，然后判断一次就进入无限循环，之后即使中断把内存里的 g_flag 改成 1，循环里检查的寄存器值还是 0。

解决办法是把声明改成：

volatile uint8_t g_flag = 0;

这样一个字的改动，在 -O0 下几乎看不到行为差异，但在 -O2 下就是天壤之别。很多人踩坑之后把 volatile 当成“消除所有优化问题的灵丹妙药”，结果遇到结构体指针场景就继续踩坑。比如用一个结构体指针指向某个状态字，只是把指针本身声明成 volatile，指向的结构体成员依然是普通内存访问，正确的写法是把指针指向的类型声明成 volatile，也就是volatile status_t *g_status;。这些细节如果不理解，单靠试错很容易被编译器折腾到怀疑人生。

4. 三个优化等级引发的“灵异 bug”复盘

4.1 软件延时被优化成零，电机疯狂抽搐

回到开头的电机项目，最终定位到的代码是这样一个自写延时函数：

void delay_us(uint32_t us) { uint32_t i; for (i = 0; i < us * 8; i++) { } }

因为空循环没有任何外部作用，-O2 下被完全删除。PWM 的换相逻辑里用这个延时等待电流衰减，延时消失后换相瞬间电流冲击过大，波形混乱。修复方案是改成基于 SysTick 或者 DWT 的硬延时，并确保判断状态寄存器时使用volatile修饰。从这以后我给自己定了一条规矩：凡是和外部物理时间有关的延时，一律不用空循环实现。空循环延时只能用在一个地方，就是“临时在调试器里停一下看逻辑”，绝不能进入量产固件。

4.2 中断标志位在 O2 下读不到

另一个项目是做电源管理，有一个按键中断把标志位置 1，主循环检测到标志后执行软关机。代码在 O1 下跑了一年都没问题，后来为了把新的显示功能塞进 Flash，把优化等级切到 Os，结果按键完全失灵。

排查过程的转折点是单步执行主循环，发现flag变量在 Watch 窗口里显示内存值已经变成 1，但程序就是不走分支。这就是典型的寄存器缓存问题：编译器在 -O2 或 -Os 下把标志位读进寄存器，循环内不再回读内存。把全局标志位声明改成volatile uint8_t之后，问题立刻消失。

这个案例给我的教训是，任何被中断修改、同时被主循环读取的全局变量，必须加 volatile；反过来，主循环写、中断读的变量也一样。这不是可选项，而是硬性要求。类似地，被 RTOS 多个任务共享的变量，光加 volatile 还不够，还需要用临界区或者互斥锁保护，因为 volatile 不解决读-改-写的原子性问题。

4.3 未对齐访问在优化后被放大为 HardFault

还有一个典型案例发生在串口协议解析模块。为了提取帧里某个 32 位数据，代码里很常见这种写法：

uint32_t value = *(uint32_t *)&buffer[3];

在 -O0 下，编译器通常会把这条语句拆成多个单字节加载指令，然后再拼成 32 位数值，因为低优化等级下它倾向于保守、逐字节处理。到了 -O2，编译器会假设&buffer[3]这个地址是 4 字节对齐的，于是直接生成一条LDR指令去读一个 32 位字。

问题在于，如果当前 Cortex-M0 或者某些要求对齐的 Cortex-M3 配置下执行未对齐的LDR，就会触发 HardFault。而 buffer[3] 从定义上往往就是奇数偏移，根本不可能对齐。我在一个 GD32F103 项目里就是遇到这个现象：O0 正常，O2 直接进硬件错误中断。

这类问题的正确做法是消除指针强转带来的对齐假设。要么用memcpy：

uint32_t value; memcpy(&value, &buffer[3], sizeof(value));

要么逐字节拼装。优化等级提高后，这类不规范代码的问题会被放大，所以我通常在代码评审阶段就禁用对 buffer 偏移地址的直接强转访问。如果遇到历史代码已经这么写，最稳妥的办法就是把那个解析文件单独设置为 O0，而不是和全工程的 O2 混在一起处理，否则后面还可能继续在其他函数上爆雷。

4.4 遇到疑似优化 bug 时的固定排查链路

现在碰到程序在 Release 下表现异常，我不会先去怀疑编译器，而是按固定套路排查。这套流程能覆盖大多数优化引发的“灵异问题”：

1. 先确认是不是优化等级差异导致的：把 Release 配置临时改成 O0，复现一次。如果恢复正常，基本就是优化行为引发。
2. 切到反汇编视角：在 Keil 的 Disassembly 窗口里定位到出问题的函数，看生成的关键汇编指令，特别是是否有挥发性变量的回读、循环体是否被删除、函数是否被内联。
3. 全局搜索可疑变量：检查被中断和主循环共享的变量，以及和外设寄存器交互的变量，有没有加 volatile；再看结构体指针的 volatile 限定层级对不对。
4. 检查指针强转：凡是*(uint32_t *)这种强制转换，都去确认源地址是否可能未对齐，以及是否违反严格别名规则。
5. 把嫌疑函数单独降级验证：在 Keil 里右键源文件 -> Options for File，把优化等级改成 O0，重新编译烧录。如果问题消失，问题大概率就在该文件的编程方式上。
6. 记录结论：把最终原因和修复方式留在工程维护文档里，方便后续其他同事借鉴。

这套链路不一定每次都能一击命中，但至少能避免把时间浪费在“编译器为什么这么笨”的情绪内耗上。

5. 精准控制优化：不要只会全局切换

5.1 单文件独立优化：Keil 工程里最实用的玩法

全局优化等级只有一套，不可能照顾到每个文件的特殊需求。Keil MDK 提供了一个非常实用但很多人忽略的功能：对单个 C 文件单独设置优化等级。操作方法是，在 Project 窗口中右键某个.c文件，选择Options for File，然后在C/C++标签页里就能覆盖全局优化设置。

这个能力特别适合处理以下场景：

• 延时、Flash 擦写、外设时序初始化这些时间敏感代码所在的文件，全局用 O2，这个文件用 O0。
• 某个从老代码里迁移过来的驱动文件，长期没完全看懂，不敢乱动，先让它保持 O0 运行。
• 第三方协议栈或中间件文件，用厂商推荐的优化等级，避免和自家优化策略冲突。

我实际项目里最常见的配置是，全局 Release 用 O2，delay.c、flash_if.c、lowpower.c这三个文件单独设为 O0。这样既保证整体性能，又把最容易出问题的局部逻辑保护起来。比全局关优化高明得多。全局切回 O0 意味着放弃所有优化，对一颗主频只有几十兆的 MCU 来说，代价有时候是毁灭性的。

5.2 函数级关闭优化：optnone 与文件拆分

如果连整个文件都关优化都觉得代价太大，还可以往下细化到函数级。ARM Compiler 6 环境下的 armclang 支持__attribute__((optnone))，可以直接让某个函数不做优化。

__attribute__((optnone)) void critical_section_delay(void) { // 这里面的代码不会被优化 }

用起来很简单，但需要注意，这个属性并不是 C 标准规定的，是编译器扩展。AC5 环境下的支持情况和 AC6 并不完全一致，我在 AC5 里很少依赖这种函数级属性，因为行为不够稳定，踩过一次坑之后就不再信任了。

最稳妥且跨编译器通用的函数级优化控制方案，其实还是拆分文件。把需要特殊对待的函数单独放到一个新的.c文件里，然后对该文件设置 O0。接口用头文件暴露，从外部看只是一个普通函数，只是实现被保护起来了。这个做法虽然多了一个文件，但完全不需要担心编译器版本差异，也方便以后代码评审。

5.3 硬件访问的正确姿势：类型限定与编译器屏障

很多优化问题的根源不是“编译器太激进”，而是“代码没告诉编译器这些东西不能被乱动”。对于硬件寄存器，CMSIS 已经用宏定义好了正确的类型修饰，比如__IO的本质就是volatile。我们希望所有外设寄存器的访问都经过 volatile，这样每次读写都会落到真实地址，不会被缓存在寄存器副本里。

但这还不够。优化等级高的时候，编译器可能会在多个 volatile 访问之间做有限的指令调度，因为 volatile 只保证“不能被删除”，不保证“顺序完全一致”的语义在实际执行中一定严谨。所以做关键硬件时序时，除了 volatile，还要在必要位置插入内存屏障。

ARM Cortex-M 内核提供了三条屏障指令：

• __DMB()：数据内存屏障，确保屏障前后数据访问的可见性。
• __DSB()：数据同步屏障，等待屏障之前的所有访问完成。
• __ISB()：指令同步屏障，用于清空流水线和预取缓冲区。

在写 Flash、配置 DMA、切换时钟源、进入低功耗模式这些场景，我会在寄存器操作前后加上合适的屏障，避免编译器优化或者 CPU 乱序执行带来的意外。Volatile 是必要条件，屏障是充分条件，两者结合才算把底层语义表达清楚。

5.4 发布前建议的优化组合与验证策略

最后聊一下发布前的优化组合策略。我现在的默认工程模板是这样配置的：

• Debug 构建：全局 O0，包含完整调试信息。
• Release 构建：全局 O2，delay.c、flash_if.c、lowpower.c单独设为 O0。
• 如果 Flash 剩余空间不足 10%，我会先确认性能瓶颈，再决定是否把全局改为 Os；如果只是个别函数占用空间，优先用单文件 O0 隔离，而不是把所有代码都拖到 Os 档位。

验证策略上，最忌讳的是“O0 下测完就算测完”。发布固件是什么优化等级，就必须在什么优化等级下做全量回归。O0 和 O2 生成的是两个行为差异巨大的二进制程序，一个在 O0 下完美运行的系统，在 O2 下可能完全跑不起来。我的习惯是，发版前至少留出一天时间，用最终优化配置跑完整测试，包括低电压、高温、长时间老化这些边角场景，尽管听起来很繁琐，但比起客户现场出问题再派人出差处理，这点时间成本非常划算。

6. 一些个人经验和最后建议

6.1 我到目前的默认选择

做了这么多年嵌入式，我的默认选择越来越保守：普通 MCU 应用如果没有特殊需求，Release 优先用 O2，而不是追求极致 O3。O3 带来的性能提升在 100 MHz 级别的单片机上往往不明显，但代码体积膨胀和调试难度上升却很实在。Flash 不够用的时候，我会先排查代码里有没有重复包含的大模块、冗余库函数、日志字符串，而不是直接切到 Os。只有当所有常规优化手段都用尽，我才会考虑 -Os 甚至 -Oz，而且切换后必定做一次完整的性能评估，确认关键中断响应时间和循环周期没有穿底。

6.2 编译列表文件教我的事

分享一个真正帮助我理解优化等级的小技巧：在 Keil 的Options for Target -> Listing标签页里，把 Assembly Listing 输出打开。编译之后，在Listings文件夹里找到对应的.lst文件，查看某个函数生成的汇编指令。尝试用同一个工程分别编译 O0 和 O2，把两个版本的函数汇编对比着看，你会直观地看到空循环是如何被删掉的、分支是如何被改写的、函数是如何被内联的。

我第一次做这个对比时，看到自己写的一个 20 行的解析函数在 O2 下只剩下 6 条指令，那种冲击感比看一百篇理论文章都强。从那以后，每次遇到优化相关疑难杂症，我都会打开反汇编对照源码，效率和直接盲猜完全不是一个级别。

6.3 给新手和老手各自的一句话

对刚开始接触 Keil MDK 的开发者，我的建议是不要从一开始就在高优化等级下调代码，先用 O0 把功能跑通，同时带着 volatile、屏障、对齐这些概念去写代码，等理解到位了再开优化，否则 bug 和优化行为混在一起，排查难度会成倍上升。

对有经验的工程师，我想说少一点对编译器的“敌意”，多一点对 C 语言底层语义的敏感。绝大多数优化导致的异常，都是代码表达不够精确的结果。编译器只是按照规则办事，它给出的优化结果其实就是一面镜子，照出平时没注意到的隐患。接受这面镜子，并学会驾驭它，比任何“万能关闭优化”的技巧都来得扎实。

最后再分享一个小经验：每次调整优化等级后，记得打开 map 文件看一眼栈使用量，特别是项目里用了 RTOS 时。优化会改变栈深度，有时是减少，有时反而因为内联扩出更大的临时变量区域。Keil 的 map 文件里有栈使用信息的参考，配合调试器观察任务栈剩余量，能避免很多发布后才会出现的栈溢出问题。优化等级这个选项虽小，但它牵一发而动全身，理解了它，你的固件才算真正从“能跑”走向“敢量产”。