cmake-3.10.0-win64-x64离线包：老项目Windows构建的兼容方案

简介：cmake-3.10.0-win64-x64.rar 是面向Windows 64位系统的CMake 3.10.0安装包，主要服务需要使用跨平台构建流程的C/C++开发者、高校学生和持续集成场景的工程师。CMake本身不直接生成可执行程序，而是通过CMakeLists.txt中的指令描述项目结构、源文件、头文件路径与链接库，再为不同平台生成Makefile、Ninja或Visual Studio解决方案，从而降低多环境维护成本。该压缩包体积约18.61MB，格式为rar，内含Windows 64位安装向导及配套组件，安装时可按需设置环境变量，安装后即可在命令行或cmake-gui中配置工程。3.10.0版本相比旧版在Find模块、依赖处理与生成器支持上有若干改进，适合学习构建系统原理或快速搭建项目骨架。目前已有1676人学习下载，既能作为入门CMake的实用工具，也可作为团队内部统一构建版本的参考包。

1. cmake-3.10.0-win64-x64.rar 是什么：老项目离线装机绕不开的 3.10

很多从 Qt 5.9.4、MSVC2017 时代走过来的 C++ 项目，到今天仍然在 Windows 上用 cmake-3.10.0-win64-x64 这个安装包。它不是一个 exe 向导安装程序，而是一个 rar 压缩包，解压就能跑。离线环境、内网机器、版本锁定的构建服务器，几乎都在用这类包把 CMake 环境一次性铺好。适合谁？适合还在维护老工程、被新版 CMake 策略警告折腾过、又不想让构建行为因为版本升级突然变化的工程师。这个包能解决的就是一件事：在当前机器上拿到一个行为确定、能被旧版 Visual Studio 和 Qt 正常识别的 cmake.exe，并且随时能删、能换、能复制到别的机器。

2. CMake 3.10 能干什么、不能干什么：生成器、策略与工具链边界

安装包到手之后，先别急着解压。先弄清楚 3.10 这个版本在现代 Windows 构建环境里的位置，不然多半会栽在“生成器对不上”这个问题上。

2.1 3.10 和 VS2017、Qt 5.9 是同一代，但别指望它认识 VS2022

CMake 本身不编译代码，它负责根据你写的 CMakeLists.txt 生成一套“别人能直接构建”的工程文件，这套东西在官方术语里叫 Generator。cmake-3.10.0-win64-x64 内置的生成器大多围绕 2017 年左右的工具链，常见的几个我在下表里列一下：

这套生成器列表意味着什么？如果你机器上只装了 Visual Studio 2022，cmake-3.10.0-win64-x64 里并没有对应的生成器，就算你手动输 -G "Visual Studio 17 2022"，它也认不出这个字符串。这不是 PATH 配置问题，是版本代差造成的。反过来，在装好 VS2017 的机器上，3.10 表现得异常稳定，配合 Qt 5.9.4 的 msvc2017_64 预编译库，几乎是那个时代的黄金组合。

我一般会先看一眼项目根目录里有没有 CMakeLists.txt，再看第一行写的 cmake_minimum_required 版本号和 target 的编译器要求，再决定要不要直接上 3.10。新版本 CMake 有“策略”机制，会对旧行为做兼容性切换，老项目在新版下经常冒出大量 deprecation 警告甚至直接报错，这是许多人反复搜“cmake 使用教程”却始终没绕出来的原因：不是不会写 CMakeLists，而是版本策略变了。

2.2 Makefile 和 CMake 的区别：装完 CMake 后你写的是什么

很多从 Makefile 转过来的开发者有个困惑：CMake 装完之后，为什么还要写 CMakeLists.txt，不能直接编译吗？这里要分清两个层次。Makefile 本身是给 make 程序看的规则文件，里面写死了编译命令、依赖关系、清理动作；一旦换编译器、换目录结构、换平台，Makefile 基本要重写。CMakeLists.txt 则是更高一层的描述：你告诉 CMake“项目里有哪些源文件、需要生成一个 exe 还是一个库”，由 CMake 这边生成对应平台的 Makefile、.sln 或 ninja.build 文件。

所以 cmake-3.10.0-win64-x64 里那个 cmake.exe，本质是一个“生成器的生成器”。它会先读取 CMakeLists.txt，再结合你在命令行里传的 -G 参数，吐出适合当前工具链的工程文件。理解这一点，你就知道排查方向了：

