这段时间陆续有朋友来问我同一个问题：VS Code 到底怎么配置 C++ 环境。说实话，这个问题看似简单，实际操作起来坑不少，尤其是第一次接触的人，很容易卡在“写好了代码，却不知道去哪里编译运行”这一步。VS Code 本质上是一个编辑器，它不像 Visual Studio 那样开箱即用地内置编译器、调试器，它需要你自己把“编译器 + 调试器 + 构建工具”这三件套装好，然后在 VS Code 里通过配置文件把它们串联起来。这也是很多人配置半天没成功的原因：不是 VS Code 出了问题，而是链路没打通。
这篇内容我以 Windows 平台为例，把从零开始配置 VS Code C++ 环境的全过程拆开讲透，包括方案选型、工具安装、核心配置文件解析、常见报错排查。适合完全没配过的新手，也适合配了好几次总有小毛病的同学。如果你用的是 macOS 或 Linux，思路完全一样，只是编译器安装方式不同，看完也能举一反三。
1. 配置之前先把路子想清楚
很多人一上来就打开 VS Code 装插件，装完发现还是编译不了，然后开始在网上搜各种教程，越搜越乱。其实配置 C++ 环境这件事，第一步不是安装，而是先想清楚整个链路是什么。
1.1 VS Code 的定位：它不是 IDE，是“组装机”
VS Code 和 Visual Studio 最大的区别在于：Visual Studio 是一台“整机”，厂商把所有零件都装好了，你直接开机就能用；VS Code 是一台“组装机”，它给了你很好的主板（编辑器界面）和电源（插件机制），但 CPU、内存、硬盘这些核心配件要你自己买回来装。这里的核心配件就是编译器（把源代码变成机器码）、调试器（帮你定位程序问题）、构建工具（帮你在多文件项目里自动决定怎么编译）。
所以 VS Code 的 C++ 开发链路至少有三层：
- 编译器：负责把
.cpp文件编译成可执行文件。Windows 上最常用的是 MinGW-w64 的g++，也可以使用 MSVC 的cl.exe。 - 调试器：负责在断点处暂停程序、查看变量值。配合 g++ 用的是
gdb。 - VS Code 插件：负责把你的编辑器和上述工具连接起来，提供智能提示、代码补全、一键编译、一键调试的入口。最核心的是微软官方的 C/C++ 扩展（
ms-vscode.cpptools）。
理解了这条链路，你就知道“配置环境”这个动作的本质是什么了：把这三层装齐，然后用三个配置文件告诉 VS Code 每一层的工具在哪个路径、怎么调用。
1.2 两条主流路线：MinGW-w64 vs MSVC
Windows 上给 C++ 选编译器，绕不开两个选择：MinGW-w64 和 MSVC。
先说明我的结论：如果你不是在做 Windows 底层 API 开发、不需要用到微软特有的编译优化选项，或者你不是在维护一个必须用 Visual Studio 打开的大型工程，那么 MinGW-w64 是更轻量、更省心的选择。原因有三点：第一，它的工具链（g++、gdb）和 Linux 上一致，语法、调试体验和你在服务器上写 C++ 几乎没区别；第二，这套工具链对 “代码 + 命令行” 的开发模式支持极好，配合 VS Code 非常顺手；第三，安装体积小、环境变量配置简单，没有 Visual Studio 那套庞大的项目系统。
MSVC 那边的情况是：它是微软官方编译器，对 Windows API 支持最好，但启动方式比较重。你通常需要安装 Visual Studio Build Tools，然后用 VS Code 的“C++ 扩展 + CMake Tools”组合去驱动它，首次配置会稍微折腾一些。
| 对比项 | MinGW-w64（g++) | MSVC（cl.exe） |
|---|---|---|
| 安装体积 | 约 1-2 GB（MSYS2 基础 + 工具链） | Build Tools 约 3-7 GB |
| 标准库 | libstdc++ | Microsoft STL |
| 与 Linux 工具链一致性 | 高，g++/gdb 通用 | 低，命令体系完全不同 |
| 适合场景 | VS Code 轻量开发、OJ 刷题、跨平台项目 | Windows 桌面程序、COM 组件、大型 MSVC 工程 |
| 调试器 | gdb | Visual Studio Debugger（vsdbg） |
我个人平时用 VS Code 写算法题、小工具、学习项目，走的是 MinGW-w64 路线，下面的实操也以此为默认方案。等你有需要再切换到 MSVC 也不难，因为 VS Code 的配置文件是“一套配置，多套工具链可用”的。
1.3 整体流程：从安装到跑通一共五步
在开始动手之前，把后面的步骤提前摆出来，免得你中途迷失方向。整个流程是：
- 安装 MSYS2，通过它的包管理器安装 MinGW-w64 工具链（g++、gdb 等）。
- 把工具链的 bin 目录加入系统 PATH 环境变量。
- 安装 VS Code 本体，以及微软官方 C/C++ 扩展。
- 写一个最简单的
hello.cpp，用 VS Code 的 tasks 配置调用 g++ 编译运行。 - 配置
launch.json，实现 F5 一键调试。
每一步都有它的目的：第 1 步解决“有没有编译器”的问题，第 2 步解决“VS Code 的终端能不能直接调用 g++”的问题，第 3 步解决“编辑器能不能理解 C++ 语法”的问题，第 4、5 步解决“能不能一键编译、能不能断点调试”的问题。这五步走完，你的基础环境才算真正落地。
2. 环境安装：MSYS2、VS Code 与插件
这一节全是实操，我把每个环节的关键动作和为什么这么做的原因讲清楚。请按顺序操作，别跳步，因为后面的配置文件依赖前面装好的工具路径。
2.1 安装 MSYS2 和 MinGW-w64 工具链
MSYS2 可以理解成一个运行在 Windows 上的软件仓库和工具链发行平台。它自带pacman包管理器（和 Arch Linux 的包管理器同源），你用它安装 g++、gdb、make、git 这些开发工具会非常方便。
从 MSYS2 官网下载安装包，安装路径建议保持默认的C:\msys64。为什么建议默认路径？因为后续很多教程、插件默认值都假设你在C:\msys64，如果你自定义到别的盘，后面配置文件里所有路径都要手动改，增加踩坑概率。当然你机器上确实 C 盘紧张，装到 D 盘也完全可以，只是后面要格外留意路径。
安装完成后，打开“MSYS2 MSYS”终端（开始菜单里能找到），先执行一次系统更新：
pacman -Syu这个过程可能需要重启终端，按照提示操作即可。更新完系统包之后，接着安装编译器工具链：
pacman -S mingw-w64-x86_64-toolchain它会问你安装哪些包，一般直接回车选 all。这一步会安装gcc、g++、gdb、mingw32-make等一整套工具。网络不好可以改用国内镜像源，中科大、清华的镜像站都有对应的 pacman 镜像配置说明，切换后速度会明显改善。
安装完成后，验证一下工具是否可用。在 MSYS2 终端里执行：
g++ --version gdb --version如果能看到版本号输出，说明工具链已经装好。接下来要做的，是让它成为 Windows 全局命令，这样你在 VS Code 的集成终端里也能直接调用。
2.2 把工具链加进 PATH
C:\msys64\mingw64\bin这个目录里放着 g++、gdb 等可执行文件。你需要把这一行路径加进系统环境变量 PATH。操作路径是：设置 → 系统 → 关于 → 高级系统设置 → 环境变量 → 系统变量 → 找到 Path → 编辑 → 新建 → 填入C:\msys64\mingw64\bin→ 确定。
这一步做完之后有个非常容易踩的坑：如果你之前已经打开了 VS Code，或已经打开了任何终端窗口，它们不会自动刷新环境变量。你必须把 VS Code 完全关闭后重新打开，再打开集成终端，执行g++ --version才会生效。很多教程到你这一步就直接干等，导致你满世界找不到 g++，其实只是终端没刷新。
验证命令是在 VS Code 的集成终端里执行（快捷键 Ctrl + `）：
g++ --version如果输出版本号，编译器这块就通了。
2.3 VS Code 本体 + 核心插件安装
VS Code 直接去官网下载即可，安装时建议选择“System Installer”版本，方便所有用户使用，同时勾选“添加到 PATH”之类的选项。
装好后第一件事是安装插件。你需要安装的核心插件是微软官方的C/C++（扩展 ID：ms-vscode.cpptools），这个插件提供了 IntelliSense（智能提示）、调试、代码导航等功能。它是整个 VS Code C++ 开发体验的地基，没有它你连语法高亮都做不好。
此外还有两个很实用的插件：
- Code Runner：扩展 ID
formulahendry.code-runner。它能在终端里一键运行当前文件，适合快速测试单个.cpp，不用每次走完整的 tasks 配置流程。 - C/C++ Extension Pack：扩展 ID
ms-vscode.cpptools-extension-pack。它把 CMake、clangd 等配套工具打包在一起，如果你后面想搞多文件工程，建议直接装上。
如果你希望界面是中文，装完 C/C++ 插件之后可以再装一个“Chinese (Simplified) (简体中文)”语言包，改装完按提示重启 VS Code 即生效。界面语言这件事纯看个人习惯，英文界面反而更好搜索问题，我不强求。
2.4 写第一个测试程序：验证整条链路
在 VS Code 里新建一个文件夹，比如D:\cpp_workspace，用 “文件 → 打开文件夹” 把它作为工作区打开。新建一个hello.cpp：
#include <iostream> int main() { std::cout << "Hello, VS Code C++!" << std::endl; return 0; }先不急着配置任何 json 文件，直接在集成终端里手动编译一把：
g++ hello.cpp -o hello.exe ./hello.exe如果终端输出Hello, VS Code C++!，说明工具链、PATH、VS Code 终端三者的链路已经打通。接下来要做的，就是把这套手动命令固化到 VS Code 的配置文件里，实现“按一个按钮就能编译调试”。
3. 三个核心配置文件的详细解析
VS Code 里和 C/C++ 环境强相关的配置文件有三个：c_cpp_properties.json、tasks.json、launch.json。它们各自负责不同维度：管代码智能提示、管编译动作、管调试会话。很多人配完一个配置文件，发现另外的功能还是不行，就是因为没搞懂三者分工。这里逐个拆开讲。
3.1c_cpp_properties.json：管智能提示和标准库识别
这个文件是 C/C++ 插件的专属配置文件。你可以通过命令面板（Ctrl + Shift + P）输入“C/C++: Edit Configurations (JSON)”来打开它。它负责告诉插件：当前代码要用哪个编译器、头文件去哪里找、语言标准是哪个。
一个比较标准的模板如下：
{ "configurations": [ { "name": "Win32", "includePath": [ "${workspaceFolder}/**" ], "defines": [], "compilerPath": "C:/msys64/mingw64/bin/g++.exe", "cStandard": "c17", "cppStandard": "c++17", "intelliSenseMode": "windows-gcc-x64" } ], "version": 4 }逐个字段说：
includePath：告诉插件去哪找头文件。${workspaceFolder}/**代表当前工作区递归所有子目录。这只是兜底，编译器自身的标准库头文件路径其实由compilerPath推断，不需要手动写。compilerPath：指定编译器路径。插件会根据这个路径自动获取内置头文件路径和默认宏定义，从而提供准确的智能提示。如果你不填这个字段，插件默认亏猜成 MSVC，头文件提示就全乱了。这是很多初学者“明明能编译，但代码下面全是红色波浪线”的根源。cppStandard：语言标准。我习惯设置为c++17，现在 C++20/23 的语法特性和库也陆续成熟，如果你的编译器支持，调成c++20也行，但要注意部分旧教程代码在 C++20 下会有兼容性提示。intelliSenseMode：环境类型。windows-gcc-x64是 Windows 下配 g++ 的标准写法，和编译器路径保持一致。
如果你直接把hello.cpp写出来，看到 include 不飘红、输入std::有补全提示，说明这个配置成功。
3.2tasks.json：管编译动作
tasks.json负责“编译”这个动作。它的本质是把你在终端里手敲的命令固化成按键触发，比如 Ctrl + Shift + B。你可以在命令面板里输入“Tasks: Configure Default Build Task”，选择“C/C++: g++.exe build active file”，VS Code 会自动生成一个基础模板。
它会生成的内容大致长这样：
{ "version": "2.0.0", "tasks": [ { "type": "cppbuild", "label": "C/C++: g++.exe build active file", "command": "C:/msys64/mingw64/bin/g++.exe", "args": [ "-fdiagnostics-color=always", "-g", "${file}", "-o", "${fileDirname}/${fileBasenameNoExtension}.exe" ], "options": { "cwd": "${fileDirname}" }, "problemMatcher": [ "$gcc" ], "group": { "kind": "build", "isDefault": true } } ] }这里面的几个变量和参数很关键。${file}代表当前激活文件的完整路径，${fileDirname}是当前文件所在目录，${fileBasenameNoExtension}是当前文件名去掉扩展名。所以这一条命令的实际展开结果就是：
g++ -fdiagnostics-color=always -g hello.cpp -o hello.exe其中-g参数是调试信息开关。这个参数非常重要，它告诉编译器在生成的 exe 里保留和源代码的对应关系，没有它 gdb 就无法正确打断点和查看变量。-fdiagnostics-color=always让 GCC 输出的错误信息带颜色，便于区分 error 和 warning。
problemMatcher字段的作用是“把终端里的编译错误快速定位到源码行”。比如编译器报了个 error，它会自动把错误解析成 VS Code 的“问题”面板里有行列号的条目，你一点就跳到源码出错位置。
我把group里的isDefault保留为 true，这样按 Ctrl + Shift + B 就会直接执行这个编译任务。如果你只想编译当前文件，这个模板完全够了。多文件项目后面再说。
3.3launch.json：管调试会话
写完代码能编译了，下一步就是能调试。在 VS Code 里按 F5，选择环境“C++ (GDB/LLDB)”，它会自动生成launch.json。调整后参考如下：
{ "version": "0.2.0", "configurations": [ { "name": "C/C++: g++.exe build and debug active file", "type": "cppdbg", "request": "launch", "program": "${fileDirname}/${fileBasenameNoExtension}.exe", "args": [], "stopAtEntry": false, "cwd": "${fileDirname}", "environment": [], "externalConsole": false, "MIMode": "gdb", "miDebuggerPath": "C:/msys64/mingw64/bin/gdb.exe", "setupCommands": [ { "description": "为 gdb 启用整齐打印", "text": "-enable-pretty-printing", "ignoreFailures": true } ], "preLaunchTask": "C/C++: g++.exe build active file" } ] }核心字段一个个过：
program：指定要调试的可执行文件路径。${fileBasenameNoExtension}.exe和 tasks 生成的可执行文件名对应。如果文件名对不上，调试器会提示找不到文件。MIMode与miDebuggerPath：调试器类型和调试器路径。这里用 gdb，因为它和 MinGW 工具链配套。如果你装了 gdb 但路径填错，F5 会直接报“无法启动调试器”。externalConsole：是否用独立控制台窗口运行程序。我建议平时调试设为false，让程序跑在 VS Code 的集成终端里，调试信息更集中；但如果你的程序需要cin输入交互，false在很多版本下会卡住输入，这时需要改成true弹出系统控制台窗口。这块不同版本差异比较大，读完第 4 节的排查再调不迟。preLaunchTask：调试前先执行的编译任务。它的值必须和tasks.json里某个label完全一致。相信我，这个“完全一致”是坑了很多人的地方，多一个空格、少一个字母都会报错。
设置到这里，你已经能享受完整的“F5 编译并调试”流程：按下 F5 → 自动执行 tasks 编译 → 生成新的 exe → 启动 gdb 进入调试会话 → 在断点处停下来看变量。
3.4 三个配置文件是怎么配合的
三个文件的配合逻辑可以概括成一条流水线：
- 写代码时，
c_cpp_properties.json起作用，让你的 IDE 体验（提示、补全、检查）足够顺畅。 - 按 Ctrl + Shift + B，
tasks.json起作用，自动调用 g++ 把当前文件编译成 exe，并把编译错误回传到问题面板。 - 按 F5，
launch.json先触发preLaunchTask（即复用 tasks 里的编译任务），编译成功后调用 gdb 加载 exe 开始调试。
所以它们之间不是“多配一个文件就多一重保险”的关系，而是职责互补。你写代码时花里胡哨的报错和补全问题，要去c_cpp_properties.json里找答案；编译阶段报错，去tasks.json里调命令和参数；调试阶段异常，去launch.json里找原因。
4. 实操过程中的典型问题与排查记录
配置环境这件事，真正有价值的内容全在“踩坑”环节。我把自己经历过的、以及带新人时最常见的几个问题整理出来，每条都附排查思路，方便你照着定位。
4.1 “g++ 不是内部或外部命令”但明明装过了
这个问题几乎 90% 的新手都会遇到。现象是：在终端里输入g++ --version，提示命令不存在，但我明明已经通过 pacman 安装了工具链。
排查思路按顺序来：
- 确认是否在 MSYS2 终端里试过。如果在 MSYS2 终端里能用、在 VS Code 终端里不能用，99% 是 PATH 没生效，要么是没加进去，要么是 VS Code 启动太早没刷新环境变量。处理办法：完全关闭 VS Code，重新打开。
- 确认 PATH 里那一行的路径是不是真的指向了
mingw64\bin。很多人会把C:\msys64\usr\bin当工具链路径，但那个目录里是 MSYS2 自带工具，没有 g++。g++ 在C:\msys64\mingw64\bin。 - 确认你是在“系统变量”的 Path 里改的，而不是“用户变量”。两个都能生效，但很多教程默认你改系统变量，看你实际操作在哪里改的，保持一致即可。
这个问题的本质是环境变量的作用域和刷新时机。改完 PATH 之后，所有“已经打开的终端窗口”都不会感知变化，只有新启动的进程才能读到新值。记住了就一次通。
4.2 中文输出乱码：控制台编码和源代码编码打架了
写std::cout << "你好"时，终端输出变成一堆乱码。这个坑不涉及编译失败，但特别影响心情。原因也不复杂：现代 VS Code 默认把源文件保存为 UTF-8 编码，而 Windows 的老牌控制台（conhost）默认代码页是 GBK（代码页 936），两者对不上，输出的 UTF-8 字节流被按 GBK 解读，就成了乱码。
方案有这么几种，按推荐程度排序：
- 把输出终端换成 Windows Terminal，它在较新版本里默认用 UTF-8，体验好很多。
- 在
launch.json里把externalConsole设为true，弹出的系统控制台窗口配合chcp 65001效果也不错，但每次都要手动切代码页。 - 在代码开头调用
system("chcp 65001");，强制当前控制台切到 UTF-8 代码页。只在 Windows 上有用，但省事。
我不推荐用编译器参数-fexec-charset=GBK去强行编译源文件，因为那等于让你的源码和 UTF-8 生态脱钩，将来跨平台时全是编码问题。
我自己的习惯是：直接给 VS Code 配上 Windows Terminal 作为默认终端，一劳永逸。VS Code 会自动检测系统里安装的 Windows Terminal，你只需把默认终端 profile 设为它即可。
4.3 按 F5 调试时提示“preLaunchTask 找不到”
这个报错文字大概是Could not find the preLaunchTask 'C/C++: g++.exe build active file'。原因很简单：launch.json里preLaunchTask的值和tasks.json里label的值不一致。
排查技巧是：打开两个 json 文件并排对比，逐个字符检查。重点字符包括冒号、空格、点号。比如 tasks 里的 label 是"C/C++: g++.exe build active file"，launch 里写成了"C/C++: g++.exe build active file"多了个空格都会失败。不想手打的，可以右键tasks.json里对应任务的label字符串，直接复制粘贴到launch.json，能省很多事。
还有一个小坑是：如果你手动新建 tasks.json 替换了自动生成的那个，或者把 label 改了名字，旧 launch.json 里的引用就失效了。所以最好的顺序是先通过“Configure Default Build Task”生成 tasks，再按 F5 生成 launch，VS Code 会在生成 launch 时自动帮你在 preLaunchTask 里填对上号的值。
4.4 明明能编译，代码里却到处都是红色波浪线
程序能跑，但编辑器里#include <iostream>下面总有红线，或者std::cout不触发智能提示。这种情况几乎都和c_cpp_properties.json有关。
排查方向有两个。先是确认compilerPath有没有指向正确的 g++。你可以打开命令面板，搜索“C/C++: Select IntelliSense Configuration”，选项里应该有 gcc-x64 之类的条目，选中后插件会拿标准库头文件来喂给语法分析。其次确认intelliSenseMode是否为windows-gcc-x64。如果插件还是按 MSVC 的方式解析代码，对 GCC 标准库里的很多扩展语法会误报。
另外还有一种情况是同时装了多个 C++ 扩展插件（比如 clangd 和 cpptools 并存），它们是冲突的，智能提示可能被其中一个接管，引发奇怪的报错。C/C++ 插件和 clangd 插件是同一个功能的两个不同实现，别同时启用。
4.5 断点没有命中，或者“当前不会命中断点”提示
代码能调试，但断点一直不命中，程序一运行直接跑完。这个问题的常见原因是编译时没有加-g调试信息。你在tasks.json的args里加一行"-g"就能解决。如果你是用 Code Runner 或手动命令编译出来的 exe，也一定要加上-g。
另一个更隐蔽的原因是“编译和调试不是同一个文件”。比如 tasks 编译的是main.cpp，launch 的program却指向了另一个名字的 exe，或者你改了源码后没有重新编译，gdb 加载的是旧的可执行文件。这种情况的排查方法是：在调试控制台看 gdb 输出的实际加载路径，和当前文件的输出名一致才正常。
还有个和 gdb 本身有关的坑：如果你的工程路径里有中文或特殊空格，某些版本的 gdb 会解析失败。虽然用引号包裹路径能缓解，但我建议开发目录一律使用纯英文路径。这算是我个人的血泪教训，中文路径下 C++ 调试出过各种诡异的兼容性问题。
4.6 常见问题速查
| 现象 | 根本原因 | 处理办法 |
|---|---|---|
| g++ 命令不存在 | PATH 未配置或终端未刷新 | 重新打开 VS Code；检查是否填了mingw64\bin |
| 中文乱码 | 源文件 UTF-8 与控制台 GBK 不一致 | 改用 Windows Terminal 或设置 externalConsole 并切代码页 |
| preLaunchTask 找不到 | launch 和 tasks 的 label 不一致 | 复制粘贴 label 字符串 |
| include 头文件飘红 | c_cpp_properties 里 compilerPath 未配置 | 配置 compilerPath，并选择 gcc-x64 IntelliSense Mode |
| 断点不命中 | 编译缺-g或编译产物与调试目标不符 | 确认 args 里有 -g，确认 program 路径对应 |
| 首次调试弹防火墙 | Windows 安全中心拦截 gdb | 在防火墙设置里允许 gdb 通过 |
| 程序有 cin 输入却卡住 | 集成终端下 stdin 支持不稳定 | 将 launch.json 的 externalConsole 改为 true |
5. 进阶方向：多文件工程与第三方库
基础环境跑通之后，很多人很快会遇到第二个瓶颈：我写的项目不再是单个.cpp，而是好几个文件，甚至要链接第三方库，这时默认的 tasks 配置就不够用了。
先说最简单的方式：改 tasks 里的args。把${file}改成${workspaceFolder}/*.cpp，意思是把你工作区根目录下所有 cpp 文件都编译进去，输出名可以指定为你主文件的名字。这套思路在文件少、目录结构简单时完全够用：
"args": [ "-g", "${workspaceFolder}/*.cpp", "-o", "${fileDirname}/${fileBasenameNoExtension}.exe" ]但一旦你的项目分层（src、include、tests），或者引入第三方库，这种方式就会失控。你需要一个真正的构建系统。两条主流路线：
- CMake + CMake Tools 插件：这是跨平台 C++ 项目的行业标准。你用 CMakeLists.txt 描述工程结构，VS Code 的 CMake Tools 插件直接帮你生成构建任务、调用编译、绑定调试器。
- Makefile + mingw32-make：如果你喜欢 Linux 下那套 make 工作流，可以在 MSYS2 里装
mingw-w64-x86_64-make，然后用 VS Code tasks 去调用它。
我个人的建议是直接学 CMake。它的学习曲线不算陡，而且和 VS Code、CLion、Visual Studio 都能良好配合，今天你在 VS Code 里写的 CMakeLists.txt，明天拿到其他地方依然能用。
至于第三方库的引入，思路是：头文件路径加到includePath，库文件路径加进 tasks 的-L参数、库名加进-l参数。比如链接 OpenCV 时，你会看到类似-IC:/opencv/include -LC:/opencv/x64/mingw/lib -lopencv_core这样的命令。这部分对刚配好环境的人来说有门槛，但等你真正开始做项目，它会自然变成刚需。
最后说点实在的
配环境这件事，最忌讳的就是“照着截图一步步操作却不知道每一步在干什么”。我见过太多人配完一遍，重装系统后还是不会配，因为脑子里的知识是记忆操作顺序，而不是理解工具链关系。你只要始终记住那条主线：编译器负责把源码变成可执行文件，调试器负责让可执行文件可以被断点，VS Code 的配置文件负责把这两件事的操作流程固化下来，一切配置问题都能迎刃而解。
我自己第一次配这套环境的时候，在 PATH 和 preLaunchTask 上卡了整整一个晚上。后来把这些步骤理清楚、写成一个 checklist，之后装机基本十分钟搞定。如果你配的过程中遇到这篇内容没覆盖到的报错，先去读终端里的原始错误信息，把关键字复制到搜索框里找答案，比反复试配置高效得多。这个小习惯，比任何环境配置都值得养成。
