结论是：cmake --version 报 command not found 并非 cmake 未安装，而是 shell 因 path 环境变量缺失对应路径、修改后未重载配置或配置文件选错（如 zsh 下误改 ~/.bashrc），导致无法定位可执行文件。
直接说结论：不是 CMake 没装好，而是 shell 没“看见”它——PATH 里缺路径、改了没重载、或者改错了配置文件。
为什么 cmake --version 报 command not found？
这是典型的 shell 查找可执行文件失败，和 CMake 本身是否完整无关。系统只按 PATH 环境变量从左到右扫描目录，一旦某个目录里有 cmake（哪怕是个坏链接），就停止搜索；如果全程没匹配上，就报这个错。
常见诱因包括：
- Linux/macOS 编译安装默认放到
/usr/local/bin，但 Alpine、Ubuntu Core 或某些容器镜像压根不把这路径放进默认PATH - Windows 安装向导勾选了 “Add to PATH”，但实际只加给了“当前用户”，而你用的是管理员 CMD 或 VS Code 终端（继承的是系统级 PATH）
- macOS Catalina 及以后用
zsh，但你往~/.bashrc里加了export PATH=...，zsh根本不读它 - Homebrew 安装后自动写入
~/.zshrc，但你没运行source ~/.zshrc，或终端是旧会话
怎么快速确认是 PATH 问题？
别猜，直接查：
CMake 4.3.2
下载
CMake 4.3.2 Windows x86_64 历史版本安装包，适合旧项目兼容、构建环境回退、CMakeLists.txt 迁移验证、Visual Studio/Ninja/Makefile 生成器测试和 C/C++ 项目维护。
- Linux/macOS：运行
echo $PATH，看输出里有没有/usr/local/bin、/opt/homebrew/bin或你自定义的安装路径（比如/opt/cmake-3.30.0/bin） - Windows：运行
echo %PATH%，检查是否含C:\Program Files\CMake\bin或%USERPROFILE%\scoop\apps\cmake\current\bin这类路径 - 再补一刀：运行
which cmake（macOS/Linux）或where cmake（Windows），如果没输出，说明确实不在PATH里
不同系统下修 PATH 的实操要点
关键不是“加路径”，而是“加对地方 + 让它生效”：
- Linux（Bash）：编辑
~/.bashrc，末尾加export PATH="/usr/local/bin:$PATH"，然后运行source ~/.bashrc - macOS（Zsh，默认）：编辑
~/.zshrc，加同样语句，再运行source ~/.zshrc；别碰~/.bash_profile，它已废弃 - Windows：进“系统属性 → 高级 → 环境变量”，在“系统变量”或“用户变量”的
Path里新增一行，填完整路径如C:\Program Files\CMake\bin；改完必须关掉所有终端再重开 - 容器/精简镜像（如 Alpine）：Dockerfile 里不能只写
apk add cmake，得显式加ENV PATH="/usr/local/bin:$PATH"，因为 Alpine 默认PATH不含该目录
CMAKE_ROOT 错误其实是路径链断裂
当你看到 CMake Error: Could not find CMAKE_ROOT，说明 cmake 可执行文件找到了，但它启动后找不到自己的资源目录（通常是 share/cmake-3.x）。根本原因往往是：
- 你用符号链接把
/usr/local/bin/cmake指向了新版本的可执行文件，但没同步更新其依赖的share目录位置 - 手动解压二进制包到
/opt/cmake-3.30.0，但PATH加的是/opt/cmake-3.30.0/bin，而 CMake 推导CMAKE_ROOT时默认回退两级目录 —— 如果你解压结构是/opt/cmake-3.30.0/cmake-3.30.0/bin/cmake，那它就找不到/opt/cmake-3.30.0/share - 多版本共存时，
which cmake返回的是旧版路径，新版 bin 目录虽在PATH里，但排在旧版后面，被优先命中
临时验证方法：运行 cmake -DCMAKE_ROOT=/opt/cmake-3.30.0/share/cmake-3.30 -P -（注意路径要精确到 share/cmake-x.y 子目录），能过就证明是推导逻辑出问题，不是文件缺失。
