结论：CMake在Windows上报“No CMAKE_C_COMPILER could be found”90%不是没装编译器，而是默认不查PATH，必须通过-G指定生成器、-D硬编码路径或在VS开发者命令提示符中运行才能被识别。
直接说结论：CMake 在 Windows 上报 No CMAKE_C_COMPILER could be found，90% 不是编译器没装，而是它根本“看不见”你装的编译器——Windows 下 CMake 默认不查 PATH，必须显式告诉它用谁、怎么用。
为什么 where gcc 能找到，cmake .. 却报错？
CMake 在 Windows 上的编译器发现机制和 Linux/macOS 完全不同：它默认跳过 PATH 搜索，只依赖三类线索：
- 你是否指定了生成器（
-G），比如-G "MinGW Makefiles"或-G "Visual Studio 17 2022" - 你是否通过环境变量（
CC/CXX）或命令行参数（-DCMAKE_C_COMPILER=...）硬编码了路径 - 你是否在正确的 shell 里运行（比如 VS 的“开发者命令提示符”，它会自动注入
cl.exe环境）
所以即使 gcc 已在 C:mingw64in 并加入 PATH，普通 CMD/PowerShell 里跑 cmake .. 依然失败——CMake 压根不会去 PATH 里翻。
cmake -G "MinGW Makefiles" .. 为什么必须加 -G？
不加 -G 时，CMake 默认尝试生成 Unix 风格的 Makefile，但它在 Windows 上找不到 make（也没 g++ 可调），于是直接放弃编译器探测。加上 -G "MinGW Makefiles" 后，CMake 就知道该去找 gcc/g++，并启用 MinGW 专用的探测逻辑（这时才会看 PATH）。
常见有效生成器值：
-
-G "MinGW Makefiles"→ 对应mingw32-make.exe，要求gcc在PATH -
-G "Ninja"→ 更快，但需提前装好ninja.exe并在PATH -
-G "Visual Studio 17 2022"→ 必须从 VS 开发者命令提示符中运行，否则cl.exe不可见
注意：-G 参数必须放在 cmake 命令最前面，且不能带空格（-G"MinGW Makefiles" 也合法，但 -G "MinGW Makefiles" 更稳妥）。
手动指定编译器路径的两种可靠写法
当自动探测不可靠（比如多版本 GCC 共存、路径含空格、或想绕过 PATH 依赖），直接锁定编译器最稳：
- 命令行一次性指定：
cmake -DCMAKE_C_COMPILER="C:/mingw64/bin/gcc.exe" -DCMAKE_CXX_COMPILER="C:/mingw64/bin/g++.exe" .. - 环境变量方式（CMD）：
set CC=C:mingw64ingcc.exe & set CXX=C:mingw64ing++.exe & cmake ..
⚠️ 路径必须是完整可执行文件路径（带 .exe），不能只写目录；反斜杠 在 CMD 中没问题，但在 PowerShell 里建议用正斜杠 / 或双反斜杠 \，避免转义问题。
VS 用户别跳过 vcvarsall.bat
装了 Visual Studio 却仍报错？大概率因为你没在“开发者命令提示符”里运行，或者没手动加载环境。CMake 需要 cl.exe 所在的完整工具链路径（含 SDK、库、头文件），这些由 vcvarsall.bat 注入。
手动加载方法（CMD）：
call "C:Program FilesMicrosoft Visual Studio2CommunityVCAuxiliaryBuild cvarsall.bat" x64 cmake -G "Visual Studio 17 2022" -A x64 ..
其中 x64 是架构，按需换成 x86 或 ARM64；-A 参数必须和 vcvarsall.bat 架构一致，否则链接会失败。
真正容易被忽略的是：每次新开 CMD 窗口都要重新 call vcvarsall.bat，它不持久生效。
