必须加-G参数，因为Windows下cmake默认调用Visual Studio生成器（如vcxproj），而非MinGW；不指定则生成的构建文件无法被mingw32-make识别，导致编译失败。
cmake .. -G "MinGW Makefiles" 为什么必须加 -G 参数？
Windows 下 cmake .. 默认调用 Visual Studio 生成器（比如 Visual Studio 17 2022），即使你装了 MinGW，它也不会自动用——除非你明确告诉它用哪个。不加 -G 就直接跑 cmake ..，大概率生成的是 vcxproj 文件，后续 make 或 mingw32-make 根本不认识，会报错：make: *** No targets. Stop. 或 sh: make: command not found。
常见写法：
-
cmake .. -G "MinGW Makefiles"—— 对应mingw32-make -
cmake .. -G "Ninja"—— 需提前装 Ninja，之后用ninja编译（更快） -
cmake ..（无-G）—— 默认走 MSVC，后续得用cmake --build .，不能用make
mingw32-make 和 make 哪个该用？
在 MinGW 环境下，mingw32-make 是官方推荐、最稳妥的选择。虽然很多教程写 make，但 Windows 上的 make 可能来自其他工具链（比如 Git for Windows 自带的 make），行为不一致，偶尔会卡在依赖解析或路径分隔符（\ vs /）上。
实操建议：
- 优先用
mingw32-make，确保它是 MinGW 安装包自带的版本（检查mingw32-make --version输出含mingw32） - 如果提示
'mingw32-make' is not recognized，说明bin/没进PATH，或者你装的是 MSYS2 的make（它叫make，不是mingw32-make） - 不用刻意 alias
make→mingw32-make，容易混淆不同环境
build 目录必须是空的吗？
不是“必须空”，但强烈建议每次新建干净的 build 目录。CMake 的缓存（CMakeCache.txt）和生成的 Makefile 绑定极强：改过 CMakeLists.txt 后，如果只运行 cmake .. 而没清缓存，它可能复用旧配置，导致 add_executable 名字没更新、源文件没重扫描、甚至链接失败却报错位置诡异。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
安全做法：
- 删掉整个
build目录再重新mkdir build && cd build - 或者保留目录但强制重配置：
cmake -B build -S . -G "MinGW Makefiles"（-B和-S是现代写法，更清晰） - 别用
cmake .在源码根目录直接生成——污染源码，且 Windows 下容易因权限或长路径出问题
编译后 exe 名字怎么控制？
exe 名字完全由 CMakeLists.txt 中的 add_executable() 第一个参数决定，和文件名无关。比如：
add_executable(mytool src/main.cpp)
生成的就是 mytool.exe，不是 main.exe。很多人写完代码发现找不到 main.exe，就是因为 CMake 里写了别的名字。
注意点：
-
add_executable()名字里**不能含空格或特殊字符**，否则 Windows 下生成失败或运行报错 - 名字区分大小写，但 Windows 文件系统不敏感，
MyTool.exe和mytool.exe实际是同一个文件 - 如果用了
project(MyProj)，默认生成的 target 名就是MyProj，但显式写add_executable会覆盖它
CMake 在 Windows 上最易被忽略的其实是生成器绑定和 build 目录状态——这两点一错，后面所有命令都像在猜谜。
