Unity 2017安装全攻略：版本匹配与模块选择是关键

前一阵帮一个实习生排一个老项目的问题。项目是两年前从另一个团队手里接过来的，Unity 版本还停在 2017.4.40f1。新电脑上装的是最新版 Unity Hub，结果打开工程时先弹出一串升级提示，还没等看清楚，场景里的部分脚本引用就飘红了。后来把对应的 Unity 2017.4.40f1 装好，重新打开同一个工程，前后不到半小时就恢复正常。

这件事很典型。很多人搜“Unity2017安装3正确方法”，大概率不是想尝鲜老版本，而是手头有一个旧工程，或者公司项目明确锁定了这个版本。这时候最重要的不是“把 Unity 装进电脑”这个动作，而是装完之后能打开对应工程、能过构建、能正常出包。

我的判断很直接：Unity 2017 安装真正的难点，不是下载和点“下一步”，而是版本匹配与模块完整。下面三个方法，本质上都是在处理这两件事。

1. 装之前，先弄明白三个问题

很多人装到一半卡住，不是因为下载速度慢，而是因为下载前没想清楚为什么要装这个版本。

1.1 工程到底需要哪个小版本

Unity 2017 是一个大版本家族，里面有 2017.1、2017.2、2017.3、2017.4 这些系列，每个系列后面还有若干补丁版本。

第一个动作永远是查工程里的ProjectVersion.txt。这个文件记录了工程创建时使用的编辑器版本，比如m_EditorVersion: 2017.4.40f1。看到哪个版本，就装哪个版本，不要凭直觉装一个看起来差不多的。

如果是从同事手里接项目，直接问对方存档时用的具体版本号。不同小版本之间虽然大多可以互相打开，但 Unity 在打开旧工程时可能提示升级，升级过程会改动项目元数据。不要在小版本上做无谓的尝试，尤其是多人协作的仓库。

1.2 目标平台决定模块

安装时不能只装主编辑器。如果你的目的是出 Android 包，却没有勾选 Android Build Support 模块，后面配置 Build Target 时会非常痛苦。WebGL、iOS、UWP 同理。

Unity 2017 的模块加载逻辑和现在不完全一样，后续补装没有新版那么顺手。所以下载前先问一句：这个工程最后要发到哪个平台？这一步决定模块集合。

这只是常见组合，不是唯一答案。真正常用的是哪几个，取决于项目。

1.3 本机工具链的兼容性

2017 年发布的 Unity 面向的是当时的环境。在现在的 Windows 10、Windows 11 上安装一般没问题，但有几个点要提前确认：

• 老版本编辑器体积不算大，但工程导入后 Library 会膨胀，安装前预留足够磁盘空间。
• 部分安全软件会把老版本安装过程误判为异常行为，至少在安装阶段放行 Unity 相关目录。
• 不要把 Unity 装在带中文的路径里，老版本对非 ASCII 路径的支持并不友好。
• 如果本机同时装了多个 Unity 版本，建议用 Unity Hub 统一管理，而不是手动安装到同一个默认目录里。

这里最容易踩坑的不是版本本身，而是“新版本能打开旧工程”这个错觉。先把版本号定死，再谈安装方式。

2. 方法一：用 Unity Hub 管理安装

这是我最推荐的方式，尤其是多人协作和需要同时维护多个 Unity 版本的环境。

2.1 在 Hub 里添加老版本的实际操作

Unity Hub 虽然是新工具，但对老版本的支持仍然保留。打开 Hub 后先登录 Unity 账号，进入 Installs 页面，选择 Install Editor。由于 2017 不在默认的最近版本列表里，需要找到“查看其他版本”或历史版本入口，再手动定位到 2017.4.40f1 这类版本。

添加版本的时候，Hub 会显示这个版本支持的模块列表。这里有个小经验：Hub 一旦把版本添加到列表里，后续再次安装或补模块会比直接安装完整包方便很多。

不过，Hub 下载偶尔会卡在“下载中”不动。很多情况下不是文件资源出问题，而是本地网络代理或缓存导致。可以先清掉 Hub 的下载缓存，再重新下载。不要反复强制重试，容易留下脏数据。

2.2 模块勾选建议

用 Hub 安装 2017 时，最容易犯的错误是只勾了主编辑器。我一般建议在安装界面上至少勾这三个组合之一：

