IAR做ARM开发时，很多人一开始只盯着能不能编过，等到后面出现库不兼容、浮点不对、标准库功能缺口，才发现前面的编译器和运行时其实没选顺。这个问题不好靠补丁式排查解决，更稳的办法是从项目建立那一步就把目标内核、执行模式、语言标准、库配置和底层接口一起对齐。IAR官方文档也把这个逻辑写得很明确，处理顺序不是先挑一个“能编译”的组合，而是先按目标核和工程能力边界去定编译器选项，再让库和运行时跟着这些选项自动匹配。
一、IAR ARM编译器怎么选
编译器怎么选，核心不是看哪个名字更新，而是看你的工程到底跑在什么核上、打算用什么语言特性、后面要不要和旧工程或旧库并存。这个顺序理顺后，很多兼容性问题在建工程时就能避开。
1、先按目标核选【Processor variant】
IAR明确说明，编译器生成的目标代码在不同Arm核之间并不总是二进制兼容，所以处理器选项必须明确指定，不能长期吃默认值。对32位工程，文档里写到默认核是Cortex-M3；对64位工程，则要明确选择支持的Armv8-A核，并配套设置执行模式。真到项目里，这一步不是“有空再调”，而是第一优先级。
2、32位和64位工程不要混着想
IAR的Arm工具链同时覆盖32位和64位模式。32位工程重点是核型号、Thumb或Arm指令模式、FPU和字节序；64位工程除了核型号，还要定数据模型是ILP32还是LP64。要是你项目已经走到AArch64，却还沿着旧32位习惯去配库和对象文件，后面出问题基本是迟早的事。
3、语言标准按项目年龄选，不要只图新
当前文档里，IAR C默认按C18走，也兼容C11，需要旧式C89时可以显式切到C89。C++这一边，编译器接受C++17源码，而且把C++17当成Standard C++的主线；但这不等于你的库也自动完整支持C++17，所以“编译器支持”和“库支持”要分开看。新项目可以直接按当前标准走，老项目尤其是历史包袱多的项目，先看语言标准迁移成本，再决定开到哪一档，会更稳。
4、浮点选项要跟目标核能力一致
如果目标核带VFP，IAR允许你通过FPU选项让浮点运算走协处理器，而不是走软件浮点库。这里最怕的是项目文件里开了硬浮点，但拿进来的库还是按软件浮点编的，或者反过来。IAR在发布说明里专门提到，把`--cpu`和`--fpu`传给链接器后，链接器就能检查引入的库和对象文件是不是跟目标CPU和FPU兼容，这个动作很适合放进正式构建链路里。
5、字节序别忽略
IAR文档写得很直接，所有用户模块和库模块必须使用相同的字节序。这个设置平时不算高频，但一旦项目里混入外部库、旧版库或别的平台迁来的对象文件，它就会变成很典型的隐性坑，所以建工程时最好一起确认。
二、IAR ARM库与运行时怎么匹配
库和运行时的匹配，关键不在于手工记库文件名，而在于理解IAR是按哪些维度做预编译库切分的。你只要把这些维度配对了，IDE和链接器大多数时候会帮你选对；反过来，只改一半设置，后面就容易出现功能缺口或链接不稳。
1、先在【Project】【Options】【General Options】【Library Configuration】里看清当前库
IAR的IDE会把最终实际使用的库文件和配置文件直接显示出来，不需要靠猜。官方说明里也提到，这一页不只是让你选库，还会显示实际生效的Library file和Configuration file。做项目排查时，先看这里，比先翻编译日志更快。
2、理解预编译库是按哪些条件分出来的
IAR当前文档写明，预编译运行时库是按处理器变体、数据模型和库配置来区分的，库文件名里还会带出执行模式、字节序、RWPI以及浮点实现方式这些信息。也就是说，库是否能直接拿来用，不只是看它是不是DLIB，还要看它跟你的核、模式、大小端和浮点路线是不是同一套。
3、Normal DLIB适合轻量场景，Full DLIB适合功能更全的场景
官方给的定义很清楚。Normal DLIB是默认配置，带C locale，但没有locale接口，没有文件描述符支持，也没有`printf`和`scanf`的多字节字符支持。Full DLIB则带完整locale接口、文件描述符支持，并可选多字节字符支持。简单说，纯裸机、小体积、少文件系统依赖的工程，往往先看Normal；一旦要碰文件、地区化或更完整的库功能，就要更认真地评估Full。
4、用Libc++时，不要再按DLIB的思路硬切
IAR文档明确写了，使用Libc++时会自动落到Full配置，而且Libc++只有这一种配置，不能再用`--dlib_config`去改成别的模式。官方还说明，若使用DLIB C++14库，凡是需要库支持的那部分C++17特性就不可用；换成Libc++C++17库后，C++17特性才是完整可用，除非文档另有说明。这个边界很关键，很多“编译器明明支持，为什么工程里还报库缺功能”的问题，根子就在这里。
5、只要用了标准输入输出，就要把底层接口想进去
IAR的DLIB运行时不是把所有I/O都替你落到板子上。官方说明里写到，只要项目用到标准流，比如`printf`或`scanf`，通常就要自己实现`__read`和`__write`；如果还要做文件I/O，就可能还要补`__open`一类底层函数。也就是说，库选对只是第一层，运行时能不能真的跑起来，还要看你有没有把低层接口接到目标板上。
6、文件和locale能不能用，不要只看源码里有没有调用
IAR文档指出，文件I/O只在Full配置里直接支持，或者你自定义库并定义了`__DLIB_FILE_DESCRIPTOR`时才成立。locale这一块也分层，Full配置可以在运行时切换locale，Normal配置则把C locale固化进去。所以工程里哪怕现在只写了少量输出，只要后面规划里有文件、编码、多字节字符或地区化需求，库配置最好一开始就按最终能力边界定。
三、IAR工程迁移前先看什么
真正容易出问题的，往往不是新建工程，而是老工程升级。旧对象文件、旧时间接口、旧语言模式，只要混进当前工程，表面上也许还能编，后面却容易埋下更难查的兼容性问题。
1、跨大版本时，旧对象文件别直接复用
IAR的迁移文档明确提醒，从6.x和7.x升到8.x时，凡是用旧C语言模式并且涉及非AEABI系统头的对象文件，都应该重新编译；旧的C++03、EC++、EEC++对象文件也都要重编。对项目来说，这意味着只升级IDE不重编库和历史对象文件，通常不是稳妥做法。
2、9.x之后时间接口要单独确认
IAR还专门写到，9.x里DLIB的默认时间处理从32位改成了64位。如果旧板级代码以前只实现了`__time32`，升级后未必还会被调用，默认的`__time64`反而会接管，而且链接器不一定会给出明显提示。这个变化很容易被忽略，但一旦项目里有日志、时间戳或协议时间字段，就值得单独复核。
3、把兼容性检查放到链接阶段
如果项目已经有自建库、第三方库和历史对象文件混用，单靠编译阶段盯选项很难百分百稳。IAR当前发布说明提到，把`--cpu`和`--fpu`也传给链接器后，链接器可以帮你识别进入构建的库和对象文件是否与目标CPU和FPU兼容。这个动作不复杂，但对把兼容性问题前移非常有用。
4、最后再决定要不要自定义库
IAR支持自定义DLIB，并在IDE里通过Custom DLIB指向自己的配置文件。这个能力适合那些既想控体积，又要补少量定制功能的项目；但前提是你已经把标准库需求边界摸清楚了。对多数工程来说，先把Normal、Full、Libc++这三条主路用明白，再考虑自定义，通常更省力。
总结
IAR ARM编译器怎么选，真正要看的不是“哪个能过编译”，而是目标核、执行模式、语言标准、浮点方式和字节序是不是一整套。IAR ARM库与运行时怎么匹配，也不是手工去挑一个库名，而是让处理器变体、数据模型、库配置、I/O接口和C++库路线对上同一套工程设定。把这两层先理顺，新项目会更稳，老项目升级也更不容易在链接和运行时阶段反复踩坑。
