CLion默认自动检测PATH中的CMake，但不可靠；必须在Settings→CMake中显式指定Bundled或绝对路径，并确保Toolchain配置一致，否则出现“CMake project is not loaded”错误。
CMake 不需要额外安装 —— CLion 自带或能自动检测，但必须正确关联到项目工具链里，否则 CMake project is not loaded 错误几乎必然出现。
CLion 里 CMake 是“自动发现”还是“必须手动指定”？
CLion 启动时会尝试自动扫描系统 PATH 中的 cmake 可执行文件，但这个行为不可靠，尤其在 Windows 下容易漏掉或选错版本。更稳妥的方式是显式指定：
- 打开 Settings | Build, Execution, Deployment | CMake
- 在
CMake executable下拉框中，优先选择Bundled（CLion 内置版本，稳定且免冲突） - 如果必须用系统版（比如要匹配 CI 环境），则点击
...手动定位到cmake.exe，常见路径如：C:\Program Files\CMake\bin\cmake.exe - 确认
Generation path不含中文、空格、长路径（推荐cmake-build-debug这类默认值）
为什么改了环境变量后 CLion 还找不到 CMake？
因为 CLion 在启动时读取一次 PATH，之后不会动态刷新。常见错误现象包括：
- 命令行里
cmake --version能正常输出，但 CLion 报 “CMake not found” - 修改了系统
Path后没重启 CLion - 用了用户级
Path，但 CLion 是以管理员/不同用户身份启动的
解决办法只有两个：
- 彻底关闭 CLion（包括托盘进程），再重新打开
- 或者绕过环境变量，直接在 Settings → CMake 里填绝对路径
Windows 下 MinGW + CMake 组合最容易卡在哪？
不是 CMake 本身，而是工具链（Toolchain）和 CMake 的协同配置。关键点：
- 必须先在 Settings | Build, Execution, Deployment | Toolchains 中配好 MinGW：指定
C++ Compiler（如g++.exe）、C Compiler（gcc.exe）、Debugger（gdb.exe） - 这个 Toolchain 必须和 CMake 配置页里的
Toolchain下拉选项保持一致 —— 两者不匹配会导致 CMake configure 阶段静默失败 - MinGW 的
bin目录（如D:\mingw64\bin）必须已加入系统Path，否则 CLion 即使指定了路径，也可能在构建时找不到链接器ld或ar - 避免混用 MSVC 和 MinGW 工具链：同一 CMake 配置里切勿让
CMAKE_CXX_COMPILER指向 MSVC 的cl.exe，而 Toolchain 却选 MinGW
如何验证 CMake 是否真正在为当前项目工作？
光看右下角 “Configuring…” 提示不够，要盯住三个地方：
- 底部状态栏是否显示
CMake: Debug（或对应构建类型），而不是灰字 “No CMake projects loaded” -
CMake 工具窗口（View → Tool Windows → CMake）里是否有清晰的 target 列表，比如
myapp、install - 项目视图中
CMakeLists.txt右键菜单是否出现Reload CMake Project，且点击后无报错 - 如果点了 Reload 后弹出错误日志，第一眼扫
-- The CXX compiler identification is unknown或Could not find compiler set in environment variable CC—— 这说明 Toolchain 和 CMake 没对上
真正生效的标志是：main.cpp 左侧出现绿色三角运行按钮，且点击能成功构建并输出结果。任何中间环节断开，都意味着 CMake 没被 CLion 正确驱动起来 —— 这个链条比看起来更脆弱，尤其是路径、权限、工具链三者稍有错位就会卡死。
