cmake --version 报 command not found 说明 cmake 已安装但未加入系统 path，需根据系统分别处理：windows 安装时漏选“add to path”、linux 源码安装后未配置 path、macos brew 安装后未重载 shell 配置（如 ~/.zshrc）均会导致此问题。
cmake --version 报 command not found 怎么办
说明 CMake 根本没进系统 PATH，不是“装没装好”，而是“装了但找不到”。Windows 安装时漏选 Add CMake to the system PATH、Linux 用脚本安装后没软链接、macOS 用 brew 装却在 zsh 里没重载 shell 配置，都会导致这个错误。
- Windows：重新运行
.msi安装包，**必须勾选**Add CMake to the system PATH for all users（选“current user”也行，但重启终端后要确认是当前用户登录态） - Linux（手动安装）：别只解压完就完事，得把
cmake二进制文件路径加进$PATH，比如：export PATH=/path/to/cmake/bin:$PATH，写进~/.bashrc或~/.zshrc后执行source ~/.zshrc - macOS：如果用
brew install cmake装完仍报错，先运行which cmake，再检查echo $SHELL—— 如果是 zsh，brew默认装到/opt/homebrew/bin，需确认该路径已在~/.zshrc中的PATH里
Ubuntu/Debian 上 sudo apt install cmake 为什么版本太旧
apt 源里的 cmake 版本由发行版冻结策略决定，Ubuntu 22.04 默认只有 3.22.x，而现代项目常要求 3.20+ 或 3.26+。低版本可能不支持 find_package(... CONFIG REQUIRED) 的严格模式，或解析不了 FetchContent_Declare 新语法。
- 首选方案：用 Kitware 官方 APT 仓库，比系统源新且稳定
sudo apt update && sudo apt install curl gpgcurl -fsSL https://apt.kitware.com/kitware-archive-key.asc | sudo gpg --dearmor -o /usr/share/keyrings/kitware-archive-keyring.gpgecho 'deb [arch=amd64 signed-by=/usr/share/keyrings/kitware-archive-keyring.gpg] https://apt.kitware.com/ ubuntu/$(lsb_release -sc) main' | sudo tee /etc/apt/sources.list.d/kitware.listsudo apt update && sudo apt install cmake - 临时应急：下载官方
.sh安装包（如cmake-3.30.5-linux-x86_64.sh），chmod +x后执行，再软链接到/usr/local/bin/cmake—— 注意别覆盖系统自带的/usr/bin/cmake，否则可能影响其他依赖它的包
Windows 用 winget install Kitware.CMake 却提示 not found
winget 源默认不包含 Kitware 官方源，winget install Kitware.CMake 是 2024 年后才被收录的，旧版 winget（winget --version 小于 1.9.0）会直接失败，不是命令写错。
- 先升级 winget：
winget upgrade --id Microsoft.Winget.Source或去 GitHub 发布页 下载最新msixbundle - 确认源已启用：
winget source list应含winget和msstore；若没有，运行winget source add -n winget -a https://cdn.winget.microsoft.com/cache - 装完后别急着用：
cmake --version可能仍显示旧版——因为 winget 默认装到%LOCALAPPDATA%\Microsoft\WinGet\Packages\Kitware.CMake，而 PATH 更新需重启终端或手动追加该路径
cmake -S . -B build 和 cmake . 有什么实际区别
前者是「现代 CMake 模式」，后者是「传统 in-source 构建」，差异不只是写法，而是构建目录隔离性、缓存可移植性和 IDE 兼容性。
-
cmake -S . -B build：明确分离源码（-S）和构建（-B）目录，build/内所有生成文件可安全删除，不影响源码；CMakeCache.txt 存在build/下，多配置（Debug/Release）可共存；VS Code 的 CMake Tools 插件默认识别这种结构 -
cmake .：构建文件直接生成在源码目录，污染CMakeFiles/、CMakeCache.txt等，git 提交易误删关键缓存；切换构建类型（比如从 Debug 改 Release）必须先rm -rf *清空，否则可能残留旧编译器设置 - 一个硬伤：
cmake .在 Windows 上若源码路径含空格或中文，大概率触发Parse error in command line argument；而-S/-B模式内部做了路径转义，更健壮
实际项目里最易被忽略的，是构建目录权限和磁盘空间——尤其在 WSL 或 CI 环境中，build/ 目录若挂载在受限文件系统（如 tmpfs 或 NTFS）上，cmake --build 可能静默失败，只报 FAILED: CMakeFiles/Makefile2 这种模糊错误。动手前先 df -h 或 Get-PSDrive 看一眼目标路径是否可写、够大。
