g++ --version有输出不代表真正可用，还需验证头文件定位、标准库链接和二进制运行能力；windows须用cmd的where.exe g++查路径，linux/macos需用g++ -v -e /dev/null确认包含路径及g++ -x c++ - -o /dev/null测试链接。
g++ --version 能输出就代表可用？不一定
很多用户看到 g++ --version 有输出就以为万事大吉，但实际运行 g++ main.cpp -o main 仍报错，根源常在路径、ABI 或环境隔离上。真正“可用”意味着：命令可调用 + 头文件能定位 + 标准库能链接 + 生成的二进制能运行。
Windows 下必须用 CMD 运行 where.exe g++
PowerShell 的 where g++ 是别名，可能返回空或错误路径；CMD 中的 where.exe g++ 才是原生命令，结果可信。
- 打开 CMD（不是 PowerShell），执行
where.exe g++ - 若无输出，说明系统 PATH 没包含 g++ 所在目录，或根本没安装
- 若有输出（如
C:\dev\mingw64\bin\g++.exe），立刻 cd 进该目录，再运行g++ --version - 检查输出末尾是否含
x86_64-win32-seh（推荐）或x86_64-posix-seh；若出现dwarf，std::thread或异常捕获大概率崩溃
Linux/macOS 验证要分三层
仅 g++ --version 成功还不够，得确认头文件和标准库路径是否真实可读。
- 运行
g++ -v -E /dev/null（注意小写-v加-E），看输出末尾的#include search starts here:区域 - 确认列出的路径（如
/usr/include/c++/13）存在且非空：ls /usr/include/c++/13/iostream应能显示文件 - 若路径指向旧版本（如
/usr/include/c++/9），但系统已装 GCC 13，说明update-alternatives或软链接未更新，需手动修复 - 验证链接能力：
echo "int main(){return 0;}" | g++ -x c++ - -o /dev/null—— 不报undefined reference to `main'才算过链
VSCode 里 g++ 报错不是插件问题
VSCode 自身不带编译器，“g++ not found”“preLaunchTask terminated”这类错误 100% 是底层工具链没配对，和 C/C++ 插件设置无关。
- 确保
g++在 CMD/Terminal 中全局可用，而不是只在某个 shell 启动脚本里临时加了 PATH - MinGW-W64 安装路径含中文、空格或括号（如
C:\Users\张三\Desktop\mingw）会导致${file}展开失败、GDB 加载符号为空、#include <bits></bits>直接报错 - 曾装过 TDM-GCC、旧版 MinGW 或 MSYS2 自带 GCC？删净所有残留的
libgcc_s_seh-1.dll，否则程序一运行就闪退 - 改完 PATH 后，务必重启 VSCode 全局实例（不只是窗口），否则 IntelliSense 数据库不会重载
最易被忽略的一点：g++ 可用 ≠ C++ 编译可用。你用 gcc main.cpp -o main 依然会报 iostream: No such file or directory —— 因为 gcc 默认不搜 C++ 头文件路径，也不链接 libstdc++。验证时一定用 g++ 命令，别手滑敲成 gcc。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
