cmake在windows上默认不查path中的gcc，需指定-g "mingw makefiles"或-d cmake_c_compiler=完整路径；mingw32-make必须在path中，路径须无空格中文，powershell推荐用正斜杠。
where gcc能用，但cmake ..报No CMAKE_C_COMPILER could be found
这是Windows下最典型的“假通真不通”现象：你确实在CMD里执行where gcc有输出，PATH也加了C:\mingw64\bin，但cmake ..依然失败。根本原因不是CMake坏了，而是它在Windows上默认**完全不查PATH里的gcc/g++**——这个行为和Linux/macOS截然不同。
只有两种情况CMake才会去PATH里找gcc：
- 你明确指定了
-G "MinGW Makefiles"（这时启用MinGW专用探测逻辑） - 你手动用
-DCMAKE_C_COMPILER=传入完整路径（如C:/mingw64/bin/gcc.exe）
没加-G时，CMake默认尝试生成Unix Makefile，但它在Windows上既找不到make，也压根不打算调gcc，直接放弃探测。
cmake -G "MinGW Makefiles" ..仍失败的常见原因
加了-G还不行？别急着重装，先检查这几点：
-
mingw32-make.exe必须在PATH里（不是make.exe，也不是gmake.exe）；CMake用mingw32-make作为构建工具，不是make - 确认
gcc.exe和g++.exe都在同一目录下（比如C:\mingw64\bin），且文件权限正常（无杀毒软件拦截） - 路径含空格或中文？比如
C:\Program Files\mingw64\bin——CMake可能解析失败，建议挪到纯英文无空格路径（如C:\mingw64） - PowerShell里用反斜杠
\容易被转义，写-G "MinGW Makefiles"时确保引号是英文直角引号，不要粘连空格
手动指定编译器路径的可靠写法
绕过PATH依赖、彻底规避探测逻辑，是最稳的方案。注意两点：路径必须是.exe全路径，且区分CMD/PowerShell语法：
- CMD下可直接写：
cmake -DCMAKE_C_COMPILER="C:\mingw64\bin\gcc.exe" -DCMAKE_CXX_COMPILER="C:\mingw64\bin\g++.exe" .. - PowerShell里反斜杠易出错，推荐用正斜杠：
cmake -DCMAKE_C_COMPILER="C:/mingw64/bin/gcc.exe" -DCMAKE_CXX_COMPILER="C:/mingw64/bin/g++.exe" .. -
环境变量方式（CMD）：
set CC=C:\mingw64\bin\gcc.exe & set CXX=C:\mingw64\bin\g++.exe & cmake ..
⚠️ 不要用set CMAKE_C_COMPILER=...——那是无效的，CMake只认命令行-D参数或CC/CXX环境变量。
CMakeLists.txt里写set(CMAKE_C_COMPILER ...)是危险操作
有人图省事，在CMakeLists.txt开头加一句set(CMAKE_C_COMPILER "C:/mingw64/bin/gcc.exe")，结果后续用-D参数覆盖失效，项目在别人机器上直接崩。
原因很简单：set()默认不可重写，一旦在CMakeLists.txt里硬编码，用户传入的-DCMAKE_C_COMPILER=会被忽略。
真正需要统一工具链（比如嵌入式GCC）时，应该用独立的toolchain file，而不是污染主配置文件。普通项目就该把选择权留给命令行——毕竟你没法替所有协作者决定用哪个gcc版本。
最麻烦的从来不是“怎么告诉CMake用谁”，而是“为什么告诉了它还不认”——Windows下PATH被无视、MinGW路径里藏了个空格、VS和MinGW环境变量打架……这些细节漏一个，错误就卡得死死的。
