当 Unity 加载项目时，Unity 包管理器会读取 项目清单，以便计算要检索和加载的包列表。当用户通过 包管理器窗口 安装或卸载包时，包管理器会将这些更改存储在项目清单文件中。项目清单文件通过 dependencies 对象管理包列表。
此外，项目清单还充当包管理器的配置文件，包管理器使用清单自定义注册表 URL 并注册自定义注册表。
您可以在 Unity 项目根文件夹下的 Packages 文件夹中找到名为 manifest.json 的项目清单文件。与 包清单文件 一样，项目清单文件使用 JSON（JavaScript 对象表示法）语法。
所有属性都是可选的。但是，如果您的项目清单文件不包含任何值，则包管理器窗口不会加载，并且包管理器不会加载任何包。
| 键 | JSON 类型 | 描述 |
|---|---|---|
| dependencies | 对象 | 项目所需的包集合。这仅包括直接依赖项（间接依赖项在 包清单每个包都有一个清单，它向包管理器提供有关该包的信息。清单包含诸如包名称、版本、用户描述、对其他包的依赖项（如果有）和其他详细信息。 更多信息 参见 词汇表 中列出）。每个条目将 包名 映射到项目所需的最小 版本 {"dependencies": {"com.my-package": "2.3.1","com.my-other-package": "1.0.1-preview.1",等等。}}指定版本号表示您希望包管理器从包注册表下载该包（即，包的 来源 是注册表）。但是，除了使用 版本 之外，您还可以指定 本地文件夹或 tarball 文件的路径 或 Git URL。 注意：您不需要在此处指定 嵌入式 包，因为包管理器会自动在您的项目 Packages 文件夹中找到它们并加载它们。如果在自己的包清单中存在具有相同 名称 的嵌入式包，则包管理器将忽略任何条目。 |
| enableLockFile | 布尔值 | 启用锁定文件以确保以确定性方式解析依赖项。默认情况下，此值为 true。有关更多信息，请参见 使用锁定文件。 |
| resolutionStrategy | 字符串 | 根据语义版本控制规则升级 间接依赖项当您的项目请求一个本身“依赖于”另一个包的包时，就会发生间接或传递依赖。例如，如果您的项目依赖于 [email protected] 包，而该包又依赖于 [email protected] 包，那么您的项目将对 Alembic 具有直接依赖项，对 Timeline 具有间接依赖项。 更多信息参见 词汇表。默认情况下，此值为 lowest。有关更多信息，请参见下面的 设置解析策略。 |
| scopedRegistries | 对象数组 | 除了默认注册表之外，还指定自定义注册表。这使您可以托管您自己的包。 有关更多详细信息，请参见 作用域注册表。 |
| testables | 字符串数组 | 列出您想要在 Unity 测试框架测试框架包（以前称为测试运行器）是 Unity 工具，它在编辑模式和播放模式下以及在独立、Android 或 iOS 等目标平台上测试您的代码。 更多信息 参见 词汇表 中加载其测试的包的名称。有关更多信息，请参见 将测试添加到包。 注意：您不需要在此处指定 嵌入式 包，因为 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 的包依赖项解析使用间接依赖项的更高版本，但这并不是一个好策略，原因有两个
更好的方法是通过设置 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，没有上限）中的最高版本 |