提示：如果报错发生在 configure 阶段，说明是 CMakeLists.txt 或工具链识别问题；如果 configure 成功但 build 报错，才轮到编译器的链接、头文件、库路径问题。

这个区分能帮你省大量时间。把“CMake 报错”笼统地拿去搜索，往往会得到一堆牛头不对马嘴的答案。

2.3 版本策略、探针机制和 3.10 的兼容边界

CMake 从 3.0 开始引入策略机制，每个策略对应一种老行为。新版本会把策略默认值切到新行为，老项目如果没主动声明，就会看到各种警告。3.10 的好处是它比 2.8 时代现代得多，又不像 3.20+ 那样对老脚本有太多新要求。最稳妥的写法是让项目明确声明：

cmake_minimum_required(VERSION 3.10)

这句话不只是版本检查，它同时把策略等级锁在 3.10 上，让构建行为可预期。另一个关键机制是编译器探针：CMake 在 configure 阶段会生成一个极小的测试工程，把自己检测到的编译器拿去编译，验证能不能通过。网上常见报错“cmake error at /usr/share/cmake-4.2/modules/cmakedeterminecompilerid.cmake:9”，本质就是新版 CMake 在 Linux 上探针失败；在 Windows 上对应的是“compiler cannot compile a simple test program”这类信息。老版本 3.10 遇到新编译器（比如 VS2022 的 cl 19.3x）时，也经常卡在探针上，因为它不知道该拿哪些宏去识别这个编译器版本。

所以别把 3.10 当万能钥匙。它的舒适区是：VS2015/2017、gcc 5～7、Qt 5.9～5.12、MinGW-w64 早期版本。超出这个范围，要么换新版 CMake，要么在构建环境里先用旧编译器把 configure 阶段撑过去。

3. 安装包怎么落地：解压、PATH 和第一条 cmake 命令

cmake-3.10.0-win64-x64.rar 的安装过程和“下一步下一步”的 exe 完全不同，它是绿色解压包。这一步做对了，后面所有命令都顺；做错了，最常见的症状是 cmd 里敲 cmake 提示不是内部或外部命令。

3.1 解压到纯英文短路径，别放默认下载目录

第一步是找解压工具。rar 格式优先用 WinRAR 或 7-Zip 处理，不要拿 Windows 自带的“全部解压缩”去碰，那个只认 zip。我习惯用 7-Zip 命令行解，可写进自动部署脚本：

7z x cmake-3.10.0-win64-x64.rar -oC:\Tools

参数说明：x 表示解压并保留目录结构，-o 后面直接跟目标目录，注意 -o 和路径之间不能加空格。解压完成后会得到 C:\Tools\cmake-3.10.0-win64-x64，里面的核心内容有两个：bin 目录下放着 cmake.exe、cmake-gui.exe、ctest.exe；share 目录下是 CMake 内置模块和模板，这些东西在 configure 阶段会用到，所以整个目录不能只拷一个 exe 出来用。

路径选择有讲究。C:\Tools 这类纯英文、无空格、层级浅的路径最省心。不要放 C:\Program Files 下面，虽然 CMake 对带空格的路径也能处理，但后续要是接 Ninja、接 Qt、接 vcvarsall.bat，空格会显著提高报错概率。也别放中文用户名目录里，3.10 的编码处理在中文路径下偶尔会有玄学问题，这个后面避坑章节再展开。

3.2 手动配置 PATH：cmd 和 PowerShell 的两种写法

解压只是把文件放到磁盘上，要让命令行认得出 cmake，得把 C:\Tools\cmake-3.10.0-win64-x64\bin 加进 PATH。常见做法是配置用户级环境变量，这样不需要管理员权限，也不会污染系统全局配置。

cmd 下用 setx 写的做法：

setx PATH "%PATH%;C:\Tools\cmake-3.10.0-win64-x64\bin"

PowerShell 下推荐直接改用户级环境变量：

$oldPath = [Environment]::GetEnvironmentVariable("Path", "User") $newPath = $oldPath + ";C:\Tools\cmake-3.10.0-win64-x64\bin" [Environment]::SetEnvironmentVariable("Path", $newPath, "User")