• Windows 桌面开发：主编辑器加 Windows Build Support。
• Android 出包：主编辑器加 Android Build Support、Android SDK & NDK。
• WebGL 运行：主编辑器加 WebGL Build Support。

如果项目里有第三方登录、推送、热更新等插件，安装完模块后还要确认插件对应的原生工程是不是兼容 2017。插件问题有时候比模块缺失更隐蔽，因为它往往在构建时才报错。

2.3 为什么推荐这种方式

因为 Unity Hub 做了一个非常重要的版本隔离。电脑上可以同时存在 2017、2019、2021 多个版本，不同工程打开时选择对应版本即可。对团队协作来说，这种可回退的方式比单独安装更好管理。后面如果要临时切换到其他版本验证问题，也不用卸载重装。

Hub 的另一个好处是项目关联。每个工程目录可以绑定一个编辑器版本，同事之间可以靠ProjectVersion.txt和 Hub 快速对齐环境。

3. 方法二：从官方存档页下载完整安装包

如果你的网络环境对 Hub 不太友好，或者你想保留一份完整的本地安装包，第二种方法是直接下载官方存档的完整安装程序。

3.1 怎么找版本

Unity 官方的发行存档页面会列出历史版本。进入后找到 2017 分类，里面能看到 2017.1 到 2017.4 的各个补丁。通常优先选 2017.4 系列的最后几个补丁，因为它是当年的长期维护版本，稳定性更好，也更容易在网上找到配套的工具链说明。

下载时可能需要登录 Unity 账号，这属于正常授权流程，提前准备好账号即可。

3.2 两个安装程序的区别

存档页通常会提供两类文件：

• Unity Download Assistant：小体积引导程序。运行后会出现一个向导，让你选择模块，然后在本地联网下载并安装。适合网速好、只需装一次的场景。
• UnitySetup 完整安装程序：体积较大，但安装时不需要联网拉取太多数据。适合网络不稳定，或者希望保留完整安装包给团队其他机器使用的情况。

如果安装到一半失败，可以换另一个安装程序再试。两个都失败，一般先怀疑安装包下载不完整，再怀疑安全软件拦截。

3.3 手动安装顺序

手动安装时，推荐按这个顺序走：

1. 先运行 UnitySetup 安装主编辑器。
2. 安装界面里如果有模块选择，按目标平台勾选。
3. 安装完成后，单独处理 Android 平台需要的 JDK 和 SDK。
4. 打开一个测试空工程，确认编辑器能正常启动。
5. 再打开目标工程验证。

注意，如果安装结束后发现模块缺失，不要立刻卸载重装。很多情况下可以在 Hub 里对已有版本执行“添加模块”，或者单独下载模块安装包补装，不需要把整个编辑器删掉重来。

4. 方法三：离线安装包加命令行安装，适合批量部署

如果你的场景是团队内统一开发环境，或者有一台离线机器，手动点安装程序效率太低。Unity 2017 的 Windows 安装程序支持无人值守安装参数，可以把安装路径和静默参数先定好，然后通过脚本批量执行。

4.1 为什么要用命令行

统一版本可以有效减少“我这边能跑，你那边不行”的问题。团队里如果每人手点安装，很容易出现有人模块勾多了、有人勾少了、有人默认路径不同等细节差异。用同一套命令行参数安装，可以保证主编辑器目录和版本一致。

4.2 一个常见写法

以下只是示例写法，具体参数要结合你下载到的实际安装包和本机环境调整。假设你下载了类似UnitySetup64-2017.4.40f1.exe的安装程序，可以在命令行里尝试：

UnitySetup64-2017.4.40f1.exe /S /D=D:\Unity2017

这里的/S表示静默安装，/D表示安装目录。不同安装程序支持的参数不完全一样，操作前先用/?或其他方式确认当前安装包的参数说明。

如果安装目录选在Program Files下，后续可能出现权限问题。建议统一安装到一个非系统目录，比如D:\Unity2017，后续补模块和配置 SDK 都更方便。

命令行安装对主编辑器比较有效，但对模块安装不一定一次性覆盖。批量部署时要额外准备模块安装包，或者用 Hub 的统一模板配置。

4.3 批量部署时的补模块

命令行方式往往只装主编辑器，模块需要专门处理。团队里如果统一使用同一个模块集合，最好先在一台机器上把模块装好，确认能成功出包，再把对应的安装包集合复制到内网共享目录。

