做嵌入式项目时，很多人一开始会把注意力放在能不能编过、能不能下载，等到代码越来越多，才发现优化等级选得不对，会直接影响后面的定位效率。IAR在官方文档里把优化等级分成None、Low、Medium和High，High下面又分Balanced、Size、Speed和No size constraints，同时还明确说明None的调试支持最好；另一份C-SPY调试文档也提醒，高优化会让源码和最终指令的对应关系变得没那么直观，变量值有时还会显示成Unavailable。也就是说，优化等级不是越高越好，而是要和当前阶段的工作目标对上。

　　一、IAR编译优化怎么选

　　IAR编译优化怎么选，真正好用的思路不是只盯着速度，而是先把当前工作分成调试、联调、验证和发布几个阶段。阶段不同，最合适的优化档位通常也不一样，直接一把拉到High，后面大概率会在调试上把时间再补回来。

　　1、先把调试配置和发布配置分开

　　在IAR里，官方本身就是按debug project和release project两条线来设计默认行为的。文档写得很清楚，debug project默认会使用fully debuggable的size optimization，release project默认则会使用high balanced optimization。这说明从工程组织上就不该把调试和发布混成一个配置，最稳妥的做法是从项目一开始就保留两套构建配置。

　　2、需要频繁单步和看变量时优先选None

　　如果当前工作主要是看初始化流程、查寄存器配置、盯局部变量变化，优先把【Project】→【Options】→【C C++Compiler】里的优化等级放在None会更省事。官方一边把None写成provides best debug support，另一边又明确建议，如果调试时需要完整看到变量值，就应使用最低优化等级，也就是None。

　　3、功能基本跑顺后再从Low或Medium往上试

　　当项目已经过了最早期的点灯和接口打通阶段，问题更多集中在流程配合和逻辑边界时，就没必要一直死守None。官方把Low和Medium定义为较低和中等级优化，这两档更适合作为过渡层，先让代码生成更接近真实运行状态，同时又不给调试带来太重负担。实际落地时，通常比直接跳到High更稳。

　　4、发布前再按目标在High里细分

　　如果当前目标是正式交付，就该进入High这一层再做选择。IAR官方给出的High子选项分别是Balanced、Size、Speed和No size constraints，其中Balanced偏均衡，Size偏代码体积，Speed偏执行速度，No size constraints则进一步放宽代码膨胀限制，专门追求速度。也就是说，发布优化不是只有一个High，而是要根据Flash压力、实时性要求和容量余量来定。

　　5、早期别急着把额外变换全打开

　　在优化等级之外，IAR还允许单独控制一些transformation。官方说明里提到，这些transformation在debug project里默认是关闭的，在release project里默认是开启的。这个默认策略其实已经给了很明确的信号，前期调试阶段先保守一些，等功能稳定后再把这部分能力放开，会比一开始就全开更容易控场。

　　二、IAR优化等级对调试有什么影响

　　IAR优化等级对调试有什么影响，最核心的不是一句调试变难，而是难在三个具体地方，分别是源码和指令的对应关系、变量可见性，以及单步时你看到的停靠位置。只要把这三点看明白，后面就不会再把很多现象误判成工具坏了。

　　1、源码和最终执行路径会变得没那么直观

　　C-SPY调试文档明确写到，优化会影响代码形态，让生成代码和源码之间的关系不再那么清楚。换句话说，同样一段C或C++代码，在高优化下可能已经被重排、合并或者挪动过，调试时看到的执行顺序就不一定还和编辑器里的书写顺序一一对应。

　　2、变量值可能暂时看不到

　　这是很多人最容易困惑的一点。官方给出的例子说明，某个局部变量从声明到真正被使用之前，编译器未必会一直给它留出栈或寄存器空间，因此C-SPY在某些时刻无法显示它的值，并会直接显示Unavailable。也就是说，变量不是一定算错了，而是此刻在优化后的机器代码里还没有一个稳定可读的位置。

　　3、越高的优化越不适合细抠逐句过程

　　文档里同时提到，变量值在step points上最可靠，也就是语句起始点和函数调用这类位置。结合高优化时源码映射变弱这一点，实际调试时就会出现一种常见感受，就是单步还能走，但对每一行中间状态的观察价值明显下降。所以高优化更适合验证结果，不太适合细抠过程。

　　4、观察方式要从盯每一行改成盯关键点

　　当项目已经用了较高优化等级，再继续用最早期那种一行一行盯变量的方式，效率通常不会太高。更实用的做法，是把注意力放在函数入口、分支出口、接口调用前后和关键状态更新点，这样更贴合C-SPY官方所说的step points视角，也更符合高优化后的真实代码组织方式。

　　5、真要完整追变量就回到None

　　这一点官方说得非常直接，如果在调试阶段需要full information about values of variables，就应当使用最低优化等级None。这个建议其实很实用，因为很多排查卡很久，不是代码太复杂，而是当前构建配置本来就不适合做精细变量观察。

　　三、IAR项目阶段该怎样切换优化等级

　　真正落地时，最怕的不是不会选，而是整个项目只用一档优化从头跑到尾。IAR项目阶段该怎样切换优化等级，关键在于把每一档都放在最适合它的阶段上，这样既不会把调试拖慢，也不会让发布结果失真。

　　1、驱动初通阶段先用None

　　这个阶段最常见的工作是看时钟、外设初始化、中断进入和基础通信链路，问题通常都比较底层。此时直接用None，再保留默认的debug information，会比追求编译后代码更小更快更有价值，因为你真正需要的是可观察性。

　　2、模块联调阶段再试Low或Medium

　　等到基本流程跑顺以后，可以单独复制一份配置，把优化往上提到Low或Medium，用来观察逻辑在轻度优化下是否仍然稳定。这一步的价值，不只是提速，更是在不一下子失去太多可调试性的前提下，让运行状态逐步贴近后期版本。

　　3、性能和容量验证阶段切到High做对比

　　当项目开始关注中断响应、循环效率、代码体积和最终资源占用时，就该把High里的Balanced、Size、Speed分开试一轮，而不是默认一路用同一个档。这样做能更早看出项目究竟是卡在容量，还是卡在速度，也方便后面给发布配置定型。

　　4、发布问题复现时保留一份高优化镜像配置

　　有些问题只会在发布档位出现，这时最怕为了方便调试直接把所有优化全关掉，结果问题也一起消失。更稳妥的做法，是保留一份接近release的高优化配置用于复现，同时再保留一份None配置用于根因定位，两边对照看，效率通常比只守着单一配置更高。这个做法是基于IAR官方对debug project和release project默认分工的延伸使用，实操里很常见。

　　总结

　　IAR编译优化怎么选，IAR优化等级对调试有什么影响，归根到底不是一个纯性能问题，而是一个工程阶段匹配问题。需要看过程、看变量、看每一步状态时，就把优化降下来；需要看真实体积和真实速度时，再把优化提上去。顺着这个节奏去切配置，IAR的优化等级就不再只是一个编译选项，而会变成帮助项目提效的控制杆。