VSCODE 配置C++环境
如果你刚开始学 C++，或者从 Dev-C++、Visual Studio 转到 VS Code，第一件事基本都是在网上搜“vscode配置c++环境”，然后跟着一篇教程装插件、改配置、写第一段 Hello World。我当年也是这么过来的，配置过程谈不上难，但坑不少：明明装了 MinGW，终端却提示“g++ 不是内部或外部命令”；明明照着教程写了 tasks.json，编译还是报错；好不容易编译通过了，中文又乱码。这篇文章就把我从踩坑到真正理解这套配置逻辑的完整过程写出来，包括为什么要这么配、每一步在做什么、出了错怎么排查，以及怎么从单文件配置升级到用 CMake 管理真实项目。适合刚接触 C++ 的新手，也适合想弄清楚 VS Code 配置原理的读者。
1. 为什么用 VS Code 写 C++：先搞清楚配置的本质
1.1 VS Code 只是一个编辑器，不是编译器
很多人第一次接触 VS Code，会把它当成一个“官方出品的、装好就能写 C++ 的软件”。实际上 VS Code 本质上是一个文本编辑器，它本身不具备把 C++ 源码变成可执行程序的能力。编译这件事，靠的是它背后调用的编译器工具链，比如 GCC、Clang、MSVC。VS Code 做的事情是：帮你编辑代码、高亮语法、补全提示、调用终端执行命令，再把编译器输出结果解析出来显示给你看。
理解这一点非常关键。因为我们说的“配置 C++ 环境”，其实包含两层：第一层是在操作系统里装好编译器并让它能被命令行调用；第二层是在 VS Code 里装好插件、写好配置文件，让编辑器和编译器配合起来。很多教程只讲第二层，结果读者在第一步就卡住了，因为那些教程默认你已经装好了编译器并且配置好了 PATH。
1.2 三种方案怎么选：编译器决定你的体验
配置 C++ 环境，第一步永远是选编译器。主流选择有三个：
- MinGW-w64（Windows 下最常用）：它是 GCC 编译器的 Windows 移植版。轻量、免费、和 Linux 下的 gcc/g++ 行为几乎一致，教程多、资料多，适合学习算法、做课程设计、写小型工具。
- MSVC（Visual Studio 的编译器）：如果你用 Visual Studio，或者项目依赖 Windows SDK，那就用 MSVC。它的调试器（Windows 调试器）和 VS Code 配合也不错，但配置路径更长，需要安装 Visual Studio Build Tools。
- Clang：在 macOS 上默认自带的就是 Clang（终端里敲 g++ 实际上指向 clang++）。它在语法报错信息上更人性化，跨平台能力也强。
我个人建议：如果你只是学习 C++ 基础语法、算法题、小游戏，Windows 上用 MinGW-w64 就好了。为什么？第一，安装简单，解压即可使用；第二，g++ 命令在国内外教程里是最通用的；第三，它包含的 mingw32-make 可以配合 Makefile，后续学 CMake 也不冲突。如果你以后要从事 Windows 桌面开发或游戏行业，再去接触 MSVC 也不迟，两者并不冲突。
1.3 配置前需要准备的东西
在开始之前，先确认几件事，避免后面白折腾：
- 一台可以正常上网的电脑，操作系统建议 Windows 10/11，Linux 或 macOS 也可以，只是操作命令不同。
- 一个干净的工作目录。我习惯在 D 盘或用户目录下建一个
cpp_project文件夹，专门放 C++ 学习代码，路径尽量不要包含中文和空格。这一步很多人忽略，但后面踩坑往往就踩在这里——有些老版本工具链对中文路径处理不好。 - 下载好 VS Code 安装包。去官网下载，安装的时候建议勾选“添加到 PATH”和“通过 Code 打开操作”这两个选项，后面很多操作会方便很多。
准备工作做好之后，我们再来拆解整个配置流程的原理。
2. 核心细节解析：编译器、插件与配置文件的关系
2.1 编译器选型：MinGW-w64 到底该装哪个版本
MinGW-w64 这个名字很多教程都在提，但真正操作时你会发现自己面对的是好多选择：32 位还是 64 位？哪个版本？用什么渠道下载？
先说位数的选择：看你的操作系统。现在绝大多数电脑都是 64 位 Windows，装 64 位的 x86_64 工具链即可。查看方法：设置 → 系统 → 关于 → 系统类型，会显示“64 位操作系统”。如果显示 32 位，就选 i686 版本。这个判断很重要，选错了会导致编译出的程序无法运行。
下载渠道方面，早期教程会让你去 SourceForge 下载 MinGW-w64，那个页面下载按钮一大堆，不小心就点到广告。现在更推荐两种方式：一是去 MinGW-w64 的官方仓库或者 GitHub 上下载，搜索“w64devkit”或“winlibs”，这些项目都提供了预编译的压缩包；二是如果你装了包管理工具，比如 winget、choco、scoop，直接一条命令就能装好。我用 scoop 装的话就是scoop install mingw，用 winget 就是winget install Mingw-w64。用包管理器最大的好处是版本更新方便，一条命令升级，不用删了重下。
装好之后怎么看自己装对了没有？打开一个终端，输入g++ --version，如果输出一长串版本信息（比如 g++.exe (MinGW.org GCC Build-20200229-1) 或类似的），说明编译器本体已经 OK。如果提示“无法识别”“不是内部或外部命令”，那就是 PATH 环境变量的问题，这个后面专门讲。
2.2 必装插件清单：别装一堆没用的
VS Code 的插件生态很丰富，但配置 C++ 环境，真正核心的其实就这几个：
第一个是微软官方的C/C++（扩展 ID：ms-vscode.cpptools）。这个插件是整套配置的核心，它提供 IntelliSense（代码补全与语法解析）、调试器集成、代码跳转等功能。装了它，你才能点击“运行”（F5）弹出调试面板，否则 VS Code 都不知道怎么启动调试器。
第二个是C/C++ Extension Pack（扩展 ID：ms-vscode.cpptools-extension-pack）。这个是一个扩展包，里面除了核心的 C/C++ 插件，还包含 CMake、CMake Tools 等扩展。如果你想用 CMake 管理项目，直接装这个包，一次到位。它还能帮你安装调试器工具，省去手动下载的麻烦。
第三个是Code Runner（扩展 ID：formulahendry.code-runner）。这个插件的作用是让你在编辑器里点击右上角的小三角按钮，直接运行当前文件。它本质上就是帮你在终端里执行“g++ 编译+运行”的命令，对新手非常友好，写算法练习题时效率很高。
剩下像 Better C++ Syntax、IntelliCode 这类插件属于增强体验，不是必须的。我给新手的建议是：先装这三个，等环境跑通了再按需扩展。装一堆插件反而会增加干扰，出现问题也难排查。插件装多了还容易卡顿，尤其是 C/C++ 插件本身对 CPU 和内存的占用就不低。
2.3 配置文件到底在配置什么：tasks.json 和 launch.json 的分工
VS Code 的项目配置都放在项目根目录下的.vscode文件夹里。C++ 配置涉及两个核心文件：
tasks.json：定义“构建任务”。通俗地说，这里定义的是“怎么把代码编译成可执行文件”这件事。它会调用编译器命令，比如g++ -fdiagnostics-color=always -g main.cpp -o main.exe，然后在 VS Code 内置终端里执行。如果你在 VS Code 里按 Ctrl+Shift+B 能触发编译，靠的就是这个文件。launch.json：定义“调试任务”。它负责告诉 VS Code 怎么启动你的程序、怎么把调试器和编译出来的可执行文件对接起来。按 F5 启动调试的时候，VS Code 读的就是这个文件。
很多新手会困惑：为什么我 Ctrl+Shift+B 能编译，但 F5 调试却不行？因为这两个功能走的是两套独立配置，少任何一个文件，对应的功能就失效。还有人说“我什么都没写，点击右上角箭头也能运行”，那多半是 Code Runner 插件在起作用，它默认使用的是一套内置命令，跟 tasks.json 没有关系。搞清楚了这些，后面配置起来就不会一头雾水。
3. 实操过程：从零一步步搭好环境
3.1 Windows：安装 MinGW-w64 并配置 PATH
我先以 Windows 为例，把完整流程走一遍。假设你下载的 MinGW-w64 压缩包是mingw64.zip，我建议解压到D:\mingw64，这样路径好记，也不会有权限问题。
解压之后打开这个目录，你应该能看到bin、include、lib等子文件夹。其中最关键的是bin目录，里面放着g++.exe、gcc.exe、gdb.exe等可执行文件。配置 PATH 的目的，就是让系统在任意路径下都能找到这些程序。
配置 PATH 的步骤：
- 按
Win + S搜索“环境变量”，打开“编辑系统环境变量”。 - 在“系统属性”窗口中点击“环境变量”按钮。
- 在“系统变量”中找到
Path，双击它，点击“新建”，输入D:\mingw64\bin，确定保存。 - 重新打开一个终端窗口（注意：已经打开的终端不会自动刷新环境变量，必须新开），输入
g++ --version。
看到版本信息之后，再测一下调试器：输入gdb --version，如果也能输出版本信息，说明调试器也装好了。这里有个容易被忽略的点：MinGW-w64 的完整工具链里是包含 gdb（GNU 调试器）的，但有些精简版或者单独下载的 gcc 包里没有。没有 gdb 的话，VS Code 的调试功能没法用。如果你用的是 w64devkit，我记得它的发布包里默认包含 gdb，一般没问题。
3.2 Linux 和 macOS 的对应操作
Linux 系统要简单得多。Debian/Ubuntu 系列执行：
sudo apt update sudo apt install build-essential gdbbuild-essential这个包会装上 gcc、g++、make 等一整套编译工具。CentOS/RHEL 系列用sudo yum groupinstall "Development Tools"。装完之后也是用g++ --version验证。
macOS 上最简单：安装 Xcode Command Line Tools，在终端里执行xcode-select --install，系统会弹出安装窗口，确认等待即可。装完之后终端里的g++实际上会链接到 Clang，但命令用法完全一样，对 VS Code 配置来说没有区别。macOS 上同样需要gdb或者用lldb，VS Code 的 C/C++ 插件默认能识别 lldb，所以一般不用额外操心。
3.3 在 VS Code 中创建项目并安装扩展
环境变量配好之后，回到 VS Code。按Ctrl+Shift+X打开扩展面板，分别搜索并安装前面说的三个扩展：C/C++、C/C++ Extension Pack、Code Runner。这一步没有太多技术含量，但装完 C/C++ 插件之后，VS Code 可能会提示你安装“C++ 编译器”或“调试器”，如果你已经手动装过了，这个提示可以忽略，不要重复安装。
然后新建一个文件夹，比如在 D 盘创建cpp_project，在 VS Code 里选择“文件 → 打开文件夹”。接着新建一个文件hello.cpp，写入：
#include <iostream> int main() { std::cout << "Hello, VS Code C++!" << std::endl; return 0; }写完之后，VS Code 的右下角或状态栏可能会弹出一个提示，问你是否信任此文件夹的作者，选择“是”即可。如果你装了官方 C/C++ 插件，此时#include这行下面可能会显示“无法打开源文件”的错误提示，这其实是 IntelliSense 在报错，不代表编译会失败，原因是 IntelliSense 还没配置编译器路径。这个问题稍后会解决。
3.4 配置 tasks.json：实现快捷键一键编译
按Ctrl+Shift+P打开命令面板，输入Tasks: Configure Default Build Task，或者直接输入C/C++: Build active file，VS Code 会引导你生成tasks.json。如果引导不成功，也可以手动在.vscode文件夹下创建tasks.json。我直接给出一个经过验证的完整配置：
{ "version": "2.0.0", "tasks": [ { "type": "cppbuild", "label": "C/C++: g++ 编译当前文件", "command": "g++", "args": [ "-fdiagnostics-color=always", "-g", "${file}", "-o", "${fileDirname}\\${fileBasenameNoExtension}.exe" ], "options": { "cwd": "${fileDirname}" }, "problemMatcher": [ "$gcc" ], "group": { "kind": "build", "isDefault": true }, "detail": "使用 g++ 编译单个 C++ 文件" } ] }逐行解释一下这些参数的含义。-fdiagnostics-color=always是让编译器输出彩色错误信息，在终端里更容易分辨 warning 和 error。-g是生成调试信息，这个必须加，否则后面用 F5 调试断点的时候，VS Code 无法把断点和源代码对应起来。${file}指当前打开的文件，${fileDirname}是文件所在目录，${fileBasenameNoExtension}是当前文件名去掉扩展名。-o指定输出文件名，所以这里的输出就是和源文件同目录下的.exe文件。
配置好之后，按Ctrl+Shift+B，如果一切正常，VS Code 底部会弹出终端窗口，你会在里面看到编译命令的执行过程，大概率是一条成功消息。然后在项目目录下就会多出hello.exe文件。
3.5 配置 launch.json：实现 F5 断点调试
有了可执行文件，接下来配置调试。切换到“运行和调试”面板（左侧那个带虫子和播放图标的按钮），点击“创建 launch.json 文件”，选择“C++ (GDB/LLDB)”，VS Code 会生成一个默认模板。把这个模板替换成下面这份：
{ "version": "0.2.0", "configurations": [ { "name": "C/C++: g++ 构建并调试当前文件", "type": "cppdbg", "request": "launch", "program": "${fileDirname}\\${fileBasenameNoExtension}.exe", "args": [], "stopAtEntry": false, "cwd": "${fileDirname}", "environment": [], "externalConsole": false, "MIMode": "gdb", "miDebuggerPath": "D:\\mingw64\\bin\\gdb.exe", "setupCommands": [ { "description": "为 gdb 启用整齐打印", "text": "-enable-pretty-printing", "ignoreFailures": true } ], "preLaunchTask": "C/C++: g++ 编译当前文件" } ] }这里几个关键字段值得记住：program是你要调试的可执行文件路径，它必须和上面tasks.json里-o指定的输出路径一致，否则调试器找不到文件。miDebuggerPath是 gdb 的完整路径，如果你不是安装在D:\mingw64，就改成你实际的路径。preLaunchTask是调试前自动执行的构建任务，它对应tasks.json里那个label。这样每次按 F5，VS Code 都会先帮你重新编译，再启动调试器，非常方便。
配置完成之后，在hello.cpp第 3 行（std::cout那一行）点一下行号左侧，会出现一个红点表示断点。按 F5，程序会在断点处停下来，这时候你可以在“监视”窗口添加变量查看值，也可以按 F10 单步执行、F11 进入函数、Shift+F5 停止调试。到这里，一套完整的“编辑—编译—调试”流程就通了。
4. 常见问题与排查技巧实录
4.1 终端提示“g++ 不是内部或外部命令，也不是可运行的程序”
这是新手遇到最多的错误，原因只有一个：系统找不到 g++ 可执行文件。要么是 MinGW 没装，要么是 PATH 没配好。排查步骤：
- 先确认你是否真的安装了编译器。打开文件资源管理器，去你解压的 MinGW 目录下找
bin\g++.exe。 - 如果存在，手动在命令行里执行
set PATH=D:\mingw64\bin;%PATH%临时加入路径，测试一下能否运行。如果临时加入后能运行，说明 PATH 持久化配置没生效。 - 检查 PATH 配置是不是加进了“系统变量”而不是“用户变量”，其实两者都可以，只要终端能读到。但要注意配置完之后必须新开终端窗口。
- 如果上述都正常，看看你是不是在 VS Code 的内置终端里输入的命令。VS Code 内置终端继承的是打开 VS Code 时的环境变量，如果 VS Code 是配置 PATH 之前启动的，那里面根本不知道新路径。重启 VS Code 就能解决。
这里我再补充一个细节：建议用英文路径安装 MinGW。有人把 MinGW 解压到C:\Program Files (x86)\mingw64，路径里的空格可能造成一些旧版工具链的问题。虽然现在大部分工具已经能正确处理空格，但没必要给自己找麻烦，用D:\mingw64这种路径最省心。
4.2 编译出的程序运行结果中文乱码
这个问题非常典型。Windows 命令行默认使用 GBK/936 编码，而你在 VS Code 里写的源码通常是 UTF-8 编码。当程序把 UTF-8 编码的中文字符输出到 GBK 终端里时，就会乱码。
解决思路有两个方向：一是让源码用 GBK 编码保存，二是不改源码而是修改终端代码页。第一个方向我强烈不推荐，因为工程上越来越统一用 UTF-8，你用 GBK 保存代码，以后换到 Linux 或者用 Git 协作，很容易出现乱码和 diff 灾难。第二个方向才是正解。
操作方式：在tasks.json的args里加一个参数，或者在代码开头加一句system("chcp 65001");（仅 Windows，且编译器要允许调用 system 函数）。我更推荐的做法是在代码里加，因为它是代码层面控制，和 VS Code 无关，换到任何环境都能生效：
#include <iostream> #include <windows.h> int main() { SetConsoleOutputCP(CP_UTF8); std::cout << "中文测试" << std::endl; return 0; }这段代码的意思是调用 Windows API 把控制台输出代码页设置为 UTF-8（65001），这样 UTF-8 源码里的中文就能正常显示。如果你在 Windows 10/11 上开启了“Beta：使用 Unicode UTF-8 提供全球语言支持”（控制面板 → 区域 → 更改系统区域设置），那基本不会遇到中文乱码，但这个选项可能影响其他软件，不建议普通用户随意打开。
4.3 按 F5 报错：“Unable to start debugging”“无法打开文件”“预启动任务失败”
这个错误要分情况看。
第一种是preLaunchTask报错。按 Ctrl+Shift+B 能编译成功，但 F5 时报“无法找到任务”，这通常是因为launch.json里的preLaunchTask值和tasks.json里的label不一致。检查两边的字符串是否完全一样，大小写和空格都要一致。这类问题我见得太多了，经常是复制配置的时候 label 写成了英文名，导致对不上。
第二种是program路径不对。调试器提示无法找到.exe文件，或者提示“无法打开文件”。检查一下编译输出目录和launch.json里的program路径是否一致。最直观的办法：手动在终端里执行一次编译命令，然后去资源管理器里找到生成的.exe，把它拖到终端里看看完整路径，和launch.json对照一下。
第三种是miDebuggerPath不对。这个报错信息通常是“gdb 路径无效”或“无法启动 GDB”。确认 gdb 是否安装，以及路径是否写对。注意 JSON 里反斜杠要转义，写D:\\mingw64\\bin\\gdb.exe，或者用正斜杠D:/mingw64/bin/gdb.exe，两种写法都可以。
4.4 IntelliSense 报错“无法打开源文件”，但编译能通过
这是很多新手会被吓到的情况：代码明明编译运行正常，但 VS Code 里#include <iostream>下面一直有红色波浪线。原因很简单：IntelliSense 没有配置编译器路径，它不知道该去哪里找标准库头文件。
在.vscode文件夹里新建一个c_cpp_properties.json，内容如下：
{ "configurations": [ { "name": "Win64", "includePath": [ "${workspaceFolder}/**", "D:/mingw64/include/**", "D:/mingw64/lib/gcc/x86_64-w64-mingw32/**" ], "defines": [], "compilerPath": "D:/mingw64/bin/g++.exe", "cStandard": "c17", "cppStandard": "c++17", "intelliSenseMode": "windows-gcc-x64" } ], "version": 4 }这里的关键是compilerPath要指向你的 g++，includePath要包含 MinGW 的 include 目录。配置好之后重新打开文件，红色波浪线就会消失。其实更稳妥的做法是：在 VS Code 命令面板输入C/C++: Edit Configurations (JSON)，它会自动根据你选的编译器生成这份配置，比我手写的更准确。
另一个小技巧：如果 IntelliSense 反应慢或者不准确，可能是它索引的范围太大。你可以右键.vscode文件夹里的settings.json，在里面加一句"C_Cpp.intelliSenseEngineFallback": "Enabled"，或者限制索引范围。不过新手阶段不建议动这些高级选项，保持默认就好。
4.5 多文件项目怎么编译：单文件的 tasks.json 不再够用
当你开始写多个.cpp文件（比如main.cpp加一个utils.cpp），上面那种“编译当前文件”的配置就行不通了——它只会编译当前打开的那个文件，链接不到另外的文件，就会报 undefined reference。解决办法有两种：
第一种，偷懒方式：把tasks.json里的${file}改成${workspaceFolder}/*.cpp，让编译器一次编译目录下所有源文件。这种方式只适合小型项目，文件多了会有重复编译的问题，而且不能指定头文件依赖顺序。
第二种，正式方式：用 CMake。CMakeTools 插件会帮你自动生成一套 build system，让 VS Code 调用 CMake 来构建项目。这种方式才是工程化的标准做法。我会在下一节展开。
4.6 其他常见问题速查
| 错误现象 | 可能原因 | 解决方案 |
|---|---|---|
| 点击运行按钮无效 | 没有配置任务或运行插件 | 安装 Code Runner 或配置 tasks.json |
| 控制台一闪而过 | 程序运行完窗口关闭 | 在代码末尾加std::cin.get();或使用 externalConsole |
| 断点不停 | 编译时没加-g参数 | 在 tasks.json 的 args 里加入-g |
| 断点变量看不到值 | 未进入调试会话只运行程序 | 确认是按 F5 启动调试，不是点击运行 |
报错缺少libwinpthread-1.dll | MinGW 的 bin 目录没有加入 PATH | 确保 D:\mingw64\bin 在 PATH 中 |
5. 进阶：从单文件配置到工程化开发
5.1 用 CMake 管理多文件项目
当你开始写超过两个源文件的项目时，靠 tasks.json 编译单个文件已经不是长久之计。CMake 是 C++ 社区事实上的标准构建工具，VS Code 配合 CMake Tools 插件使用体验很好。安装扩展之后，按 Ctrl+Shift+P 输入CMake: Quick Start，它会帮你生成一个CMakeLists.txt项目骨架。你也可以手动创建，模板如下：
cmake_minimum_required(VERSION 3.10) project(Demo) set(CMAKE_CXX_STANDARD 17) add_executable(demo main.cpp utils.cpp )写完CMakeLists.txt之后，VS Code 底部状态栏会出现一个“生成”和“调试”按钮。点击“生成”，CMake Tools 会调用 CMake 生成构建目录（通常是build），然后调用编译器编译。点击那个小虫图标就可以进行调试，它会自动处理好所有路径问题。
这里有一个值得注意的差别：CMake Tools 插件并不依赖你之前手写的tasks.json和launch.json，它有自己的一套流程。如果使用 CMake 的项目同时存在旧的 tasks 配置，可能会互相干扰。我建议在引入 CMake 之后，可以把旧的.vscode配置清掉，让 CMake Tools 接管构建和调试。
5.2 代码格式化与静态检查：让代码风格规范化
环境配置好只是开始，一个舒适的 C++ 开发环境还应该包含代码格式化和静态检查。VS Code 的 C/C++ 插件内置了 clang-format 的集成。按Shift+Alt+F即可格式化当前文件，默认的风格是基于 clang-format 的 LLVM 风格。你可以在设置里指定风格，比如Google或WebKit。我的习惯是：
{ "C_Cpp.clang_format_fallbackStyle": "Google" }此外，C/C++ 插件高阶版（C/C++ Advanced）还能集成 cppcheck 之类的静态检查工具，可以在编译之前发现一些潜在问题，比如未初始化变量、资源泄漏等。不过对新手来说，先学会编译运行和调试，静态检查可以慢慢接触。
5.3 提升日常写码效率的几个小设置
最后分享几个我实测很提升体验的 VS Code 设置项，放在.vscode/settings.json里即可：
{ "editor.formatOnSave": true, "editor.fontSize": 16, "editor.minimap.enabled": true, "files.encoding": "utf8", "files.autoGuessEncoding": true, "C_Cpp.errorSquiggles": "EnabledIfIncludesResolve", "terminal.integrated.defaultProfile.windows": "Command Prompt" }formatOnSave是保存时自动格式化，配合 clang-format 可以让你不用手动整理缩进；files.encoding设为utf8和autoGuessEncoding是为了解决旧文件编码不统一的问题；terminal.integrated.defaultProfile.windows设成 Command Prompt 是为了避免 VS Code 默认用 PowerShell 导致某些终端命令行为不一样。
对于终端，我还要多说一句：VS Code 内置终端和系统终端的体验不完全一样。如果你发现某些命令在内置终端里执行和在系统终端里执行结果不同，先看看 VS Code 右下角当前用的终端类型。Windows 上我建议用命令提示符（cmd）作为默认，因为很多旧教程里的命令都是按 cmd 写的，用 PowerShell 有时会出现%PATH%展开等行为差异。
5.4 我踩过坑之后的一点体会
整篇文章写到这里，该配的也都配完了。最后说点个人感受。很多同学在配置 C++ 环境时容易陷入“按教程抄配置”的状态，复制一个tasks.json过来能跑就跑，改了环境又不行了。我建议你把这几个文件当成自己的代码一样对待，至少搞清楚每个字段在做什么。下次换电脑、换系统、换目录结构，一切都能自己快速解决。
另外一个小建议：配置环境本来就是开发能力的一部分。刚接触 C++ 的时候你会觉得命令行难用、环境变量烦人，但等你真正理解编译器是怎么工作的，再回来看这些配置，会觉得一切都很自然。我现在用 VS Code 写 C++ 最多的一次，配置时间不到五分钟，大部分时间反而花在调代码上。这就是熟练的收益。
如果这篇文章你看完了还是没配成功，大概率是编译器路径的问题。用我前面给的排查方法逐条检查一遍；如果还是不行，把你的报错信息原样搜一遍，一般都能找到答案。编程路上没有不被报错折磨过的人，希望你能尽早配好环境，把时间留给真正有意思的代码。
