企业官网建设流程全解析

嵌入式开发这行干久了，你会发现一个很有意思的现象：很多人对IDE的忠诚度堪比信仰。有人死守IAR不放，觉得它编译出来的代码就是比别的工具链小一圈；也有人一头扎进VSCode的怀抱，再也不想回到那个上世纪画风的编辑器里。我两边都深度用过，最后的结论可能有点反直觉——这俩根本没必要二选一，把它们拼起来用，才是目前Windows平台上最舒服的嵌入式开发姿势。

这套组合的核心思路很简单：IAR负责它最擅长的事——编译、链接、生成针对特定芯片优化的机器码，以及配合硬件仿真器做底层调试；VSCode负责它最擅长的事——代码编辑、智能补全、版本管理、终端操作、插件生态。两者通过合理的工程配置和任务编排串联起来，你得到的是一个既有IAR编译质量保障、又有现代编辑器体验的开发环境。这篇文章我会把整套配置流程拆开揉碎讲清楚，包括IAR工程怎么建、VSCode怎么接、调试怎么打通、常见坑怎么绕，适合刚入行的嵌入式新人，也适合想从Keil或纯IAR环境迁移出来的老手。

1. 为什么要把VSCode和IAR拼在一起用

1.1 单独用IAR的痛点在哪

IAR Embedded Workbench在嵌入式圈子的地位不用我多说，尤其是做8051、STM8、瑞萨、部分ARM Cortex-M芯片的时候，IAR的编译器优化能力确实是第一梯队的。同样一段C代码，IAR编译出来的二进制文件往往比GCC小百分之十到二十，这在Flash只有几十KB的单片机项目里就是生与死的差别。

但IAR的编辑器体验，说实话，这些年进步有限。代码补全基本靠猜，跳转定义偶尔失灵，多文件搜索慢得让人想砸键盘，Git集成几乎等于没有。你如果想在IAR里用上类似VSCode那种丝滑的代码导航、括号着色、参数提示、实时语法检查，基本不可能。更别提VSCode那边海量的插件生态了，从代码格式化到AI辅助编程，从串口监视到Markdown预览，IAR原生环境完全给不了。

我自己的日常是这样的：写代码的时候在VSCode里，编译和下载的时候切到IAR，调试的时候看情况——简单问题用IAR自带的C-SPY调试器，复杂逻辑分析用VSCode配合插件看变量和调用栈。这种来回切换一开始确实别扭，但配置好之后，实际上大部分时间你只需要在VSCode里按一个快捷键，编译结果和错误信息就自动出来了，根本不用手动切窗口。

1.2 VSCode单独用的局限

反过来，纯VSCode加GCC工具链的方案，在开源社区和Linux嵌入式开发里很流行，但放到Windows下的闭源芯片开发场景里就有点力不从心。首先是编译器问题，很多芯片厂商只提供IAR和Keil的器件支持包，GCC那边要么没有，要么是社区维护的版本，稳定性和优化程度都差一截。其次是调试器支持，IAR的C-SPY对自家仿真器和主流硬件调试探针的支持是最完整的，VSCode的Cortex-Debug插件虽然也能用，但配置起来麻烦，而且对某些老芯片的支持并不好。

还有一个很现实的问题：很多公司的既有项目就是IAR工程，你不可能为了用VSCode就把整个项目迁移到Makefile或CMake。这时候最务实的做法就是保留IAR工程结构，让VSCode去适配它，而不是反过来。

1.3 双剑合璧的核心逻辑

这套方案的本质是职责分离。IAR作为编译和调试后端，VSCode作为编辑和操作前端，两者通过命令行接口和文件系统进行通信。具体来说，IAR提供了命令行编译工具IarBuild.exe，你可以用它在不打开IDE的情况下编译整个工程；VSCode的Tasks系统可以调用这个命令行工具，把编译输出捕获到终端面板里；调试方面，IAR生成的.out文件可以被VSCode的调试插件读取，配合launch.json配置就能实现源码级调试。

这种架构的好处是解耦。你不需要修改IAR工程的任何原有配置，不需要迁移代码，不需要重新验证编译结果。VSCode只是在外面套了一层更舒服的壳，底层还是你熟悉的那个IAR。哪天不想用VSCode了，直接打开IAR，一切照旧。

2. 环境搭建：从零开始配置这套组合

2.1 IAR的安装与工程创建

