Windows下CMake免安装zip版：从解压到跑通构建的实用指南

关注

原创 2026-10-12 13:50:33 267 阅读 AI 写同款· GEO 优化 ›

简介：CMake 3.17.1 官方免安装包专为 64 位 Windows 开发者准备，解压后可将 bin 目录加入环境变量，即可在命令行或集成开发环境中直接调用 cmake 可执行程序，免去安装向导的等待。压缩包共六千一百六十九个文件，约三十二点四七兆字节，主体为 txt、html、rst 与 cmake 文件，分别承担命令行帮助、离线文档、模块说明以及构建配置示例，另含少量可执行的 cmake、ctest、cpack 等工具，目录结构完整。这些文件均来自官方稳定发布版，还集成了 cmake-gui 图形界面，既能可视化配置工程，也能用 ctest 运行测试、用 cpack 生成安装包，覆盖从编译到分发的常用链路。适合希望快速部署构建系统的开发者、需要离线查阅文档的团队，以及正在学习跨平台构建流程的学生。已有 1188 人学习下载，在搭配 Visual Studio、Ninja、MSVC 等环境时可直接作为便捷起点，尤其适合网络条件不佳或需反复迁移环境的场景。

1. 拿到 cmake-3.17.1-win64-x64.zip，等于拿到了什么

一个新同事入职，机器是 Windows 10 企业版，没装任何构建工具。我给他的第一件事不是装 Visual Studio，而是把 cmake-3.17.1-win64-x64.zip 解压到 D:\tools\cmake-3.17.1 ，加一下 PATH，然后让他敲 cmake --version 。这一步过了，后面聊生成器、聊编译器、聊构建脚本才有意义。

这个免安装包解决的是最实际的问题：不带安装向导、不写注册表、不依赖管理员权限，解压完 bin 目录里就是 cmake.exe 、 cmake-gui.exe 、 ctest.exe 、 cpack.exe 。它叫“免安装”，本质是官方把安装版里复制到系统目录的那部分文件直接打成了 zip，换句话说 CMake 本身就是绿色软件的设计思路，安装包只是帮你做路径写入和快捷方式而已。

但这篇不止讲“怎么解压”。你会发现“免安装”三个字背后还有一层容易翻车的真相：CMake 只是一个构建系统生成器，它自己不会编译代码。zip 包解压后虽然能跑，但生成 Visual Studio 工程时它要去找 MSBuild，用 MinGW 时它要去找 g++，这些编译器不会因为你解压了 cmake 就自动出现在系统里。所以真正的工作量在“怎么让 CMake 找到你的工具链”，而不是“怎么让 cmake.exe 跑起来”。这篇文章就按这个顺序来：先把这个包用对，再把工具链配通，最后把坑填平。

2. 为什么选官方 zip 免安装版而不是安装向导：选型逻辑与适用边界

2.1 安装版和免安装版的本质区别，以及“绿色解压”的适用场景

Windows 上 CMake 的官方分发形式主要有两种： cmake-x.y.z-windows-x86_64.msi 安装版和 cmake-x.y.z-win64-x64.zip 免安装版。MSI 版做的事情包括：把文件复制到 C:\Program Files\CMake 、在开始菜单创建快捷方式、把 CMake 的 bin 目录写进系统级 PATH，还有比较关键的一步——把 CMake 的 Visual Studio 插件文件交给 VS 的扩展目录。

zip 版只做一件事：把同样的文件按原目录结构打成一个压缩包。解压到一个目录后， bin 、 doc 、 share 这些文件夹就已经是完整的运行布局。

所以选 zip 版的动机很直接——版本隔离。项目 A 需要 3.17.1，项目 B 需要 3.20.x，MSI 装完只能存在一个版本，或者你得靠改 PATH 来回切换，搞不好就把系统路径搞乱了。zip 版可以在 D:\tools 下并列放 cmake-3.17.1 、 cmake-3.20.5 ，切换时只改环境变量，不影响任何项目文件。

