简介：本资源面向VSCode初学者、计算机专业学生以及需要为C/C++搭建编译调试环境的开发者，系统讲解编辑器的基础操作与C/C++工程配置思路，帮助零基础读者跨过安装插件、配置编译器、调试运行等常见门槛。压缩包共收录1132个文件，约230.42MB，内容以png操作截图、md说明文档、go源码、sh脚本、yaml配置以及jpg示意图为主，另有html、json、css等前端与配置文件，类型丰富，既便于对照图文步骤操作，也可作为环境配置的参考样本，适合按目录逐层查阅。目前已有4845人学习下载，说明该套讲解在实际使用中具备较好的可参考性。读者可从中获得编辑器界面与快捷键用法、插件安装与主题设置、C/C++扩展与编译工具链配置、调试任务与运行参数设置等完整内容，并借助大量截图与说明文档快速定位问题、复现配置过程，减少在环境搭建上反复试错的成本。
1. 装完就卡在第一次按 F5：VSCode 配 C/C++ 到底卡在哪一步
第一次装 VSCode 的人几乎都经历过同一个小崩溃：插件装了一堆，新建一个.cpp，按下 F5，弹窗问"选择环境"，选完 C++ (GDB/LLDB)，终端闪一下，什么都没留下。于是回到搜索框继续敲"VSCode 配置 C/C++ 环境"，在十几个教程之间来回看。问题不在手笨，而在于 VSCode 本身只是一层编辑器外壳，不带编译器、不带调试器、不带标准库，C++ 能力全靠外部工具链加几个 JSON 文件拼出来。这份讲解走的就是这条链路：插件怎么挑、MinGW-w64 怎么装、tasks.json和launch.json每个字段怎么改、跑不起来先看哪里。适合刚上手 C++ 课设的同学、从重型 IDE 迁过来想轻量化的人，以及需要在新机器上十分钟重建环境的老手。
2. 编辑器与编译器是两回事：先搞清装完为什么还是跑不了
把 VSCode 当成"能写代码的记事本"会更接近事实。它负责的是文本编辑、语法高亮、跳转、补全界面，真正把.cpp变成.exe的是外部编译器，把程序停下来看变量的是外部调试器。理解这一层分工，后面所有配置文件的定位就顺了：tasks.json是在告诉编辑器"用哪条命令去编译"，launch.json是在告诉调试器"启动哪个可执行文件、用哪个调试后端"，c_cpp_properties.json只影响补全和报红，不参与实际构建。很多人翻车就翻在把第三份文件当成构建配置，改了半天includePath，g++依然找不到。
2.1 三层结构：编辑器、工具链、插件各管什么
我一般把 Windows 上的 C++ 开发环境拆成三层来看。最上层是 VSCode 本体，它跨平台、启动快、插件生态大，代价是开箱即用程度近乎为零。中间层是工具链，Windows 上最常见的是 MinGW-w64，提供gcc.exe、g++.exe、gdb.exe、mingw32-make.exe这一组可执行文件，也可以换成 LLVM/Clang 那一套。最下层是插件，C/C++ 扩展负责语法分析、补全、调试适配，Code Runner 负责一键跑单文件，CMake Tools 负责接管 CMake 工程。
这三层之间的耦合很松，松到容易出事。举个常见的：插件市场里装了 C/C++ 扩展，只代表编辑器能解析头文件、能挂 GDB，不代表机器上有g++。反过来，命令行里g++ --version能出版本号，也不代表 VSCode 的集成终端继承了同样的PATH——尤其当你是从桌面图标启动、而环境变量是刚改的，那个进程可能还拿着旧的环境块。这类玄学问题的排查套路很固定：先在 VSCode 内置终端里敲验证命令，再看配置文件里的路径是绝对路径还是依赖 PATH。
选型上我的建议是：只要能接受 Windows 平台，新手直接用 MinGW-w64 走 GCC 路线，理由不是它更先进，而是社区里绝大多数"VSCode 配置 C/C++"的资料都基于这套组合，遇到问题搜得到；已经习惯 MSVC 的可以装 Visual Studio Build Tools，配cl.exe和cppvsdbg，但配置文件字段和网上教程差异较大，不适合第一次搭环境。macOS 和 Linux 自带或包管理器一条命令就能装好g++与gdb/lldb，配置文件的写法基本一致，只是miDebuggerPath和路径分隔符要改。
还有一个容易被忽略的点：不要在一台机器上同时装多个 MinGW 发行版并把它们都塞进PATH。曾经有个同学机器里三份g++.exe，编译用的是 A 的编译器，调试用的却是 B 的gdb，症状是断点能停但变量显示乱码、单步跳行。这种组合故障没有明确报错，属于典型黑匣子，只能靠统一路径来避免。
2.2 插件清单：只装必需的四五个
插件装太多是新手第二大坑源。补全类插件互相抢补全、格式化插件互相对抗、主题类插件拖慢启动，这些都不报错，只是让你觉得"卡"。我给一套最小可用清单，装完就能干活：
| 插件 | 作用 | 是否必需 |
|---|---|---|
| C/C++ | 语法解析、补全、GDB/LLDB 调试适配 | 必需 |
| C/C++ Extension Pack | 打包了上面那个及若干辅助件 | 可选，图省事可装 |
| Code Runner | 右键一键运行单文件，做练习很快 | 可选 |
| CMake Tools | 工程化项目的构建与调试入口 | 用到 CMake 再装 |
| Chinese (Simplified) Language Pack | 界面汉化 | 可选 |
装 C/C++ 扩展之后，第一次打开.cpp文件它会在右下角提示下载编译器或配置 IntelliSense，这一步可以拒绝，等你把 MinGW-w64 装好、路径确定之后，再让它生成或手写c_cpp_properties.json，能少走一轮弯路。
Code Runner 有个默认行为要提前知道：它默认执行的是"编译并运行当前文件"，输出落到"输出"面板而不是终端，遇到cin、scanf输入时会卡住没法输入。解决办法是在设置里把code-runner.runInTerminal打开，让它改用集成终端。这不是 bug，是输出通道的选择问题，理解了就不会觉得是环境坏了。
设置项上我只改三个：files.autoSave设为onFocusChange，切窗口自动保存，避免"改了没存就编译"的假故障；files.encoding设为utf8，Windows 上不设容易出现中文注释乱码；editor.formatOnSave打开，配合C_Cpp.clang_format_fallbackStyle设为{ BasedOnStyle: Google, IndentWidth: 4 }，让保存即格式化。
2.3 文件夹工作区与 .vscode 目录：打开方式决定配置生效范围
一个特别高频的疑问是"我按教程配好了，换个文件又不行"。八成是打开方式的问题：VSCode 有"打开文件"和"打开文件夹"两种姿态，前者以单文件为中心，${workspaceFolder}这类变量拿不到值；后者才是一个工作区，配置文件、相对路径、多文件构建才有意义。
标准操作是这样：先在磁盘上建一个项目目录，比如D:\code\cpp-lab，把它拖进 VSCode 窗口，或者用菜单打开文件夹。然后在资源管理器面板根节点下新建.vscode文件夹，三份 JSON 都放进去。这样配置随项目走，换项目不互相干扰，把整个目录拷给别人也能直接用。
cpp-lab/ ├── .vscode/ │ ├── tasks.json │ ├── launch.json │ └── c_cpp_properties.json ├── src/ │ └── main.cpp └── bin/.vscode目录建议加进版本控制忽略之外的说明文件里，团队协作时它反而应该提交——环境配置本身就是工程的一部分。个人习惯上，我还会在工作区里放一个notes.md记下这台机器上工具链的绝对路径，重装系统或者换机器时照着改三处路径就能恢复，比重新翻教程快得多。
3. 装 MinGW-w64：让 g++ 与 gdb 变成随手能敲的命令
工具链这一环最容易出问题，因为它发生在 VSCode 之外。判断装没装好，标准只有一个：在一个全新的终端窗口里，g++ --version和gdb --version都能出版本信息。只看安装程序提示"安装完成"没有意义，PATH 没配好等于没装。
3.1 发行包怎么挑：x86_64-posix-seh 这一串后缀的含义
MinGW-w64 的下载页面上会有一堆命名相似的文件，名字里每个词都在表达约束。以x86_64-posix-seh为例：x86_64表示 64 位目标平台；posix表示线程模型使用 POSIX 实现，支持std::thread、std::mutex这些 C++11 线程设施；seh表示异常处理机制使用结构化异常处理，只在 64 位下可用，性能优于旧的sjlj。
选择建议很直接：64 位 Windows 就挑x86_64-posix-seh。如果后面要写多线程代码却选了win32线程模型，std::thread直接编译不过，报一串thread相关的未定义引用，这个坑在课设里非常常见。另外推荐用压缩包版而不是在线安装器，解压到固定路径比如D:\toolchain\mingw64，路径里不要有空格和中文，能省掉后面链接器报路径错误的一大类问题。
解压后目录结构大致是bin/、include/、lib/、x86_64-w64-mingw32/。bin下应该有g++.exe、gcc.exe、gdb.exe、mingw32-make.exe。如果bin下只有mingw32-g++.exe这种带前缀的老式命名，说明拿到的是较老的包，功能上能用，但配置里写的命令名要跟着改。
3.2 环境变量配置与三条验证命令
把D:\toolchain\mingw64\bin追加到系统环境变量Path里，注意是bin目录，不是 mingw64 根目录。改完之后必须关掉所有已经打开的终端和编辑器进程，再重新开一个——已经运行的进程不会刷新环境块，这是"我明明配了 Path 却提示不是内部或外部命令"最常见的原因。
验证分三步走，每步失败指向不同的问题：
# 1. 看编译器是否在 PATH 里 g++ --version # 2. 看调试器是否在 PATH 里 gdb --version # 3. 看实际命中的是哪一个可执行文件（排查多版本冲突） where g++第一条出版本号，说明编译链路通了；第二条出版本号，说明调试链路通了；第三条最关键，where会按 PATH 顺序把所有同名可执行文件都列出来，如果输出了多行，第一个才是实际生效的那个，其余的应该从 PATH 里清掉。有些机器上还残留着旧 IDE 自带的gcc，顺序一乱就会导致版本错配。
接着验证一下真正能编译出东西：
cd /d D:\code\cpp-lab g++ -g -Wall -std=c++17 src/main.cpp -o bin/main.exe bin\main.exe-g生成调试信息，没有它断点基本用不了；-Wall打开常用警告，把潜在问题提前暴露；-std=c++17指定标准版本，新代码里用auto、结构化绑定、if constexpr时需要。三步都过，命令行这一层就可以不用再管了。
3.3 一个最小可调试程序：从源码到断点命中
准备一个足够小、但包含循环和变量的程序，用它来验证编译与调试两条链路。文件放在src/main.cpp：
#include <iostream> #include <vector> int main() { std::vector<int> nums{3, 1, 4, 1, 5, 9, 2, 6}; int sum = 0; for (int i = 0; i < static_cast<int>(nums.size()); ++i) { sum += nums[i]; // 在这里下断点，观察 i 与 sum std::cout << "i=" << i << " sum=" << sum << std::endl; } std::cout << "total=" << sum << std::endl; return 0; }在编辑器行号左侧点一下出现红点，就是断点。此时按 F5 如果没有launch.json，会弹出环境选择，选 C++ (GDB/LLDB) 再选g++.exe生成配置，这样生成的是默认模板，路径多半是错的，只能作为起点。正确做法是后面第 4 章手写一份，字段少、可控。
断点能停下来，说明三件事同时成立：编译时带了-g、launch.json的program指到了刚生成的可执行文件、miDebuggerPath指向了正确的gdb.exe。只要有一项不成立，表现各不相同：没有-g时断点是灰的、提示"未绑定"；program写错时弹窗说找不到文件；gdb路径错时调试会话直接起不来。把这三条对应关系记住，以后出问题能一秒定位到该看哪个字段。
注意：Windows 上带中文或空格的路径会让部分链接器和调试器报奇怪的错误，比如找不到源文件、无法读取符号表。项目路径、工具链路径都尽量保持纯英文。
4. 三份 JSON 配置文件的字段拆解：tasks / launch / c_cpp_properties
这三份文件加起来不到一百行，但每个字段改错都会引出一个具体症状。我按"谁在什么时候读它"的顺序讲：tasks.json是构建阶段被读取，launch.json是调试启动阶段被读取，c_cpp_properties.json是编辑阶段被 IntelliSense 读取。搞清楚触发时机，就不会出现"改了没反应"的困惑——很多字段的改动需要重新触发对应动作才生效。
4.1 tasks.json：把一条长编译命令固化下来
在项目里按Ctrl+Shift+P，执行Tasks: Configure Task，选Create tasks.json file from template→Others，然后整份替换成下面这版。这是我的固定模板，只改两处路径就能用：
{ "version": "2.0.0", "tasks": [ { "type": "cppbuild", "label": "build-single-file", "command": "D:/toolchain/mingw64/bin/g++.exe", "args": [ "-fdiagnostics-color=always", "-g", "-Wall", "-Wextra", "-std=c++17", "${file}", "-o", "${fileDirname}/${fileBasenameNoExtension}.exe" ], "options": { "cwd": "${fileDirname}" }, "problemMatcher": ["$gcc"], "group": { "kind": "build", "isDefault": true }, "detail": "编译当前活动文件，输出到同目录同名 exe" } ] }逐项说明。label是这个任务的唯一名字，launch.json里的preLaunchTask必须和它逐字一致，大小写都不能差，对不上就会出现"调试前没有执行构建"的静默失败。command用绝对路径而不是g++，避免 PATH 继承问题，代价是换机器要改，这正是前面建议记notes.md的原因。args里-g和-Wall建议永远保留；${file}是当前活动文件，${fileDirname}是它所在目录，${fileBasenameNoExtension}是不带扩展名的文件名，三者组合实现"编译当前文件、输出同名 exe"。problemMatcher设为$gcc后，编译错误会以可点击的形式出现在"问题"面板，比读终端快得多。group.isDefault为true时，Ctrl+Shift+B直接触发这个任务，不用每次选。
一个隐藏前提：${file}只认当前激活的编辑器标签。当你在头文件上按Ctrl+Shift+B时，编译的是那个.h，结果会得到一堆莫名其妙的错误。养成先点回main.cpp再构建的习惯，或者后面第 6 章换成按目录通配。
4.2 launch.json：让 F5 停在断点上而不是一闪而过
launch.json决定调试器怎么启动。在调试面板点"创建 launch.json 文件"，选 C++ (GDB/LLDB)，然后按下面这版改：
{ "version": "0.2.0", "configurations": [ { "name": "gdb-launch", "type": "cppdbg", "request": "launch", "program": "${fileDirname}/${fileBasenameNoExtension}.exe", "args": [], "stopAtEntry": false, "cwd": "${fileDirname}", "environment": [], "externalConsole": false, "MIMode": "gdb", "miDebuggerPath": "D:/toolchain/mingw64/bin/gdb.exe", "setupCommands": [ { "description": "为 gdb 启用整齐打印", "text": "-enable-pretty-printing", "ignoreFailures": true } ], "preLaunchTask": "build-single-file" } ] }关键字段的作用：program必须和tasks.json里-o指定的输出路径对上，这是两份文件之间唯一的强耦合点，改一个必须改另一个。request为launch表示启动新进程，要附加到已有进程才用attach。stopAtEntry设为true会让程序在main入口就停，排查"程序根本没进去"这类问题时很省事。externalConsole在 Windows 上我建议保持false，用集成终端输出；设为true会弹一个独立黑窗口，好处是cin输入体验更接近命令行，坏处是窗口一闪而过时看不到任何错误信息。preLaunchTask指向 4.1 的label，按 F5 时先编译再调试，省掉手动构建这一步。setupCommands里那条-enable-pretty-printing让std::vector、std::string在调试面板里显示成正常内容而不是一堆内部指针，强烈建议保留。
调试会话里值得用的操作不多：F9 切断了点，F10 单步跳过，F11 单步进入，Shift+F5终止。变量面板可以右键"添加到监视"，把sum、nums.size()这类表达式钉住。调用堆栈面板在递归或崩溃时最有用，点任意一帧能直接跳到对应源码行。
4.3 c_cpp_properties.json：红波浪线不等于代码有错
这份文件只服务编辑体验。当#include <iostream>下面出现红色波浪线、跳转std::转到空文件，多半是这里没配好，而不是代码问题。
{ "configurations": [ { "name": "mingw64", "includePath": [ "${workspaceFolder}/**", "D:/toolchain/mingw64/include/**", "D:/toolchain/mingw64/x86_64-w64-mingw32/include/**" ], "defines": ["_DEBUG", "UNICODE", "_UNICODE"], "compilerPath": "D:/toolchain/mingw64/bin/g++.exe", "cStandard": "c17", "cppStandard": "c++17", "intelliSenseMode": "windows-gcc-x64" } ], "version": 4 }compilerPath是这里最重要的字段，填对之后 IntelliSense 会自己去问编译器要系统头文件路径，includePath里其实只需要补项目自己的目录。反过来说，如果compilerPath填错或为空，includePath写再全也还是会报红。intelliSenseMode要和工具链匹配，Windows 上的 GCC 用windows-gcc-x64，填成linux-gcc-x64会导致部分标准库符号解析异常。cppStandard要和tasks.json里的-std保持一致，否则会出现编辑器认为某个语法可用、编译却报错的分裂现象。
改完之后执行一次C/C++: Reset IntelliSense Database，或者重开窗口，让缓存刷新。红波浪线消失但编译仍报错的话，问题一定在tasks.json，两份文件服务的是不同阶段。
4.4 三份配置的联动关系与改法
把改动路径整理成一张表，出问题时按症状查：
| 症状 | 该改的文件 | 具体字段 |
|---|---|---|
| 编译找不到头文件 | tasks.json | args里补-I路径 |
| 断点是灰色、提示未绑定 | tasks.json | 确认-g存在 |
| 按 F5 提示找不到程序 | launch.json | program路径 |
| 按 F5 后直接用旧版本运行 | launch.json | preLaunchTask与 label 是否一致 |
| 调试会话启动失败 | launch.json | miDebuggerPath |
| 头文件报红但能编译 | c_cpp_properties.json | compilerPath、includePath |
| 编辑器标准与编译标准不一致 | 两份都要改 | cppStandard与-std |
这套模板的边界也要说清楚：它只适用于"单文件、无第三方库、无构建系统"的练习场景。一旦项目拆成多个.cpp并需要链接，或者引入 CMake，就该进入第 6 章的做法，硬在这三份文件上打补丁会越来越难维护。
5. 排查清单：五个反复出现的现场与成因
下面五条是我在帮别人看环境时遇到频率最高的，每条都按"看到什么 → 为什么 → 怎么办"写。它们的共同点是都没有明确报错指向根因，只能靠排除法。
5.1 终端闪一下就关、看不到任何输出
现象：按 F5 之后底部终端出现一行命令，随即消失，程序像是没跑。
原因通常是两个。一是externalConsole设为true，程序在独立黑窗口里跑完立即退出，窗口跟着关。二是程序本身没有暂停点，main返回后窗口就没了。前者是配置问题，后者是代码问题。
解决：把externalConsole改回false，输出落到集成终端，历史记录会保留；同时在main的return前加一句std::cin.get();或打个断点，方便看清结果。如果连编译错误都没看到就消失，说明preLaunchTask没有生效，构建失败了但调试器仍尝试启动旧文件——回去检查 label 是不是拼错了。
5.2 中文乱码：源码是 UTF-8，控制台按 GBK 解读
现象：源码里的中文注释和cout中文输出在终端里变成一堆问号或方块。
原因：文件保存编码与控制台代码页不一致。Windows 控制台默认代码页通常是 936（GBK），而多数编辑器默认把文件存成 UTF-8。
解决分两步。先在 VSCode 设置里把files.encoding设为utf8，右下角状态栏确认当前文件确实是 UTF-8。再在tasks.json的args里加"-fexec-charset=GBK"，让编译器把字符串字面量按 GBK 输出。两处对齐之后乱码消失。如果只是自己练习、不打印中文，直接把输出改成英文最省事。
5.3 头文件报红、#include <iostream>找不到
现象：代码能编译能运行，但编辑器里满屏红波浪线，跳转失效。
原因：IntelliSense 的路径索引没建好，和实际构建完全无关。常见触发场景是把项目文件夹从别处拷过来，或者装完扩展后没有重新解析。
解决：打开命令面板执行C/C++: Edit Configurations (UI)，确认"编译器路径"指向g++.exe，IntelliSense 模式选windows-gcc-x64；然后执行C/C++: Reset IntelliSense Database并重开窗口。极少数情况是扩展版本与工具链不匹配，回退一个扩展版本即可。判断标准很简单：能编译通过就说明代码没问题，剩下的都是编辑器索引的事。
5.4 改了代码，跑出来还是旧结果
现象：明明改了cout的内容，运行输出没变化。
原因有三个层次。最浅的是文件没保存，自动保存没开的情况下很常见。其次是program指向的 exe 和tasks.json输出路径不是同一个，调试器跑的是上一次留下的旧文件。最深的是任务根本没执行，preLaunchTask名字对不上，VSCode 静默跳过构建直接启动。
解决：先开files.autoSave；再对照两份配置里的输出路径，确保${fileBasenameNoExtension}.exe在两边写法一致；最后在"终端 → 运行任务"里手动跑一次build-single-file，看它是否真的出现在任务列表里。这一步能一次性排除掉大部分"改了没反应"。
5.5 多版本工具链混用导致的诡异行为
现象：断点能停，但变量显示不全、单步跳行错乱、std::string显示成一串数字。
原因：编译用的g++.exe和调试用的gdb.exe来自不同发行版或不同位数。GDB 对调试信息格式有版本要求，混用时不报错，只是行为异常。
解决：用where g++和where gdb确认两者在同一目录下，且配置文件里miDebuggerPath与其他地方引用的路径一致。统一成一份工具链之后，这类问题会彻底消失。我现在的习惯是——只要新机器上出现任何调试异常，第一件事就是where一遍，而不是先去改 JSON。
6. 进阶：多文件工程、CMake 接管与一套能带走的调试习惯
单文件练习跑通之后，下一步大概率是多文件。把tasks.json里的${file}换成目录通配就能应付小工程：把args中的${file}改成"${fileDirname}/*.cpp"，同时在args开头补"-I"和"${fileDirname}"，让同目录的头文件能被找到。这种写法在文件不多时够用，缺点是每次全量重编，且要求所有.cpp平铺在同一层目录；一旦分src/、include/两层就抓不全，得改成"${workspaceFolder}/src/**/*.cpp"，同时把工作目录cwd设为${workspaceFolder}，输出路径也统一放到bin/下。
文件数超过十个、或者要引入第三方库时，就该让 CMake 接管。装 CMake Tools 扩展，在项目根目录放一份CMakeLists.txt：
cmake_minimum_required(VERSION 3.20) project(cpp_lab LANGUAGES CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) set(CMAKE_EXPORT_COMPILE_COMMANDS ON) # 生成编译数据库，供 IntelliSense 使用 set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_SOURCE_DIR}/bin) file(GLOB_RECURSE SRC ${CMAKE_SOURCE_DIR}/src/*.cpp) add_executable(cpp_lab ${SRC})CMAKE_EXPORT_COMPILE_COMMANDS打开后会生成compile_commands.json，编辑器的 C/C++ 扩展可以直接读它，从此不用再手写includePath。之后走命令面板的CMake: Configure选工具链，CMake: Build构建，调试则用状态栏选择启动目标，launch.json交给扩展自动生成。这套流程的学习成本主要在 CMake 本身，环境配置反而变简单了。file(GLOB_RECURSE)有个众所周知的缺点：新增源文件后不重新 configure 不会被发现，团队项目里通常显式列出源文件，个人练习用通配更省事。
| 场景 | 推荐方式 | 配置文件数量 |
|---|---|---|
| 单文件刷题 | Code Runner 或 tasks.json | 1 |
| 三五个文件的小作业 | tasks.json 通配符 | 3 |
| 有目录结构、引第三方库 | CMake Tools | 1 份 CMakeLists |
| 需要多套构建配置切换 | CMake presets | 2 |
调试技巧上只强调一条：看崩溃不要从"哪里出错"开始猜，先看调用堆栈最内层那一帧的局部变量，再往上翻一层看入参。std::vector越界这类问题，堆栈里往往停在标准库的operator[]上，真正越界的下标在上一层。配合"监视"面板把size()和i一起盯住，比反复加cout快得多。至于断点打在哪里，我的习惯是函数入口一个、循环体内条件断点一个，条件写i == n，只在特定轮次停下。
说个自己的教训。最早搭这套环境时，我把三份 JSON 从网上抄来就再没看过，路径写的是别人的示例目录，某次换机器之后所有项目一起失效，我花了一整晚在插件和扩展版本上折腾，最后发现只是g++.exe的绝对路径不对。从那以后我每次新建项目，都会先跑一遍g++ --version、where g++、where gdb这三条，再确认tasks.json的command、launch.json的miDebuggerPath和c_cpp_properties.json的compilerPath指向同一份工具链，最后才写第一行代码。这套动作花不了一分钟，但省下的时间够写好几个练习。希望帮到你。
本文还有配套的精品资源，点击获取