先说IAR这边。安装过程没什么好讲的，官网下载安装包，一路下一步就行。需要注意的是版本选择，如果你做的是8051或者STM8这类8位机，要用对应的IAR版本，比如IAR for 8051；如果是ARM Cortex-M，就用IAR for ARM。不同版本的工程文件格式不通用，装错了打不开别人的工程。

安装完成后，建议把IAR的命令行工具路径加到系统环境变量里。默认路径一般是C:\Program Files\IAR Systems\Embedded Workbench x.x\common\bin，把这个路径加到Path里，后面VSCode调用IarBuild.exe的时候就不用写全路径了。

新建工程的标准流程是：File → New → Workspace，然后Project → Create New Project，选择芯片型号和工程模板。这里有个细节，工程模板建议选"Empty project"而不是带main函数的模板，因为模板里往往包含一些你不需要的启动文件和库，后期清理起来麻烦。建好工程后，在Project → Options里配置芯片型号、时钟频率、优化等级、输出格式这些关键参数。

注意：IAR的工程文件是.ewp，工作空间文件是.eww。一个工作空间可以包含多个工程，做多模块项目的时候很有用。VSCode那边配置的时候要指向.ewp文件，不是.eww。

2.2 VSCode的安装与必备插件

VSCode官网下载Windows版本，安装时记得勾选"添加到PATH"和"将'通过Code打开'操作添加到资源管理器目录上下文菜单"，这两个选项能省很多事。

插件方面，核心的就这么几个：

• C/C++（微软官方）：提供代码补全、跳转、错误检查，是VSCode写C代码的基础。
• IAR Build：社区维护的插件，可以直接在VSCode里调用IAR的编译命令，省去手动配置Tasks的麻烦。
• Cortex-Debug：如果你用的是ARM Cortex-M芯片，这个插件配合J-Link或ST-Link可以实现源码级调试。
• Serial Monitor：串口监视器，调试的时候看打印信息很方便。
• GitLens：代码版本管理增强，看每一行是谁什么时候改的。

其他像Better C++ Syntax、Include Autocomplete、Error Lens这些辅助插件，看个人喜好装就行。不建议装太多，VSCode插件装多了启动会变慢，而且有些插件之间会冲突。

2.3 工作区配置文件的组织方式

VSCode的工作区配置放在.vscode文件夹里，核心是三个文件：c_cpp_properties.json、tasks.json、launch.json。这三个文件建议直接放在项目根目录下，跟IAR工程文件平级，这样整个项目结构清晰，换电脑的时候把整个文件夹拷走就行。

c_cpp_properties.json负责告诉VSCode去哪里找头文件、用什么编译器标准。关键配置项是includePath，要把IAR的编译器头文件路径和工程自己的头文件路径都加进去。IAR的头文件一般在C:\Program Files\IAR Systems\Embedded Workbench x.x\arm\inc下面，具体路径根据版本和芯片架构不同会有变化。

tasks.json定义编译任务，核心是调用IarBuild.exe并传入工程文件路径和配置名称。launch.json定义调试配置，需要指定调试器类型、可执行文件路径、仿真器型号等参数。

3. 核心配置详解：让VSCode真正驱动IAR

3.1 c_cpp_properties.json的精确配置

这个文件决定了VSCode的代码智能感知准不准。配置不好的话，你会看到满屏的红色波浪线，明明能编译通过的代码它非说找不到头文件。

{ "configurations": [ { "name": "IAR", "includePath": [ "${workspaceFolder}/**", "C:/Program Files/IAR Systems/Embedded Workbench 9.0/arm/inc/**", "C:/Program Files/IAR Systems/Embedded Workbench 9.0/arm/inc/c/**" ], "defines": [ "USE_STDPERIPH_DRIVER", "STM32F10X_MD" ], "compilerPath": "C:/Program Files/IAR Systems/Embedded Workbench 9.0/arm/bin/iccarm.exe", "cStandard": "c99", "cppStandard": "c++14", "intelliSenseMode": "windows-gcc-arm" } ], "version": 4 }