另一个动机是 CI 和装机脚本。给新机器装构建环境时，用 PowerShell 脚本下载 zip、解压、写环境变量，整个过程秒级完成，不需要点向导，也不需要 UAC 弹窗。对需要批量初始化开发机的团队来说，这是唯一可靠的方式。安装包还要鼠标点几个下一步，脚本没法优雅地处理这种交互。

不适用的情况也有：如果你只是偶尔在个人机器上用 CMake，并且希望右键菜单或 VS 集成自动可用，那 MSI 省心一些，它与 Visual Studio 的集成是安装程序自动注册的。zip 版虽然也能让 VS 识别（通过 CMAKE_EXPORT_COMPILE_COMMANDS 或直接在 VS 里打开 CMakeLists.txt），但前提是你得把环境变量配到你当前这个用户会话里，否则 VS 找不到 cmake 路径。

2.2 版本选型的一个常见疑问：“3.17.1 是不是太老了”与兼容性底线

2025 年的视角看 3.17.1，确实不是新版本。但 C++ 项目的构建系统有个跟普通依赖不一样的地方：CMake 写的是 cmake_minimum_required(VERSION 3.17) ，这个声明决定了响应文件里生成的语法版本和兼容特性，太低会有问题，太高则编译器不配合。

3.17.x 这个版本线有一个实际意义：它是 CMake 首次相对稳定支持 CMAKE_CXX_STANDARD 与 target_compile_features 组合处理的版本，对 C++17 项目很友好。同时它跟 Visual Studio 2019 的 v142 工具集配合默契，对 Qt 5.15 的 -DCMAKE_PREFIX_PATH 查找也比较成熟。如果是公司内部的存量老项目，比如从 3.5 或者 3.10 一路升上来，3.17.1 是一个风险很低的中间版本——比它新的版本可能改变 FindBoost 的查找策略，比它旧的可能不支持某些 target 的 USES_TERMINAL 特性。

版本选择上给三条可操作建议。第一，看你的编译器下限——用 VS2017 或更老的工具集，选 3.17 没问题；但用 VS2022 v143 工具集，3.17 的 VS 生成器仍能工作，只是 CMake 里有些新特性（如 VS_PROJECT_IMPORT ）在配置文件里不会出现，不影响基本生成。第二，看 cmake_minimum_required 写多少——你不可能用一个 3.17.1 的 CMake 去配置一个要求 cmake_minimum_required(3.24) 的项目，因为新版 CMake 会直接拒绝执行。第三，追求长期维护的项目不必执着于最新，稳定版里挑一个团队验证过的版本即可。

2.3 zip 目录结构拆解：bin 里那五个 exe 各管什么

解压后先别急着用，花一分钟搞清楚目录布局。根目录下有 bin 、 doc 、 share 、 licenses 等目录，其中真正关系到日常使用的是 bin 和 share 。

bin 目录包含五个可执行文件：

cmake.exe ：命令行入口，配置、生成、构建入口，约等于全部工作的入口。
cmake-gui.exe ：图形界面，适合查看缓存变量，但不适合做批量流程。
ctest.exe ：测试驱动工具，从 CTestTestfile.cmake 读取测试列表并执行。
cpack.exe ：打包工具，生成安装包或归档文件。
cmake-gui.exe 的同目录下没有 cmcldeps.exe ，这个不影响。

share 目录是真正容易被忽略的部分： share/cmake-x.y.z/Modules 存放标准模块文件（如 FindBoost.cmake 、 FindQt5.cmake ）， share/cmake-x.y.z/Templates 存放代码模板。免安装版的模块目录位置是相对固定的，如果你的自定义模块或工具链文件放在某个路径下，可以用 CMAKE_MODULE_PATH 指向它们。

提示：zip 版不写入注册表，所以 Windows 的“添加或删除程序”里不会有它的记录。卸载 = 删除目录 + 从 PATH 移除，这是绿色版最舒服的特性，但也意味着你没法在控制面板里确认它是否存在。

3. 官网下载、校验与解压部署：把免安装包用对的一套完整操作

