1. 先说清楚为什么会有这个需求以及它到底在解决什么写 C 程序的老伙计们应该都有一段 Dev-C 的青春记忆。大学上机课、计算机二级备考、被指针和结构体折磨的夜晚那个老旧的界面和“运行”按钮一点就弹出来的黑色控制台窗口就是我们对“写代码”这件事最初的认知。后来工作了或者接触开源社区以后慢慢转向 VSCode轻量、插件生态丰富、颜值高、跨平台但有一个坎始终绕不过去——运行一个 C 程序总感觉不对劲。为什么不对劲因为 VSCode 默认是在内置终端里运行程序的。你按下 CtrlF5结果输出结果挤在编辑器下方那块窄窄的面板里没有独立的窗口想用 scanf 从键盘输入交互起来特别别扭程序一跑完输出一闪而过想看个结果还得截图或者拼命往上翻。最要命的是中文乱码明明代码里写着 printf(“你好”)终端里显示的却是一堆看不懂的字符。这些体验用习惯了 Dev-C 那套“弹窗运行”逻辑的人是真的很难接受。我当初从 Dev-C 转 VSCode 的时候在这上面折腾了整整两天。上网搜解决方案搜出来的全是“在 VSCode 里配置 C/C 环境”“安装 MinGW”“改 launch.json”之类的老生常谈没有一个正面回答“怎么让它弹窗运行”这个问题。后来自己翻文档、试参数、踩坑才搞明白 VSCode 其实完全具备“调起外部控制台窗口”的能力只是默认没有配置好或者说官方文档给的示例压根没往这个方向引导。这篇文章我就把整套方案写清楚从最基本的原理讲到可以直接复制粘贴的配置最后再把常见问题一网打尽。适合谁看刚用 VSCode 写 C 语言、正在跟内置终端和乱码问题死磕的新手也适合被公司文档逼着换编辑器、但心里还惦记着 Dev-C 那种干脆利落感的老手。解决什么问题一句话总结让 VSCode 在你按下运行键之后弹出一个独立、干净的黑色控制台窗口来跑你的 C 程序——和 Dev-C 一模一样。2. 理清思路VSCode 和 Dev-C 的运行机制到底差在哪2.1 两者的“工作流”差异才是根本原因先说清楚一个底层逻辑。Dev-C 是集成开发环境自带编译器通常是 MinGW 或者 TDM-GCC它的运行按钮背后做了一整套动作调用编译器生成 exe、然后使用system(cmd /c pause)之类的机制在新开的控制台宿主窗口中加载并执行这个 exe、程序结束后按任意键暂停。整个过程对用户是透明的你看到的就是一个窗口弹出来程序在里面跑跑完停在结果页面上。VSCode 本质上是编辑器不是 IDE。它运行 C 程序靠的是两件事一个是tasks.json里定义的任务负责编译另一个是launch.json里的调试或运行配置负责执行。默认情况下VSCode 会调用其内置的“集成终端”来显示运行结果。这个终端是从编辑器内部启动的它不是在操作系统层面新建了一个独立进程窗口而是把输出“托管”到了 VSCode 的 UI 面板上。于是就会出现那堆问题交互输入别扭、中文编码不匹配、程序结束终端进程直接返回提示符导致输出丢失。这就是最核心的认知点想让 VSCode “弹窗”运行 C 程序本质上是让 VSCode 放弃内置终端作为执行宿主而是通过调用系统命令Windows 下就是 cmd 或 PowerShell新建一个独立窗口然后把编译好的 exe 丢进去运行。搞清楚这一点后面所有配置都不用死记硬背你能自己推导出来。2.2 为什么很多人第一波尝试就翻车网上很多教程一上来就让你装 Code Runner 插件。Code Runner 确实能一键运行但它默认还是在集成终端里跑顶多帮你自动把编译和运行两步合成一步并不能实现“弹独立窗口”。有人就在这里面绕了好久装完插件、点运行发现还是没弹窗以为是配置问题折腾半天一无所获。还有人走上了改 launch.json 的路子比如把externalConsole参数设成true。这个参数确实是用来控制是否弹出外部控制台窗口的但注意它是给调试模式F5 启动的调试会话用的不是给普通的“运行”用的。如果你只是按 CtrlF5不调试运行或者干脆直接跑 tasks.json 里的任务这个参数根本不会生效。我第一次试的时候就犯了这个错误改完 launch.json 里外没反应后来才意识到自己用错了入口。搞清楚这两点之后方案其实就很清晰了。我们有两个方向可以走一是修改 tasks.json 里的任务定义让“生成”任务顺带调起外部窗口二是用 cmd 的/c start命令在集成终端里间接启动一个新窗口。这两个方向我实际都测过各有优劣下面分开讲。3. 环境准备先确认你的“地基”牢不牢在折腾“弹窗”这个事之前先把最基础的环境检查一遍。我见过太多人卡了半天才发现自己的 VSCode 根本连编译器都没配置好那后面的一切都是空中楼阁。首先是 C/C 扩展。打开 VSCode 的扩展面板搜 “C/C”认准微软出的那个作者显示是 Microsoft图标是个蓝底 C 字。这个插件提供语法高亮、智能提示、调试支持和 tasks.json、launch.json 的自动生成是整个流程的基础。我建议你在没有它的情况下不要进行任何操作因为没有它会非常痛苦。然后是编译器。Windows 上最常用的是 MinGW-w64GCC 的 Windows 移植版。下载安装好以后关键一步是配环境变量。把编译器所在的 bin 目录通常是类似C:\mingw64\bin这样的路径加入系统 PATH 环境变量。验证方法开一个新的命令提示符窗口输入gcc --version能显示版本号就说明配置成功。注意是开新窗口因为环境变量改了以后已经打开的窗口不会自动刷新。还有一件事建议顺手把 VSCode 完全关掉再重新打开。很多人配完环境变量后VSCode 还是报“找不到编译器”就是因为没重启。这个坑太常见了我大学室友就是在这一步摔了跟头愣是搞了两小时最后发现换个新窗口就好了。检查完这两样按CtrlShiftP打开命令面板输入 “C/C: Edit Configurations (UI)”进入编译器路径设置页面确认 Compiler path 指向你的 gcc.exe。如果一切正常这一步会生成一个c_cpp_properties.json文件里面记录的路径就是之后所有操作的基础。地基牢了咱们才开始盖房子。4. 核心改造亲手编写 tasks.json 让程序弹窗运行4.1 认识 tasks.json 的编译任务模板正常情况下当你第一次在一个 .c 文件上按 CtrlF5或者从菜单栏选择“终端 - 配置默认生成任务”VSCode 会自动生成一个 .vscode 文件夹里面包含 tasks.json 和 launch.json。tasks.json 里的内容大概是这样的{ version: 2.0.0, tasks: [ { type: cppbuild, label: C/C: gcc.exe 生成活动文件, command: C:\\mingw64\\bin\\gcc.exe, args: [ -fdiagnostics-coloralways, -g, ${file}, -o, ${fileDirname}\\${fileBasenameNoExtension}.exe ], options: { cwd: ${fileDirname} }, problemMatcher: [ $gcc ], group: { kind: build, isDefault: true }, detail: 调试器生成的任务。 } ] }这个任务做的事情很简单用 gcc 把当前打开的 .c 文件编译成同目录下同名 .exe。${file}是当前文件的完整路径${fileDirname}是当前文件所在目录${fileBasenameNoExtension}是文件名不含后缀的部分。这些都是 VSCode 内置的变量理解它们对后面改造很重要。注意这里我只写了编译任务没有写运行任务。VSCode 默认的 CtrlF5 流程是先执行编译任务然后通过 launch.json 的配置启动调试器来运行程序。我们的目标是要在这条链路上插入一个“打开外部窗口”的环节。4.2 旧方案在 tasks.json 里添加 command 调用外部控制台我最早折腾出来的方案是在编译任务后面再加一个运行任务用 VSCode 的command类型任务来调起外部 cmd 窗口。思路是先编译生成 exe然后调用cmd.exe /c start去启动一个新的命令提示符窗口窗口内的命令就是运行那个 exe。这样就能实现“弹窗运行”的效果。完整配置如下可以直接复制但建议看完后面的解释再动手{ version: 2.0.0, tasks: [ { type: cppbuild, label: C/C: gcc.exe 生成活动文件, command: C:\\mingw64\\bin\\gcc.exe, args: [ -fdiagnostics-coloralways, -fexec-charsetUTF-8, -g, ${file}, -o, ${fileDirname}\\${fileBasenameNoExtension}.exe ], options: { cwd: ${fileDirname} }, problemMatcher: [ $gcc ], group: { kind: build, isDefault: true }, detail: 调试器生成的任务。 }, { label: Run C Program in External Window, type: shell, command: cmd /c start \C Program\ cmd /k \chcp 65001 nul \${fileDirname}\\${fileBasenameNoExtension}.exe\\, dependsOn: C/C: gcc.exe 生成活动文件, group: { kind: build, isDefault: true } } ] }这里我加了一个关键参数-fexec-charsetUTF-8它的作用是告诉编译器生成的 exe 里字符串常量按 UTF-8 编码处理。这样配合新窗口里执行的chcp 65001把控制台代码页切换成 UTF-8就能从根源上解决中文乱码问题。这个参数太重要了后面单开一节详细讲。第二个任务就是核心它是一个shell类型的任务意味着 VSCode 会调用系统 shell 来执行command里的命令。我拆开来解释一下这条命令的含义。cmd /c start C Program cmd /k chcp 65001 nul \${fileDirname}\\${fileBasenameNoExtension}.exe\这条命令初看像天书一层层拆开就明白了。最外层cmd /c表示我要启动一个新的 cmd.exe 进程来执行后面的整串命令接下来的start C Program是 cmd 的一个内部命令专门用来“新开一个窗口”后面引号里的C Program是给这个新窗口随便起的标题再后面的cmd /k表示这个新窗口里也要跑一个新的 cmd 进程/k参数的意思是执行完命令后不退出保持窗口开启方便我们看运行结果然后再一层引号里先执行chcp 65001 nul把代码页切到 UTF-8注意nul是把这段命令的输出吞掉不让它在窗口里刷屏表示前一条命令成功后再执行后面那条也就是运行我们的 exe。dependsOn字段的意思是这个运行任务会先触发它依赖的编译任务也就是先生成 exe然后再执行自身命令。这样你只需要按一次快捷键就能完成“编译 - 弹窗运行”整条链路。我这里用了一个技巧把group都设成build且isDefault: true这样在“终端 - 运行生成任务”菜单里两个任务会被归为一组快捷键 CtrlShiftB 会直接蹦出任务选择器选择那个 Run 任务就能跑。这个方案我用了一段时间实测可用但也有两个小毛病。一是从集成终端里看命令输出会看到一堆 cmd 的启动信息虽然不影响结果但不够清爽二是在某些 Windows 版本上start嵌套 cmd 的引号匹配偶尔会出问题导致窗口一闪而过。后来我研究出了更稳的第二套方案。4.3 新方案直接修改 launch.json通过 externalConsole 弹窗运行我后来发现其实可以更优雅地解决这个问题——既然externalConsole参数本来就是为了调起外部窗口设计的那我们就好好利用它。只不过别把它放在调试配置里而是建立一个专门用于“运行”的配置。具体做法在 launch.json 里增加一个配置externalConsole设为true然后把program指向编译好的 exe。这样按 F5 时VSCode 会先执行 preLaunchTask编译然后直接弹出一个独立的控制台窗口来运行程序。修改后的 launch.json 是这样如果文件不存在可以从命令面板执行“Debug: Open launch.json”创建{ version: 0.2.0, configurations: [ { name: Run in External Window, type: cppdbg, request: launch, program: ${fileDirname}\\${fileBasenameNoExtension}.exe, args: [], stopAtEntry: false, cwd: ${fileDirname}, environment: [], externalConsole: true, MIMode: gdb, miDebuggerPath: C:\\mingw64\\bin\\gdb.exe, preLaunchTask: C/C: gcc.exe 生成活动文件, setupCommands: [ { description: Enable pretty-printing for gdb, text: -enable-pretty-printing, ignoreFailures: true } ] } ] }这里externalConsole: true是关键。当这个值为 true 时调试器不会把程序挂到 VSCode 内置终端上而是调用系统的控制台宿主来创建独立窗口。对于不使用调试器、只是想“跑一下看结果”的场景这个窗口点击后还会保留住程序的输出。配套地tasks.json 里也简化了不需要那个花里胡哨的 shell 任务只要保留一个干净的编译任务就行。整体流程变成按 F5 - VSCode 执行编译任务 - 编译成功 - 弹出一个新窗口运行 exe - 程序等待输入 / 输出结果 - 按任意键窗口关闭因为 VSCode 的弹窗模式会挂起窗口。我第一次这么配置以后体验好了非常多特别是调试功能还保留着——如果你的运行有问题可以在 VSCode 内置调试器里打断点排查而日常直接运行则用弹窗模式两不耽误。这也是我更推荐这个方案的原因。4.4 编译命令里必加的编码参数防乱码的根源在这一行很多人在 VSCode 里写 C 程序遇到中文乱码第一反应是改窗口的代码页或者改 VSCode 的编码设置改了半天还是乱。核心原因没搞明白乱码发生在两个环节一个在“源代码 - 可执行文件”的编译环节另一个在“可执行文件 - 控制台窗口”的显示环节光改显示端不解决根本问题。Windows 下 VSCode 默认的文件编码是 UTF-8而 GCC特别是 Windows 版编译时默认把源代码当成当前系统本地代码页通常是 GBK也就是 CP936来读。于是源代码里用 UTF-8 存的中文字符串被 GCC 按 GBK 的规则解释成了一个一个错的字节序列编译进 exe 后自然就是乱码的根源。同理printf 里直接写死的汉字在 exe 里其实存的是被错误编码过的字节。解决办法是加编译参数-fexec-charsetUTF-8告诉 GCC源码里的字符常量请按 UTF-8 编码存入 exe。配合运行时把控制台的显示代码页切到 65001也就是 UTF-8两个环节都对齐了中文才能正常显示。如果你用的是第 4.2 节的 shell 任务方案窗口里的chcp 65001 nul就是做这个事的如果你用 4.3 节的 launch.json 方案你需要在environment里加一项或者在自己的程序开头先用 system 函数执行一下chcp 65001更直接的做法是在program的 cwd 里启动前先调用system(chcp 65001 nul), 但我不建议在代码里加这种硬编码更推荐在 launch.json 的 environment 字段里设置{name: LANG, value: zh_CN.UTF-8}实测也能部分解决。最稳妥的办法其实是两条腿走路编译参数加上-fexec-charsetUTF-8运行时在新窗口里执行chcp 65001。5. 手把手实操从零配置一个能弹窗运行的 C 项目5.1 新建工作目录和 Hello World 测试文件空讲理论没意思我这边直接带你把整套流程走一遍从新建文件到最后成功弹窗一步一步来。为了演示方便我建了一个专门的目录比如E:\CWorkspace\PopupDemo然后新建一个源文件hello.c代码如下#include stdio.h int main() { printf(你好世界\n); printf(如果你能看到这个窗口说明弹窗配置成功了。\n); printf(请输入一个数字测试一下输入功能\n); int n; scanf(%d, n); printf(你输入的是%d\n, n); system(pause); return 0; }注意这里的system(pause)。在 Dev-C 里你不需要写这行因为它的运行窗口自带“按任意键继续”的暂停机制。但 VSCode 的外部弹窗在程序正常结束后窗口可能自动关闭所以我们需要在程序的末尾手动加一个暂停这样运行完还能看到结果。这个习惯建议保留至少在弹窗方案里非常实用。5.2 创建 tasks.json 和 launch.json完整可复制配置在 VSCode 里打开这个文件夹然后按CtrlShiftP输入 “C/C: Add Debug Configuration” 或者直接 F5VSCode 会提示选择环境选 C (GDB/LLDB)生成默认的配置。然后把上面 4.2 和 4.3 的代码分别覆盖到.vscode/tasks.json和.vscode/launch.json里。切记tasks.json 里的编译任务必须保留launch.json 里的preLaunchTask指向的任务名必须和 tasks.json 里的 label 完全一致字母大小写都不能错。我踩过一个坑把 label 里的C/C: gcc.exe 生成活动文件复制到 preLaunchTask 时因为冒号后面多了一个空格导致 VSCode 找不到任务弹窗运行直接失败。这类“隐性错误”编译器不会报VSCode 也不给提示查起来特别费劲。此外如果你装的编译器路径不同记得改 tasks.json 里的command和 launch.json 里的miDebuggerPath。我这里的路径是C:\mingw64\bin\你要是装在 D 盘或者其他目录按实际情况修改。5.3 配置好后怎么运行快捷键和菜单操作一览配置好之后有三种方式可以启动我们的“弹窗运行”流程按 F5这是调试模式会走 launch.json 的配置触发 preLaunchTask 编译然后弹窗运行程序同时保留完整的调试能力断点、变量监视都可能用。按 CtrlF5这是不调试直接运行但它会走内置终端不是弹外部窗口所以这个快捷键反而不适合我们用。这点容易混淆务必注意。按 CtrlShiftB这是“运行生成任务”会打开任务选择器你选那个 Run in External Window 对应的 shell 任务如果你用的是 4.2 方案或者直接选中编译任务。我最推荐的日常用法是 F5它最接近 Dev-C 里“编译并运行”的肌肉记忆。按一下VSCode 先编译编译没问题就弹窗窗口里程序跑起来输入输出都自由。如果有语法错误问题面板会直接列出不用等到弹窗。5.4 验证弹窗成功的关键观察点配置完成后按 F5观察有没有以下现象。第一VSCode 底部状态栏会先显示“正在构建”一秒左右后消失第二屏幕正中央或脱离 VSCode 的位置弹出一个黑色窗口第三窗口里第一行显示“你好世界”第二行显示提示信息程序等待输入。这三个现象同时出现说明弹窗运行配置成功。如果窗口一闪而过或者什么都看不到就去看“终端”面板里有没有报错常见错误集中在 gcc 路径不正确、任务名不匹配、编译失败这几种。下一节我把常见问题整理成速查表。6. 日常使用中的常见问题排查与避坑指南6.1 弹窗一闪而过根本看不见运行结果这是最高频的问题原因通常有三个。第一个是编译失败程序本身有语法错误或者链接错误exe 根本没生成VSCode 的弹窗机制就会直接失败。第二种是system(pause)缺失程序跑完之后窗口跟着进程一起退出肉眼根本来不及看。注意system(pause)在 4.2 方案的cmd /k模式下其实可以省略因为/k会保持窗口存活但如果你用的是 launch.json 的 externalConsole 模式system(pause)基本是必须的。第三种是start嵌套问题就是 4.2 方案里引号匹配出错、cmd 解析命令失败这种情况建议换用 4.3 的新方案。从 pragma 角度说我建议无论如何都在代码末尾加system(pause)这是最保险的。有些 IDE 或者调试器会在程序结束后自动暂停但依赖外部控制台时自己动手最可靠。6.2 窗口弹出来了但中文全是乱码中文乱码我在前面已经详细讲了原理这里直接说排查步骤。第一步确认 tasks.json 的编译参数里有-fexec-charsetUTF-8没有这个参数编译出来就是按 GBK 解释的错字节怎么改窗口代码页都没用。第二步确认窗口里执行了chcp 65001在 4.2 方案里这是写进命令里的在 4.3 方案里如果你没有手动设置环境变量建议在代码最前面调用一次system(chcp 65001 nul)或者直接在 launch.json 的environment字段加一个LANGzh_CN.UTF-8。第三步确认 VSCode 本身的文件编码是 UTF-8右下角状态栏点击编码按钮选择“通过编码重新打开”选 UTF-8。三步全做完乱码基本绝迹。我还要提醒一个隐蔽问题如果你用记事本手动改过源码记事本在另存时有很大的概率把编码存成 ANSIGBK那就和 VSCode 的 UTF-8 又冲突了。建议所有修改都在 VSCode 内部完成保持一致。6.3 按 F5 提示找不到任务或找不到 gcc这个错误通常是因为 launch.json 里的preLaunchTask名称和 tasks.json 里的任务 label 不一致最常见的是大小写、空格、全角半角符号不匹配。在 JSON 里不要写全角冒号或者中文引号一个不小心就是 bug。还有一种情况是 tasks.json 语法出错比如缺少逗号或者括号不匹配VSCode 会提示红色波浪线或者直接报“无法分析 JSON”。遇到这种建议把 tasks.json 内容删了重写不要手工修JSON 的括号嵌套很容易看得晕。另外gcc 路径找不到的问题除了环境变量之外还有一种可能你装的是 Dev-C 自带的编译器通常埋在老旧的 MinGW32 路径下那个版本太老而且路径里可能有空格。强烈建议单独装一个官方版 MinGW-w64装的时候记得选 x86_64 架构、win32 threads、seh 异常处理模型这几个选项影响兼容性。路径里不要有中文和空格——这一点太重要了我曾经在C:\Program Files (x86)下面装 MinGW结果折腾了一整个下午的路径转义。6.4 我一按 CtrlF5 还是在内置终端里跑怎么回事好问题这个坑尤其隐蔽。CtrlF5 在 VSCode 的默认键位里绑定的是“运行而不调试”它使用的执行机制和 F5调试不一样。F5 走 cppdbg 调试器externalConsole 参数生效所以能弹窗CtrlF5 走的是 VSCode 自己的运行逻辑很多时候会直接复用集成终端externalConsole 根本无济于事。如果你习惯了 CtrlF5可以自己改键位绑定把它重映射到 F5 的调试启动上或者干脆养成用 F5 的习惯。我的建议是直接改键位打开键盘快捷方式CtrlK CtrlS搜 “run without debugging”把它的绑定删掉或者改成别的避免习惯性误触。另一种常见误解是装了 Code Runner 插件后它的运行按钮也是走内部终端跟 externalConsole 无关。如果你既想要 Code Runner 的一键体验、又想要外部弹窗需要单独配置该插件的自定义运行命令但个人认为没必要——F5 已经足够好用了。6.5 常见问题速查表为了你以后排查方便我把上面这些典型问题整理成一个速查表现象可能原因解决方案弹窗一闪而过程序没有暂停机制代码末尾加system(pause)弹窗一闪而过编译失败exe 没生成打开终端看 gcc 报错信息修复后重试中文乱码编译参数缺-fexec-charsetUTF-8tasks.json 的 args 里加上该参数中文乱码窗口代码页不是 UTF-8窗口执行chcp 65001或环境变量设 LANGF5 提示找不到任务preLaunchTask 名称不匹配核对 launch.json 和 tasks.json 的 label 完全一致找不到 gcc编译器没装或路径不对重装 MinGW-w64配置 PATH重启 VSCode路径中有空格/中文编译器或工作目录路径非法换目录或者用反斜杠转义和引号包裹CtrlF5 不弹窗走了内置终端执行逻辑改用 F5或修改键位绑定屏幕没有窗口但没报错程序快速运行完毕暂停被忽略检查是否把 pause 写在 return 之后7. 关于这个方案的反思与延伸建议我实际操作了相当长一段时间以后发现这套“弹窗运行”方案并不只是“折腾一下让体验变好”这么简单它背后反映了一个更实际的问题不同背景的程序员进入同一个编辑器后对“运行”这件事的心理预期差异巨大。Dev-C 的窗口模式天然适合学习阶段——因为那个阶段你大部分时间在写控制台程序交互都是标准输入输出一个独立的黑窗口反而是最直观的反馈。而 VSCode 的集成终端偏工程化它更适合处理日志输出、多任务并行、环境变量的统一管理这些复杂场景。所以在团队里如果有刚转过来的新手我通常建议他们先用本文的 4.3 方案过渡几周把精力聚焦在语言本身而不是适配编辑器上。等他们慢慢上手以后再引导尝试集成终端、多任务、调试器这些高级功能会发现这些工具各有适用场景并不是什么非此即彼的东西。还有一个延伸思路其实这个操作同样适用于运行 Python、Java 甚至 Node.js 脚本。比如你想让一个 Python 程序也弹窗运行只需要在 tasks.json 里构造类似命令cmd /c start python 你的脚本.py等于是举一反三。VSCode 的 tasks 系统本质上就是一个通用任务执行器不只是为 C/C 服务的学会这一招其它语言也能玩转。我个人的习惯是把 tasks.json 和 launch.json 这两个文件加入项目自带的配置文件版本库里这样团队里任何人克隆项目下来按一个 F5 就能获得一致的体验不用每个人各自折腾一遍。这是很多 VSCode 项目欠缺的“开箱即用”意识建议大家都养成的习惯。最后再分享一个小技巧如果你发现弹窗窗口的位置每次都不一样可以在代码里调用MoveWindow或SetConsoleTitle来固定位置和标题虽然这个纯粹是锦上添花、不影响功能但当你盯着屏幕调程序调了一整天有一个位置稳定、标题醒目的控制台窗浮躁的心情会舒缓不少。技术在细节里体现温度配置这种东西讲究的就是贴合自己的习惯——你现在可以把 VSCode 改造成你最顺手的样子了。