vs code配置cmake项目需按cmake逻辑执行：先用cmake -s -b生成构建系统，再用cmake --build编译；launch.json的program必须指向构建输出的含调试符号的可执行文件，路径须为绝对路径且与构建类型匹配。
能用，但得按 CMake 的逻辑来，不是装完插件点一下就跑起来。VS Code 本身不编译代码，它靠 CMake Tools 插件读 CMakeLists.txt，再调用你本地的编译器（比如 g++ 或 cl）生成可执行文件。中间任何一环断掉——比如环境变量没设对、CMakeLists.txt 写错、构建目录权限不对——都会卡在“找不到构建目标”或“调试按钮灰色”这种地方。
cmake --build 和 cmake -S/-B 是什么关系？
这是最常被混淆的两个命令，它们不是替代关系，而是分工关系：cmake -S 指定源码路径，-B 指定构建目录，作用是“生成构建系统”（比如 Ninja 的 build.ninja 文件）；cmake --build 则是在已生成的构建系统上真正执行编译链接。
-
cmake -S . -B build：告诉 CMake “源码在当前目录，构建产物放build/文件夹里”，运行后build/下会出现一堆中间文件和构建配置 -
cmake --build build：只负责调用 Ninja 或 Make 去干活，不会重新解析CMakeLists.txt - VS Code 的
CMake Tools插件默认就是按这套流程走的：先执行cmake -S -B，再执行cmake --build。如果你手动删了build/目录，下次构建会自动重建；但如果你只改了源码没改CMakeLists.txt，它通常跳过-S -B阶段，直接--build
为什么 launch.json 里不能直接写 g++ 命令？
因为 VS Code 调试器（GDB/LLDB）需要的是已编译好的二进制文件路径，不是编译命令。你在 launch.json 里填的 program 字段，必须指向 cmake --build 输出的可执行文件，比如 "program": "${workspaceFolder}/build/helloworld.exe"。
- 如果填错路径（比如写成
./main.cpp或./build/main.cpp），调试器启动时会报Cannot find executable - 如果构建类型是
Debug但launch.json指向了Release目录下的文件，断点可能无法命中——因为Release默认不带调试符号 -
CMake Tools插件会在状态栏显示当前激活的构建类型（如Debug），这个值决定了cmake -B生成的构建配置，也决定了cmake --build输出的二进制是否含调试信息
build 目录放在哪才不容易出问题？
别放桌面、别放 C:\Program Files、别放带中文或空格的路径。Windows 上最稳妥的是放在项目根目录下，比如 ${workspaceFolder}/build，并用 settings.json 固定下来：
{
"cmake.buildDirectory": "${workspaceFolder}/build"
}
- VS Code 默认会在项目根目录建
build/，但如果之前手动删过，或者多人协作时有人改过设置，就容易出现“找不到构建缓存”错误 - 如果项目要同时支持
Debug和Release，建议用"${workspaceFolder}/build/${buildType}"，这样两个构建互不干扰，切换构建类型时不用清空整个build/ - MinGW-w64 用户尤其注意：不要把
build/放在 MinGW 安装目录里（比如D:\mingw64\build），CMake 可能因权限或路径长度报错
真正的麻烦往往不在写代码，而在构建系统和编辑器之间那几层抽象没对齐——比如你以为 CMakeLists.txt 里写了 add_executable(myapp main.cpp) 就万事大吉，结果发现 main.cpp 文件名拼错了，或者 build/ 目录被 Git 忽略导致别人拉代码后第一次构建失败。这些细节不显眼，但卡住的时候，90% 的时间都花在查它们上。
