1. 为什么要把 VS Code 和 Keil5 凑在一起用嵌入式开发这个圈子有个很有意思的现象大家一边骂 Keil5 的编辑器难用一边又离不开它。原因很简单Keil MDK 的编译器、调试器、器件支持包这套组合拳在 ARM Cortex-M 开发里依然是绕不过去的存在。但它的代码编辑体验确实停留在十年前——没有智能补全、没有多光标、没有 Git 集成、主题也丑。VS Code 恰好补上了这块短板轻量、插件生态丰富、界面现代、跨平台。所以这套组合的核心思路就是用 VS Code 写代码用 Keil5 编译和调试。两者各干各擅长的事通过合理的工程配置让它们协同工作。这篇文章我会把从零搭建这套环境的完整流程拆开讲包括 Keil5 的安装与配置、VS Code 的插件选型、工程目录的组织方式、编译任务的定义、调试链路的打通以及我在实际使用中踩过的各种坑。适合谁看如果你是刚接触 STM32 或 C51 的嵌入式新手跟着做能少走很多弯路如果你已经用 Keil5 开发了一段时间但被它的编辑器折磨得够呛这篇文章能帮你把开发体验提升一个档次如果你之前尝试过 VS Code Keil5 但配置到一半放弃了我也会把那些容易卡住的环节重点讲清楚。先说清楚一个前提这套方案不是要你抛弃 Keil5而是让 VS Code 成为你的主力编辑器Keil5 退居幕后做它最擅长的事——编译、链接、下载、调试。你依然需要安装 Keil5依然需要它的 License只是日常写代码的时候不用再面对那个界面了。2. 环境准备Keil5 与 VS Code 的安装要点2.1 Keil5 安装版本选择与器件包管理Keil MDK 的安装本身不复杂但有几个关键决策点需要提前想清楚。第一个问题是版本选择。Keil MDK 目前主流的是 MDK-ARM V5 系列比如 V5.38、V5.39 这些版本。我的建议是不要盲目追新选一个你所用芯片官方例程验证过的版本最稳妥。比如 STM32F1 系列的很多老例程是在 MDK V5.20 左右验证的用太新的版本反而可能遇到编译器行为差异。如果你用的是比较新的芯片比如 STM32H7 或 GD32 的新型号那就选较新的 MDK 版本确保器件支持包能正常安装。第二个问题是 C51 和 MDK 的共存。很多学校教学还在用 8051而工作中又需要 STM32所以经常需要在一台机器上同时装 Keil C51 和 Keil MDK。这两个可以装在同一目录下安装顺序是先装 C51 再装 MDK这样 MDK 的安装程序会自动识别已有的 C51 安装并做整合。如果你先装了 MDK 再装 C51可能会出现一些路径冲突的问题。安装路径建议用默认的C:\Keil_v5不要放在中文路径或带空格的路径下否则后续配置编译任务时容易出问题。第三个问题是器件支持包Device Family Pack。Keil5 安装完之后你需要的芯片支持包不一定已经装好了。比如你要开发 STM32F103就需要安装Keil.STM32F1xx_DFP这个包。安装方式有两种一种是通过 Keil5 自带的 Pack Installer 在线安装另一种是去官网下载.pack文件离线安装。我强烈建议用离线安装的方式因为 Pack Installer 的在线下载速度经常让人崩溃。下载好.pack文件后双击就能自动安装非常省事。注意Keil5 的 License 管理是另一个容易出问题的地方。MDK-Lite 版本有 32KB 代码限制对于稍微大一点的项目就不够用了。如果你有正版 License 直接激活即可如果是评估用途注意不要使用来源不明的注册工具合规使用软件是基本职业素养。2.2 VS Code 安装与基础配置VS Code 的安装没什么好说的官网下载安装包一路下一步就行。但有几个配置项建议在装完之后立刻调整。首先是中文语言包。虽然英文界面用久了也能习惯但对于刚上手的同学来说中文界面能降低不少认知负担。在扩展市场搜索Chinese (Simplified)安装即可装完重启 VS Code 就生效了。其次是字体配置。嵌入式开发经常要看寄存器定义和汇编代码等宽字体是必须的。我推荐JetBrains Mono或Cascadia Code前者对代码连字支持很好后者是微软自家的字体在 Windows 上渲染效果不错。在设置里搜索editor.fontFamily修改即可顺便把editor.fontSize调到 14 或 15长时间看代码眼睛会舒服很多。还有一个容易被忽略的配置是文件编码。Keil5 默认使用 GB2312 编码而 VS Code 默认是 UTF-8。如果你在 VS Code 里打开一个 Keil5 创建的源文件中文注释可能会变成乱码。解决办法是在 VS Code 设置里搜索files.autoGuessEncoding并勾选这样 VS Code 会自动检测文件编码。或者更彻底一点把你项目里所有源文件统一转成 UTF-8 编码然后在 Keil5 的Edit - Configuration - Editor里把编码也改成 UTF-8。统一编码能避免很多莫名其妙的乱码问题。2.3 工程目录的组织方式在开始装插件之前先想清楚你的工程目录怎么组织。这直接影响到后续 VS Code 的配置复杂度。我推荐的结构是这样的项目根目录下放.vscode文件夹存放 VS Code 的配置文件、Core文件夹存放用户代码、Drivers文件夹存放 HAL 库或标准库、MDK-ARM文件夹存放 Keil5 的工程文件。这个结构其实是 STM32CubeMX 生成工程的默认结构如果你用 CubeMX 生成代码直接就是这个样子。为什么要把 Keil5 的工程文件单独放在一个子目录里因为 Keil5 在编译时会生成大量中间文件.o、.d、.crf、.axf等如果和源代码混在一起VS Code 的文件搜索和 Git 管理都会变得很痛苦。把它们隔离在MDK-ARM目录下然后在 VS Code 的settings.json里把**/MDK-ARM/**加入files.exclude和search.exclude整个世界就清净了。如果你不用 CubeMX 而是手动创建工程也建议遵循类似的结构。核心原则就一条源代码和编译产物分离。3. 插件选型哪些值得装哪些是坑3.1 C/C 插件IntelliSense 的核心VS Code 写 C 代码微软官方的C/C扩展是必装的。它提供语法高亮、智能补全、跳转定义、查找引用、错误提示等功能。但很多人装完之后发现补全不准、头文件找不到、宏定义识别不了然后就放弃了。问题不在插件本身而在于c_cpp_properties.json这个配置文件没有配对。这个文件的作用是告诉 C/C 插件你的头文件在哪里、你的宏定义有哪些、你用的是什么编译器。对于 Keil5 工程来说你需要把 Keil5 工程里配置的 Include Paths 和 Define 都同步到这个文件里。具体怎么配打开 Keil5 工程点击Options for Target在C/C选项卡里能看到Include Paths和Define两项。把 Include Paths 里的所有路径复制出来在c_cpp_properties.json的includePath数组里逐条添加注意路径要用正斜杠/而不是反斜杠\并且要加上${workspaceFolder}/前缀。Define 里的宏定义复制到defines数组里。编译器路径这一项指向 Keil5 安装目录下的ARM\ARMCC\bin\armcc.exe如果是 AC5 编译器或ARM\ARMCLANG\bin\armclang.exe如果是 AC6 编译器。这个设置影响的是 IntelliSense 的解析行为不影响实际编译。实操心得如果你用的是 STM32CubeMX 生成的工程c_cpp_properties.json里需要添加的宏定义通常包括USE_HAL_DRIVER和你的芯片型号宏如STM32F103xE。这两个宏不定义的话HAL 库的头文件会报一堆找不到定义的错误。3.2 嵌入式开发相关插件推荐除了 C/C 插件还有几个插件能显著提升嵌入式开发体验。Cortex-Debug是调试环节的核心插件。它配合 OpenOCD 或 J-Link 可以实现 VS Code 内的断点调试、变量查看、寄存器查看等功能。不过它的配置相对复杂需要你有一个独立的调试探针ST-Link、J-Link 等并且需要配置launch.json。如果你目前只用 Keil5 自带的调试器这个插件可以先不装等后续需要脱离 Keil5 调试时再折腾。ARM Assembly插件提供 ARM 汇编的语法高亮如果你需要看启动文件或写汇编代码这个很有用。Linker Script插件提供链接脚本的语法高亮对于需要手动调整内存布局的项目很有帮助。Hex Editor插件可以让你在 VS Code 里直接查看.hex或.bin文件不用再开专门的十六进制编辑器。GitLens虽然不是嵌入式专用但对于管理代码版本非常有用。嵌入式项目经常需要对比不同版本的寄存器配置GitLens 的行内 blame 功能能让你快速定位每一行代码是谁在什么时候改的。Better Comments插件能让你的注释更有层次感。比如用// !标记警告、// ?标记疑问、// TODO标记待办在代码里一眼就能区分出来。3.3 那些看起来很美好但实际很鸡肋的插件插件市场里有一些看起来很诱人的嵌入式相关插件但实际用下来体验并不好。比如某些号称能一键编译 Keil 工程的插件本质上就是帮你调用 Keil 的命令行工具但配置起来比自己写 tasks.json 还麻烦而且灵活性很差。还有一些插件试图在 VS Code 里复刻 Keil5 的器件配置界面但更新滞后新芯片支持跟不上。另外要警惕的是那些要求你上传工程文件到云端进行解析的插件。嵌入式工程里可能包含公司的专有代码或硬件配置信息上传到第三方服务器存在泄密风险。这类插件不管功能多诱人都不建议在正式项目中使用。我的原则是插件只装真正需要的能用配置文件搞定的事情就不装插件。VS Code 本身的任务系统和配置文件已经足够灵活过度依赖插件反而会增加环境的不稳定性。4. 核心配置让 VS Code 调用 Keil5 的编译链路4.1 理解 Keil5 的命令行编译工具要让 VS Code 调用 Keil5 的编译能力首先得知道 Keil5 提供了哪些命令行工具。在 Keil5 安装目录的UV4文件夹下有一个UV4.exe这就是 Keil5 的主程序。它支持命令行参数常用的有这几个UV4.exe -b project.uvprojx -o build_log.txt批量编译工程编译日志输出到指定文件UV4.exe -r project.uvprojx -o build_log.txt重新编译所有文件UV4.exe -c project.uvprojx清理工程UV4.exe -j0 project.uvprojx编译但不弹出界面这些参数的含义可以通过UV4.exe -h查看帮助。关键的一点是-j0参数它让 Keil5 在后台静默编译不会弹出那个烦人的进度窗口。还有一个工具是fromelf.exe位于ARM\ARMCC\bin或ARM\ARMCLANG\bin目录下。它用于将编译生成的.axf文件转换成.hex或.bin格式。在 Keil5 的Options for Target - User选项卡里通常会配置一个 After Build 命令来调用 fromelf 生成 hex 文件。如果你在 VS Code 里编译这个 After Build 命令也会被执行所以 hex 文件会正常生成。4.2 编写 tasks.json 实现一键编译VS Code 的任务系统通过.vscode/tasks.json文件配置。下面是一个可以直接用的配置模板{ version: 2.0.0, tasks: [ { label: Keil Build, type: shell, command: C:/Keil_v5/UV4/UV4.exe, args: [ -b, ${workspaceFolder}/MDK-ARM/your_project.uvprojx, -j0, -o, ${workspaceFolder}/MDK-ARM/build_log.txt ], group: { kind: build, isDefault: true }, problemMatcher: [ { owner: keil, fileLocation: [autoDetect, ${workspaceFolder}], pattern: { regexp: ^(.*)\\((\\d)\\):\\s(warning|error|note):\\s(.*)$, file: 1, line: 2, severity: 3, message: 4 } } ], presentation: { reveal: silent, panel: shared } }, { label: Keil Rebuild, type: shell, command: C:/Keil_v5/UV4/UV4.exe, args: [ -r, ${workspaceFolder}/MDK-ARM/your_project.uvprojx, -j0, -o, ${workspaceFolder}/MDK-ARM/build_log.txt ], problemMatcher: [] }, { label: Keil Clean, type: shell, command: C:/Keil_v5/UV4/UV4.exe, args: [ -c, ${workspaceFolder}/MDK-ARM/your_project.uvprojx ], problemMatcher: [] } ] }这个配置里几个关键点解释一下。command指向 UV4.exe 的完整路径注意路径分隔符用正斜杠。args里的${workspaceFolder}是 VS Code 的变量代表当前工作区根目录。problemMatcher是精华所在它定义了如何从编译日志里提取错误和警告信息提取出来的信息会显示在 VS Code 的问题面板里点击就能跳转到对应代码行。那个正则表达式^(.*)\\((\\d)\\):\\s(warning|error|note):\\s(.*)$匹配的是 Keil5 编译输出的典型格式比如../Core/Src/main.c(45): warning: variable i was declared but never referenced。如果你的 Keil5 输出格式不太一样可能需要微调这个正则。配置好之后按CtrlShiftB就能触发编译编译结果会输出到build_log.txt同时错误和警告会显示在问题面板里。4.3 编译日志的解析与问题定位Keil5 的编译日志默认输出到文件而不是直接打印到终端。这是-o参数的作用。但这样有个问题编译过程中你看不到实时输出得等编译结束才能看到日志。解决思路是在 tasks.json 里加一个dependsOn让编译任务依赖一个打开日志文件的任务。或者更简单一点用 VS Code 的输出面板选择对应的任务输出通道也能看到部分实时信息。编译日志里常见的信息类型有几种。warning是警告通常不影响编译结果但值得关注error是错误必须修复才能编译通过note是提示信息一般是编译器给出的补充说明。还有一种L6218E: Undefined symbol是链接错误表示某个函数或变量没有定义通常是源文件没加到工程里或者库文件没链接。实操心得Keil5 的编译日志里文件路径是相对于.uvprojx文件所在目录的。所以 problemMatcher 里的fileLocation要设置成[autoDetect, ${workspaceFolder}]这样 VS Code 才能正确解析出文件的绝对路径。如果路径解析不对点击错误信息就跳不到正确的文件。5. 调试链路从 Keil5 调试到 VS Code 调试5.1 Keil5 自带调试器的使用要点在打通 VS Code 调试之前先用 Keil5 自带的调试器把硬件连接调通是很有必要的。Keil5 的调试配置在Options for Target - Debug选项卡里。调试器选择取决于你用的硬件探针。ST-Link 选ST-Link DebuggerJ-Link 选J-LINK / J-TRACE Cortex。选好之后点击旁边的Settings按钮在Debug标签页里能看到是否识别到了芯片。如果识别不到检查一下驱动是否安装、USB 线是否插好、芯片是否供电。Flash Download标签页里要确认烧录算法是否正确。比如 STM32F103C8T6 需要选STM32F10x Med-density Flash算法。如果算法选错了烧录会失败或者烧进去的程序跑不起来。Debug标签页里还有一个Reset and Run选项勾上之后烧录完会自动复位运行不用手动按复位键。这个选项在频繁烧录调试时很有用。5.2 用 Cortex-Debug 插件实现 VS Code 内调试如果你想让调试也在 VS Code 里完成就需要Cortex-Debug插件配合 OpenOCD 或 J-Link GDB Server。以 ST-Link OpenOCD 为例你需要先安装 OpenOCD。安装好之后在 VS Code 的launch.json里配置调试任务{ version: 0.2.0, configurations: [ { name: Cortex Debug (OpenOCD), cwd: ${workspaceFolder}, executable: ${workspaceFolder}/MDK-ARM/your_project.axf, request: launch, type: cortex-debug, servertype: openocd, configFiles: [ interface/stlink.cfg, target/stm32f1x.cfg ], svdFile: ${workspaceFolder}/STM32F103.svd, runToEntryPoint: main, preLaunchTask: Keil Build } ] }几个关键配置项说明一下。executable指向 Keil5 编译生成的.axf文件这个文件包含了调试符号信息。configFiles里指定 OpenOCD 的接口配置和目标芯片配置不同芯片的配置文件不一样OpenOCD 安装目录下的scripts/target文件夹里能找到各种芯片的配置。svdFile是芯片的寄存器描述文件配置之后在调试时能查看外设寄存器的值非常方便。preLaunchTask指定调试前先执行编译任务确保调试的是最新代码。SVD 文件可以从芯片厂商官网下载比如 STM32 的 SVD 文件在 ST 官网的 CMSIS 包里就有。把 SVD 文件放到工程目录下在 launch.json 里指向它即可。5.3 调试配置中的常见坑Cortex-Debug 的配置有几个容易踩坑的地方。第一个是 OpenOCD 的路径问题。servertype设为openocd时插件会去系统 PATH 里找 openocd.exe。如果你没把 OpenOCD 加到 PATH就需要在 launch.json 里加一个serverpath字段指定完整路径。第二个是 ST-Link 驱动冲突。如果你同时装了 Keil5 的 ST-Link 驱动和 OpenOCD 自带的驱动可能会出现其中一个用不了的情况。解决办法是统一用 ST 官方的 ST-Link 驱动OpenOCD 配置里用stlink.cfg接口文件即可。第三个是.axf文件路径。Keil5 默认把.axf文件生成在MDK-ARM/Objects目录下文件名和工程名一致。如果你改了工程名或者输出路径记得同步修改 launch.json 里的executable字段。第四个是断点不生效的问题。这通常是因为编译时没有生成调试信息。检查 Keil5 的Options for Target - Output选项卡确认Debug Information被勾选了。没有调试信息的话VS Code 里设的断点不会命中。6. 常见问题与排查技巧实录6.1 编译相关的高频问题问题一VS Code 里编译报错找不到 UV4.exe这个通常是路径配置错误。检查 tasks.json 里的command字段确认 Keil5 的安装路径是否正确。如果你把 Keil5 装在了非默认路径需要相应修改。另外注意路径里的反斜杠要改成正斜杠或者用双反斜杠转义。问题二编译通过但问题面板里没有错误信息检查 problemMatcher 的正则表达式是否匹配你的 Keil5 输出格式。不同版本的 Keil5 输出格式可能有细微差异。可以打开build_log.txt看看实际的输出格式然后调整正则。问题三编译速度慢Keil5 的编译速度本身就不算快尤其是全量编译的时候。可以开启并行编译来加速在 Keil5 的Options for Target - C/C选项卡里把Optimization设为-O1或-O2同时在Options for Target - Output里勾选Browse Information会拖慢编译速度如果不是必须可以取消勾选。问题四中文注释乱码前面提到过统一编码是根本解决办法。如果暂时不想改编码可以在 VS Code 里用Reopen with Encoding命令选择 GB2312 重新打开文件。6.2 调试相关的高频问题问题一Keil5 能烧录但 VS Code 调试连不上先确认 OpenOCD 能否独立运行。在命令行里执行openocd -f interface/stlink.cfg -f target/stm32f1x.cfg看看能否正常识别到芯片。如果 OpenOCD 本身就连不上VS Code 里肯定也连不上。检查硬件连接、驱动、芯片供电。问题二断点命中但变量值显示不对这通常是优化级别太高导致的。编译器优化后某些变量可能被优化掉或者寄存器分配发生变化导致调试器读到的值不准确。调试阶段建议把优化级别设为-O0发布时再改成-O2或-O3。问题三单步调试时程序跑飞检查中断向量表是否正确。如果你在调试时触发了中断但没有对应的中断服务函数程序会跳转到默认的中断处理函数通常是一个死循环。另外检查堆栈大小是否足够堆栈溢出也会导致程序跑飞。问题四SVD 文件加载后外设寄存器不显示确认 SVD 文件的芯片型号和实际芯片一致。有些 SVD 文件覆盖了整个系列但个别型号的外设寄存器地址可能不同。如果 SVD 文件不对可以尝试从芯片厂商官网下载对应型号的 SVD。6.3 环境配置的独家避坑技巧技巧一用符号链接解决路径问题如果你的工程需要在多台电脑上开发而不同电脑上 Keil5 的安装路径不同可以用符号链接来统一路径。在 Windows 上用mklink /D C:\Keil_v5 D:\Program Files\Keil_v5创建一个符号链接这样无论实际装在哪里路径都是C:\Keil_v5。技巧二把 .vscode 文件夹加入版本控制.vscode文件夹里的tasks.json、launch.json、c_cpp_properties.json这些配置文件建议加入 Git 版本控制。这样团队里其他人拉取代码后直接就有配好的开发环境不用每个人重新配一遍。但settings.json里如果有个人偏好设置可以不加或者用.gitignore排除。技巧三用工作区文件管理多工程如果你同时开发多个嵌入式项目可以用 VS Code 的工作区功能。创建一个.code-workspace文件把多个工程文件夹加进来每个工程有独立的.vscode配置。这样切换项目时不用重新打开窗口直接在同一个窗口里切换即可。技巧四定期清理编译产物Keil5 的编译产物会越积越多尤其是.o文件和.d文件。定期执行Keil Clean任务清理一下能避免一些莫名其妙的链接错误。但注意清理后需要全量编译时间会比较长。技巧五备份 Keil5 的器件支持包如果你在多个电脑上开发建议把安装好的器件支持包.pack文件备份到网盘或移动硬盘。这样在新电脑上配置环境时不用重新下载直接离线安装即可。器件支持包通常放在C:\Keil_v5\ARM\PACK目录下。7. 进阶玩法让这套环境更顺手7.1 代码格式化与静态检查VS Code 的 C/C 插件自带代码格式化功能快捷键是ShiftAltF。但默认的格式化风格可能不符合你的习惯可以在.clang-format文件里自定义。比如设置缩进为 4 个空格、大括号换行风格、指针对齐方式等。把.clang-format文件放在工程根目录VS Code 会自动识别。静态检查方面可以装C/C Advanced Lint插件它集成了 cppcheck 等静态分析工具能在编码阶段发现潜在的空指针、数组越界、内存泄漏等问题。对于嵌入式开发来说这类问题往往在运行时才暴露能在编码阶段发现会省很多调试时间。7.2 串口调试与日志输出嵌入式开发离不开串口调试。VS Code 里可以装Serial Monitor插件直接在编辑器里查看串口输出不用再开额外的串口助手。配置好波特率、数据位、停止位之后就能实时看到 MCU 打印的调试信息。如果你用的是 J-Link 调试器还可以用 RTTReal Time Transfer功能输出日志。RTT 不需要占用串口速度也比串口快很多。配合Cortex-Debug插件可以在 VS Code 的调试控制台里直接看到 RTT 输出。7.3 用 Git 管理嵌入式工程嵌入式工程的 Git 管理有几个特殊之处。编译产物.o、.axf、.hex、.bin不应该加入版本控制在.gitignore里排除掉。Keil5 的工程文件.uvprojx、.uvoptx建议加入版本控制但.uvoptx里包含了一些用户界面相关的配置比如打开的窗口位置如果团队协作时经常冲突可以只保留.uvprojx。另外如果你用了 CubeMX 生成代码.ioc文件一定要加入版本控制。这个文件记录了所有的外设配置是重新生成代码的依据。没有它的话后续想改配置就得手动改代码了。7.4 多编译器共存的处理有些项目可能同时用到 AC5 和 AC6 编译器。Keil5 从 V5.37 开始默认使用 AC6但很多老工程是用 AC5 编译的。如果直接切换编译器可能会遇到一堆编译错误。处理办法是在 Keil5 的Options for Target - Target选项卡里把ARM Compiler切换成你需要的版本。AC5 和 AC6 的语法有一些差异比如 AC6 对 C99 的支持更好但对一些 AC5 的扩展语法不支持。如果工程里用了 AC5 特有的语法要么改代码适配 AC6要么继续用 AC5。VS Code 的c_cpp_properties.json里compilerPath也要相应指向对应版本的编译器否则 IntelliSense 的解析结果可能和实际编译结果不一致。8. 我在这套环境上踩过的真实坑说几个我实际踩过的坑都是文档里不会写的。第一个坑是 Keil5 的-j0参数在某些版本上不生效。我遇到过 UV4.exe 加了-j0还是会弹窗的情况后来发现是 Keil5 的某个版本对-j0的支持有问题。解决办法是升级 Keil5 到较新的版本或者用-j1参数最小化窗口而不是完全隐藏。第二个坑是 VS Code 的 C/C 插件在解析 ARM 特有的关键字时出错。比如__irq、__weak、__packed这些关键字IntelliSense 可能不认识导致代码里出现红色波浪线。解决办法是在c_cpp_properties.json的defines里加上这些关键字的定义比如__weak、__packed__attribute__((packed))等。第三个坑是编译日志里的中文路径问题。如果你的工程路径里有中文Keil5 的编译日志里中文会变成乱码导致 problemMatcher 解析失败。解决办法很简单工程路径不要用中文。第四个坑是 OpenOCD 的配置文件版本不匹配。不同版本的 OpenOCD 配置文件语法可能有差异比如stlink.cfg在新版本里可能改名叫stlink-dap.cfg。如果调试连不上先检查一下 OpenOCD 的版本和配置文件是否匹配。第五个坑是 VS Code 的自动保存和 Keil5 的文件锁冲突。VS Code 默认开启自动保存而 Keil5 在编译时会锁定工程文件。如果 VS Code 在 Keil5 编译时自动保存了源文件可能导致编译结果不一致。解决办法是把自动保存改成onFocusChange或者off手动CtrlS保存。这套环境搭好之后日常开发体验会比纯 Keil5 好很多。代码补全、跳转、Git 集成、多光标编辑这些功能一旦用习惯了就回不去了。但也要承认这套方案不是银弹它解决的是编辑体验问题编译和调试的底层还是 Keil5 那套东西。如果你的项目对编译速度有极高要求或者需要更现代的调试功能可以考虑迁移到 CLion 或基于 CMake 的构建系统那是另一个话题了。