做嵌入式开发的朋友，应该都懂那种“改一行代码，等半分钟编译光标还在转圈”的滋味。Keil5作为ARM生态最经典的IDE，稳定是稳定，但那个编辑器体验确实是停留在上上个时代——代码一多就卡成PPT，函数跳转时灵时不灵，更别提什么代码补全和格式化。我自己的主力电脑还是老款i5，每次打开稍微大一点的工程，风扇就开始飙，说实话挺影响心情的。
后来实在忍不了，我试着把编辑部分迁移到了VSCode上，配合Keil Assistant插件做编译和下载的桥接。实际用了两个多月，把手上两个量产维护项目和三个正在开发的工程都迁过来了。今天这篇就把整套配置过程、原理、还有我踩过的坑整理出来，给同样受Keil5折磨的朋友一个参考。
这套方案适合谁？简单说：要继续用Keil的编译器和工程管理，但想让编辑器更像现代IDE的人。不适合谁？如果你对Keil已经熟到闭眼操作、也不在乎编辑器体验，那没必要折腾。但如果你每次写代码都觉得“哪里不对”，那这套组合真的值得试一次。
1. 为什么我决定把Keil5换成VSCode+Keil Assistant
1.1 Keil5到底难用在哪
先说痛点。Keil5最大的问题不是功能不够，而是编辑器体验严重拖后腿。
第一个痛点是卡。工程稍微大一点，比如包含标准外设库的STM32F1项目，打开源文件要加载半天，滚动代码都有迟滞感。如果装了多个芯片包，启动时更是得等交互界面完全就绪才能操作。编代码的时候代码补全弹窗偶尔会闪一下，大部分时间根本不出来，写程序基本靠手速和记忆。
第二个痛点是代码阅读能力太弱。Keil5的函数跳转有时候能跳，有时候跳不过去，遇到带条件编译的代码段更是经常“找不到定义”。Ctrl+F搜索全工程，扫出来的是一堆二进制和HAL库源码，你得自己一点一点筛。想看清楚一个函数被谁调用了，不好意思，Keil没这个功能。
第三个痛点是UI和现代工具脱节。快捷键体系老旧，很难自定义；主题就那几种，代码高亮配色看得眼睛疼；Git这类版本控制工具，在Keil里基本是裸奔状态，我得来回切SourceTree和文件夹。时间久了，写代码的效率跟用记事本其实差不了太多。
1.2 对比过的几个方案，为什么最后是它
我大概花了一个周末去研究替代方案，在放弃之前，整理过这么几条路线：
方案A：VSCode + Makefile + GCC工具链。这条路最“正道”，完全脱离Keil，用arm-none-eabi-gcc编译STM32工程。我拿小工程试了一下，发现整理启动文件、链接脚本、Makefile要花不少时间，而且一旦遇到芯片厂商某些私有库，兼容性问题就开始冒出来。最关键的是，公司项目里有人还在用Keil维护，我如果用GCC整套环境，跟别人协作时就特别别扭。
方案B：VSCode + EIDE插件。EIDE其实也很强，可以在VSCode里重新组织工程结构、调用Keil编译器、甚至烧录调试。但它最大的问题是：EIDE有自己的工程管理方式，需要把Keil工程导入或手工重建，对老工程和多人协作来说有迁移成本。而且EIDE的配置项更多，新手容易在“工程文件夹、构建配置、输出路径”这些地方绕晕。
方案C：VSCode + Tasks直接调用UV4命令行。这个思路本质上是对的，因为Keil提供了UV4.exe的命令行接口，可以在终端里直接编译工程。我试过自己写task.json调用，能编译能输出，但每次都要自己处理错误信息格式、文件路径、退出码判断，而且没有一键烧录，用起来还是不够顺手。
方案D：VSCode + Keil Assistant插件。这个插件的思路是：直接解析Keil的.uvprojx工程文件，然后把Keil的UV4命令行包装成VSCode里的Build、Flash、Debug按钮。等于说，工程管理和编译核心还是Keil，VSCode只管编辑和交互。它的优势在于：不需要改动现有工程结构、不需要重新配置编译器路径、团队成员可以继续用Keil、只有你自己用VSCode也不会互相干扰。
我最后选了方案D，主要看中的就是“兼容现有Keil工程”这一点。对于已经跑了好几年的产品代码，完全重构工具链风险太高，能用最低成本把编辑器换掉，已经解决了我80%的痛点。
1.3 Keil Assistant插件的工作原理
搞懂了原理，后面配置就不会一头雾水。Keil Assistant做的事情其实不复杂：它读取.uvprojx工程文件，解析出目标芯片型号、源文件列表、编译选项、输出路径等信息，然后调用Keil的UV4.exe在后台完成编译和下载动作。
我用个小表格概括一下：
| 操作 | 实际执行的底层命令 | 说明 |
|---|---|---|
| Build/Rebuild | UV4.exe -r 工程.uvprojx -o 输出.txt | 编译并生成结果文本 |
| Flash下载 | UV4.exe -f 工程.uvprojx -t 目标名 | 调用Keil配置的烧录器下载程序 |
| Debug | 直接打开UV4.exe加载工程 | 在Keil里进行在线调试 |
搞清楚这个关系非常重要。它意味着Keil Assistant并不是一个独立的编译器，也不是对Keil的替代品。Keil5本身还是要装好、要能正常编译，插件只是把VSCode变成了一个“遥控器”。
2. 环境准备与前置检查
2.1 Keil5安装时的几个关键细节
很多人在Keil5装完后才发现在VSCode里打不开工程，其实是Keil侧的安装本身就留了坑。
第一个是安装路径。Keil5默认装到C盘，我没有改，但强烈建议不要使用带空格的路径，更不要用中文路径。比如D:\Program Files (x86)\Keil_v5这种路径，虽然多数时候能跑，但某些命令行参数传递时可能会出问题。我见过有人装在“D:\开发工具\Keil5”下面，结果C/C++插件的includePath怎么配都报错，最后把路径改掉重装才解决。
第二个是芯片支持包。Keil5刚装完只带了一部分ARM基础包，具体芯片型号需要额外安装DFP（Device Family Pack）。你在VSCode里打开工程后，如果插件报错说找不到“STM32F103”，大概率就是Keil5里没有装对应芯片包。
打开Keil5的Pack Installer，找到你要用的芯片厂商（比如STMicroelectronics），安装对应系列的支持包。注意如果公司项目用了较老的型号，建议在Pack Installer里勾上“Use latest versions of all installed Packs”并按需安装，不一定要追最新版本，但至少要有匹配的版本。
第三个是Keil工程格式。刚才提过，Keil Assistant只认.uvprojx，这是MDK5的项目文件格式。如果你打开的工程是.uvproj（Keil4老格式），先用Keil5打开并另存一下，转换成新版格式再操作。
2.2 VSCode安装与必备扩展
VSCode的安装没什么好说的，官网下载安装包、一路Next就行。需要注意的是，VSCode是用户级应用，不需要管理员权限，这点对办公电脑特别友好。
装完后先装两个基础扩展：
- C/C++，微软官方那个，提供IntelliSense、代码导航、调试支持，是最核心的扩展。
- Keil Assistant，这是本文主角。在扩展市场搜“Keil Assistant”，作者是CLAUDE的版本是社区里最常用的。安装后重启一下VSCode。
额外推荐顺手装上中文语言包（Chinese (Simplified)），把界面切成中文，对不熟悉英文菜单的朋友会友好很多。
这里有个细节：VSCode的版本不要追太老。我记得有一段时间Keil Assistant插件在旧版VSCode上会加载失败，如果你遇到插件装完没反应，先看看VSCode是不是太久没更新了。另外，如果你公司电脑有安全软件拦截扩展下载，需要在防火墙里放行VSCode的网络权限。
2.3 动手配置前，先验证UV4命令行是否可用
这一步非常关键，却经常被人跳过。Keil Assistant的编译和烧录都是通过UV4.exe完成的，如果Keil侧面有问题，在VSCode里再怎么调插件都没用。
验证方法很简单。先找到UV4.exe的路径，一般是C:\Keil_v5\UV4\UV4.exe。然后打开命令行（Win+R输入cmd回车），执行：
"C:\Keil_v5\UV4\UV4.exe" -h如果Keil安装正常，命令行会输出UV4的用法说明。如果提示找不到文件，说明Keil的安装路径不对或者UV4主程序没装好，需要先回到Keil5修复环境。
更进一步的验证是直接命令行编译一个测试工程。找一个你能正常用Keil打开的.uvprojx文件（假设放在D:\project\demo.uvprojx），执行：
"C:\Keil_v5\UV4\UV4.exe" -b "D:\project\demo.uvprojx" -o "D:\project\build_log.txt"然后打开build_log.txt，能看到跟Keil界面里一样的编译输出信息。如果这一步顺利，后面在VSCode里的操作基本就是顺水推舟了。
3. Keil Assistant配置实战：从安装到一键编译烧录
3.1 安装插件并打开Keil工程
打开VSCode，进入扩展面板（Ctrl+Shift+X），搜索“Keil Assistant”，点击安装。安装完成后右下角通常会提示重新加载窗口。
重启完之后，有两种方式打开Keil工程：
方式一：命令面板按Ctrl+Shift+P打开命令面板，输入“Keil”，会看到“Keil: Open with Keil Assistant”命令。回车，然后在文件选择框里定位到你的.uvprojx文件。
方式二：右键菜单在VSCode资源管理器里找到.uvprojx文件，直接右键，菜单里会有“Open with Keil Assistant”选项，点击即可。
打开成功后，VSCode底部状态栏或者侧边栏会出现一个Keil的图标/按钮组，里面有Build、Rebuild、Flash、Debug等操作。这一步就说明插件已经成功解析了工程。
这里有个容易踩的坑：打开.uvprojx之前，先确保这个工程在Keil5里能正常编译。如果你拿一个本身就有编译错误的工程来试，插件打开后虽然会展示界面，但第一次Build就会报一堆错误，你很难分清是插件配置问题还是工程本身的问题。我建议拿一个干净的、确定能编译通过的工程来走通整个流程。
3.2 配置UV4路径的两种方法
插件第一次使用，通常需要告诉它UV4.exe在哪。具体有两种配置方式：
方式一：界面设置打开VSCode设置（Ctrl+,），在搜索框输入“keil”，找到“Keil: UV4 Path”选项，填入UV4.exe的完整路径。比如：
C:\Keil_v5\UV4\UV4.exe方式二：直接编辑settings.json
按Ctrl+Shift+P输入“Open User Settings (JSON)”，在配置文件中加上：
{ "keil.UV4Path": "C:\\Keil_v5\\UV4\\UV4.exe" }需要注意，JSON文件里Windows路径的反斜杠要写成双反斜杠\\，否则解析会出错。如果你不确定路径写没写对，可以按住Ctrl键点击路径里的“UV4.exe”文字，VSCode会帮你验证文件是否存在。
还有一个细节：如果你同时装了Keil5的C51版和MDK版，UV4Path要指到MDK版那个目录，因为ARM工程需要的是ARM编译器（armcc/armclang），C51版是给51单片机用的，两者工具链不一样。网上有些朋友在“keil5兼容c51和stm32安装”时把两个版本都装了，结果UV4Path指到了C51那边，自然编译不了ARM工程。
3.3 配置C/C++的includePath和defines，彻底解决跳转和补全
插件能编译了，但VSCode对代码的智能提示、跳转、补全，还需要单独配置C/C++扩展。这是整个配置过程中最费时的一步，也是最有回报的一步——配好了，代码阅读体验直接起飞。
在VSCode命令面板输入“C/C++: Edit Configurations (UI)”，会打开一个可视化配置界面。也可以直接在工作区里生成.vscode/c_cpp_properties.json文件。我直接给出一个经过验证的配置模板：
{ "configurations": [ { "name": "STM32", "includePath": [ "${workspaceFolder}/**", "C:/Keil_v5/ARM/ARMCC/include", "C:/Keil_v5/ARM/PACK/ARM/CMSIS/**", "C:/Keil_v5/ARM/PACK/Keil/STM32F1xx_DFP/**" ], "defines": [ "STM32F103xE", "USE_STDPERIPH_DRIVER" ], "compilerPath": "C:/Keil_v5/ARM/ARMCC/bin/armcc.exe", "cStandard": "c11", "cppStandard": "c++17", "intelliSenseMode": "windows-gcc-x64" } ], "version": 4 }我记得刚开始配置的时候，最迷糊的地方在于includePath到底要包含哪些目录。其实本质就一句话：要让VSCode找到你代码里所有#include的头文件。
可以分这么几类：
- 工程自身目录：用
${workspaceFolder}/**通配符递归匹配，覆盖自己写的头文件和源文件。 - 编译器自带头文件：比如
C:\Keil_v5\ARM\ARMCC\include，这是ARMCC编译器自带的C标准库头文件，像string.h、stdio.h这些。 - CMSIS头文件：一般在
C:\Keil_v5\ARM\PACK\ARM\CMSIS\**目录下，负责Cortex-M内核的寄存器定义和系统函数。 - 芯片厂商DFP头文件：比如STM32F1的包在
C:\Keil_v5\ARM\PACK\Keil\STM32F1xx_DFP\**（不同版本可能路径稍有差异），这里面有stm32f10x.h等元器件级定义。 - 标准外设库头文件：如果你的工程用了标准库（SPL），需要把库文件里的
inc目录手动加进来。比如D:/project/STM32F10x_StdPeriph_Driver/inc。
defines的配置要和Keil工程里的设置保持一致。在Keil5中，Options for Target → C/C++选项卡的Preprocessor Symbols里能看到类似STM32F103xE, USE_STDPERIPH_DRIVER这样的宏定义。这些宏会影响头文件里的条件编译，如果漏了某个宏，代码导航就会跳到错误的分支去，看起来很诡异。
我做个对照说明：
| 配置项 | 作用 | 常见错误 |
|---|---|---|
| includePath | 让VSCode找到头文件 | 漏配芯片DFP路径导致“cannot open source input file” |
| defines | 匹配工程的条件编译宏 | 漏配STM32F103xE导致寄存器定义都失效 |
| compilerPath | 让VSCode模拟该编译器的语法规则 | 路径指错导致IntelliSense全失效 |
| intelliSenseMode | 设置IntelliSense的语言模式 | 用msvc模式解析ARM代码会报奇怪错误 |
macOS上如果没装clangd等工具，就保持windows-gcc-x64默认即可。Windows平台下最稳妥。
配置完成后，保存文件，VSCode会重新解析整个工程。第一次解析可能需要几十秒，之后再做代码跳转和补全就会明显变顺。如果还是不行，按Ctrl+Shift+P执行“C/C++: Reset IntelliSense Database”，清掉缓存重新解析一次。
3.4 一键Build、Flash、Debug的完整流程
配置完成后，整个工作流是这样的：
日常写代码的阶段，直接用VSCode编辑源码，代码补全、语法高亮、函数跳转、格式检查都交给C/C++扩展。
需要编译的时候，点击Keil Assistant插件面板上的Build按钮。编译过程中，VSCode底部会弹出任务输出窗口，实时显示编译日志。如果编译报错，在输出面板里点击错误信息，VSCode会直接跳到源码出错的那一行。这个体验比Keil好太多，Keil里点击错误信息虽然也能跳，但偶尔会跳错行号，VSCode这边基本是准的。
编译通过后，接上调试器（ST-Link、J-Link这类），点击Flash按钮，插件会调用Keil的下载逻辑，把生成的hex或axf文件烧录到芯片里。我试过ST-Link和J-Link，都能正常烧录。前提是Keil工程里已经把烧录器配置好了。
如果需要在线调试、设断点、看寄存器，点击Debug按钮，Keil Assistant会直接拉起UV4.exe打开当前工程。也就是说，调试环节还是离不开Keil的窗口，毕竟VSCode这边并没有做调试器的底层对接。这一步挺重要，别到时候点了个Debug按钮发现什么反应都没有，误以为插件坏了。
我实际使用中的感受是：日常90%的编码和编译操作已经不需要打开Keil了，只有调试、设置烧录选项、查看反汇编时才会切回Keil窗口。VSCode这边的任务面板加源代码文件，基本上把“写代码”这件事彻底现代化了。
4. 打造更顺手的编辑器体验：编码、Git、快捷键配套
4.1 中文注释乱码的根源与两种解决方案
VSCode默认用UTF-8编码读写文件，但Keil5创建的老工程文件，中文注释通常是GBK/GB2312编码。你辛辛苦苦配好环境，打开工程一看，源码里的中文注释全变成“锟斤拷”了，代码没毛病，但满屏乱码真的让人崩溃。
解决办法有两个方向：
方向一：跟随旧工程，用GBK解读文件在VSCode右下角状态栏找到“UTF-8”字样，点击它，选择“通过编码重新打开”，然后选择“GBK”或“GB2312”。也可以直接改设置：
{ "files.encoding": "gbk" }把全局或工作区编码设为GBK后，旧工程的中文注释就能正常显示了。这个方案对老工程最省事，不用改任何文件内容，风险最低。
方向二：统一转存为UTF-8如果你的工程是你自己控制的，建议趁早把所有源文件统一转成UTF-8。方法是用VSCode打开所有源文件，右下角编码改为“通过编码保存”，选择UTF-8，保存。保存完之后，记得同步去Keil5里调整设置：Edit → Configuration → Encoding里改成UTF-8。这样两边都统一成UTF-8，以后不管用哪个环境打开都不会乱码。
这块我要特别提醒一句：转换编码之前先备份，或者用Git提交一版。因为编码转换是全局操作，万一某个文件里用了非ASCII字符的字符串字面量，转换后有些字节会被重新编码，可能导致字符串内容看起来对但实际显示变了。我踩过一次这个坑，后来学乖了，转之前先提交一个“转换编码”分支，出问题直接回退。
4.2 Git、Better Comments、EditorConfig这些配套工具
嵌入式工程同样需要版本控制。Keil里没有Git集成，VSCode这边天然支持Git，只需要装一下Git for Windows，然后在扩展市场搜索GitLens安装，就能在VSCode里看每一行代码的提交信息。这个功能在排查“这段代码谁改的、为什么改”时非常好用。
Better Comments这个扩展，能让你用不同颜色区分普通注释、待办、警告信息。比如我用// !标注意特别注意项，用// ?标记待确认问题，看起来非常直观。
EditorConfig可以统一不同成员的缩进风格。嵌入式项目最常见的坑是有人用Tab、有人用空格，还有人Tab宽度不一样，打开别人代码全是锯齿。在工程根目录放一个.editorconfig，里面规定indent_style = space、indent_size = 4，配合VSCode的“检测缩进”功能，大部分格式混乱都能避免。
其他值得装的还包括：
- Hex Editor：查看生成的hex或bin文件，自带十六进制视图。
- Cortex-Debug：如果你后续想深入做J-Link调试，这个扩展能在VSCode里直接调GDB调试ARM芯片，不过配置门槛稍高，我暂时还没完全用起来。
- vscode-icons：让工程目录里的文件有对应图标，尤其是.uvprojx、.c、.h文件能一眼区分，看着舒服。
4.3 设置工作区快捷键与任务命令
VSCode里编译和烧录都有对应命令，可以在键盘快捷键设置里绑定到顺手的位置。我把Build绑定到Ctrl+Shift+B，Flash绑定到Ctrl+Shift+D（虽然和内置调试快捷键有些冲突，但习惯了就还好）。这样手指不用离开键盘就能完成“改代码→编译→烧录”的循环。
如果你想让配置文件更可控，可以手动建立VSCode的Tasks。按Ctrl+Shift+P输入“Tasks: Open User Tasks”，可以自己写一个调用UV4的构建任务。这算是进阶用法，适合想彻底掌控编译输出格式的场景。
举个例子，一个简单的task.json这样写：
{ "version": "2.0.0", "tasks": [ { "label": "Keil Build", "type": "shell", "command": "C:/Keil_v5/UV4/UV4.exe", "args": ["-r", "${workspaceFolder}/demo.uvprojx", "-o", "${workspaceFolder}/build_log.txt"], "problemMatcher": [] } ] }这样可以在VSCode里直接用Tasks的快捷键触发Keil的命令行编译。不过既然装了Keil Assistant，大部分场景下不需要再手动写task，了解原理就好，等哪天插件不维护了，你还能有自己的备用方案。
5. 避坑指南：配置和日常使用中最常见的几个问题
5.1 编译失败：头文件找不到，宏定义缺失
症状：点击Build之后，输出面板里出现大段“cannot open source input file ‘stm32f10x.h’: No such file or directory”或者一个文件里蹦出几百个“identifier is undefined”错误。
原因多半是includePath没有包含芯片DFP或者库函数的头文件目录。我在配置过程中，发现很多人只加了${workspaceFolder}/**，忘了加Keil安装目录下的CMSIS和DFP路径，结果工程自己的头文件能找到，但芯片寄存器定义全都找不到。
处理方式。
- 在VSCode命令面板执行“C/C++: Edit Configurations (JSON)”，确认c_cpp_properties.json里的includePath是否有类似这样的条目：
"C:/Keil_v5/ARM/PACK/**", "C:/Keil_v5/ARM/ARMCC/include"如果你的工程用了标准外设库，把库的inc目录手动加进去。
执行“C/C++: Reset IntelliSense Database”重置索引。
这种方法对“跳转失败”也有效。有时候VSCode的IntelliSense数据库缓存了旧的路径信息，重置一次就正常了。
5.2 显示问题：函数跳转偶尔会跳错版本
同一个函数名在代码里出现多个定义的情况很常见。在HAL库和老标准库混用的情况下，跳转经常跳到你不想要的那个定义。VSCode的“Go to Definition”有时会列出所有候选定义让你选，有时则直接跳到第一个匹配项。
我建议做法是：在配置工程时，只把当前工程实际用到的库加入includePath，不要图省事把整个磁盘的Keil包全加进来。比如你用的是标准外设库，就不要把HAL库的目录也加进来，否则同名冲突会让你怀疑人生。
还有一个办法是：右键点击需要跳转的函数名，选择“Go to Type Definition”或者“Peek Definition”（预览窗口），这样不用离开当前文件就能确认是不是你要找的那个。
5.3 烧录和调试问题：Flash按钮点了没反应
症状：点击Flash按钮，VSCode输出面板什么都没显示，或者显示“no target connected”之类的错误。
这个问题的根源，我排查过好几个工程，最后基本都是Keil工程里的烧录配置没设置好。Keil Assistant的Flash只是“按下Keil里的Download按钮”，它不会帮你设置烧录器。你需要先在Keil5里手动打开工程：
Options for Target → Debug → Settings，选择正确的调试器（ST-Link/J-Link/CMSIS-DAP），确认能读到设备ID；再切到Utilities选项卡，勾选“Use Debug Driver”，并确认Flash Download里的编程算法（Flash Algorithm）选对了你的芯片。
配好之后保存工程，回到VSCode再点Flash，基本就能烧了。如果你用的是一块自己画的板子，没有板载调试器，特别注意下调试器连接甚至还有供电问题。
另外有一种情况：Keil里编译生成了.axf文件，但没勾选生成.hex文件。有些烧录器/引导程序只认hex格式，如果Flash烧录后板子没反应，先回Keil里看看Output选项卡是否勾了“Create HEX File”。这个细节藏在Keil的设置里，不看不知道，看了之后好多“烧录失败”都是这个原因。
5.4 常见问题速查表
| 症状 | 可能原因 | 处理方式 |
|---|---|---|
| VSCode中文注释乱码 | 文件编码是GBK，VSCode默认UTF-8读取 | 右下角改为“通过编码重新打开”，选GBK |
| 编译报“cannot open source input file” | includePath缺少库/DFP路径 | 打开c_cpp_properties.json，补全路径 |
| 函数跳转/补全没反应 | IntelliSense数据库失效或编译器路径错误 | 执行“C/C++: Reset IntelliSense Database” |
| Build按钮是灰色不可点 | 没有用Keil Assistant打开.uvprojx工程 | 重新用“Open with Keil Assistant”打开工程 |
| 编译成功后没有生成hex文件 | Keil工程未勾选“Create HEX File” | Keil里Output选项卡勾选对应选项并保存 |
| Flash烧录失败或没反应 | Keil的烧录器/Utility配置有问题 | 回Keil里配置Debug和Utilities，确认能连接目标板 |
| 点击Debug按钮只打开了Keil没调试 | 插件本身只负责拉起Keil，不接调试 | 在Keil里手动创建调试会话 |
| VSCode里Terminal执行UV4命令乱码 | 终端编码与Keil输出编码不一致 | 在终端里执行chcp 65001切换UTF-8代码页，或保留GBK |
| 打开老.uvproj工程失败 | 工程格式是Keil4老格式 | 用Keil5打开并另存为.uvprojx格式 |
| 插件安装后没有出现Keil面板 | 插件版本或VSCode版本过旧 | 升级VSCode到最新版，重装插件，重启窗口 |
5.5 性能优化：大工程卡顿还能再压一压
刚才说的都是功能性问题，还有一个我很想拿出来单独聊的：编译速度和VSCode本身卡顿。
先说编译速度。Keil Assistant并不改变编译速度，因为实际编译还是UV4在做。如果你觉得Build太慢，可以试试只在Keil工程配置里把优化等级降低，或者把编译输出信息等级调成“No Browse Info”（少生成一些浏览信息）。ARMCC/ARMCLANG在生成浏览信息时确实会拖慢速度，如果不需要在Keil里看函数调用树，关掉能快一些。
再说VSCode本身的卡顿。大工程下，C/C++扩展的IntelliSense会扫描大量文件，CPU占用很高。如果你机器性能一般，可以在设置里搜索“C_Cpp: IntelliSense Engine”，把它改成“Disabled”，这样会暂时停用智能补全，但能明显减轻卡顿。或者只对当前文件使用IntelliSense（“C_Cpp: Intelli Sense Cache Size”调大一点）。
如果你像我一样经常同时打开多个工程文件夹，建议每个工程单独开一个VSCode窗口，不要把多个.uvprojx堆在同一个工作区里。这样IntelliSense不会同时扫描N个工程的头文件，整体响应速度会好很多。
6. 个人使用体感与一点补充建议
整套环境用到现在，我的日常流程已经变成：VSCode写代码，Ctrl+Shift+B一键编译，Flash按钮烧录，调试时才回Keil。说句实话，编译速度并没有变快——核心还是同一套编译器——但是“写代码”这个过程本身的流畅度提升非常明显，代码补全、跳转、Git历史、多光标编辑、格式化，这些现代编辑器该有的功能终于都有了。
如果你也打算迁移，我给几个建议：
- 先用一个小工程试水，走通“打开工程→编译→烧录”全流程，别一上来就迁移主力项目。
- Keil5继续留着，不是可有可无，而是必须保留。配置烧录器、调试会话、查看反汇编、处理某些特殊的编译选项，这些都离不开Keil本身。
- 遇到问题先回Keil验证。如果Keil里编译都过不了，VSCode里自然也是失败的。别在插件层面白白排查半天。
- 合理配置includePath，别贪多。把该加的目录加全，不该加的库不加，代码跳转才能又准又稳。
最后再分享一个小技巧。如果你经常要在一堆代码里搜某个寄存器字段或者查某个外设初始化流程，可以试试VSCode自带的“Go to Symbol in Workspace”（Ctrl+T），输入关键字能直接搜到整个工程的符号，比Keil的搜索好用太多。我用这个小功能查代码定义的频率，比用文件管理器找文件高得多。
折腾一套顺手的开发环境，投资半天时间，换来每天写代码的好心情，这笔账怎么算都值。
