VSCode本身不编译也不调试，只是封装g++、gdb等外部工具；报错根源在于路径、参数或上下文配置错误，需依次排查环境变量继承、compilerPath写死、tasks.json/launch.json变量有效性及MSYS2特有的gdb路径与externalConsole设置。
VSCode 本身不编译、不调试，它只是把 g++、gdb 这些命令封装成可点击操作的界面流程。你配错的不是“VSCode”，而是 VSCode 调用外部工具时的路径、参数或上下文——这是绝大多数人卡住的根本原因。
为什么 g++ --version 在 cmd 里能跑，但在 VSCode 终端里报错？
常见现象：你在 Windows 的 CMD 或 PowerShell 里输入 g++ --version 正常返回，但打开 VSCode 内置终端（Ctrl+`）后却提示“g++ 不是内部或外部命令”。
本质是终端继承的环境变量不同：
- 系统级 PATH 修改后，**已打开的 VSCode 进程不会自动刷新环境变量**，必须完全关闭 VSCode（包括后台进程）再重启
- VSCode 内置终端默认启动的是 PowerShell（Win10/11），而某些 MinGW 安装包（如 MSYS2 的 UCRT64）只向 CMD 的 PATH 注册，PowerShell 可能读不到
- 如果你用的是 MSYS2 安装的 MinGW-w64，它的
g++实际在ucrt64in或mingw64in下，但你只加了msys64usrin——这个路径里只有 shell 工具，没有编译器
验证方式：在 VSCode 终端里运行 $env:PATH -split ';' | Select-String mingw（PowerShell）或 echo %PATH%（CMD），确认输出中确实包含你解压/安装 MinGW 的 bin 目录（例如 C:msys64ucrt64in）。
立即学习“C++免费学习笔记（深入）”；
c_cpp_properties.json 里的 compilerPath 必须写死，不能靠猜测
即使 g++ 命令全局可用，VSCode 的 IntelliSense（代码补全、跳转、波浪线检查）也**完全不依赖 PATH**，它只认 c_cpp_properties.json 里写的 compilerPath。写错就会：头文件标红、std::vector 无法识别、#include <bits/stdc++.h> 报错。
正确做法：
- 先在终端里运行
where g++（Windows）或which g++（WSL），得到完整路径，比如C:msys64ucrt64ing++.exe - 在 VSCode 中按 Ctrl+Shift+P → 输入
C/C++: Edit Configurations (UI)→ 在 “Compiler path” 栏粘贴上面的路径 - 确保 “IntelliSense mode” 对应选
gcc-x64（MinGW-w64）或clang-x64（Clang），别选msvc-x64（那是 Visual Studio 的） - 保存后，VSCode 底部状态栏会显示 “Tag parsing finished”，这时再看波浪线是否消失
tasks.json 和 launch.json 的路径变量不是万能的
很多人复制网上的 tasks.json 示例，里面用 "${file}" 或 "${fileDirname}${fileBasenameNoExtension}.exe"，结果一编译就失败，错误信息像：g++.exe: error: no input files 或 Cannot launch program 'xxx.exe' (error code = 2)。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
问题出在两个地方：
-
"${file}"只在当前编辑的文件被保存后才有效；如果文件是新建未保存的（如Untitled-1），这个变量为空，g++就收不到源文件路径 -
"${fileDirname}\${fileBasenameNoExtension}.exe"在 Windows 上反斜杠如果没转义，JSON 会解析失败；更稳妥写法是用正斜杠/或双反斜杠\ -
launch.json中的"program"必须指向**已成功生成的 .exe 文件**，不是源文件；如果tasks.json没执行成功，这里必然失败
建议初学者先手动在终端里跑通一句编译命令，比如：g++ -g hello.cpp -o hello.exe，再把这整行复制进 tasks.json 的 "command" 和 "args" 字段，避免变量陷阱。
MSYS2 用户最容易忽略的 gdb 路径和控制台模式
用 MSYS2 安装的 MinGW-w64（如 UCRT64），它的 gdb 默认在 ucrt64ingdb.exe，但 VSCode 的 C/C++ 扩展有时会错误地去找 msys64usringdb.exe（那个是旧版，不支持 Windows 原生调试）。
同时，launch.json 里 "externalConsole": true 是关键：
- 设为
false（默认）：程序输出直接打在 VSCode 调试控制台，但std::cin会卡住，因为没真正连接到 Windows 控制台 - 设为
true：弹出独立 cmd 窗口，cin正常工作，但你需要手动关掉窗口，否则下次调试会报错“端口被占用”
如果你用的是 MSYS2 的 UCRT64 工具链，launch.json 中必须显式指定：
"miDebuggerPath": "C:\msys64\ucrt64\bin\gdb.exe",
而不是留空或填错路径。少一个字符，F5 就只会显示 “Unable to start debugging”。
真正的难点从来不在“怎么配”，而在于理解 VSCode 只是管道工——它不生产 g++，也不理解 C++，它只负责把你的配置翻译成一条条命令，扔给系统去执行。一旦某处路径、权限、上下文对不上，整条链就断了。盯住终端输出的具体错误文字，比照着查 g++、gdb、PATH、compilerPath 四个点，90% 的问题当场解决。
