Unity 加载项目时，Unity Package Manager 会读取项目清单，以便计算要获取并加载的包的列表。当用户通过 Package Manager 窗口安装或卸载包时，Package Manager 会将这些更改存储在项目清单文件中。项目清单文件通过依赖关系对象来管理包的列表。
此外，项目清单充当 Package Manager 的配置文件，它使用清单来自定义注册表 URL 并注册自定义注册表。
您可以在 Unity 项目根文件夹下的 Packages 文件夹中找到名为 manifest.json 的项目清单文件。与包清单文件类似，项目清单文件使用 JSON（JavaScript 对象表示法）语法。
所有属性均为可选。但是，如果您的项目清单文件不包含任何值，则不会加载 Package Manager 窗口，并且 Package Manager 不会加载任何包。
提示：任何时候，都可以从 Unity 帮助主菜单中选择 Reset packages to defaults 来解决注册表问题。但请注意，此操作将重置您对项目中的依赖项所做的所有更改，因此最好将这种策略用作最后的选择。
| 键 | 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 | Boolean | 启用锁定文件以确保以确定性方式解析依赖项。默认情况下设置为 true。有关更多信息，请参阅使用锁定文件。 |
| resolutionStrategy | String | 基于语义版本控制规则升级间接依赖项。默认情况设置为 lowest。有关更多信息，请参阅下面的设置解析策略。 |
| scopedRegistries | 对象数组 | 指定除了默认注册表之外的自定义注册表。这样允许您托管自己的包。 请参阅范围注册表了解更多详细信息。 |
| testables | 字符串数组 | 列出要在 Unity 测试框架中加载其测试的包的名称。有关更多信息，请参阅向包添加测试。 注意：不需要指定嵌入式包，因为 Unity 测试框架默认它们是可测试的。 |
{
"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 | 升级到具有相同主要和次要组件的最高版本。例如，对于请求的版本 1.2.3，此策略选择以下范围内的最高版本： [1.2.3, 1.3.0) （即 >= 1.2.3 且 < 1.3.0）。 |
| highestMinor | 升级到具有相同主要组件的最高版本。例如，对于请求的版本 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 且没有上限） |
Note: These ranges never allow a dependency to jump from a stable release to an experimental or pre-release package.