3.1 目录规划与解压命令：给不同版本留出并列空间

先做目录规划再下载，避免解压后到处都是。我常用的目录结构是：

D:\tools\
    cmake-3.17.1\
    cmake-3.20.5\
    compiler\
        mingw-w64\
        llvm\

打开命令提示符，执行：

mkdir D:\tools\cmake-3.17.1
tar -xf cmake-3.17.1-win64-x64.zip -C D:\tools\cmake-3.17.1 --strip-components=1

Windows 10 1803 以后自带的 tar.exe 可以解压 zip， --strip-components=1 会把压缩包内顶层的 cmake-3.17.1-win64-x64 目录去掉，让文件直接落在 cmake-3.17.1 下。如果系统没有 tar（比较老的环境），可以用 PowerShell：

Expand-Archive -Path cmake-3.17.1-win64-x64.zip -DestinationPath D:\tools\cmake-3.17.1

注意 Expand-Archive 不支持 --strip-components ，解压后会在目标目录里多一层 cmake-3.17.1-win64-x64 子目录。我的做法是先解压到临时目录，再把那层目录里的文件移动出来。逻辑很简单：目标是让 D:\tools\cmake-3.17.1\bin\cmake.exe 这个路径直接可用，不要多套一层。

3.2 三步配 PATH：当前会话、用户级、系统级怎么选

PATH 配置有三种范围，对应不同需求。

当前命令行会话（只对本次终端生效）：

set "PATH=D:\tools\cmake-3.17.1\bin;%PATH%"
cmake --version

用户级环境变量（对当前 Windows 用户所有新开的程序生效，推荐）：

$currentPath = [Environment]::GetEnvironmentVariable("Path", "User")
[Environment]::SetEnvironmentVariable("Path", "$currentPath;D:\tools\cmake-3.17.1\bin", "User")

系统级环境变量（对所有用户生效，需要管理员权限，不推荐在开发机上乱改）：

调用 setx 命令或系统属性面板。日常开发执行第一种或第二种——第一种适合快速验证，第二种适合把版本固定下来。给出参数说明：第三条 SetEnvironmentVariable 的第三个参数必须是 "User" 或 "Machine" 之一，少了它只会改当前进程的内存值，关掉终端就丢。

配完之后，如果当前是 PowerShell，别急着直接敲 cmake， $env:Path 的值不会自动刷新。需要执行：

$env:Path = [Environment]::GetEnvironmentVariable("Path", "User") + ";" + $env:Path

然后再验证。这里有一个高频踩坑：用户级 PATH 和系统级 PATH 同时存在，两者都会被合并进会话环境，且系统级会排在前面。如果系统里装了其他版本 CMake 且系统级 PATH 里有一套，你用户级的设置可能被抢。用第三方的环境变量修改工具时尤其容易出现这种问题，因为很多工具只显示用户级变量，看不出系统级里的旧路径。

3.3 验证安装有效性的 4 个检查点

配完 PATH 之后逐一验证，不是只敲个版本号就完事。

where.exe cmake
cmake --version
cmake --help
cmake --system-information | findstr /i "CMAKE_ROOT"

第一行 where.exe cmake 用来确认当前会执行到的是哪个 cmake。如果输出里有多个路径，说明 PATH 里存在多个版本，需要确认排在前面的是不是你解压的这个。

第二行看到的版本号要精确到 3.17.1 。这里有个容易忽略的坑：有些机器上装了 Visual Studio 自带的 CMake，VS 的组件路径里有一个版本可能比你的新， where 的顺序决定了最终执行谁。

第三行 --help 用来确认生成器列表里有没有 Visual Studio 16 2019 和 MinGW Makefiles 。这一步很重要，因为 zip 版不会自动识别“你装了哪些编译环境”，它只是把生成器选项列给你看，真正能不能用它取决于工具链是否存在。

第四行 CMAKE_ROOT 的输出应该是 D:/tools/cmake-3.17.1/share/cmake-3.17.1 。如果这个路径是错的，后边的 include() 指令会找不到模块文件。zip 版出现这个问题的原因是：解压时不完整，或者把 share 目录单独拿走了。