这里有几个关键点。includePath里的${workspaceFolder}/**表示递归包含工作区所有子目录，这样工程自己的头文件不管放在哪一层都能被找到。IAR的系统头文件路径要写绝对路径，而且要用正斜杠或者双反斜杠，单反斜杠在JSON里是转义字符会出问题。

defines里放的是全局宏定义，跟IAR工程Options → C/C++ Compiler → Preprocessor里定义的宏保持一致。这个很重要，因为很多芯片的头文件会根据宏定义来决定包含哪些寄存器定义，宏不对的话代码补全就会出错。

compilerPath指向IAR的编译器可执行文件，这样VSCode在解析代码的时候会用IAR的编译器内置宏，比用GCC的解析器准确得多。intelliSenseMode选windows-gcc-arm是因为IAR的ARM编译器跟GCC的语法兼容度比较高，选这个模式误报最少。

实操心得：如果你发现某个头文件明明存在但VSCode就是找不到，先检查路径里有没有空格或特殊字符。IAR默认装在Program Files下面，路径里有空格，有些插件处理不好。实在不行就把IAR装到没有空格的路径下，比如C:\IAR。

3.2 tasks.json：把编译搬到VSCode里

这个文件是整套方案的核心，它让VSCode能够直接调用IAR的编译工具链。

{ "version": "2.0.0", "tasks": [ { "label": "IAR Build", "type": "shell", "command": "IarBuild.exe", "args": [ "${workspaceFolder}/project.ewp", "-build", "Debug", "-log", "all" ], "group": { "kind": "build", "isDefault": true }, "problemMatcher": { "owner": "cpp", "fileLocation": ["relative", "${workspaceFolder}"], "pattern": { "regexp": "^(.*)\\((\\d+)\\)\\s*:\\s*(error|warning|remark)\\s*(.*)$", "file": 1, "line": 2, "severity": 3, "message": 4 } }, "presentation": { "reveal": "always", "panel": "shared", "clear": true } }, { "label": "IAR Rebuild", "type": "shell", "command": "IarBuild.exe", "args": [ "${workspaceFolder}/project.ewp", "-rebuild", "Debug", "-log", "all" ], "group": "build", "problemMatcher": { "owner": "cpp", "fileLocation": ["relative", "${workspaceFolder}"], "pattern": { "regexp": "^(.*)\\((\\d+)\\)\\s*:\\s*(error|warning|remark)\\s*(.*)$", "file": 1, "line": 2, "severity": 3, "message": 4 } } } ] }

IarBuild.exe的参数说明一下：第一个参数是工程文件路径，-build表示增量编译，-rebuild表示全量重编，后面跟的是配置名称（Debug或Release），-log all表示输出所有日志信息。

problemMatcher是让VSCode能解析编译错误的关键。IAR的错误输出格式是文件名(行号): 错误类型: 错误信息，正则表达式要跟这个格式匹配。配好之后，编译出错时VSCode的"问题"面板里会列出所有错误，点击就能跳转到对应代码行，比在IAR的Build窗口里翻日志舒服多了。

presentation里的clear: true表示每次编译前清空终端，避免旧输出干扰。panel: shared表示所有编译任务共用一个终端面板，不会开一堆窗口。

配好之后，按Ctrl+Shift+B就能触发编译，编译结果直接显示在VSCode的终端里。如果编译通过，你会看到IAR输出的链接信息和最终生成的.out文件路径。

3.3 launch.json：打通调试链路

调试配置取决于你用的硬件仿真器。以J-Link调试STM32为例：

{ "version": "0.2.0", "configurations": [ { "name": "IAR Debug (J-Link)", "type": "cortex-debug", "request": "launch", "servertype": "jlink", "cwd": "${workspaceFolder}", "executable": "${workspaceFolder}/Debug/Exe/project.out", "device": "STM32F103RC", "interface": "swd", "svdFile": "${workspaceFolder}/STM32F103xx.svd", "preLaunchTask": "IAR Build", "armToolchainPath": "C:/Program Files/IAR Systems/Embedded Workbench 9.0/arm/bin", "serverpath": "C:/Program Files/SEGGER/JLink/JLinkGDBServerCL.exe" } ] }

executable指向IAR编译生成的.out文件，这个文件包含了调试符号信息。device填你的芯片型号，svdFile是芯片外设寄存器描述文件，配好之后调试时能看到所有外设寄存器的实时值，非常方便。preLaunchTask指定编译任务，这样每次启动调试前会自动编译一次，保证调试的是最新代码。

armToolchainPath指向IAR的ARM工具链目录，因为Cortex-Debug需要调用arm-none-eabi-gdb来解析调试信息。IAR自带的GDB工具在arm/bin目录下。

注意：IAR生成的.out文件格式跟GCC的ELF格式略有差异，Cortex-Debug插件对IAR格式的支持在旧版本里有些问题。如果遇到调试符号加载失败，可以试试在IAR的Project → Options → Linker → Output里把格式改成"Debug information for C-SPY"，或者升级Cortex-Debug插件到最新版。

4. 实操流程：一个完整的开发循环

4.1 新建项目的标准步骤

假设你要做一个基于STM32F103的LED闪烁项目，完整流程是这样的：

第一步，在IAR里新建工程。File → New → Workspace，然后Project → Create New Project，选STM32F103RC，模板选Empty project。建好后在Project → Options里设置时钟频率为8MHz外部晶振，优化等级选Medium，输出格式选Debug information for C-SPY。

第二步，在IAR里添加源文件。右键工程 → Add → Add Files，把main.c、stm32f10x_gpio.c、stm32f10x_rcc.c这些文件加进去。然后在Options → C/C++ Compiler → Preprocessor里定义USE_STDPERIPH_DRIVER和STM32F10X_MD两个宏。

第三步，在项目根目录下建.vscode文件夹，把前面说的三个配置文件放进去。注意c_cpp_properties.json里的includePath要包含标准外设库的头文件路径，tasks.json里的工程文件名要跟实际的.ewp文件名一致。

第四步，在VSCode里打开项目文件夹，按Ctrl+Shift+B测试编译。如果配置正确，终端里会输出IAR的编译日志，最后显示"Build succeeded"。

第五步，按F5启动调试。如果J-Link连接正常，程序会下载到芯片里并停在main函数入口。这时候你可以设断点、看变量、单步执行，跟IAR自带的调试器体验基本一致。

4.2 日常开发的快捷键与操作流

配置好之后，日常开发基本不用打开IAR了。我的操作流是这样的：

写代码在VSCode里，Ctrl+Space触发代码补全，F12跳转定义，Shift+F12查找引用，Ctrl+Shift+F全局搜索。这些操作在IAR里要么没有，要么慢得让人抓狂。

编译按Ctrl+Shift+B，错误信息直接显示在终端和问题面板里，点击错误跳转到代码行。修完错误再按一次，直到编译通过。

调试按F5，Cortex-Debug会自动调用J-Link GDB Server，下载程序，停在main函数。设断点用F9，单步用F10（跳过）和F11（进入），看变量在左侧的VARIABLES面板，看外设寄存器在CORTEX PERIPHERALS面板。

串口输出用Serial Monitor插件，配置好波特率和端口号，程序里的printf重定向到串口后，打印信息直接显示在VSCode里，不用再开单独的串口助手。

版本管理用VSCode内置的Git功能，改完代码直接提交，diff视图比IAR的版本比较功能好用一百倍。

4.3 编译输出与错误定位技巧

IAR的命令行编译输出信息量很大，默认会打印每个源文件的编译过程、优化信息、链接信息。如果项目文件多，终端会刷得很快。-log all参数会输出所有信息，如果只想看错误和警告，可以改成-log warnings或-log errors。

错误定位的关键在problemMatcher的正则表达式。IAR的错误格式有时候会有变体，比如有些版本会在文件名后面带完整路径，有些只带文件名。如果发现错误信息解析不出来，可以先用-log all跑一次，看看实际的输出格式，然后调整正则表达式。

我遇到过一种情况：IAR编译时报错说某个头文件找不到，但那个头文件明明在工程目录里。查了半天发现是IAR的工程配置里头文件搜索路径用的是相对路径，而VSCode调用IarBuild.exe时的工作目录跟IAR IDE的工作目录不一样，导致相对路径解析错误。解决办法是在tasks.json的options里指定cwd为工程根目录，或者在IAR工程配置里把头文件路径改成绝对路径。

5. 常见问题与排查实录

5.1 编译相关的高频问题

问题一：IarBuild.exe找不到或无法执行。

这个通常是环境变量没配好。检查系统Path里有没有IAR的common\bin目录。如果没有，手动加上，然后重启VSCode让环境变量生效。另一个可能是IAR安装路径里有空格，命令行解析出问题，解决办法是用引号把路径包起来，或者在tasks.json里用"command": "\"C:/Program Files/IAR Systems/.../IarBuild.exe\""这种形式。

问题二：编译通过但VSCode报红。

这是c_cpp_properties.json配置不完整导致的。VSCode的IntelliSense用的是自己的解析器，跟IAR的编译器是两套系统。解决办法是把IAR工程里所有的宏定义和头文件路径都同步到c_cpp_properties.json里。如果还是报红，可以在VSCode的设置里把C_Cpp.errorSquiggles改成Disabled，眼不见心不烦，反正编译能过就行。

问题三：编译速度慢。

IAR的命令行编译默认是单线程的，多文件项目编译起来确实慢。可以在IarBuild.exe的参数里加-parallel开启多核并行编译，能快不少。另外，如果只是改了一两个文件，用-build增量编译而不是-rebuild全量编译。

5.2 调试链路的典型故障

问题一：J-Link连接失败。

先检查硬件连接，SWD接口的SWCLK、SWDIO、GND、VCC四根线有没有接对。然后检查J-Link驱动有没有装，设备管理器里能不能看到J-Link设备。如果都没问题，可能是芯片被读保护了，用J-Link Commander执行unlock命令解锁。

问题二：调试时断点不生效。

这种情况通常是优化等级太高导致的。IAR在High优化等级下会做激进的代码重排和变量优化，导致断点位置跟源码对不上。调试的时候把优化等级降到Low或者None，调完再改回去。

问题三：变量值显示不正确。

Cortex-Debug读取变量值依赖调试符号，如果.out文件里的符号信息不完整，变量就显示不出来。检查IAR的Linker → Output里有没有勾选"Debug information"，以及优化等级是不是太高把变量优化掉了。把变量声明加上volatile关键字通常能解决。

5.3 插件冲突与性能优化

VSCode插件装多了确实会互相打架。我遇到过C/C++插件和某个代码格式化插件冲突，导致保存时自动格式化把代码改乱。解决办法是只装必要的插件，格式化用IAR自带的或者手动控制。

性能方面，如果项目文件很多（几百个源文件），VSCode的IntelliSense会占用大量内存。可以在c_cpp_properties.json里把includePath缩小到实际需要的目录，不要用/**递归包含整个工作区。另外，把C_Cpp.intelliSenseEngine改成Tag Parser模式，虽然功能少一些但速度快很多。

6. 进阶技巧：把这套组合用到极致

6.1 多工程工作区的管理

实际项目往往不止一个工程，比如一个Bootloader加一个Application，或者一个主控加几个从控。IAR的工作空间（.eww）可以包含多个工程，VSCode这边可以用多根工作区（Multi-root Workspace）来管理。

具体做法是在VSCode里File → Add Folder to Workspace，把每个工程目录都加进来，然后保存为一个.code-workspace文件。每个工程目录下有自己的.vscode配置，互不干扰。编译的时候在tasks.json里定义多个任务，用dependsOn指定依赖关系，比如先编译Bootloader再编译Application。

这种管理方式的好处是，你可以在一个VSCode窗口里同时编辑多个工程的代码，跳转定义可以跨工程，搜索也是全局的。比在IAR里开多个窗口来回切方便得多。

6.2 结合Git做版本控制

IAR工程文件（.ewp、.eww）是XML格式的，里面包含了大量绝对路径和本机配置信息，直接提交到Git会带来很多麻烦。建议的做法是：

• 把.ewp和.eww加入.gitignore，不提交。
• 用IAR的"Export Project"功能导出工程配置为.xml文件，提交这个文件。
• 或者用CMake或Makefile来管理编译配置，IAR工程文件只作为本地开发用。

如果团队里所有人都用IAR，那直接提交.ewp也行，但要约定好IAR的安装路径一致，否则绝对路径对不上。更稳妥的做法是在IAR工程里用相对路径引用头文件和源文件，这样换电脑也能用。

VSCode这边的.vscode文件夹建议提交，因为里面的配置是团队共享的。但c_cpp_properties.json里的IAR安装路径可能因人而异，可以用环境变量代替绝对路径，比如${env:IAR_PATH}/arm/inc。

6.3 串口调试与日志输出

嵌入式开发离不开串口打印。传统的做法是开一个串口助手，但来回切窗口很烦。VSCode的Serial Monitor插件可以直接在编辑器里看串口输出，还支持发送数据。

配置方法：安装Serial Monitor插件，在设置里配置波特率、数据位、停止位、校验位，然后选择串口端口。打开监视器后，程序里通过printf输出的信息会实时显示。如果芯片的printf没有重定向到串口，需要自己实现fputc函数，把字符写到USART的发送寄存器。

更高级的用法是结合VSCode的Output Colorizer插件，给不同级别的日志加颜色。比如在打印信息里加[ERROR]、[WARN]、[INFO]前缀，然后在插件里配置对应的颜色规则，调试的时候一眼就能看出问题。

6.4 代码诊断与静态分析

IAR自带的静态分析工具C-STAT可以在编译时检查代码质量，但报告是在IAR IDE里看的。VSCode这边可以用C/C++插件的代码分析功能，或者装专门的静态分析插件。

我常用的组合是C/C++插件加Clang-Tidy。Clang-Tidy需要单独安装LLVM工具链，然后在VSCode的设置里配置clang-tidy的路径和检查规则。配好之后，保存文件时会自动运行静态检查，潜在的空指针、内存泄漏、未初始化变量这些问题会直接标出来。

不过要注意，Clang-Tidy的检查规则跟IAR的编译器警告不完全一致，有些Clang-Tidy报的问题IAR并不认为有问题。建议把Clang-Tidy的检查级别调低一些，只关注严重的错误，避免被大量误报干扰。

6.5 嵌入式AI开发的前瞻性配置

现在嵌入式AI是个热词，很多项目开始在MCU上跑轻量级神经网络。这类项目对开发环境的要求跟传统嵌入式有些不同，需要额外的工具链支持，比如TensorFlow Lite Micro的代码生成、模型量化工具等。

VSCode在这方面有天然优势，Python插件、Jupyter插件可以直接在编辑器里跑模型训练和量化脚本，生成的C代码再集成到IAR工程里编译。整个流程可以在一个VSCode窗口里完成，不用在多个工具之间来回倒腾。

配置上需要注意的是，嵌入式AI项目的代码量通常比较大，IntelliSense可能会卡。建议把模型推理相关的代码单独放在一个文件夹里，在c_cpp_properties.json里排除掉不需要索引的目录，只保留核心的推理引擎和业务代码。

7. 我踩过的坑和最后分享几个实用技巧

先说一个让我折腾了大半天的坑。有一次换电脑，把整个项目文件夹拷到新机器上，VSCode里编译死活过不去，报错说找不到某个库文件。查了半天发现是IAR工程文件里用了绝对路径引用库文件，旧电脑上库在D盘，新电脑上只有C盘。解决办法是在IAR的Project → Options → Linker → Library里把库文件路径改成相对路径，或者用$PROJ_DIR$变量。这个变量是IAR内置的，表示工程文件所在目录，用它来拼路径就能保证换电脑不出问题。

另一个坑是关于中文路径的。IAR对中文路径的支持一直不太好，如果项目放在带中文的文件夹里，编译时可能会报一些莫名其妙的错误。VSCode这边倒是没问题，但IAR的命令行工具会挂。所以项目路径最好全用英文，别图省事用中文文件夹名。

还有一个实用技巧是给tasks.json加多个编译配置。比如Debug配置用低优化等级方便调试，Release配置用高优化等级出最终版本。在tasks.json里定义两个任务，分别对应IAR工程里的两个配置，用Ctrl+Shift+B的时候可以选择编译哪个配置。这样不用每次手动去IAR里改优化等级。

最后分享一个提高效率的小习惯：把常用的VSCode命令绑定到快捷键上。比如我把"重新编译"绑到Ctrl+Alt+B，"启动调试"绑到Ctrl+Alt+D，"打开串口监视器"绑到Ctrl+Alt+S。这样手不用离开键盘就能完成整个开发循环，效率提升很明显。

这套VSCode加IAR的组合我用了快两年，中间也尝试过纯VSCode加GCC、CLion加OpenOCD这些方案，最后还是回到了这个组合。不是说其他方案不好，而是这套组合在Windows平台上的稳定性和兼容性确实是最好的，尤其是当你需要同时维护多个不同芯片平台的项目时，IAR的器件支持包和VSCode的统一编辑体验结合起来，能省下大量切换工具和重新学习的时间。如果你也在用IAR但受不了它的编辑器，强烈建议花一个下午把VSCode这套配置搭起来，后面省下的时间绝对值得这个投入。