1. 从《Hello Linux!》看过来为什么写 C/C 我一定要用 VSCode这个系列走到这里大家已经见过了命令行、Shell、文本处理这些基本功。写过几行代码之后自然要面对一个现实问题在 Linux 下到底用什么写 C/C 最顺手我前几年试过 Vim、Emacs、CLion、Qt Creator兜兜转转最后主力的日常编码环境还是落在了 VSCode 上。这并不代表 VSCode 是万能的而是它在“编辑体验”“插件生态”“远程开发”这三件事上确实覆盖了绝大多数我实际写代码的场景。先说它的定位。VSCode 本质上不是一个传统意义上的 IDE它更像一个“编辑器内核 海量扩展”的组合体。你用它的方式决定了它可以是一个顺手的高亮文本编辑器也可以是一套完整的断点调试工具链甚至可以变成一个直连远程 Linux 服务器的“云 IDE”。对于 C/C 开发来说它最大的好处是不逼你一次性学会所有东西。你可以先用它写单文件练习再逐步接触 CMake、调试器、远程开发这个过程是渐进式的不会像某些 IDE 一样开局就甩你一大堆工程配置概念。同时它是完全免费的对 Linux 的支持非常原生。我经常在本地 Ubuntu 上写代码再用 Remote-SSH 连接到实验室的一台 Linux 工作站继续写同一份代码整个过程没有任何割裂感。这一点Vim 党也许会说“我 tmux vim 也能做到”确实没错但我个人的体会是VSCode 的图形化调试体验、文件树、全局搜索、插件市场这些能力能明显降低写 C/C 时的“心智负担”。如果你刚接触 Linux或者刚准备把日常开发环境迁到 Linux从 VSCode 入手绝对比一上来就啃 Vim 脚本要舒服得多。这篇文章不是简单罗列安装步骤而是从真实使用的角度把从“安装 VSCode”到“本地编译调试”再到“远程开发”的完整链路走一遍顺便把我在这个过程中踩过的坑和验证过的配置原样分享出来。2. 安装与基础配置先把编辑器本身弄顺手2.1 在 Linux 上安装 VSCode 的三种方式与我的取舍在 Linux 下装 VSCode最常见的是三招从官网下载安装包、配置微软软件源后用 apt 安装、或者用 snap 安装。我分别说下实际体验。第一种去 VSCode 官网下载.deb或.rpm包。这个方法最直观下载完直接sudo dpkg -i code_xxx.debDebian/Ubuntu 系就能装好。缺点是后续升级需要你自己重新下载不能自动跟随系统源更新。偶尔你还可能碰到依赖缺失的情况比如缺libnss3之类的运行时库需要手动apt install -f修一下。第二种配置微软官方 apt 源。我一直用的是这个方法因为它能让你像升级普通软件包一样通过sudo apt update sudo apt upgrade顺带把 VSCode 升到最新版。配置方式其实很简单先把微软的 GPG key 导入再在/etc/apt/sources.list.d/下面新建一个 vscode 的源文件里面写好 deb 地址。整个过程在微软官方文档里都有照着做就行。注意一点国内网络环境下微软的源速度可能有波动但在我实际体验中尚可接受如果你发现 apt update 卡住了可以换时间段重试或者用镜像。第三种是 snap 方式命令是sudo snap install code --classic。我试过一段时间但最终放弃了。主要原因是 snap 包的启动速度明显慢第一次冷启动要等快照挂载打开窗口能明显感知到延迟其次 snap 的沙箱机制有时会和调试器、文件系统交互产生小摩擦尤其是当你需要访问/tmp或某些挂载目录时。如果你只是随手用用snap 没问题但作为日常主力开发环境我不推荐。装完之后终端里敲code就能从命令行启动编辑器。这里顺便安利一个高频操作进入项目目录后直接执行code .VSCode 会以当前目录为工作区打开省掉先开编辑器再选文件夹的步骤。这个习惯越早养成日常效率提升越明显。2.2 首次启动必做的几项配置汉化、字体、自动保存与文件关联刚装完的 VSCode 界面是英文的对不少新手来说第一眼有点劝退。其实汉化很简单在扩展商店搜索“Chinese (Simplified) (简体中文) Language Pack”安装后右下角会提示切换语言重启一下就是中文界面。我个人建议如果你刚开始接触先用中文界面降低学习门槛等用顺手之后再切回英文也不迟因为英文界面在搜索插件文档时对应关系更直接。接下来我把几个高频基础配置按优先级列一下字体与显示。默认字体在 Linux 下显示中文注释时偶尔会有毛边。我喜欢设置成Noto Sans Mono CJK SC或Sarasa Mono SC更纱黑体这类等宽字体对中文的渲染兼容性很好。在“设置”里搜索font-family把字体名字按顺序填进去同时把editor.fontSize调到 14 或 15看起来更舒服。自动保存。搜索files.autoSave建议设为afterDelay并把延迟时间设成 1000 毫秒。这样写代码时不用时刻记着 CtrlS编译前编辑器已经替你保存好了能避免不少“改了半天没保存直接编译旧代码”的尴尬。显示不可见字符。打开editor.renderWhitespace设为all空格和 Tab 一眼就能区分。C/C 对缩进虽然不像 Python 那样有语法意义但混用空格和 Tab 会让代码风格变得很乱这个设置能帮你在萌芽阶段就发现问题。文件关联。如果你偶尔会改 Makefile、CMakeLists.txt、.ld链接脚本这类非常规扩展名的文件VSCode 有时不会自动识别语言。可以在设置里搜索files.associations把*.ld映射到c把Makefile.*映射到makefile这样语法高亮和缩进规则就正常了。还有一个小技巧打开“命令面板”CtrlShiftP输入shellCommand相关的插件时可以实现更多自定义操作。不过每个人习惯不同基础配置不用贪多把上面这几项设好编码体验已经能超过一半没做任何设置的选手了。3. 本地 C/C 开发环境从“能编译”到“能调试”3.1 安装完整的 C/C 工具链gcc、g、gdb、make很多新手在 VSCode 里写完代码点运行却报“找不到 gcc”原因就是只装了编辑器没装编译器。VSCode 本身不负责编译 C/C它只是负责把“编译命令”交给系统的工具链去执行。所以在 Linux 上我们要先把编译调试的底子打好。以 Ubuntu/Debian 系为例打开终端执行sudo apt update sudo apt install build-essential gdbbuild-essential是一个元包它会帮你把gcc、g、make、libc6-dev等基础工具一次装齐。装完之后验证一下gcc --version g --version gdb --version make --version这里我强调一点不要只装gcc编程时经常用到 C所以g必须也有。如果后面要链接数学库之类的可能还需要libtool、automake这类辅助工具但初期不需要用到再装。如果你用的是其他发行版比如 Fedora/RHEL 系对应命令是sudo dnf install gcc gcc-c gdb makeArch 系则是sudo pacman -S gcc gdb make。原理都一样就是把工具链凑齐。装好后可以写一个最简单的hello.cpp在终端里手动编译试试g -g hello.cpp -o hello这里-g参数是生成调试信息后面用 GDB 调试时必须有它。确认能在终端手动编译后我们再进入 VSCode 的自动化配置。3.2 安装 C/C 扩展与 Code Runner让 F5 真正生效打开 VSCode 扩展商店搜索并安装微软官方发布的“C/C”扩展发布者是 Microsoft。这个扩展提供代码智能提示、断点调试、语法检查等核心能力。注意不要装成社区里那些同名但非官方的扩展认准发布者。安装后我一般还会再装一个“Code Runner”它可以直接在编辑器右上角看到一个播放键点击就能快速运行当前文件。对于写算法题、做小练习的场景非常方便。但正经项目调试我不用 Code Runner它只是“运行”不涉及断点、变量监视这些调试能力。装完 C/C 扩展后第一次打开 C/C 文件时VSCode 右下角可能会弹出提示问你是否配置 IntelliSense 模式选择 Linux 对应的模式一般是linux-gcc-x64即可。如果你编程时发现头文件找不到、波浪线满天飞多半是这里的编译器路径没有指对。可以在.vscode/c_cpp_properties.json里手动指定{ configurations: [ { name: Linux, includePath: [ ${workspaceFolder}/**, /usr/include/**, /usr/local/include/** ], defines: [], compilerPath: /usr/bin/gcc, cStandard: c17, cppStandard: c17, intelliSenseMode: linux-gcc-x64 } ], version: 4 }配置文件的路径是项目下的.vscode/c_cpp_properties.json。如果你不知道该填什么可以直接点右下角的状态栏项“C/C 配置”VSCode 会帮你生成可视化编辑界面省得手写 JSON。3.3 核心配置tasks.json 和 launch.json打通一键编译与调试这一步是很多人从“用 VSCode 写代码”到“在 VSCode 里正经调试”的关键门槛。你需要理解两个文件的分工tasks.json负责告诉 VSCode“怎么把代码编译成可执行文件”launch.json负责告诉它“怎么启动调试器去跑这个可执行文件”。先看tasks.json。在项目根目录创建.vscode文件夹在里面新建tasks.json内容大致如下{ tasks: [ { type: cppbuild, label: C/C: g 编译活动文件, command: /usr/bin/g, args: [ -fdiagnostics-coloralways, -g, ${file}, -o, ${fileDirname}/${fileBasenameNoExtension} ], options: { cwd: ${fileDirname} }, problemMatcher: [$gcc], group: { kind: build, isDefault: true }, detail: 由调试器生成的任务。 } ], version: 2.0.0 }这里面几个变量要解释一下${file}是当前活动文件路径${fileDirname}是当前文件所在目录${fileBasenameNoExtension}是去掉扩展名的文件名。也就是说当你打开hello.cpp并触发生成任务时VSCode 会执行/usr/bin/g -g hello.cpp -o hello生成的hello可执行文件就放在和源码相同的目录里名字也叫hello因为源文件是 hello.cpp所以 basename 就是 hello。然后看launch.json。同样在.vscode目录下新建{ version: 0.2.0, configurations: [ { name: C/C: g 生成和调试活动文件, type: cppdbg, request: launch, program: ${fileDirname}/${fileBasenameNoExtension}, args: [], stopAtEntry: false, cwd: ${fileDirname}, environment: [], externalConsole: false, MIMode: gdb, setupCommands: [ { description: 为 gdb 启用整齐打印, text: -enable-pretty-printing, ignoreFailures: true } ], preLaunchTask: C/C: g 编译活动文件, miDebuggerPath: /usr/bin/gdb } ] }关键点在于preLaunchTask字段它会在启动调试之前先执行tasks.json里 label 为“C/C: g 编译活动文件”的任务也就是说按下 F5 的一瞬间编辑器会自动先编译再启动 GDB 调试。如果编译报错就不会进入调试而是在下方“终端”面板里把报错信息列出来。这里的miDebuggerPath指向的是 GDB 的路径。多数字器上的默认路径就是/usr/bin/gdb但如果你的 GDB 是自己编译安装到/usr/local/bin的这里就要对应改掉。启动调试后你可以在代码左侧单击行号设置断点然后按 F5 运行按 F10 单步跳过按 F11 进入函数按 F5 继续运行到下一个断点。这些快捷键和 Windows 下的其他 IDE 非常接近迁移成本很低。3.4 升级体验用 clangd 替换 C/C 扩展的智能提示微软官方 C/C 扩展虽然开箱即用但它的智能提示速度尤其在大型工程上有时会让人有点着急。如果你后续开始接触那种上万行的工程文件我建议你关注一下clangd这个工具。clangd是 LLVM 项目附带的 C/C 语言服务器它基于clang编译器前端对 C/C 的语义理解非常准确补全响应速度也快很多。使用方法是通过sudo apt install clangd装好然后到 VSCode 扩展商店安装“clangd”扩展。注意安装后要禁用或卸载微软官方的 C/C 扩展否则两个插件的智能提示会互相干扰反而更卡。当然这里有个权衡C/C 扩展和clangd各有拥趸。官方扩展胜在“配置简单、调试集成好”clangd胜在“补全准、速度快、支持 clang-tidy 静态检查”。我的建议是初学阶段用官方扩展就行代码量大了、工程复杂了再切clangd不必一开始就给自己上强度。另外可以顺手配一下clang-format这是统一代码风格的利器。在项目根目录放一个.clang-format文件内容可以是BasedOnStyle: Google IndentWidth: 4然后打开需要格式化的文件按 ShiftAltF代码就自动变成统一的风格。别小看这一步多人协作时代码风格整齐能省下大量 review 时的无意义争论。4. 远程开发实战把代码留在服务器把界面留在本地4.1 Remote-SSH 的安装与原理VSCode 远程开发为何体验接近本地远程开发是我认为 VSCode 在 Linux 生态里最值得讲的能力。你不再需要把代码拉到本地编辑完再传回服务器而是直接在本地 VSCode 窗口里访问远程 Linux 机器上的文件像操作本地目录一样。编译、运行、调试都在远程机器上发生本地只是展示界面和接收输入。这对“开发环境必须在 Linux 上跑但你不一定坐在那台 Linux 机器前”的场景简直是量身定做。具体怎么做在扩展商店搜索并安装“Remote - SSH”发布者是 Microsoft。装好后VSCode 左侧会出现一个远程资源管理器图标。点击“连接”输入 SSH 连接命令比如ssh zhang192.168.1.100回车即可。第一次连接时VSCode 会在远程机器上下载并启动一个“VSCode Server”后端组件这个过程可能需要几十秒。之后每次连接就会快很多。这里解释一下背后的机制你在扩展商店里装上 Remote-SSH 后本地 VSCode 会建立一个通道把编辑器的 UI 层和数据层分开。你在本地看到的文件树、打开的标签页数据实际上都来自远程服务器上的文件系统。你在远程终端里执行的一切命令也都是在远程机器上真实运行的。这种架构的好处是代码不需要同步到本地编译速度和使用服务器上的库、工具链都不受本地环境影响。一个常见的困惑是“为什么我在远程服务器上打开终端看到的pwd是在某个目录而不是我的 home”。这是因为远程窗口里的集成终端默认把工作目录初始化为 VSCode 打开的那个文件夹。如果你 SSH 进入后直接code .打开当前目录终端就会以当前目录为起点。这个行为也可以在设置里调整但我个人建议就保持默认逻辑最简单。4.2 配置 SSH 免密登录不用每次输入密码的开发体验远程开发唯一的“烦”点是每次连接都要输密码。特别是每天要反复连接、断开输密码的次数一多你就明白为什么所有人都推荐配免密登录。免密登录的原理是 SSH 公钥认证你本地生成一对密钥把公钥放到远程服务器的~/.ssh/authorized_keys文件里。之后 SSH 连接时服务器会校验收到的公钥签名匹配成功就放行不需要密码。操作流程如下# 在本地机器上生成密钥对如果还没有的话 ssh-keygen -t ed25519 -C yournamelocal # 将公钥复制到远程服务器 ssh-copy-id zhang192.168.1.100ssh-copy-id会自动把本地的~/.ssh/id_ed25519.pub内容追加到远程用户的authorized_keys中。注意它依然需要你输入一次密码因为这是第一次建立信任关系之后就不用了。对于经常连接的多台服务器我建议在本地~/.ssh/config里写一个模板Host myserver HostName 192.168.1.100 User zhang Port 22 IdentityFile ~/.ssh/id_ed25519之后在 VSCode 远程连接窗口里直接输入ssh myserver就能连上。如果涉及多个端口或非默认端口Port字段特别有用。整个配置写好一次后续都非常省心。还有一个很多人问的问题远程开发时能记住密码吗VSCode 官方并不建议在配置里明文保存密码而是推荐用上面这种公钥认证的免密方式。通过ssh-agent还可以让密钥在会话期间缓存避免每次重连都重新输入密钥口令。实测下来配置好IdentityFile后几乎可以做到秒连且全程无交互这种体验一旦习惯了就回不去了。4.3 远程开发中的资源管理端口转发、扩展管理与断开重连远程窗口里本地和远程之间的网络链路也不是只用来传文件。一个非常实用的功能是“端口转发”你可以把远程服务器上的某个端口映射到本地地址例如在远程开发窗口里的“端口”面板添加3000本地就能通过http://localhost:3000访问远程服务。对于调试 Web 服务或后端程序来说这比单独用 SSH 隧道配置方便得多。再说说远程环境的扩展管理。远程连接后VSCode 扩展列表会分为“本地安装的扩展”和“SSH: 服务器上安装的扩展”两类。比如 C/C 扩展、clangd、CMake 扩展这类涉及编译、调试的工具必须在远程端安装因为它们要调用远程机器上的编译器。而像中文字体、主题这类纯 UI 的扩展本地装了就够了。VSCode 在扩展面板里会明确标注扩展安装位置第一次用的时候稍加留意就不会搞混。断开重连时还有一个常见操作如果你在远程终端里跑了一个长时间任务比如make大型工程直接关掉 VSCode 窗口的话任务会被中断。我的经验是长任务要么放在远程机器的tmux或screen会话里跑要么保证 VSCode 窗口处于后台状态而不是直接结束进程。这是使用远程开发时比较容易踩的坑提前了解能少走弯路。5. C/C 开发进阶从单文件到工程化5.1 用 CMake 组织多文件工程别再靠手敲 g 简历当你开始写超过两三个文件的项目时继续把每个.cpp文件都手动加入tasks.json的编译参数显然不现实。这时候 CMake 就登场了。CMake 本身是一个构建系统生成器它不直接编译代码而是根据CMakeLists.txt描述生成 Makefile 或 Ninja 构建脚本再交给编译器执行。打个比方g是厨师CMake 是“今日菜单加采购清单”。你只要告诉 CMake 这个工程有哪些源文件、用什么标准、需要链接什么库他就能自动帮你规划好怎么做出一道菜。一个最简单的CMakeLists.txt长这样cmake_minimum_required(VERSION 3.10) project(hello_demo) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) add_executable(hello main.cpp utils.cpp)然后在 VSCode 里安装 CMake Tools 扩展发布者是 Microsoft。装好之后用 VSCode 打开项目根目录扩展会自动识别CMakeLists.txt并在底部状态栏出现“构建”相关按钮。你可以选择目标、选择构建类型Debug/Release、一键构建和运行。这里需要注意Debug 构建会包含调试信息Release 构建会做优化初学调试时建议始终使用 Debug 模式。如果要用 GDB 调试 CMake 构建出来的程序还需要对launch.json做一点调整。比如把program指向${workspaceFolder}/build/helloCMake 默认输出目录然后把preLaunchTask改成“CMake 构建”。更简单的做法是直接在 CMake Tools 面板里点击“调试”按钮它会自动在后台完成构建并用 GDB 启动程序省去手工编辑 JSON 的步骤。对于接触工程化不久的朋友我强烈建议在 VSCode 里早点用上 CMake Tools它能帮你建立起“项目结构”的概念而不是永远停留在“单个文件跑起来就行”的层面。5.2 调试技巧条件断点、变量监视、调用堆栈与核心转储调试这种事很多人一开始只会“在断点处停下看看”但 GDB 和 VSCode 的图形化调试给我们提供了更多东东。我这里结合真实场景说几个高频技巧。条件断点。当一个循环要跑一万次你只想知道变量i 9999时程序的状态普通断点会让人按 F5 按到崩溃。在 VSCode 里右键断点选择“编辑断点”在表达式框里输入i 9999这个断点就只会在条件满足时触发。原理是 GDB 帮你自动插桩在每条语句执行前检查条件只有为真时才真正停下。这是排查“循环某一次才出错”的利器。变量监视。左侧“运行和调试”面板里的“监视”区域可以添加变量名或表达式比如*(bufoffset)、strlen(str)。调试会话运行中这些表达式会实时更新。比在代码里到处乱写printf要优雅得多。不过要注意有些表达式在优化模式下求值结果可能和源码不完全一致所以当程序行为“不合常理”时先确认是不是用了 Release 编译。调用堆栈。当程序崩溃后停在某个奇怪位置你首先要看的就是“调用堆栈”面板它列出了从程序入口到当前崩溃点的所有函数调用路径。这条路径能快速告诉你“这个 bug 是从哪一层调用进来的”。排查段错误时堆栈信息甚至比报错信息本身还管用。另外我建议学一下 Linux 下的核心转储。在终端里输入ulimit -c unlimited然后让程序崩溃一次会生成core文件。用 GDB 打开它gdb ./hello core就能直接定位到崩溃时的堆栈和变量值。VSCode 里虽然也可以加载核心文件调试但我个人觉得这一步放在终端里操作更灵活。核心转储在处理偶发崩溃时价值极大它相当于把“案发现场”保留了下来不用反复复现 bug。5.3 内存检查与性能剖析把 Valgrind 用起来C/C 的内存管理自由是一把双刃剑很多看似“玄学”的崩溃、数据错乱根源都是内存越界、使用未初始化变量或内存泄漏。这时候就需要 Valgrind 这个老朋友了。在 Ubuntu 上安装很简单sudo apt install valgrind然后对编译好的程序跑valgrind --leak-checkfull --show-leak-kindsall ./helloValgrind 会输出详细的内存报告包括“定义但从未使用”“条件跳转依赖未初始化值”“堆内存泄漏”等。我第一次用它扫描一个旧项目时才发现有十几处小内存泄漏有些代码路径只在特定参数下才会触发全靠自己肉眼看根本不可能发现。Valgrind 会明确指出泄漏发生在哪个文件、第几行、分配时的调用堆栈照着修就行。性能剖析方面如果你觉得程序卡顿又不知道瓶颈在哪可以用gprof或perf来采样。不过在 VSCode 里我们通常不会把性能剖析做成可视化界面更多是跑一次分析工具然后把结果文件打开看函数耗时。对初学者来说先把 Valgrind 用好把内存问题解决掉性能问题往往也会迎刃而解。6. 常见问题排查与避坑实录6.1 高频问题速查表报错信息与解决方案对照我整理了一份平时被问到最多的 VSCode C/C 问题对照表基本覆盖了从安装到远程开发的绝大多数情况现象常见原因解决方案VSCode 打开后中文乱码文件编码不是 UTF-8设置files.encoding为utf8或重新用 UTF-8 保存编译时报“file not found”头文件路径没包含在c_cpp_properties.json的includePath里添加路径按 F5 报“无法找到任务”tasks.json的label与launch.json的preLaunchTask不匹配对照两个 JSON 文件的 label 字段确保完全一致远程连接提示“下载 VSCode Server 失败”远程机器网络受限手动在远程机器上装对应版本的vscode-server-linux-x64.tar.gzg命令找不到编译工具链未安装执行sudo apt install build-essential调试时报找不到gdb调试器未安装执行sudo apt install gdb波浪线满天飞但编译正常IntelliSense 模式配置错误检查c_cpp_properties.json的compilerPath和intelliSenseMode远程窗口里扩展不生效扩展装在了本地端在远程资源管理器里确认扩展装到“SSH: 服务器名”下C/C 扩展和 clangd 冲突两个语言服务器同时启用停用其中一个扩展这些坑几乎每个实际用过 VSCode 写 C/C 的人都会遇到一两个。我写代码这两年多帮身边同事排查问题下来发现绝大部分都集中在“配置路径”和“扩展安装位置”这两类上。6.2 环境差异与细节坑发行版、容器与工作区目录的注意事项除了上面这些对号入座的问题还有几个容易忽略的细节。第一不同 Linux 发行版之间工具链的版本差异可能很大。比如 Ubuntu 20.04 自带的 GCC 是 9.x而 Ubuntu 22.04 是 11.x两者对 C17/20 的支持程度不同。如果你在写代码时用了比较新的语法特性在本地编译通过到了远程旧机器上却报错先检查一下两边的g --version。碰到这种问题尽量不要在代码里使用非常前沿的语法或者在项目里明确标注最低编译器版本。第二如果远程不是实体机而是容器环境比如 SSH 进到 Docker 容器里VSCode 其实也能通过 Remote-SSH 连接。但要注意容器里可能没有完整的gdb调试权限或者 ptrace 被限制这时候调试器启动会失败。通常的解决办法是用docker run --cap-addSYS_PTRACE --security-opt seccompunconfined重新启动容器。这类环境问题不怪代码先排查调试权限是最省时间的路线。第三工作区目录的选择。VSCode 打开一个远程文件夹时它的“文件夹”概念会映射到远程机器上的真实路径。如果你用 VSCode 远程打开的是/根目录扩展管理器可能因为权限问题无法正常安装扩展比如无法写入/root/.vscode-server或/home/user/.vscode-server以外的路径。建议始终打开一个有写权限的项目目录也就是你真正存放代码的目录。另外如果你的项目里有大量生成文件比如build/目录、.o文件建议在.gitignore里忽略它们也可以在 VSCode 设置里用files.exclude和search.exclude把它们藏起来否则全局搜索和文件树会非常臃肿。最后聊聊“没有编辑过的文件会关上”这个默认行为。VSCode 的标签页和浏览器不同它默认会保留你打开过的文件方便快速切换。但如果你打开了几十个文件而编辑器又不想因为标签太多而变卡可以把workbench.editor.limit.value设成一个数值比如 10超过数量的旧标签会被自动关闭。这个功能对于偶尔用 VSCode 看服务器上几十个.c文件的人来说非常实用。我个人在实际使用中最大的心得是不要试图一次把所有配置都弄到“完美”。VSCode 的配置是高度个人化的每个人的工作流差异很大。先把最核心的“编辑、编译、调试、远程连接”这条链路跑通用的过程中哪里不舒服再逐步调整。把 VSCode 用成自己的形状比照着别人的完美配置一步步复刻要有用得多。毕竟工具是服务开发效率的代码才是真正需要被关注的东西。