一个完整检查脚本可以这样写：

set "PATH=D:\tools\cmake-3.17.1\bin;%PATH%"
cmake --version && ^
where cmake && ^
cmake --system-information 2>nul | findstr /i "CMAKE_ROOT CMAKE_HOME_DIRECTORY"

3.4 文件完整性校验：官方 sha256 值去哪找、怎么对

zip 包下载完先校验哈希，这一步很多人跳过，但不该省。官网下载页每个压缩包旁边都列了 SHA-256 校验值。在 PowerShell 里执行：

Get-FileHash -Path cmake-3.17.1-win64-x64.zip -Algorithm SHA256

把输出值与官网展示的哈希做比对。两个一致则说明文件完整，不一致则说明下载过程损坏或被篡改。这里给出为什么用 SHA-256 不用 MD5：MD5 在 2005 年后已经被证实存在碰撞攻击，虽然日常下载出错这类非恶意场景用 MD5 也能发现，但既然是检验文件完整性，用更强的算法不增加任何成本。

注意：一个文件的哈希值必须和它的精确文件名、精确版本对应。从某站下载的“3.17.1”和官网的 3.17.1 哈希值不同是有可能的，不代表一定有问题，稳妥做法是从官网入口下载、与官网页面展示的哈希做比对。

4. 跑通一个最小 CMake 构建：从 CMakeLists.txt 到可执行文件的完整链路

4.1 写一个最小 CMakeLists.txt：cmake_minimum_required 与 project 的版本博弈

免安装版的 CMake 就绪后，立即用它跑一次完整流程。

先建一个测试目录：

D:\demo\
    CMakeLists.txt
    main.cpp

main.cpp 随意写个 Hello：

#include <iostream>
int main() {
    std::cout << "cmake zip works" << std::endl;
    return 0;
}

CMakeLists.txt 写成：

cmake_minimum_required(VERSION 3.17)
project(zip_demo CXX)

add_executable(zip_demo main.cpp)

第一行的 VERSION 3.17 不是拍脑袋：如果写高了（比如 3.24），3.17.1 的 CMake 会拒绝配置；写低了（比如 3.5），编译器多老都能编，但你会失去 target 相关的一些新特性。对于一个验证性质的 demo，3.17 恰好与当前 CMake 版本一致，这是最保守也最常见的写法。

project() 里只声明 CXX ，避免 CMake 去检查 C 编译器。严格来说大多数环境同时有 C 和 C++ 编译器，但减少不必要的检查可以更快暴露问题。

4.2 用 Visual Studio 生成器配置与构建：命令行里做一次完整的 VS 构建

假设机器上装了 Visual Studio 2019 或者 2022（带 C++ 桌面开发工作负载），则可以用 Visual Studio 16 2019 或 Visual Studio 17 2022 生成器。

打开“适用于 VS 的开发者命令提示符”或者普通终端执行：

mkdir build-vs
cd build-vs
cmake .. -G "Visual Studio 16 2019" -A x64
cmake --build . --config Release

第一行建目录，第二行配置，第三行生成并构建。这里的关键参数是 -A x64 ，它决定 VS 解决方案里各项目的平台工具集使用 x64，不写则默认为 Win32（也就是 x86），构建出来的程序没法充分利用 64 位能力。

执行过程中注意观察输出：如果配置阶段报 CMAKE_CXX_COMPILER: NOTFOUND ，说明 CMake 没有找到 VS 安装。虽然 VS 装在系统里，但在普通终端下 CMake 默认查找逻辑依赖注册表里 VS 的安装路径，没找到时通常是 VS 的 C++ 工作负载没装。如果配置成功，会在 build-vs 下生成 zip_demo.sln 等文件，然后 cmake --build 会启动 MSBuild 编译。

