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在调试文档里也明确提醒，高优化会让源代码与生成代码的对应关系变弱，变量值与单步体验会变得不可靠。