另外，批量部署之后一定要写一个环境记录文件，把以下信息记下来：

• Unity 编辑器版本号。
• 安装路径。
• JDK 版本和路径。
• Android SDK 版本和路径。
• 项目要求的 Minimum API Level 和 Target API Level。

有了这份记录，后面任何一台新机器都能按相同步骤还原环境，而不是靠个人记忆。

5. 装完以后，先按这个链路排查

安装成功不等于环境就绪。按下面的顺序排查，可以避免在错误的方向上浪费时间。

5.1 先处理 License

常见报错是No valid Unity Editor license found. Please activate your license.。这个一般是编辑器未登录、网络未连通，或者个人版授权没有完成。解决路径是：打开编辑器，使用 Unity 账号登录，选择 Personal 授权。

这里不要直接去网上找删掉注册表或修改配置文件的办法。虽然有人这样临时处理，但容易留下隐患，在团队环境里也不可控。真正的生产环境应该走正式授权流程。

5.2 再查 Android 构建环境

2017 默认的 Android 构建链路比新版旧，很多老项目打开时能进编辑器，但一 Build 就报错。问题多数出在 JDK、SDK、NDK 版本不匹配。

检查顺序：

• 打开 Build Settings，进入 Player Settings，确认 Minimum API Level 和 Target API Level。
• 确认本机 JDK 位数和版本，2017 时代常用的是 JDK 8。
• 如果项目里用过第三方 Android 插件，插件要求的 API Level 也会影响构建结果。

有一个很常见的诱惑是：看到新版平台要求，就把 Target API Level 调到 35。但 Unity 2017 的构建链并不支持那么新的 API 等级。项目原本是 26 或 28，就不要为了迎合平台提示强行升级，否则会触发一堆资源编译错误。

5.3 老项目的脚本引用和 Library

旧工程第一次用新装的 2017 打开，过程会非常慢，因为 Unity 要重新生成 Library。这个阶段不要中途强制退出，否则容易损坏 Library 产生残留。

如果编译完成后部分脚本引用丢失，先看控制台报错是不是来自第三方 DLL，或者 .NET 版本不匹配。不要急着改代码，多数情况下是版本迁移导致元数据变化，重新导入即可。

5.4 用最小用例确认环境

等到工程能正常打开以后，建议建一个空场景做最小验证。选择一个完整出包任务，比如打 Windows 空包或者 Android 空包。它能快速暴露模块缺失、SDK 路径配置错误、许可证异常这一类问题。

如果空包能出来，说明整个安装链路基本通了。如果空包失败，就不要急着去调业务代码，先回头检查模块和构建环境。

6. 安装决策流程和最终建议

把前面的内容收束成一个五步决策框架，方便以后装其他老版本时复用。

6.1 一个可复用的五步决策框架

• 第一步：查看ProjectVersion.txt，锁定具体版本号。
• 第二步：确认目标平台，决定要装的模块集合。
• 第三步：选择安装方式。单人开发用 Hub，离线环境用完整安装包，团队批量部署用命令行。
• 第四步：安装后先做最小空包构建验证。
• 第五步：检查 License、JDK/SDK、API Level，并记录本机配置。

这套流程不只是针对 2017，换作 2018、2019 甚至 5.x，同样适用。老版本安装的底层逻辑是一致的，变的只是模块名和默认工具链。

6.2 一些边界

这个方法的重点是让 Unity 2017 在现在的系统上复现出来，并不适合所有场景。

如果你打算把 2017 工程迁移到 2020 以后的版本，会遇到 API、包管理、渲染管线升级等问题，那是另一个话题，不能靠改安装版本解决。

如果只是想学习 Unity 游戏开发，也没有必要专门装 2017。直接使用当前长期维护版本会更合适。

另外，不要从来路不明的渠道下载所谓的绿色版、精简版。旧版本本来就很依赖主编辑器与模块的完整映射，缺文件会导致后续构建反复踩坑。团队环境里引入不可控的二进制，风险不值得。

6.3 回到最开始那个结论

回到最实用的建议：先找到版本号，再选安装方式，最后用空包构建验证。Unity 2017 本身并不难装，难点在于你有没有在安装前把版本、模块、工具链、账号授权这四件事想清楚。

把这四件事处理好，这个老版本照样可以稳定支持一个生产项目很久。