下单配置生成器（VS）里 --config Release 是指定实际构建的配置，配合与 CMAKE_BUILD_TYPE 无关，这是 VS 与 Makefile 生成器的重要差异，新手容易在这里产生误解——在 VS 生成器里，配置是在构建时指定的，而在 MinGW Makefiles 生成器里，配置是在配置阶段通过 CMAKE_BUILD_TYPE 指定的。

4.3 用 MinGW 走一遍：考验 PATH 整合能力的最短路径

如果机器上没有 VS，用 MinGW-w64 也能完成同样的验证。前提是 MinGW 的 bin 目录（包含 g++.exe ）已经在 PATH 中。

mkdir build-mingw
cd build-mingw
cmake .. -G "MinGW Makefiles" -DCMAKE_BUILD_TYPE=Release
cmake --build .

-G "MinGW Makefiles" 是生成器参数，表示生成 MinGW 的 makefile。这里的 -DCMAKE_BUILD_TYPE=Release 是配置级变量，在 Makefile 生成器中编译器选项会在配置阶段确定（如 -O3 、 -DNDEBUG ），因此必须先指定。如果漏掉它，默认是空串，构建出来的是无优化版本，后续 ctest 的测试结果可能因断言而表现不一致。

整个链路中容易出问题的是 MinGW 识别。CMake 会在 PATH 中查找 sh.exe 、 gcc.exe 、 g++.exe 。如果 PATH 里既装了 Git 的 usr/bin 又有 MinGW 的 bin，CMake 在构建时会报 sh.exe was found in your PATH ，这是 CMake 对 MinGW 与 MSYS 混用的一个已知警告。处理办法：构建时把 Git 的 usr\bin 临时从 PATH 中去掉，或者用下面的命令行只保留必要路径：

set "PATH=D:\tools\cmake-3.17.1\bin;D:\Tools\mingw64\bin;%SystemRoot%\System32"

构建产物是 build-mingw\zip_demo.exe ，可以执行验证：

zip_demo.exe

4.4 生成器选择逻辑：VS 与 MinGW 怎么选

生成器选择的本质是回答一个问题：你要谁来做最后的编译驱动。VS 生成器产出的不是 makefile，而是 .sln + .vcxproj ，由 MSBuild 驱动编译；MinGW Makefiles 产出的本质是 makefile，由 mingw32-make 驱动。

从项目角度讲，Windows 上如果团队统一用 VS，就用 VS 生成器，这样调试体验最好，也不用维护两套工具链；如果做跨平台项目或 CI 需要在 Windows 上跑同样的 CMake 流程，MinGW 更接近 Linux 上的 Makefile 行为，构建速度在纯增量场景下通常比 MSBuild 快一点。但注意，用 MinGW 构建的 exe 依赖 libstdc++-6.dll 和 libgcc_s_seh-1.dll 等运行库，部署时要带上 MinGW 的 bin 目录。

如果两种生成器都能用，我的默认选择是 VS 生成器——原因只有一个，调试断点比啥都重要。MinGW 的 GDB 调试在 Windows 上的体验确实不如 Visual Studio 原生调试器，这是事实。

5. 免安装 CMake 的 5 个常见坑：现象、原因、解决

5.1 双击 cmake-gui.exe 后找不到编译器，配置时报错

用 cmake-gui 打开 CMakeLists.txt，点 Configure，选择“Visual Studio 16 2019”，结果报 CMAKE_CXX_COMPILER NOTFOUND 。

原因：cmake-gui 是独立进程，它不继承命令行里手动添加的 PATH，也不会自动发现 VS 安装路径中的所有组件。如果 VS 装得比较“精简”，没装 C++ 工作负载，或者 CMake 缓存里残留上一次配置错误的编译器路径，就会报这个错。

解决：不用 cmake-gui 选编译器，改用命令行显式指定并写入缓存——用 VS 开发者命令提示符打开 cmake-gui，或在命令行里先执行 cmake .. -G "Visual Studio 16 2019" -A x64 成功一次后，再用 cmake-gui 加载同一个 build 目录。这样 CMakeCache.txt 里的 CMAKE_CXX_COMPILER 已经是有效的 VS 编译器路径。