参数说明：setx 的坑在于它会读取当前终端里的 PATH 快照写回注册表，如果当前终端 PATH 已经被其他程序改得乱七八糟，容易把旧值截断；PowerShell 版本直接操作 User 级别的原始值，更安全。注意 setx 有 1024 字符截断风险，如果你的 PATH 已经很长，调用前先 echo %PATH% 看看长度。

修改完之后，已经打开的 cmd 窗口不会自动生效，必须新开一个终端。这一点很多人反复栽：配置完 PATH 后在原窗口试 cmake --version，结果还是“不是内部或外部命令”，于是认为是安装包有问题。

3.3 验证版本：为什么 cmake --version 是第一个检查项

新开 cmd 或 PowerShell 窗口后，依次执行三条命令验证环境：

cmake --version where cmake cmake --help

参数说明：cmake --version 会输出版本号，看到 3.10.0 就说明 exe 能跑；where cmake 检查当前 PATH 里找到的 cmake 到底是哪一个，防止机器里装了多个版本导致调错；cmake --help 输出生成器列表和参数说明，这能顺便验证 3.10 内置生成器是否正常加载。

版本验证这一步看着简单，但它是后面一切排错的前提。特别是机器里已经装了新版 CMake 的场景，你费劲配置半天，where cmake 才发现系统优先找到的是 C:\Program Files\CMake\bin，老版本根本没参与构建。这种情况的处理办法是：把 C:\Tools\cmake-3.10.0-win64-x64\bin 在 PATH 里的顺序提前到最前面，或者干脆在构建脚本里写死 cmake 的绝对路径。

3.4 CMake GUI 第一次打开：连 VC++ 运行库都可能是障碍

命令行能用之后，再验证 GUI。cmake-3.10.0-win64-x64\bin\cmake-gui.exe 不依赖安装器，但依赖 Microsoft Visual C++ 运行库。如果你那台机器是从零开始的内网环境，双击 cmake-gui.exe 很可能直接弹“由于找不到 VCRUNTIME140.dll 无法继续执行”。这不是安装包坏了，而是系统缺 VC++ 2015-2022 Redistributable x64。

解决办法是找一台能上网的机器，下载并安装 vc_redist.x64.exe，然后离线拷到目标机器上装上。装完再打开 cmake-gui，就能看到熟悉的界面了：上方是 source 目录和 build 目录，中间是配置选项区，下方是 configure 和 generate 按钮。GUI 和命令行用的是同一个引擎，差别只在你不必手敲参数。

提示：GUI 工具在首次 Configure 时会把你选的生成器缓存在 CMakeCache.txt 里。以后同一个 build 目录再用命令行 cmake .. 会自动沿用缓存里的生成器，不需要重新指定 -G，但前提是 cache 没有被删除。

4. 用 3.10 跑通一个 Windows 最小构建：从命令行到 Ninja

环境配好之后，找一个最小工程验证整个链路。这里用一个只有单个源文件的项目做示范，从写 CMakeLists.txt 到生成、编译，完整走一遍。这一步跑通，就说明 cmake-3.10.0-win64-x64 里的核心模块没有因为解压路径、运行库或 PATH 问题产生残缺。

4.1 最小 CMakeLists.txt 文件

新建目录 D:\demo，在里面放 main.cpp 和 CMakeLists.txt：

cmake_minimum_required(VERSION 3.10) project(demo LANGUAGES CXX) add_executable(demo main.cpp)

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

逻辑说明：cmake_minimum_required(VERSION 3.10) 告诉 CMake 按 3.10 的策略处理兼容性问题，也顺带排除了机器上更老版本运行时直接拒绝的情况。project(demo LANGUAGES CXX) 声明这是一个只用 C++ 的项目，CMake 会由此决定去探针哪个编译器。add_executable(demo main.cpp) 把 main.cpp 编成 demo.exe。这个文件结构是所有 CMake 工程的地基。

4.2 命令行配置生成：生成器参数怎么选

进入 D:\demo 目录后，标准做法是创建 build 目录隔离源码和产物：

cmake -S D:\demo -B D:\demo\build -G "Visual Studio 15 2017" -A x64

