VSCode运行C++报错90%源于配置文件联动错误：tasks.json中command需用绝对路径、args须含-g和-std=c++17、输出路径须与launch.json的program完全一致；preLaunchTask必须与task label逐字匹配；compilerPath须指向g++.exe而非gcc.exe；miDebuggerPath需显式指定gdb.exe路径。
VSCode 运行 C++ 报错，90% 不是代码问题，而是 tasks.json 和 launch.json 里路径、标签或参数没对上——尤其 preLaunchTask 和 label 大小写不一致、program 指向的文件根本没生成，或者 gdb.exe 路径写错后缀或漏了反斜杠。
tasks.json 编译任务总失败：command 找不到或 args 不生效
Windows 下 tasks.json 里写 "command": "g++" 很容易失败，因为 VSCode 的 task shell 环境不一定继承系统 PATH（尤其重启后未刷新终端）。这不是环境变量没配好，而是 task 自身没加载它。
- 最稳写法是用绝对路径：
"command": "C:\mingw64\bin\g++.exe"（双反斜杠）或"command": "C:/mingw64/bin/g++.exe"（正斜杠也行） -
args必须包含-g（否则调试时看不到变量）、-std=c++17（避免if constexpr等语法报错），且-o输出路径要和launch.json中program完全一致 - 输出名推荐用
"${fileDirname}\${fileBasenameNoExtension}.exe"，比如main.cpp→main.exe；别写成a.exe或硬编码hello.exe，否则换文件就崩 - 如果项目含多个
.cpp文件，args不能只写"${file}"，得列全："${fileDirname}\*.cpp"（注意 Windows 不支持 shell 通配符展开，稳妥起见还是手动列）
launch.json 报 “program ‘…/main.exe’ does not exist”
这个错误不是 launch.json 写错了，而是 tasks.json 根本没执行成功，或者执行了但输出路径和 program 对不上。VSCode 调试器不会自动编译，它只找现成的可执行文件。
-
preLaunchTask字段值必须和tasks.json里对应 task 的label**逐字匹配**（包括空格、大小写），例如"label": "g++ build active file"，那这里就得写"preLaunchTask": "g++ build active file" -
program推荐写成"${fileDirname}\${fileBasenameNoExtension}.exe"，和 tasks 输出保持同目录、同名；不要写"./main.exe"或"${workspaceFolder}\main.exe"，除非你真把 exe 放那儿了 -
miDebuggerPath必须显式指定，比如"C:\mingw64\bin\gdb.exe"；漏掉这行，Windows 下会报spawn gdb ENOENT -
cwd设为"${fileDirname}"更合理——程序运行时需要读取同目录下的文件（如配置、输入），而不是工作区根目录
IntelliSense 报 “cannot open source file ‘vector’”
这不是编译器问题，是 c_cpp_properties.json 里的 compilerPath 没指向 C++ 编译器，或者指向了 gcc.exe 而非 g++.exe。IntelliSense 依赖编译器路径来解析标准库头文件路径。
立即学习“C++免费学习笔记（深入）”；
- 务必用
"compilerPath": "C:\mingw64\bin\g++.exe"（不是gcc.exe），否则#include <string>、<vector>全红 - 不要手动填
includePath，扩展会根据compilerPath自动推导；手填容易漏 UCRT 或 win32 API 路径 - 验证方式：打开命令面板（
Ctrl+Shift+P），运行C/C++: Edit Configurations (UI)，点右下角放大镜图标让扩展自动扫描 PATH 中的编译器——选中g++.exe即可 - 如果仍报错，检查 MinGW 安装时是否选了
win32线程模型 +seh异常处理；选posix会导致libwinpthread路径不被 IntelliSense 自动识别
GDB 调试时断点不命中或直接闪退
断点失效往往不是配置错，而是编译没带 -g，或 MinGW 线程模型与调试器不兼容；控制台闪退则是因为 externalConsole 设为 false 后，程序跑完窗口立刻关闭。
- 确认
tasks.json的args包含-g，且没有被其他参数（如-O2）覆盖；优化选项可能内联函数导致断点跳过 - MinGW 必须选
win32线程模型（不是posix），否则 GDB 无法正确挂起线程，表现为“断点灰色不可用”或“Unable to start debugging” - 想看控制台输出又不想闪退，设
"externalConsole": true，并确保system("pause")或getchar()在main()结尾；设false时，输出会打在 VSCode 集成终端里，但无交互能力 - 如果 gdb 启动卡住或报
Failed to launch program，检查杀毒软件是否拦截了gdb.exe—— 临时禁用或加白名单
真正卡住人的地方，从来不是“怎么配”，而是 tasks.json 和 launch.json 之间那几处看似微小的路径、标签、参数联动；改完一个文件，必须同步核对另一个，缺一不可。
