IAR里体感上的“编译慢”，很多时候并不全是编译器本身慢，而是把源码索引、浏览信息更新、无效重建和全量重编都叠在了一起。IAR官方文档把这几层分得很清楚：日常的【Make】本来就是只编译自上次构建后发生变化的文件，而Source Browser又有自己单独的生成、更新和缓存目录；再加上并行构建、构建文件目录和配置隔离，速度差别会非常明显。

很多人刚把IAR和ARM工程接起来时，最容易卡住的不是编译器本身，而是CMSIS、软件包和头文件路径这三件事没有串到一起。表面上看，问题像是找不到`core_cm4.h`、设备头文件不识别，或者换了芯片以后包依赖一片发红；实际上在IAR里，这几步是有固定入口的。IAR当前文档说明，传统CMSIS-Pack工程可以通过【Project】里的【CMSIS-Manager】安装Pack并选择组件，新建工程时还可以直接选择【Empty CMSISPack project】；如果走的是CMake或CMSIS-Toolbox路线，则又有单独的Pack root和自动下载缺包选项。

做STM8工程时，最让人头疼的不是代码本身，而是项目明明能打开，一编译却连续报错。有时是找不到头文件，有时是链接阶段缺库，还有一种更常见，就是项目从别人电脑拷过来以后，路径设置全都还在，但本机就是编不过。IAR针对STM8的工具链本身把标准头文件和预编译库分得很清楚，头文件主要在stm8inc，预编译库和对应的库配置文件主要在stm8lib；再加上IDE里编译器和链接器的路径入口本来就不是同一个位置，所以这类问题不能只看报错字面，得顺着编译阶段和链接阶段分别往下查。

IAR做ARM开发时，很多人一开始只盯着能不能编过，等到后面出现库不兼容、浮点不对、标准库功能缺口，才发现前面的编译器和运行时其实没选顺。这个问题不好靠补丁式排查解决，更稳的办法是从项目建立那一步就把目标内核、执行模式、语言标准、库配置和底层接口一起对齐。IAR官方文档也把这个逻辑写得很明确，处理顺序不是先挑一个“能编译”的组合，而是先按目标核和工程能力边界去定编译器选项，再让库和运行时跟着这些选项自动匹配。

很多人刚上手IAR时，容易把建工程这件事想得很简单，点几个按钮能编过去就算完了。可真到项目往里加文件、分Debug和Release、多人协作、后面再接手维护时，问题就慢慢出来了，目录放得乱，组名随手起，模板也没有统一口径，最后工程能跑，但没人愿意接。IAR官方文档其实把基础路径讲得很清楚，工作区、项目、组、文件、配置是分层管理的，默认还会生成Debug、Release以及List、Obj、Exe这些输出目录，所以一开始把骨架搭顺，比后面反复挪工程省事得多。

在IAR里新建工程或导入工程后，最常见的卡点之一就是【Device】下拉框里找不到目标芯片，导致链接脚本、启动文件、调试配置都无法按器件生成。这个问题通常不是工程坏了，而是设备支持包没有安装到位，或工程依赖的CMSIS器件包没有落到本机Pack仓库。下面按先定位缺什么、再把Pack装进去、最后验证生效的顺序，把整套流程一次做完整。

map文件本质上是链接器把最终可执行镜像如何落到各个内存区域的账本，想看内存占用，核心不是盯着某一个段名，而是把map里的汇总数字、内存区域与段放置三件事对齐。IAR里只要在链接器的List选项启用Generate linker map file，构建后就会在输出目录生成对应的map文件，后续所有定位都围绕它展开。

断点打上了却一直不停，表面看像是调试器失灵，实际上更常见的原因是编译器优化让源代码与最终指令不再一一对应，或调试信息与当前下载到目标机的镜像不一致。IAR在调试文档里也明确提醒，高优化会让源代码与生成代码的对应关系变弱，变量值与单步体验会变得不可靠。