VSCode中task.json需用绝对路径指定g++（如"C:msys64ucrt64ing++.exe"），args显式写"${file}"、"-o"及输出路径，必须含"group": "build"且文件名小写tasks.json置于.vscode/下，调试前须通过preLaunchTask联动确保可执行文件已生成。
VSCode里task.json怎么写才能正确调用g++编译
关键不是“写对语法”，而是让task.json里的命令和你本地实际的g++路径、参数逻辑一致。很多人配完没反应，其实是command字段写成了"g++"，但系统根本找不到——尤其在Windows上没装MinGW或没加环境变量时，VSCode压根不认这个命令。
实操建议：
- 先在终端里手动跑一遍
g++ --version，确认能执行；不行就去MinGW或WSL里找真实路径，比如"C:\msys64\ucrt64\bin\g++.exe" -
args里必须显式指定输入输出："${file}"（当前文件）、"-o"、"${fileDirname}\${fileBasenameNoExtension}.exe"（Windows）或"${fileDirname}/${fileBasenameNoExtension}"（macOS/Linux） - 别漏掉
"group": "build"，否则Ctrl+Shift+B不会默认选中它 - 如果用了C++17特性，加
"-std=c++17"；头文件在子目录？补"-I./include"
为什么Ctrl+Shift+B没弹出你的编译任务
VSCode只在当前工作区有.vscode/tasks.json且至少一个任务带"group": "build"时，才把该任务列进构建菜单。没有这个字段，或者文件不在工作区根目录下，快捷键就失效。
常见错误现象：
立即学习“C++免费学习笔记（深入）”；
- 把
tasks.json放在用户级配置里（%USERPROFILE%AppDataRoamingCodeUser asks.json），它只影响全局终端，不参与项目构建 - 文件名写成
task.json或Tasks.json——必须是全小写tasks.json，且在.vscode/子目录下 - 多个任务都标了
"group": "build"，但没设"presentation": {"echo": true, "reveal": "always", "focus": false, "panel": "shared"}，导致输出被吞掉，你以为没运行
调试前要不要先生成可执行文件：launch.json和task.json怎么联动
VSCode的C++调试器（cppdbg）本身不编译，它只运行已存在的二进制。所以launch.json里的program字段必须指向一个**已经存在**的可执行路径，不能指望调试时自动编译。
可靠做法是用前置任务（preLaunchTask）绑定：
- 在
launch.json里写"preLaunchTask": "g++ build active file"，名字必须和tasks.json里对应任务的label完全一致（区分大小写） - 确保那个任务的
dependsOn或自身逻辑能覆盖所有依赖，比如多文件项目要改args为"${fileDirname}/*.cpp"，否则只编当前文件 - 如果
program路径写错（比如Windows下写了.out后缀），调试器会报Cannot launch program 'xxx': File not found，而不是编译失败
Windows下MinGW和MSVC混用导致task.json失效
同一台机器装了Visual Studio和MinGW，VSCode可能默认调用cl.exe（MSVC编译器），但tasks.json里写的却是g++参数（比如-std=c++17），结果报一堆不识别的选项错误。
判断依据很简单：
- 看终端输出第一行是不是
g++.exe: error: unrecognized command-line option '-std=c++17'——这是MSVC在冒充g++ - 检查
command是否真的指向g++.exe，而不是靠环境变量模糊匹配 - 更稳妥的做法：在
tasks.json里用绝对路径+完整文件名，彻底绕过PATH查找逻辑 - 如果必须切工具链，改
command的同时，把args里的-std换成/std:c++17，-o换成/Fe:，否则参数直接被忽略
真正麻烦的不是配置步骤，而是编译器行为差异藏在参数细节里——比如g++ -O2和cl /O2对内联函数的处理就不一样，但task.json里看不出这点。得看输出日志里实际执行的是哪个命令。
