Unity 加载项目时，Unity Package Manager 会读取项目清单，以便计算要获取并加载的包的列表。当用户通过 Package Manager 窗口安装或卸载包时，Package Manager 会将这些更改存储在项目清单文件中。项目清单文件通过依赖关系对象来管理包的列表。
此外，项目清单充当 Package Manager 的配置文件，它使用清单来自定义注册表 URL 并注册自定义注册表。
您可以在 Unity 项目根文件夹下的 Packages 文件夹中找到名为 manifest.json 的项目清单文件。与包清单文件类似，项目清单文件使用 JSON（JavaScript 对象表示法）语法。
所有属性均为可选。但是，如果您的项目清单文件不包含任何值，则不会加载 Package Manager 窗口，并且 Package Manager 不会加载任何包。
| 键 | JSON 类型 | 描述 |
|---|---|---|
| dependencies | 对象 | 项目所需的包的集合。这仅包括直接依赖项（间接依赖项列在包清单中）。每个条目都将包名称映射到项目所需的最低版本：{"dependencies": {"com.my-package": "2.3.1","com.my-other-package": "1.0.1-preview.1",etc.}}指定版本号表示您希望 Package Manager 从包注册表下载包（即，包的来源是注册表）。但是，除了使用版本之外，还可以指定本地文件夹路径或 tarball 文件路径，或者 Git URL。 注意：无需在此处指定嵌入式包，因为 Package Manager 会在项目的 Packages 文件夹中找到这些包并自动对它们进行加载。如果在自己的包清单中存在相同名称的嵌入式包，Package Manager 会忽略相关的任何条目。 |
| enableLockFile | 布尔值 | 启用锁定文件以确保以确定性方式解析依赖项。默认情况下，该值设置为 true。有关更多信息，请参阅使用锁定文件。 |
| resolutionStrategy | 字符串 | 基于语义版本控制规则升级间接依赖项。默认情况下，该值设置为 lowest。有关更多信息，请参阅下面的设置解析策略。 |
| scopedRegistries | 对象数组 | 指定除了默认注册表之外的自定义注册表。这样允许您托管自己的包。 有关更多详细信息，请参阅作用域注册表。 |
| testables | 字符串数组 | 列出要在 Unity Test Framework 中加载其测试的包的名称。有关更多信息，请参阅向包添加测试。 注意：您无需在此处指定嵌入式包，因为 Unity Test Framework 假定它们默认可测试。 |
{
"scopedRegistries": [{
"name": "My internal registry",
"url": "https://my.internal.registry.com",
"scopes": [
"com.company"
]
}],
"dependencies": {
"com.unity.package-1": "1.0.0",
"com.unity.package-2": "2.0.0",
"com.company.my-package": "3.0.0",
"com.unity.my-local-package": "file:<path>/my_package_folder",
"com.unity.my-local-tarball": "file:<path>/my_package_tarball.tgz",
"com.unity.my-git-package": "https://my.repository/my-package.git#v1.2.3"
},
"enableLockFile": true,
"resolutionStrategy": "highestMinor",
"testables": [ "com.unity.package-1", "com.unity.package-2" ]
}
虽然您可以通过将包版本显式添加到项目清单，来强制 Unity 的包依赖项解析使用更高版本的间接依赖项，但这不是一个很好的策略，原因有两点：
更好的方法是自定义 Package Manager 如何根据语义版本控制规则选择间接依赖项，方法是设置 resolutionStrategy 属性：
| 值： | 描述： |
|---|---|
| lowest | 不升级间接依赖项。相反，它完全使用请求的版本。这是默认模式。 |
| highestPatch | 升级到具有相同 Major 和 Minor 组件的最高版本。例如，对于请求的版本 1.2.3，此策略选择 [1.2.3, 1.3.0) 作用域内的最高版本（即 >= 1.2.3 和 < 1.3.0）。 |
| highestMinor | 升级到具有相同 Major 组件的最高版本。例如，对于请求的版本 1.2.3，此策略选择 [1.2.3, 2.0.0) 作用域内的最高版本（即 >= 1.2.3 和 < 2.0.0）。注意：版本 1.0.0 标志着第一个稳定、可用于生产环境的版本。低于此值时，版本 0.X.Y 表明其 API 尚不稳定，连续的次要版本可能会引入重大更改。SemVer 规范的这一部分允许在不妨碍快速开发的情况下发布包的早期版本。因此，当目标版本为 0.X.Y 时，highestMinor 的行为类似于 highestPatch，以确保选择向后兼容的版本。例如，对于请求的版本 0.1.3，此策略会选择作用域 [0.1.3,0.2.0) 中的最高版本。 |
| highest | 升级到最高版本。例如，对于请求的版本 1.2.3，此策略选择 [1.2.3,) 作用域内的最高版本（即 >= 1.2.3 且没有上限） |