VS Code 与 Keil 组合：嵌入式开发编译下载体验升级指南

做嵌入式开发的朋友应该都有过这种经历打开 Keil准备改一个 bug结果先被它的编辑器卡了半天。代码联想慢不说主题配色长期停留在“上古”风格看 Git 历史、做代码格式化基本都要切到别的工具。Keil 就像一个厨艺很好但厨房脏乱的老师傅——编译和下载确实稳可写代码的体验实在谈不上现代。我在几个项目里被这个问题折磨过之后开始尝试“VS Code 编辑 Keil 编译下载”的组合方案平时写代码、看代码、查定义都在 VS Code 里完成到编译和烧录的时候再通过命令行把活交回给 Keil 引擎。这套流程稳定跑了一年多几个同事也陆续照着我这边的方式配置过今天把里面涉及的原理、配置步骤和踩坑记录整理出来希望能帮你少走点弯路。1. 整体设计思路VS Code 管编辑Keil 管编译1.1 为什么不直接在 VS Code 里调 armcc一开始我确实试过在 VS Code 里直接调用 ARM 编译器比如 armcc 或者 armclang。这样做的想法很直接反正 Keil 也是用同一个编译器我在 VS Code 里自己拼命令行不就行了试过之后才发现这事没有想的那么简单。一个完整的 Keil 工程编译的时候远不止“源文件 头文件”这么简单里面还涉及一堆隐式信息分散加载文件.sct决定了代码段、数据段怎么放置直接查命令行参数传进去很麻烦。工程里每个源文件可能有独立的编译选项比如某个文件额外定义了宏另一个文件关掉了某类警告。芯片型号相关的寄存器定义、启动文件、系统初始化文件都是 Keil 在后台悄悄处理的。各种中间文件的依赖关系比如某个头文件变化之后到底哪些 .o 需要重新编译也要自己维护。与其自己在 VS Code 里重建一套构建系统不如直接复用 Keil 的工程构建能力。所以最终方案是VS Code 只负责编辑和交互真正干活的是 Keil 的 UV4.exe 命令行模式。1.2 用 UV4.exe 命令行模式作桥梁Keil 自带的 UV4.exe 其实支持一套命令行参数。我重点用的两条是UV4.exe -b 工程文件.uvprojx -j0 -o 编译日志.txt UV4.exe -f 工程文件.uvprojx -j0 -o 下载日志.txt第一条是编译工程-b即 build。第二条是执行下载-f即 flash会把编译生成的烧录文件写入目标芯片。-j0表示不弹出 Keil 的 GUI 窗口全部在后台完成-o则把过程日志导出到指定文件。为什么用这个方案而不是自己拼编译命令核心原因是零成本迁移已有的 .uvprojx 工程文件直接就能用不需要新建构建规则。依赖处理很稳Keil 自己管理源文件依赖、头文件依赖、预编译头等改动工程后在 VS Code 里重新编译即可不会漏编译。下载算法不用重新配置烧录器型号、SWD/JTAG 接口、Flash 下载算法这些参数都存在工程文件里UV4 打开工程自然就知道该怎么做。1.3 整体工作流拆解配置完成之后的日常开发流程是在 VS Code 里打开工程目录先读代码、跳转定义、看 Git 改动。改完代码按快捷键CtrlShiftB调起编译任务后台跑 Keil 编译。编译日志输出到 VS Code 面板报错了直接双击跳转到源码对应行。编译通过后执行下载任务芯片跑起来后在串口工具或调试器里验证。整个过程Keil 窗口基本不会弹出。最理想的情况下Keil 仅仅作为后台引擎存在这正是我想要的体验。2. 环境准备与工具链梳理2.1 软件清单与版本说明在开始配置之前先把需要的软件列清楚。我的环境是 Windows 10 专业版用的是 Keil MDK版本从 5.27 到 5.38 都测过这套配置在这些版本上表现一致。清单如下VS Code版本无所谓保持最新就好C/C 扩展微软官方那个用于代码跳转和智能提示也可以用 clangd 替代后面细说Keil MDK安装时建议装到非中文、无空格的路径比如D:\Keil_v5对应的芯片支持包这个 Keil 会自己装通常不用额外操心要注意的是Keil 5 早期版本默认编译器是 ARMCCAC5新版本默认是 ARMCLANGAC6。对后面的配置来说这两者的差异主要体现在编译宏和语法标准上但 UV4.exe 这个外壳会把差异都消化掉所以不会影响我们在 VS Code 里的配置。2.2 确认 Keil 工具链路径配置前先确认三个路径UV4.exe 的路径一般在Keil安装目录\UV4\UV4.exe。编译器目录AC5 在Keil安装目录\ARM\ARMCCAC6 在Keil安装目录\ARM\ARMCLANG。设备支持包目录在Keil安装目录\ARM\PACK。这三个路径里UV4.exe 的路径必须记住后面配运行时要用编译器目录主要给 VS Code 的 C/C 插件做智能提示用设备支持包目录一般不需要手动配但你要做跨工程的头文件索引时可能用得上。2.3 给系统环境变量加一条 PATH为了让后面的命令行操作更省事我建议把UV4.exe所在目录加到系统 PATH 环境变量里。这样我在 VS Code 的任务里直接写UV4.exe就可以了不用每次写绝对路径。不过考虑到不同电脑上的环境可能不一样后面我提供的配置还是用绝对路径这样最稳妥别人的机器上复制过去也能直接用。提示Keil 默认装的是 64 位版本安装程序同时提供了 32 位版本选项。如果你在用某些老旧的第三方插件或者旧版烧录器驱动32 位版本兼容性会好些。我实测下来 64 位版本配 J-Link、ST-Link 都没问题一般不需要特意换。3. 让 VS Code 真正读懂 Keil 工程3.1 没有智能提示的编辑器是没有灵魂的在 VS Code 里打开 Keil 工程的文件夹默认状态下编辑器是不认识这个工程的。它不知道芯片型号、不晓得头文件在哪、不明白什么宏被定义了。这时候你打开一个.c文件会发现所有系统头文件全部标红跳转定义完全失效代码提示更是别想。要让 VS Code 的 C/C 扩展正确工作核心是配置一个叫c_cpp_properties.json的文件。这个文件定义了编译器路径、头文件搜索路径、宏定义等关键信息。它不参与实际编译但决定了代码编辑器里显示什么内容、能不能看懂代码。这个配置文件的生成方式有两种在 VS Code 里打开任意.c或.h文件会在右下角看到一个灯泡提示点击“编辑配置信息”。也可以手动在.vscode目录下创建c_cpp_properties.json。我把自己的配置贴出来你可以对照着理解{ version: 4, configurations: [ { name: KeilProject, includePath: [ ${workspaceFolder}/**, D:/Keil_v5/ARM/ARMCC/include, D:/Keil_v5/ARM/PACK/ARM/CMSIS/5.9.0/CMSIS/Core/Include ], defines: [ STM32F407xx, USE_HAL_DRIVER ], compilerPath: D:/Keil_v5/ARM/ARMCC/bin/armcc.exe, cStandard: c11, cppStandard: c17, intelliSenseMode: windows-gcc-x64 } ] }重点解释几个字段includePath这里写的是头文件的搜索路径。${workspaceFolder}/**表示工程目录下所有子目录。芯片厂商提供的标准外设库、HAL 库的头文件路径也要根据你工程的实际位置加进来。defines这里的宏必须和 Keil 工程里 C/C 选项卡中定义的宏一致。如果漏了芯片型号相关的宏很多条件编译的代码段就不会被识别你会看到大量代码被灰色折叠跳转也会失灵。compilerPath指定编译器路径后VS Code 会按这个编译器的标准解析语法和类型信息。AC5 就指向 armcc.exeAC6 则指向 armclang.exe。intelliSenseMode虽然 Keil 是 ARM 编译器但 Windows 上这个选项设置成windows-gcc-x64时C/C 扩展能正常工作。这是一个经验值不同版本可能需要微调。3.2 从 .uvprojx 里提取关键信息c_cpp_properties.json里的 includePath 和 defines 不会自动同步 Keil 工程。每次 Keil 工程里加了新的头文件路径或宏定义这边也得手动改。一种笨办法是打开.uvprojx文件用搜索功能找IncludePath和Define标签。.uvprojx本质是个 XML 文件源码都在里面。比如搜索Define你会看到类似这样的片段DefineSTM32F407xx,USE_HAL_DRIVER/Define把这个值复制到 VS Code 的配置里对应项就齐了。为了避免每次都要手动同步我写了一个简易的 Python 脚本解析.uvprojx里的 IncludePath、Define 和源文件列表然后自动生成c_cpp_properties.json的配置片段。这个脚本不需要完整解析所有内容只抽这三个关键字段就好。3.3 用 clangd 替代 C/C 扩展可选如果你觉得微软的 C/C 扩展在大型工程里提示有点慢可以试试 clangd。clangd 需要工程提供一个compile_commands.json文件来告知每个源文件的编译参数。由于 Keil 工程不想 CMake 那样天然生成这个文件你需要借助一个额外的转换工具从.uvprojx里提取信息并生成。我在一个中型工程上试过这个方案索引速度和代码补全准确率确实更高但配置成本也高不少。如果你是初学者建议先用微软的 C/C 扩展跑通整套流程之后再去尝 clangd。4. 配置一键编译tasks.json 详解4.1 UV4 命令行参数逐个拆解先把 UV4.exe 的命令行参数说透这样你改动起来心里才有底。Keil 的 UV4.exe 支持一套固定的命令行语法UV4.exe [-b|-f] 工程名 [-t 目标名] [-j0] [-o 日志文件] [-n]参数的含义如下-b编译模式退出时返回 0 表示编译成功返回非 0 表示失败。-f下载Flash模式会把编译生成的烧录文件写入芯片。-t 目标名如果你的工程里配置了多个目标比如 Debug 和 Release用这个参数指定编译哪个。-j0指定输出格式-j0表示纯文本日志适合重定向到文件。-o 文件路径把过程和结果日志写到文件里。-n禁止 GUI 窗口弹出。实际命令行是这样的D:\Keil_v5\UV4\UV4.exe -b C:\project\mcu.uvprojx -j0 -o C:\project\build_log.txt注意-b后面跟的是.uvprojx文件的完整路径。日志文件路径也要完整否则 UV4 会在当前目录乱找。4.2 编写 tasks.jsonVS Code 的任务系统本质上是把命令行程序挂到快捷键和命令面板上。我在.vscode目录下建了一个tasks.json内容如下{ version: 2.0.0, tasks: [ { label: Keil Build, type: shell, command: D:\\Keil_v5\\UV4\\UV4.exe, args: [ -b, ${workspaceFolder}\\my_project.uvprojx, -j0, -o, ${workspaceFolder}\\build_log.txt ], group: { kind: build, isDefault: true }, problemMatcher: [] } ] }重点看几个字段label任务名字显示在命令面板里可以随意起。typeshell表示通过命令行执行。commandUV4.exe 的完整路径注意反斜杠要写成\\。args命令行参数数组。group把任务绑定到CtrlShiftB。isDefault: true表示直接按快捷键就执行它不用再选。problemMatcher这个是错误解析器我暂时设为空数组后面专门讲怎么配。保存后按下CtrlShiftB底部应该会弹出终端面板显示 UV4 的编译日志。我实测过编译一个一百多个源文件的工程耗时在二十秒到三十秒左右和手动打开 Keil 编译差别不大。4.3 让编译错误在 VS Code 里跳转上面的配置能编译但编译报错之后你只能去build_log.txt里找错误位置再手动切回源文件。这个体验还是不够好。VS Code 的problemMatcher就是解决这个问题的。它负责从工具输出里扫描错误信息在“问题”面板里列出警告和错误位置信息能直接跳转到文件对应行列。Keil 的编译错误输出格式有下面几种path\file.c(12): error: #20: identifier xxx is undefined path\file.c(34): warning: #68-D: integer conversion resulted in a change of sign所以需要在tasks.json里加一个自定义 pattern。我把配好的内容贴出来你可以直接参考problemMatcher: { owner: keil, fileLocation: [relative, ${workspaceFolder}], pattern: { regexp: ^(.*)\\((\\d)\\):\\s(error|warning):\\s(.*)$, file: 1, line: 2, severity: 3, message: 4 } }这个正则要求编译输出严格符合文件路径(行号): 级别: 错误描述的格式。如果你是 AC5 编译器输出基本就是这样的AC6 的格式稍有不同我后面在问题排查里会讲怎么调。配置好之后再编译一次按CtrlShiftJ能直接呼出问题面板点一下错误就能跳到代码对应行效率提升非常明显。提示实际调试时如果发现一些错误没有被识别到不要急着改正则。可以先看一次完整的编译日志对照里面的每一条输出格式再调整regexp。另外你还可以给 pattern 加一个loop字段值为 true表示连续匹配多个错误。4.4 附加技巧设置环境变量避免日志乱码UV4 输出的日志文件默认编码是系统 ANSI 编码。如果你的源码路径或文件名包含中文日志里可能出现乱码。解决方案有两个在tasks.json里给任务加一个options字段指定编码。直接用 UTF-8 编码保存日志文件再看的时候就不会乱。我在国内开发环境里遇到中文路径的概率不小建议你直接用下面的配置options: { env: { PYTHONIOENCODING: utf-8 }, cwd: ${workspaceFolder} }另外尽量把工程路径放在纯英文目录下从根上避免潜在问题。5. 配置一键下载烧录也交给 VS Code5.1 UV4 下载命令的核心逻辑编译通过之后下一步是烧录。Keil 的下载功能封装了 J-Link、ST-Link、CMSIS-DAP 等烧录器的驱动以及芯片对应的 Flash 下载算法。这些信息全在工程文件和调试选项里配置好了不需要 VS Code 去关心。UV4 的下载命令参数如下UV4.exe -f 工程文件.uvprojx -j0 -o 下载日志.txt关键点是-f。它会重新编译一次然后执行“下载”操作。要注意的是UV4 的-f模式在下载前会先检查工程是否最新如果没有重新编译它会先生成一个新的烧录文件再下载。5.2 把下载任务集成到 tasks.json在上面的tasks.json里加一个新任务即可。这里我写一个实际用过的例子{ label: Keil Flash, type: shell, command: D:\\Keil_v5\\UV4\\UV4.exe, args: [ -f, ${workspaceFolder}\\my_project.uvprojx, -j0, -o, ${workspaceFolder}\\flash_log.txt ], problemMatcher: [], group: build }配置完成后打开命令面板CtrlShiftP输入task就能看到“Keil Flash”回车执行。也可以自己在 keybindings.json 里绑快捷键我绑的是CtrlShiftF9用惯了效率不比 Keil 里的 Download 按钮慢。5.3 烧录日志怎么看执行下载任务后终端里打印的日志长这样Build started: Project: my_project *** Using Compiler V5.06 update 7 (build 960), folder: D:\Keil_v5\ARM\ARMCC Build Target Target 1 linking... Program Size: Code28616 RO-data2504 RW-data252 ZI-data6144 FromELF: creating hex file... .\Objects\my_project.axf - 0 Error(s), 0 Warning(s). Load .\Objects\my_project.axf Flash Load: 84.0 KBytes Programming Done. Verify OK. Application running.倒数第二行的Programming Done.和最后一行Application running.是我判断烧录成功的标志。如果中间出现Wrong Device ID或Cannot access target说明烧录器连接有问题排查方向是线缆、目标板供电和烧录器驱动。5.4 下载前的关键检查项用这个方案烧录有些细节要提前确认Keil 工程里的调试器配置必须是可用的。从 VS Code 触发下载和从 Keil 点击下载底层用的是同一套配置不会因为换了个入口就自动调整。第一次使用前建议先在 Keil 里手动点一次 Download确认无误再切到 VS Code。Check 选项如果 Keil 工程里勾选了“Download to Flash”和“Reset and Run”那下载完成后芯片会自动复位运行。如果你没勾“Reset and Run”程序是写进 Flash 了但不会自动跑。日志文件路径必须可写。UV4 在某些特殊目录下比如 Program Files 下可能会因为权限问题无法创建日志文件到时候你会看到命令执行成功但日志是空的。解决办法是给日志指定到工作区目录下。注意UV4.exe 执行下载时不会自动选择一个目标设备如果一个工程里配置了多个目标建议在 Keil 里把常用目标设为 Active Target。或者也可以在命令行里加-t 目标名来指定避免下载到错误的目标。我吃过这个亏当时工程里保留了一个参考用的旧目标结果点了下载却把旧固件烧进去了排查了半天才发现是目标选错。6. 常见问题与排查技巧实录6.1 智能提示正常但一编译就报错这个现象很典型VS Code 里没有标红代码跳转也正常结果一点编译就报“cannot open source file xxx.h”。原因通常是c_cpp_properties.json里的 includePath 和 Keil 工程里的头文件路径不一致。VS Code 的智能提示能搜到头文件并不代表 Keil 编译时也能搜到因为 Keil 有自己的一套头文件路径配置。解决办法是对齐两边。在 Keil 的魔术棒Options for Target- C/C - Include Paths 里看看实际路径是什么确保c_cpp_properties.json包含了同样的路径。还有一种情况是编译依赖某些芯片标准库头文件这些路径在 Keil 里是相对路径搬到 VS Code 配置时要转成工作区相对路径或绝对路径。6.2 AC5 与 AC6 的错误输出格式差异如果你用的是 AC6ARMCLANG编译器UV4 的错误输出可能长这样path\file.c:12: error: use of undeclared identifier xxx path\file.c:34: warning: unused variable yyy它把文件名和行号分开了和 AC5 的文件路径(行号)格式不同。这时problemMatcher的正则需要改成regexp: ^(.*):(\\d):\\s(error|warning):\\s(.*)$本质区别在于括号位置AC5 的格式是file(line)AC6 是file:line。如果你在 Keil 里切换了编译器版本记得同步调整 problemMatcher。6.3 UV4 编译成功但返回非零状态码按CtrlShiftB跑完终端显示编译成功没有错误但任务图标显示失败。这是因为 UV4 在某些情况下比如有警告但没错误返回值不是 0。这不是致命的但会干扰你的判断。解决方式有两个忽略返回码把 tasks 的presentation配置改成reveal: never这样就算任务显示失败也不会一直弹终端。查看build_log.txt末尾的 “0 Error(s), 0 Warning(s)”以这个为准判断成功。我的习惯是两件事都做任务配置里放宽返回码的提示但日志文件始终保留方便出问题时候翻。6.4 源文件新增后没有自动出现在编译列表里Keil 的工程文件记录了源文件列表如果你在 VS Code 里新建了一个.c文件但忘记在 Keil 工程里添加它编译时会提示 undefined symbol 或者根本不包含这个文件。这是“VS Code 编辑 Keil 编译”方案的经典陷阱。Keil 不会自动扫描目录新增文件工程文件是固定的。解决办法有每次新建源文件后去 Keil 里把它加到工程树里。或者反过来在 Keil 里建文件用 VS Code 改代码。进阶方案是写一个脚本解析.uvprojx自动把目录里的新.c文件追加进去这样能实现“伪自动添加”。我当时在一个复用性较强的工程模板里这么干过效果还不错。提醒一点.uvprojx改动后如果 VS Code 和 Keil 同时开着建议先把 VS Code 里的相关文件关了再让 Keil 刷新避免文件锁冲突。6.5 中文路径导致的编译和下载失败我做过一次实验把同一个工程复制到含中文的目录下比如D:\项目备份\mcu在 VS Code 里能正常打开但编译时 UV4 报了一堆预处理错误。后来确认是 UV4 对中文路径支持不完善某些版本会直接崩。建议是工程目录用纯英文路径里不要带空格不要带中文。如果你的工程已经在中文目录里能迁移就迁移迁移不了至少也要保证c_cpp_properties.json里所有路径都转成了正确的编码格式。大部分情况下迁移到英文目录后问题会自动消失。6.6 编译日志乱码且错误跳转失效我前面提过编码问题这里再细化一下。UV4 在简体中文系统上输出 GBK 编码文本VS Code 内部按 UTF-8 解析所以匹配不到。解决办法是在任务配置里加一条环境变量让输出编码统一到 UTF-8。还有一个更稳的土办法不用任务输出面板直接打开build_log.txt看日志。VS Code 能用“打开方式”以 UTF-8 或 GBK 方式重新加载文件日志文件总归不会丢。如果你希望一劳永逸可以顺手把 VS Code 的files.encoding设置为gbk并在工作区里为日志文件单独配置files.encoding: utf8。我自己做过类似组合这样可以兼顾大多数场景。6.7 使用 git 时产生的 .uvprojx 冲突这个话题严格说不是 VS Code 专属问题但在 VS Code 环境里很容易被放大。.uvprojx里记录了源文件列表、编译选项、调试配置等信息多人协作时一个不小心“优化了一个编译选项”就会导致整个文件 diff 变得很大。我的建议是不要轻易格式化或自动编辑 .uvprojx。如果确实需要加源文件、加宏定义尽量通过 Keil 界面操作。遇到冲突时优先通过文本对比手动合结合。你在 VS Code 里用内置的合并编辑器处理.uvprojx冲突是可行的但要看仔细别把编译选项合并丢了。6.8 多目标工程编译目标选择如果你的 Keil 工程里有多个目标比如一个 Debug、一个 Release默认编译的是当前激活目标。在 VS Code 命令行编译时可以通过-t参数指定UV4.exe -b 工程.uvprojx -t Debug -j0 -o debug_log.txt UV4.exe -b 工程.uvprojx -t Release -j0 -o release_log.txt这在实际项目里非常有用。我之前维护过一个低功耗设备项目同样的源码一个目标跑的是完整调试功能另一个目标裁剪了很多模块通过-t就能在 VS Code 里分任务编译不用每次切 Keil 里的 Active Target。7. 额外几个能提升幸福感的小配置7.1 格式化代码Keil 的编辑器格式化能力几乎为零。在 VS Code 里给工程配上格式化工具可以让代码风格统一。C 语言用的比较多的是 clang-format装上之后在.clang-format文件里写一点规则然后保存时自动格式化。要注意的是有些嵌入式工程里的代码是芯片厂商生成的比如各厂商的 HAL 库它们的缩进风格五花八门。如果保存时全量格式化会导致 Maga 级别的 diff 噪声。我的做法是只对工程目录下自己写的业务代码启用格式化对库文件目录忽略参考配置如下[c]: { editor.formatOnSave: true, editor.defaultFormatter: xaver.clang-format }同时在设置里把厂商库目录加到files.exclude和search.exclude这样既不影响浏览也不会被意外格式化。7.2 文件搜索与文件图标Keil 工程里通常有很多.h、.c文件配合 VS Code 的CtrlP文件搜索比在 Keil 的工程树里翻文件夹快太多了。强烈建议开启 VS Code 的“文件图标主题”把.uvprojx和.uvoptx的图标设置成可识别样式扫一眼就知道哪个是工程文件。也可以在.vscode/settings.json里加一段files.associations: { *.uvprojx: xml, *.uvoptx: xml, *.sct: linker-script }这样.uvprojx会按 XML 语法高亮.sct文件也能有基本的颜色区分阅读起来舒服很多。7.3 一体化终端VS Code 里可以开一个内置终端切到 Keil 工程目录直接用命令行做一些辅助操作。比如手动调 UV4 的-t参数编译特定目标或者跑脚本处理日志都很顺手。我经常在 VS Code 终端里跑命令cd D:\project\mcu $env:UV4D:\Keil_v5\UV4\UV4.exe $env:UV4 -b mcu.uvprojx -j0 -o last_build.log这样脱离任务面板也能快速验证编译命令是否正确方便调试 tasks.json 的改动。7.4 自动保存 自动编译如果你习惯改完代码立刻接编译任务建议把 VS Code 的自动保存打开默认情况下切窗口或关闭标签页时会自动保存。这样编译时使用的始终是最新的代码不会出现那种“我改了代码但编译的还是旧版本”的诡异问题。至于要不要做“保存后自动编译”我建议谨慎。嵌入式的编译比网页开发耗时多保存后立刻编译会频繁打断思路。我个人的用法是手动编译配合快捷键控制在合适的频次。8. 关于这套方案的一些额外心得跑了一年多这套方案之后我得说它并不是银弹。有些场景下仍然需要打开 Keil比如在线仿真调试断点、变量观察、寄存器查看Keil 的调试器集成度不是 VS Code 能替代的还有第一次配置烧录算法时也需要在 Keil 里点。但日常开发中最耗时间的部分其实不是调试而是看代码、改代码、查资料、跑构建。这几个环节在 VS Code 里的体验优势非常明显尤其是面对那种历史包袱重、老代码多的工程VS Code 的多光标、搜索、Git 集成能让你省下不少时间。根据个人经验这套配置最适合以下场景团队主要用 Keil 做开发但个人希望提升编码体验的开发者。工程规模中等偏上头文件多、模块多的项目。需要频繁对比代码、梳理逻辑、做代码审查的人VS Code 的 Git 插件比 Keil 里的 Git 集成好用太多。如果你只是偶尔改个小 demo或者还在学习 Keil 本身那还是先把手动编译下载跑熟再说。要是你已经具备一定基础又对这种“编辑器替换”的玩法感兴趣不妨从 c_cpp_properties.json 和 tasks.json 开始花一下午把它配好。配置好之后你会发现自己写代码和编译之间的手感会有一个明显的提升。如果配置过程中遇到问题欢迎按我文章里提到的排查思路来查如果试出了更好的方案也欢迎一起交流。工具本来就是用来改善效率的合适就好。