程序出现难以诊断的依赖冲突是很常见的事。举例来说，在同一个项目中包含 datomic (最新版本) 和 clojurescript (最新版本) 就会导致 guava 依赖项冲突（18 与 21+），而错误和解决方案则由 clojurescript 与 datomic 的顺序以及它们在整体依赖图中的相对依赖深度决定。
能够快速诊断并解决此类冲突对于保持现有项目运行并仍有权按需或必要升级库和依赖项非常重要。我提议两点。
首先，与其在解决冲突的同时构建图，不如作为次要过程，用足够的信 息构建一个足以解决冲突的图。这样总能确保依赖关系分析可以在稍后的时间进行，或者可以应用不同的解决算法。
其次，明确定义解决算法。目前我相信它可能是这样的：
1. 根版本是“固定的”
2. 图中较深版本的版本高于较浅版本的版本（假设叶子比根深）。
3. 在深度相同时，最高版本胜出。
将问题分解为两部分，第一部分是构建一个定义所有可能情况的数据结构，第二部分是通过解决算法过滤该图，这允许工具更好地了解潜在的依赖关系问题。
