CMake在Windows上不会从PATH查找gcc/g++，必须显式指定-G "MinGW Makefiles"及编译器路径，否则因探测失败报No CMAKE_CXX_COMPILER错误。
直接说结论：CMake在Windows上根本不会主动从PATH里找gcc或g++，哪怕你把C:\mingw64\bin加进环境变量也没用——这是它设计上的硬性限制，不是你配置错了。
为什么g++ --version能运行，但CMake就是报No CMAKE_CXX_COMPILER could be found
CMake在Windows上的编译器发现逻辑和Linux/macOS完全不同。它默认只认MSVC（通过注册表和vswhere.exe扫描），对MinGW完全不走PATH搜索路径。你能在终端敲g++ --version成功，只说明环境变量生效了；但CMake压根不查这个，所以报错是必然的，不是“没配好”，而是“它本来就不看”。
- 验证方式：打开全新PowerShell，执行
g++ --version和cmake ..，前者成功后者失败——这就是典型表现 - 别再反复检查
PATH是否加对了，那只是浪费时间 - 错误信息里出现
after EnableLanguage，就坐实了这是编译器探测阶段失败，不是后续构建问题
-G "MinGW Makefiles"必须显式指定，否则CMake会误判
如果不加-G参数，CMake在Windows上默认尝试生成Unix Makefiles，但它找不到make（Windows没原生make），于是退而求其次去搜MSVC——结果你没装VS，就卡死在编译器检测环节。
- 正确命令是：
cmake -B build -G "MinGW Makefiles" - 注意引号必须保留，空格不能省，大小写不敏感但建议按官方写法
- 如果还报
CMAKE_MAKE_PROGRAM is not set，说明它找到了g++，但找不到make可执行文件——此时要确认mingw32-make.exe或make.exe确实在bin/目录下，且名字没被改错（比如重命名成make后没保留.exe扩展名）
指定编译器路径比依赖环境变量更可靠
既然CMake不看PATH，那就绕过它的自动探测，直接喂给它路径。尤其是当你机器上同时装了MSVC和MinGW时，显式指定能彻底避免冲突。
- 最简写法：
cmake -B build -G "MinGW Makefiles" -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ - 更稳妥写法（推荐）：
cmake -B build -G "MinGW Makefiles" -DCMAKE_C_COMPILER=C:/mingw64/bin/gcc.exe -DCMAKE_CXX_COMPILER=C:/mingw64/bin/g++.exe - 路径中用正斜杠
/，不要用反斜杠\，否则CMake解析会出错 - 如果路径含空格（比如
C:\Program Files\...），必须用双引号包裹整个路径，但cmake命令本身不支持带空格路径的简写形式，建议一律用无空格安装路径（如C:/mingw64）
动态库缺失会导致configure阶段失败，不是编译失败
常见报错：The C compiler "C:/mingw64/bin/gcc.exe" is not able to compile a simple test program. 表面是编译器问题，实际是gcc.exe运行时找不到libstdc++-6.dll或libgcc_s_seh-1.dll。
- 临时解决：把
C:/mingw64/bin加进系统PATH，然后重启终端（不是刷新环境变量，是新开窗口） - 长期方案：在CMake配置时通过
environment注入路径，比如用CMakePresets.json设置PATH字段，或在命令行用set PATH=C:\mingw64\bin;%PATH%再跑cmake - 注意：复制DLL到
build/目录或CMake安装目录只是权宜之计，每次升级MinGW都得重来
真正容易被忽略的点是：CMake对MinGW的支持本质是“被动适配”，不是“主动兼容”。它不提供GUI向导、不自动注册、不缓存路径——每一步都要你亲手钉死。哪怕只漏掉-G或写错一个斜杠，它都不会给你模糊提示，只会报最底层的EnableLanguage失败。所以别猜，直接按路径+生成器+编译器三要素全写死，反而最省时间。
