解析和冲突

将一个包添加到项目清单后，Unity 会将该包视为项目的依赖项（一个直接依赖项）。但是，一个包也会进一步依赖其他包，这可能会导致在使用这个包的项目中产生间接依赖项。

由于大多数项目需要多个包才能开发游戏和应用，因此 Package Manager 必须评估所有请求的（直接或间接）包版本以从注册表中检索，并决定安装这些包的哪一个版本。为此，它会计算出一组能满足项目中所有直接和间接依赖项的包，从项目的依赖项开始，递归搜索每一个间接依赖项，收集所有的依赖信息，然后挑选出一组能够满足依赖要求且没有任何冲突的包。例如，此依赖关系图表示项目中具有四个直接依赖项及其所有间接依赖项：

在此示例中：

• 浅蓝色节点代表项目的直接依赖项。
• 深蓝色节点显示此项目中间接依赖项的相同的包和版本。
• 红色节点显示同一个包的两个不同版本，这是一个冲突。

注意：只需要解析具有版本声明的包依赖项。相对于基于版本的依赖项，Package Manager 优先选择从其他来源安装的包（如嵌入式包和使用本地路径、Git URL 声明的依赖项以及内置包。

选择最佳解决方案

根据项目清单中定义的包集合，评估所有可能的包组合可能需要很长时间：一个项目可能依赖数百个包，每个包都依赖于数百个其他包，大多数需要不同的版本。

锁定文件和 resolutionStrategy

为了提供最有效的解决方案，Package Manager 通过在锁定文件中跟踪以前使用的包版本来确定它们的优先级。这保证了使用相同输入的后续依赖解析会产生相同的输出。它还最大限度地减少了耗时的操作，例如下载、解压缩或复制包。

有时，Package Manager 无法找到一个仅包含锁定包的解决方案。在这种情况下，Package Manager 使用升级风险最小的解决方案，默认情况下，补丁升级优先于次要或主要版本升级，次要版本升级优先于主要版本升级。但是，您可以使用 resolutionStrategy 属性自定义您希望 Package Manager 在考虑更高版本时的激进程度。

示例

在此示例中，请求了以下软件包的多个版本：

• burst@1.2.2（两次）和 burst@1.3.0-preview.3
• collections@0.5.1-preview.11 和 collections@0.5.2-preview.8
• jobs@0.2.4-preview.11（两次）和 jobs@0.2.5-preview.20

使用直接和间接依赖项集合，Package Manager 选择 burst 包 (burst@1.3.0-preview.3) 的最高版本，从而满足 collections@0.5.2-preview.8 包的依赖：

• Unity 2019.4 中添加了新的包依赖解算器 (SAT) NewIn20194