最稳配置是官方.msi安装并勾选加PATH；验证需在新终端运行cmake --version、cmake -E echo "OK"，并用cmake -G确认生成器可用性，避免仅依赖命令行基础响应。
直接装官方 .msi 并勾选加 PATH，是最稳的配置方式。其他方法（如 zip 解压、Chocolatey、winget）可行，但容易因环境变量没生效或路径冲突导致 cmake --version 找不到命令。
怎么验证 CMake 是否真正可用
很多人执行 cmake --version 看到输出就以为配好了，其实只是“命令能运行”，不代表它能正确调用编译器或生成项目。
- 必须在新打开的终端里运行 —— 修改 PATH 后旧终端不会自动刷新环境变量
- 运行
cmake -E echo "OK"，确认基础命令解析正常 - 如果后续要用 Visual Studio 生成器，运行
cmake -G查看输出中是否包含Visual Studio开头的选项；若没有，说明 VS 没装 C++ 工具或 CMake 没扫描到 - 如果要用 MinGW，先确保
gcc --version和mingw32-make --version都能运行，再试cmake -G "MinGW Makefiles" ..
选哪个生成器（-G）最不容易出错
Windows 上默认不指定 -G 时，CMake 会尝试选一个本地可用的生成器，但结果不可控 —— 可能选 Ninja（没装就报错），也可能选 VS（但版本不对）。
- 开发调试阶段推荐用
-G "Visual Studio 17 2022"（对应 VS 2022）或-G "Visual Studio 16 2019"，前提是已安装对应版本的 “使用 C++ 的桌面开发” 工作负载 - 纯命令行构建、无 VS 环境时，用
-G "MinGW Makefiles"，但必须确保mingw32-make在 PATH 中，且CMAKE_MAKE_PROGRAM未被错误覆盖 - 避免用
-G "Unix Makefiles"—— Windows 下它依赖 MSYS2 或 WSL，不是原生方案，容易卡在 shell 路径或换行符上
VS Code + CMake Tools 插件常见断点失效问题
装了插件、生成了 build 目录、也能编译运行，但按 F5 调试时断点灰色、不命中 —— 这通常不是 CMake 配置问题，而是调试器链路断了。
-
launch.json中program必须指向最终生成的.exe绝对路径，不能写相对路径或依赖${fileDirname}动态计算 -
miDebuggerPath必须填完整路径，即使已加环境变量 —— VS Code 的 CMake Tools 不继承系统 PATH 来找gdb.exe或vsdbg.exe - 如果用 MSVC 工具链，
type应为cppvsdbg，不是cppdbg；后者只认 GDB/LLDB，对vcvarsall.bat加载的调试环境无效 - 检查 CMake 配置是否启用了调试信息：
set(CMAKE_CXX_FLAGS_DEBUG "$ENV{CMAKE_CXX_FLAGS_DEBUG} /Zi")（MSVC）或-g（MinGW），否则生成的二进制里根本没有符号表
PATH 写对只是起点，真正卡住的往往是生成器和调试器之间的隐式约定 —— 比如 VS 工具链默认期望 PDB 文件同名同目录，而 MinGW 默认不生成它。这些细节不显式处理，cmake .. 就算跑过也不会报错，但后续全链路崩得无声无息。