提示：如果构建目录第一次配置就失败，它会留下 CMakeCache.txt 。下一次配置前先删除这个文件，否则新指定的 -G 和 -A 可能被缓存里的旧值覆盖。删除方法：直接删掉 build 目录下所有文件重来，这是最干脆的。

5.2 明明解压了，但 `cmake --version` 显示的版本不是 3.17.1

现象：PATH 里加了 D:\tools\cmake-3.17.1\bin ，但终端里敲 cmake --version 显示的却是 3.20.x 或 3.26.x。

原因：系统级 PATH 中有一个更早注册的 CMake，顺序排在用户级 PATH 的前面。Windows 合并 PATH 时，系统级在前、用户级在后，从前往后查找可执行文件，先找到先执行。

解决：

# 查看 cmake 实际解析到了哪个路径
where.exe cmake
# 查看系统级与用户级里的所有 CMake 相关路径
$env:Path -split ';' | Where-Object { $_ -like '*cmake*' }

把系统级 PATH 里旧的 CMake bin 路径删掉，或者把它从系统级挪到用户级并排到 3.17.1 之后。改完必须重开终端，因为已在运行的会话不会刷新环境变量。最保险的验证方式：新开终端执行 where.exe cmake ，确认只有 D:\tools\cmake-3.17.1\bin\cmake.exe 。

5.3 PATH 加好了，但 PowerShell 里立刻执行 cmake 还是“无法识别”

现象：刚加完用户级环境变量，还在当前 PowerShell 窗口里敲 cmake --version ，提示找不到命令。

原因：当前 PowerShell 进程的环境变量是从它启动那一刻的快照读取的，修改用户级 PATH 只影响新进程。

解决：手动刷新当前会话：

$env:Path = [Environment]::GetEnvironmentVariable("Path", "User") + ";" + [Environment]::GetEnvironmentVariable("Path", "Machine")

注意这里 Machine 需要管理员权限才能读取。如果执行报错，就用自己的用户级 + 已有的系统级组合。这个处理和 5.2 本质是同一件事：Windows 环境变量更新的滞后性。我自己的习惯是配完环境变量后干脆重新开一个终端，不强行在当前窗口凑合，因为你后续要跑的每一行都在依赖这个 PATH，不如让它干净。

5.4 成功构建 exe，但双击运行提示找不到 libstdc++-6.dll

现象：用 MinGW 工具链构建成功后，exe 拷贝到别的机器（或者直接双击运行），报缺少 libstdc++-6.dll 或 libgcc_s_seh-1.dll 。用 VS 生成器构建的不会出这个问题。

原因：MinGW 的 GCC 是动态链接 libstdc++ 的，exe 依赖 MinGW bin 目录下的运行库 DLL；这些 DLL 在 PATH 里时能跑，不在时找不到。VS 运行库通过 Windows 本身的 VC redist 机制部署，bin 目录下默认没有 DLL 依赖，但要记得装 VC++ Redistributable。

解决：

# 查看 exe 依赖的 DLL 列表（MinGW 自带工具）
objdump -p zip_demo.exe | grep "DLL Name"

把 MinGW 的 bin 目录中的 libstdc++-6.dll 、 libgcc_s_seh-1.dll 、 libwinpthread-1.dll 复制到 exe 同目录下，或用 windeployqt 之类工具制作可分发文件夹。静态链接也是一种做法：MinGW 构建时加 -static-libgcc -static-libstdc++ ，但这会增大 exe 体积。

5.5 CMake 找不到 Qt 或 Boost，明明已经装好了

现象：配置项目时， find_package(Qt5 REQUIRED) 或 find_package(Boost REQUIRED) 报未找到，但 Qt 或 Boost 明确已经解压到某个目录。

原因：CMake 查找第三方库遵循一套固定的搜索路径，zip 版 CMake 不会知道你把 Qt 解压到了 D:\Qt\5.15.2 ，除非你告诉它。它不是万能定位器， CMAKE_PREFIX_PATH 是为这类场景设计的变量。

