很多团队做IAR交付时，真正麻烦的不是能不能编过，而是发布包里到底该放什么、不同配置怎么一起出、产物名字怎么区分、后面追版本时靠什么回溯。IAR本身已经给了几块很关键的能力，包括Batch Build批量构建、iarbuild.exe命令行构建、Build Actions前后处理、Output Converter输出格式转换，以及把构建信息写入日志文件的能力，所以发布包最好围绕这几项来收口，而不是每次靠人工东拼西凑。

　　一、IAR怎么生成发布包

　　IAR生成发布包，建议先把发布动作拆成配置、构建、转换、收集四步。这样做的好处是，IDE内手工发版和流水线自动发版能共用同一套口径，后面不容易乱。IAR文档说明，Batch Build可以一次构建多套配置，iarbuild.exe可以从命令行调用工程，Output Converter可以把链接后的ELF再转成适合烧录或交付的格式。

　　1、先把Release配置单独固定

　　发布不要直接拿日常调试配置出包，先把Release的优化、宏开关、链接脚本和输出目录固定下来；如果一个工程要同时出Debug和Release，或者还要出不同板型版本，可以直接放进Batch Build里统一跑，避免漏编某个配置。IAR官方对Batch Build的定义就是把多个build configurations按顺序放进一个batch里统一构建。

　　2、再把交付格式一次性出齐

　　IAR的链接器默认产出ELF，若要交付烧录文件，可以在Project里的Output Converter打开Generate additional output，再用ielftool转成Motorola S-record、Intel Extended hex、TI-TXT或Raw binary。也就是说，elf适合调试留档，hex或bin适合生产烧录，最好不要只留一种。

　　3、用Build Actions自动收集和搬运文件

　　如果发布包还要把目标文件复制到指定目录，或者在构建完成后顺手整理文件，IAR可以在Project里的Build Actions里配置前后处理动作。官方示例里既给了时间戳写入，也给了自动复制文件的做法，核心就是通过Command line、Input files、Output files和Build order把这些动作接进构建流程。

　　4、要做自动化发版时改用iarbuild.exe

　　如果团队已经在做持续集成，发布包就不要只靠IDE手点。IAR官方说明iarbuild.exe可以直接用项目文件作为输入做命令行构建，这样更适合和脚本、版本库标签、制品库上传放到同一条流水线里。基于这个能力，更稳妥的做法是把正式发布统一收口到命令行任务上。

　　二、IAR产物归档怎么规范

　　发布包生成出来以后，最怕的是目录里只有一个hex，过两周谁也说不清它从哪个工程、哪个配置、哪次提交来的。IAR自己提供了输出文件变量、Build Log落盘和多格式导出能力，所以产物归档最好围绕可追溯来定，而不是只图目录干净。

　　1、归档时至少分三类文件

　　第一类是可烧录产物，如hex、bin、srec；第二类是可分析产物，如elf和map；第三类是过程证据，如构建日志。IAR在Output Converter里支持多种promable output format，在Build Log里又支持写入日志文件，所以把这三类分开留档，后面定位问题会省很多事。

　　2、归档目录不要手写死路径

　　IAR支持一组argument variables，例如$TARGET_PATH$、$TARGET_FNAME$，也支持自定义变量。更稳妥的做法是把项目名、配置名、输出目录和归档目录都变量化，这样工程换机器、换工作区、换分支时，发包脚本不用跟着大改。

　　3、每次发版都保留一份构建日志

　　很多团队只留结果文件，不留过程证据，后面一旦出现版本争议就很被动。IAR的Build window支持Live Log to File，把构建消息写入日志文件并设置过滤级别，所以正式发布时最好把这份日志和产物一起归档。

　　4、同一版本只认一套正式发布包

　　如果一个版本既有手工补包又有临时重编包，后面最容易混。更实用的规范是，每个正式版本只保留一个主归档目录，里面再按配置拆分文件，历史版本只增不改；若必须重发，就提升版本号或补丁号，不要覆盖原包。这个规范是基于IAR的批量构建、日志留档和变量化输出能力做出的工程化建议。

　　三、IAR版本标记怎么规范

　　版本标记这件事，不能只停在文件名上。更稳妥的做法，是让版本信息同时出现在二进制内部、发布文件名和归档记录里，这样现场拿到固件、研发拿到工程、测试拿到日志时，三边看到的是同一个版本口径。IAR文档里已经给了时间戳写入和预处理宏支持，这正好可以拿来做版本落地。

　　1、文件名里至少带版本号和配置名

　　发布文件不要只叫app.hex，至少应带产品名、版本号、配置名和日期批次。IAR虽然不替你定义命名规则，但它提供了$TARGET_FNAME$、$TARGET_PATH$这类变量和Build Actions，所以把统一命名规则接进后处理是可行的。

　　2、二进制内部写入构建时间

　　IAR官方示例明确给出，可以用**DATE**和**TIME**初始化字符串，再通过Build Actions触发相关文件重编，把时间戳嵌进最终binary。这样做的价值很直接，哪怕脱离文件名，程序本体里也能读到构建时间。

　　3、同时写入编译器版本信息

　　除了时间，还建议把工具链版本一起写进版本字符串。IAR文档说明**VER**可以返回IAR编译器版本号，**BUILD_NUMBER**还能标识当前编译器的build number。对长期维护项目来说，这两项在排查同源码不同编译结果时很有用。

　　4、版本号来源要统一

　　最怕的是源码里一套版本号，文件名又是一套。更稳妥的做法是把版本号集中放在单一头文件或单一构建变量里，再让文件命名、版本字符串和归档目录共同引用这一份源头。IAR支持自定义参数变量和命令行构建，所以这套统一口径既能在IDE里跑，也能迁到流水线。

　　总结

　　IAR怎么生成发布包，关键不是编完就手工拷文件，而是先固定Release配置，再用Batch Build或iarbuild.exe做统一构建，用Output Converter补齐hex或bin，用Build Actions自动搬运和整理文件。IAR产物归档与版本标记怎么规范，重点也不是目录摆得整齐，而是让烧录文件、调试文件、构建日志和版本信息形成同一条追溯链。这样做完之后，发布包不只是能交付，更能在后面定位问题、复现构建和核对版本时站得住。