运行cmake -G可列出当前平台所有可用生成器并标出默认项（带*），单配置生成器需配置时用-DCMAKE_BUILD_TYPE指定构建类型，多配置生成器则在cmake --build时用--config选择。
直接用 -G 指定生成器，不指定就走默认——但默认值依赖平台和 CMake 版本，不能靠猜。
怎么查当前平台支持哪些生成器
运行 cmake -G（注意后面不跟任何参数），CMake 会列出所有在当前系统上可用的生成器，并标出带 * 的默认项。比如 Windows 上常见默认是 Visual Studio 17 2022，Linux 上通常是 Unix Makefiles。
- 输出里没出现你想要的生成器？说明它根本不可用——比如没装 Visual Studio 就别想用
Visual Studio 17 2022 -
cmake --help也能看到生成器列表，但不如cmake -G直观 - 某些生成器名称带空格或版本号，必须加英文双引号，例如：
cmake -G "Ninja"、cmake -G "Visual Studio 17 2022"
单配置 vs 多配置生成器对构建流程的影响
生成器类型决定了 CMAKE_BUILD_TYPE 什么时候生效，也影响后续 cmake --build 的写法：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
单配置生成器（如
Ninja、Unix Makefiles）：构建类型必须在cmake配置阶段指定，例如：cmake -S . -B build -G Ninja -DCMAKE_BUILD_TYPE=Release -
多配置生成器（如
Visual Studio 17 2022、Xcode）：配置时不指定构建类型，而是在构建时用--config参数选择，例如：cmake --build build --config Release - 混用会失败：用
Ninja却在cmake --build里加--config Debug，会报错Unknown argument --config
生成器选错会导致编译器/链接器不按预期工作
生成器不仅决定项目文件格式，还隐式绑定工具链：
- 在 macOS 上用
Ninja，CMake 默认调用clang++和ld；换成Xcode生成器，就走 Xcode 自带的 toolchain - Windows 上用
MinGW Makefiles会找gcc，而Visual Studio 17 2022默认用MSVC，哪怕你装了 MinGW 也不会自动切过去 - 交叉编译时尤其关键：选
Ninja+ 手动设CMAKE_TOOLCHAIN_FILE是主流做法；选Visual Studio生成器做交叉编译则非常受限，基本不可行
环境变量 CMAKE_GENERATOR 能省事但容易埋坑
设了这个变量后，cmake -S . -B build 就不用每次敲 -G，但要注意：
- 变量只对当前 shell 有效，不是全局永久设置
- 如果同时传了
-G参数，它会覆盖环境变量值 - CI 环境里设错变量，可能导致本地能过、CI 构建失败，且错误信息不明显
- 多人协作时，最好显式写在脚本里，别依赖隐式环境变量
真正麻烦的不是选哪个生成器，而是选完之后没意识到它绑定了编译器、决定了构建类型传递时机、还可能让交叉编译路径突然失效——这些细节不踩一次坑很难记住。