参数说明：-S 指定源码根目录，-B 指定构建目录，构建目录不存在时会自动创建。-G 后面是生成器名称，引号不能省，因为 Visual Studio 15 2017 里有空格。-A x64 是 3.8 引入的架构选项，等价于老写法里把生成器写成 “Visual Studio 15 2017 Win64”。3.10 两种都支持，优先用 -A x64，语义更清晰。

如果这台机器没装 VS2017，而你想测试命令行流程，可以换成 MinGW 工具链：

cmake -S D:\demo -B D:\demo\build -G "MinGW Makefiles" -DCMAKE_CXX_COMPILER=g++

参数说明：MinGW Makefiles 生成器需要 mingw32-make 和 g++ 都在 PATH 里，DCMAKE_CXX_COMPILER 用来显式指定编译器。CMake 探针会去验证 g++ 能不能编译小型测试程序，验证通过才会继续。这个路径适合装了 MinGW-w64 但没装 Visual Studio 的开发者。

configure 完成后，build 目录下会生成 CMakeCache.txt、CMakeFiles 目录和 .sln 工程文件。这时候再执行编译：

cmake --build D:\demo\build --config Release

参数说明：--build 是统一入口，CMake 会读缓存里的生成器，自己调用 MSBuild 或 make 完成编译。--config Release 只在多配置生成器（VS）下有意义，对于单配置生成器（MinGW Makefiles、Ninja），构建类型在 configure 阶段用 -DCMAKE_BUILD_TYPE 指定。

4.3 CMake GUI：Source/Build 路径和 Configure 按钮生成的缓存文件

命令行跑通以后，再用 cmake-gui 演示一遍。打开 cmake-gui，在 Source 一栏填 D:\demo，在 Build 一栏填 D:\demo\build_gui，点 Configure，第一次会弹出生成器选择框，选 Visual Studio 15 2017，架构选 x64，然后 CMake 开始执行探针并生成缓存。这个过程中 GUI 底部的输出窗口会滚动显示编译器检测信息，和命令行输出完全一致。

Configure 之后点 Generate，会生成 .sln 文件。这跟你用命令行 -S -B 的效果没有区别，区别只在于 GUI 可以随时改选项：比如想在 Release 和 Debug 之间切换，在 GUI 里的 CMAKE_BUILD_TYPE 或 VS 多配置下拉框里改。对新手来说，GUI 的最大价值是能看到每一轮配置到底卡在哪个模块上。

顺便说一句，很多人用 VSCode 配 CMake 开发，VSCode 的 CMake Tools 插件只是调用系统里的 cmake，最终行为仍然是这套流程。你给插件指定的 kit，本质上就是指定 -G 生成器和编译器的组合。

4.4 用 Ninja 提速：ninja cmake 的组合怎么配

VS 生成器会生成 .sln，但增量编译速度一般。想要更快的本地构建，常见做法是配 Ninja：CMake 生成 build.ninja 文件，Ninja 根据依赖关系并行执行编译。cmake-3.10.0-win64-x64 本身支持 Ninja 生成器，但它不附带 ninja.exe，需要另备一个放 PATH 里。

假设 ninja.exe 在 C:\Tools\ninja，配置步骤：

set PATH=C:\Tools\ninja;%PATH% cmake -S D:\demo -B D:\demo\build_ninja -G Ninja -DCMAKE_BUILD_TYPE=Release ninja -C D:\demo\build_ninja

参数说明：第一行把 ninja 目录临时加进当前终端 PATH；第二行让 CMake 使用 Ninja 生成器，CMAKE_BUILD_TYPE 指定 Release，对应编译选项是 -O2；第三行 ninja -C 是 Ninja 自己的编译命令，效果等同 cmake --build build_ninja。Ninja 在增量编译上比 VS 生成器快不少，因为它不用反复检查 .vcxproj 的项目依赖链。

Ninja 配合 VS2017 的 cl.exe 时，需要先激活 vcvarsall 环境，否则 CMake 找不到编译器和 Windows SDK。这一步经常被忽略，于是又出现编译器探针问题。

call "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" x64

参数说明：vcvarsall.bat 是 VS 提供的环境初始化脚本，它把 cl.exe、link.exe、Windows SDK 的 include/lib 路径全部注入当前终端。必须在同一个终端窗口里先执行它，再执行 cmake。VS 生成器在 GUI 环境下会自动处理这部分，Ninja 生成器不会，因为 Ninja 本身不是 VS 的构件。

