程序存在难以诊断的依赖冲突是很常见的。一个很好的例子是，在同一个项目中包含 datomic（最新版）和 clojurescript（最新版）。这会在 guava 依赖项中引入冲突（18 与 21+），错误和解决方案都是由 clojurescript 与 datomic 的顺序及其在整体依赖图中的相对深度决定的。
能够快速诊断和解决这类冲突对保持现有项目运行，并仍然有自由选择升级库和依赖项至关重要。我提出两点建议。
首先，不是在决定解决方案的同时构建图，而是在二次过程中构建足够信息的图来决定解决方案。这样可以确保在稍后时间或应用不同的解决方案算法时可以进行依赖分析。
其次，正式化解决方案算法。目前我相信它可能如下：
1. 根版本被“固定”
2. 图中较深的版本优先于较浅的版本（假设叶节点高于根节点）。
3. 如果在深度方面存在平局，则较高的版本获胜。
将问题分解为两部分，第一部分是构建一个定义所有可能性的数据结构，第二部分是通过解决方案算法过滤该图，这允许工具可以更多了解潜在的依赖问题。
