vscode终端无法识别g++说明其未继承更新后的path，需完全退出vscode进程并重启；验证方法为对比echo %path%输出与cmd中是否一致，不一致则环境未刷新。
g++ --version 在 CMD 里能用，但在 VSCode 终端报错
这说明 MinGW 已正确安装且系统 PATH 设置无误，问题出在 VSCode 进程没继承更新后的环境变量。Windows 下，图形界面启动的程序（比如双击 VSCode 图标）不会自动加载新配置的 PATH，除非你完全退出所有 VSCode 实例（包括任务栏后台进程），再重新打开。
验证方法：在 VSCode 集成终端中执行 echo %PATH%，复制输出，粘贴到 CMD 中对比——如果关键路径（如 C:msys64mingw64in）缺失，就是环境未刷新。
- 关闭所有 VSCode 窗口，右键任务栏图标 → “退出”，确保进程结束
- 按
Ctrl+Shift+Esc打开任务管理器，搜索Code.exe，结束全部相关进程 - 重新启动 VSCode，再进终端运行
g++ --version - 若仍失败，尝试注销 Windows 账户再登录（比重启更轻量）
tasks.json 里 command 写相对路径还是绝对路径？
写绝对路径更可靠。VSCode 的 tasks.json 默认不依赖 shell 的 PATH 查找机制，尤其当终端类型是 PowerShell 或未启用 login shell 时，"command": "g++" 很可能直接失败。
你应该明确指向可执行文件，例如：
{
"command": "C:\msys64\mingw64\bin\g++.exe",
"args": ["-g", "${file}", "-o", "${fileDirname}\${fileBasenameNoExtension}.exe"]
}
注意：\ 是 Windows JSON 字符串中的转义要求；路径必须和你实际安装位置一致，比如用 MSYS2 安装的 UCRT64 工具链，路径通常是 C:msys64ucrt64ing++.exe。
- 别用
gcc当 C++ 编译器，它默认按 C 语言规则处理，g++才链接标准 C++ 库 - 如果路径含空格或中文，VSCode 任务大概率崩溃，务必避免
- 改完
tasks.json后，需重新触发构建（Ctrl+Shift+B），不会自动热重载
为什么 launch.json 里 preLaunchTask 能运行，但断点不生效？
常见原因是 miDebuggerPath 指向了错误的 gdb.exe，或者 GDB 版本与 MinGW 不匹配。VSCode 调试器（cppdbg）靠 GDB 控制断点、单步等行为，如果 GDB 启动失败或无法读取调试符号，断点就只是灰色圆圈，点击无响应。
检查点：
-
miDebuggerPath必须是完整路径，例如C:\msys64\mingw64\bin\gdb.exe，不能只写gdb - 确保
g++ -g编译时生成了调试信息（tasks.json的args里必须有-g） - 确认
gdb.exe和g++.exe来自同一工具链（比如都来自mingw64，而非混用ucrt64和mingw64） - 如果用 MSYS2 安装，优先选
UCRT64终端安装的工具链，它对 Win11/2022 兼容性更好
PATH 里有多个 MinGW 路径，哪个该保留？
只留一个，且必须是最新、最匹配当前 Windows 子系统的那个。常见冲突路径包括：C:MinGWin（老旧）、C:msys64mingw64in（传统 MinGW-w64）、C:msys64ucrt64in（推荐，支持 UCRT 运行时，兼容性更强）。
查清当前生效的是哪一个：
在 VSCode 终端中运行：Get-Command g++ | Select-Object Source（PowerShell）或 where g++（CMD）
- 如果返回多个结果，说明 PATH 顺序混乱，删掉旧路径（尤其是
C:MinGW或 Cygwin 相关路径） - 把首选路径（如
C:msys64ucrt64in）移到 PATH 列表最前面 - MSYS2 用户注意：
ucrt64工具链对应 UCRT64 终端，mingw64对应 MINGW64 终端，二者不混用 - 修改 PATH 后，必须彻底重启 VSCode，否则终端仍沿用旧环境
最易被忽略的一点：VSCode 的集成终端是否启用了 login shell。Windows 用户虽不常涉及 shell 配置文件，但 macOS/Linux 用户若用 zsh/bash，必须设置 terminal.integrated.shellArgs 为 ["-l"]，否则 ~/.zshrc 里的 PATH 补充不会生效——而这个设置，在 Windows 上反而可能引发 PowerShell 启动异常，所以别盲目套用。