解决：

cmake .. -G "Visual Studio 16 2019" -A x64 ^
    -DCMAKE_PREFIX_PATH="D:\Qt\5.15.2\msvc2019_64" ^
    -DBOOST_ROOT="D:\libs\boost_1_75_0"

先说清两个参数区别： CMAKE_PREFIX_PATH 是通用查找前缀， find_package 找 Qt5、ZLIB、OpenCV 时都会优先从这里找； BOOST_ROOT 是 FindBoost 模块专有的提示变量，指向 Boost 根目录。Boost 的 Find 模块比较“固执”， BOOST_ROOT 写错或 Boost 目录结构不符合它预期时，它会直接报错。

如果用了 cmake-gui ，在输入框里填这两个变量后点 Configure 一样生效。关键点是这个“坑”的本质是变量没有被传递下去——你在命令行里写了，但你用的 cmake-gui 没填，或你填了但变量名大小写写错了。CMake 变量名是大小写敏感的， CMAKE_PREFIX_PATH 全大写，写成 cmake_prefix_path 不会被识别。

6. 从“单个包”到“可复用工具链”：把 CMake 版本管理做成习惯

标题只给了一个 zip 包，但真正让这个包发挥价值的，是在多项目环境中稳定复用它。最后一章聊实践技巧：不光是“用对了”，还要“用得久”。

第一个习惯是目录命名带完整版本号，不叫“cmake”而叫“cmake-3.17.1”。这能避免你在两个项目需要不同版本时改来改去。切换靠环境脚本，比如在项目根目录放一个 setup_env.cmd ：

@echo off
set "PATH=D:\tools\cmake-3.17.1\bin;%PATH%"

项目需要 3.20 时，把第一行路径换成 D:\tools\cmake-3.20.5\bin 。这样版本跟随项目，不跟随系统。比起一台机器全局只有一个版本，这个习惯在维护多个老项目时能少踩一半的坑。

第二个技巧是用 cmake -E 系列命令做文件操作。 cmake -E copy_directory 、 cmake -E remove_directory 不依赖 Windows 的 robocopy 或 PowerShell 的 Copy-Item，在 CMake 脚本里保持跨平台一致性。这个平时用得不多，但在你写自动化脚本时会发现比 cmd 原生命令可靠。

第三个技巧是验证某个第三方包与当前 CMake 版本是否兼容。做法是在一个干净的构建目录里指定你选的 CMake 路径执行一次配置：

D:\tools\cmake-3.17.1\bin\cmake.exe -S . -B build-check -G "Visual Studio 16 2019" -A x64

这样能避免在旧版本 CMake 下执行新特性语法时报的“CMake Error at CMakeLists.txt:xx (target_link_options): target_link_options unknown”这类错误。 target_link_options 是 3.13 才有的命令，3.17 可以安全用，但如果换到 3.10 就会报错。版本验证用这个方式最直接：先把目标版本跑一遍，报错就说明 CMakeLists 写法与该版本不兼容。

最后一个习惯建议在团队内普及： .gitignore 里固定把 build*/ 排除，并且每次构建前确认 CMakeCache.txt 不混入源码目录。按 3.17.1 的路径规范，缓存放在源码树外的独立目录，否则不同生成器共享一个 cache 时会出现“之前是 VS 生成的，现在用 MinGW 配置结果还残留 VS 的 MSBuild 路径”的脏缓存问题。写过一次这个教训就记住了——那一次我花了一个小时排查，最后发现只是忘了删上一轮构建留下的 CMakeCache.txt 。

我的习惯是：新机器拿到手，第一件事永远是解压 zip、配 PATH、跑 cmake --system-information ，然后保留一份 where cmake 的截图。环境变量这种“黑匣子”，截图比记忆可靠。希望你也能通过这个免安装包把构建环境理顺，少在环境配置上耗时间；工具链理顺了，后面写代码、调编译错误的时间才真正属于你自己。希望帮到你。