确认g++真正可用需在cmd中运行where.exe g++定位路径，再进该目录执行g++ --version验证输出含x86_64-win32-seh；路径须纯英文无空格，删净旧gcc冲突文件，重置intellisense数据库。
VSCode 本身不带编译器，所有“g++ not found”“preLaunchTask terminated”“undefined reference to `WinMain'”类报错，根源都在底层工具链没装对、或装歪了——不是插件问题，也不是 VSCode 设置问题。
怎么确认 g++ 真的可用？别信 where g++
PowerShell 的 where g++ 常返回空或错误路径，因为它是别名，实际调用的是 Get-Command，可能漏掉非标准路径下的可执行文件。真正可靠的方式是：
- 打开 CMD（不是 PowerShell），运行
where.exe g++—— 这才是 Windows 原生命令 - 再手动进到该路径，执行
g++ --version，看输出是否含x86_64-posix-seh或x86_64-win32-seh - 如果版本号后面跟着
posix但异常处理标的是dwarf，说明线程模型和异常机制不匹配，std::thread或catch(...)很可能崩溃
MinGW-W64 安装路径里有中文或空格？直接放弃
哪怕只是 C:\Users\张三\Desktop\mingw64 这种路径，也会导致 tasks.json 中的 ${file} 展开失败、GDB 调试时符号加载为空、甚至 #include <bits></bits> 报找不到头文件——这不是 bug，是 MinGW-W64 工具链自身对路径编码的硬限制。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 必须使用纯英文、无空格、无括号的路径，例如
C:\dev\mingw64或D:\tools\mingw1320 - 解压后立刻检查
C:\dev\mingw64\bin\g++.exe是否真实存在，右键属性 → “详细信息”里确认文件版本与描述匹配 - 若曾用过 TDM-GCC、旧版 MinGW、MSYS2 自带的 GCC，请先删干净——它们的
libgcc_s_seh-1.dll会和新版冲突，导致程序一运行就闪退
tasks.json 编译命令写错一个参数，就 link 失败
VSCode 默认生成的 tasks.json 往往只编译单文件，而 C++ 多文件项目一旦涉及 main() 以外的函数定义，就会报 undefined reference。关键不在“有没有写 g++”，而在参数顺序和链接逻辑：
-
-c只编译不链接，适合生成 .o；多文件必须去掉它，改用g++ *.cpp -o main.exe - Windows 下必须显式加
-static-libgcc -static-libstdc++，否则运行时缺 DLL - 如果用了
std::filesystem，得额外加-lstdc++fs；用std::regex可能要-lpcre（取决于 MinGW 版本） -
"args"数组里，"${file}"和"${fileDirname}/*.cpp"是两回事：前者只编当前文件，后者才扫同目录所有源码
launch.json 调试启动失败？大概率是 gdb 路径或 cwd 错了
即使 g++ 能编译出 exe，launch.json 仍可能卡在“无法启动调试会话”。常见原因不是 GDB 没装，而是：
-
miDebuggerPath指向了gdb.exe，但实际路径是C:\dev\mingw64\bin\gdb.exe—— 必须写绝对路径，不能用变量 -
cwd（当前工作目录）设成"${fileDirname}"，但你的程序依赖相对路径读配置文件，结果找不到config.txt - MinGW-W64 13.2.0 自带的
gdb.exe在某些 Windows 版本上需以管理员权限运行才能 attach 进程，否则报Operation not permitted
最易被忽略的一点：VSCode 的 C/C++ 插件缓存会记住上次失败的 IntelliSense 配置，即使你重装了 MinGW，它仍可能沿用旧的 compilerPath 和 includePath。务必手动打开命令面板（Ctrl+Shift+P），执行 C/C++: Reset IntelliSense Database，再重启窗口。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