5. 安装和使用的 5 个常见坑：从“找不到编译器”到 Qt5Config.cmake 报错

下面这些坑，是我在 Windows 上给项目装 cmake-3.10.0-win64-x64 时反复踩过的。每一条都按“现象 → 原因 → 解决”写，希望能让你少走弯路。

5.1 cmake 不是内部或外部命令

现象：新开 cmd 窗口执行 cmake --version，系统提示“cmake 不是内部或外部命令，也不是可运行的程序或批处理文件”。

原因：只有三种可能。第一种是 PATH 变量里确实没加 bin 路径，或者加的路径写错了，比如写成了 C:\Tools\cmake-3.10.0-win64-x64 而不是其下的 bin。第二种是终端窗口没重开，PATH 修改还在缓存里。第三种是 PATH 里同时有多个 CMake，系统先找到了旧版本或损坏版本。

解决：先 echo %PATH% 看有没有 bin 路径；再新开一个终端试；再用 where cmake 看实际命中的是哪个文件。定位到具体是哪一层问题之后，用 3.2 小节的 PowerShell 方式重新写一遍用户级 PATH，然后重开终端。

5.2 Visual Studio 2022 装好了，3.10 却提示找不到生成器

现象：机器上装了最新的 Visual Studio 2022，执行 cmake -S . -B build 时报错，提示找不到可用的生成器，或者 “Could not find a supported Visual Studio version”。

原因：cmake-3.10.0-win64-x64 的 VS 生成器只认识 VS2017 这一代的注册表项。VS2022 的安装信息对 3.10 来说是个黑匣子，CMake 靠探测注册表里的 VsDevCmd.bat、vswhere 等机制来定位编译器，老版本不认识新路径。

解决：要么换这台机器上的构建工具链，安装 VS2017 Build Tools；要么升级 CMake 到支持 VS2022 的版本。3.10 和 VS2022 之间没有可行的兼容参数，别试图用 -G 字符串硬凑。如果你只是需要在同一台机器上用老 CMake 构建老项目，装的 VS2017 和 VS2022 可以共存，通过 vcvarsall.bat 的路径区分。

5.3 编译器探针失败：CMakeDetermineCompilerId 相关报错

现象：configure 阶段输出“Compiling the CXX compiler identification source file”之后直接报错，错误信息里能看到 CMakeDetermineCompilerId.cmake 相关路径；在 Linux 上常见的是 cmake error at /usr/share/cmake-4.2/modules/cmakedeterminecompilerid.cmake:9 这类报错，Windows 上则表现为探针生成的临时 exe 无法运行。

原因：探针是 CMake 在 build 目录的临时子目录里生成一个极小程序并用检测到的编译器去编译运行。如果杀毒软件实时防护拦截了探针生成的临时 exe，或者编译器路径、Windows SDK 环境没配对，探针必然失败。

解决：先在 PowerShell 里执行 vcvarsall.bat 激活完整编译环境，再重新 cmake；同时把杀毒软件对 build 目录的实时扫描临时关掉。如果确认是杀软问题，将 build 目录加入白名单。最后，删掉 CMakeCache.txt 和 CMakeFiles 目录再 configure，探针结果不会被旧缓存污染。

5.4 Qt5Config.cmake 报错：找不到 Qt5 组件

现象：项目里写了 find_package(Qt5 COMPONENTS Core Widgets)，configure 时报错，大意是“Could not find a package configuration file provided by Qt5”；网上常出现的是 cmake error at c:/qt/qt5.9.4/5.9.4/msvc2017_64/lib/cmake/qt5/qt5config.cmake 这种具体路径的报错。

原因：CMake 的 find_package 依赖 CMAKE_PREFIX_PATH 去搜索 Qt 安装目录。如果你没把 Qt 的 msvc2017_64 路径告诉 CMake，它根本不知道 Qt5Config.cmake 在哪。另一个原因是 Qt 库的编译器和当前生成器不匹配，比如拿 Qt 的 msvc2017 库去配 MinGW，即使找到了 Qt5Config.cmake，探针也会在编译阶段失败。

解决：显式指定前缀路径，正斜杠和反斜杠都行，但我习惯用正斜杠避免转义问题：

cmake -S D:\demo -B D:\demo\build -G "Visual Studio 15 2017" -A x64 -DCMAKE_PREFIX_PATH=C:/Qt/Qt5.9.4/5.9.4/msvc2017_64

参数说明：CMAKE_PREFIX_PATH 告诉 CMake 到哪个根目录下去找库的 config.cmake。Qt5Config.cmake 的实际位置是 lib/cmake/Qt5 下的包配置，CMake 会自动拼接查找。这一项加对之后，Qt5 的 include、lib、dll 路径都会自动进入构建。

5.5 中文路径导致 configure 失败：玄学但真实的编码问题

现象：工程文件全在 D:\测试项目\demo 下，cmake-gui 能正常打开，但 configure 时报“无法打开文件”或“invalid escape sequence”，错误信息有时还带着乱码。

原因：CMake 3.10 对 Windows 中文路径的处理不完善。它内部大部分字符串按 UTF-8 处理，老版本又不做代码页转换，中文字符在 NMake 或 MSBuild 调用环节里很容易变成乱码传给编译器。

解决：把源码、构建目录、Qt 路径、CMake 安装路径全部放到纯英文路径下。已经写在中文路径里的项目，复制到 D:\demo 再构建，别在 CMake 层面强改代码页，太折腾且不保证有效。这是我目前见过的唯一“换路径就好”的 CMake 玄学问题——你可以在英文路径下多试几种写法，中文路径则每次都翻车。

6. 再进一步：把 3.10 配给 Qt 5.9.4 + MSVC2017 的完整参数和验证方法

最后给你一套我在实际项目中用过的完整参数组合，目标是用 cmake-3.10.0-win64-x64 构建一个依赖 Qt 5.9.4 的 64 位桌面程序。这套组合适合老项目离线迁移，也适合新项目主动锁定老工具链。

先写好 CMakeLists.txt 的顶层组织。多模块项目常见做法是顶层文件只做全局声明和子目录添加，不写具体源文件：

cmake_minimum_required(VERSION 3.10) project(myapp LANGUAGES CXX) set(CMAKE_CXX_STANDARD 14) set(CMAKE_CXX_STANDARD_REQUIRED ON) set(CMAKE_AUTOMOC ON) set(CMAKE_AUTORCC ON) find_package(Qt5 COMPONENTS Core Widgets REQUIRED) add_subdirectory(src) target_link_libraries(myapp PRIVATE Qt5::Core Qt5::Widgets)

逻辑说明：set(CMAKE_AUTOMOC ON) 让 CMake 对含 Q_OBJECT 的头文件自动运行 moc，这是 Qt 项目必需的一步，手写 moc 命令会又累又容易错。find_package(Qt5...) 里的 REQUIRED 表示找不到就中断 configure，避免生成一个注定编译失败的工程。

配置构建目录：

cmake -S . -B build -G "Visual Studio 15 2017" -A x64 -DCMAKE_PREFIX_PATH=C:/Qt/Qt5.9.4/5.9.4/msvc2017_64 -DCMAKE_BUILD_TYPE=Release

参数说明：这套参数里，-G 锁定生成器，-A 锁定架构，CMAKE_PREFIX_PATH 指向 Qt 的 msvc2017_64 目录。VS 生成器下 CMAKE_BUILD_TYPE 实际不参与编译选项，真正的 Release/Debug 由 VS 里的 config 切换决定，但写上无妨，有些脚本会读取它做条件判断。

验证方法分三步。第一步看 configure 输出末尾有没有 “Configuring done” 和 “Generating done”；第二步打开 build 目录下的 .sln，确认 Qt5 的引用和 moc 生成文件都在；第三步直接编译 exe，运行起来确认 Qt 的 dll 能找到。Qt 的 dll 需要拷贝到 exe 目录，或者把 C:/Qt/Qt5.9.4/5.9.4/msvc2017_64/bin 加到 PATH。

我的个人习惯是，每在一台机器上装好这类离线安装包，就在 C:\Tools 下建一个 README.txt，把 CMake 版本、对应 VS 版本、Qt 路径、Ninja 路径、谁装的、装给哪个项目用，全部写进去。半年后再回来看看，这个 README 就是你最大的后悔药——不然你根本记不清这台机器上的 3.10 是从哪拷来的、当时为什么不用 3.20。希望帮到你。

本文还有配套的精品资源，点击获取