目录
1.依赖冲突的原因
如果maven项目中，A依赖于B和C，B依赖于1.0版本的D，C依赖于2.0版本的D，这时候就会出现依赖冲突。
在A上加载使用D依赖的时候，maven会根据依赖路径最短优先原则，加载一个D依赖，另一个是不会被使用的。
在大多数时候，依赖冲突可能并不会对系统造成什么异常，但是，在某些特定的情况下会导致系统报错，比如，版本的变化导致API不同，或者删除了类，而正好又使用到有所变化的API或者被删除的类，那么就会导致系统报错。
2.复现一个依赖冲突场景
为了后文讲解怎么定位依赖冲突，这里我们先复现一个依赖冲突场景。
三个module：
-
orderService
-
productService
-
platformService
依赖关系如下：
orderService依赖：
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-lang3</artifactId>
<version>3.8.1</version>
</dependency>productService依赖：
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-lang3</artifactId>
<version>3.9</version>
</dependency>platform的依赖：
<dependency>
<groupId>org.example</groupId>
<artifactId>orderService</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>org.example</groupId>
<artifactId>productService</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>3.如何定位依赖冲突
3.1.maven show dependencies
IDEA中自带一个功能，maven show dependencies，右击pom文件可以调出，或者右上角的快捷键也可以调出
maven show dependencies，会为我们显示一棵maven的依赖树：
蓝色箭头是正常的依赖关系，红色箭头是依赖冲突关系。
如果依赖太多，ctrl+F可以弹出依赖列表，在其中可以选择想定位到的依赖：
很遗憾的是maven show dependencies这种方式的场景实在是有限，正常的稍微上一点体量的项目，依赖树都会很大，用这种方式会把人看傻。
这里我随便拿一个博主经历过的项目上的依赖树拿出来，是长这样的：
这种依赖树，根本就没办法去看，就算定位到了，依赖路径的线条你都找不清楚。所以就没有办法了吗？当然是有的，这就是IDEA的一款插件，我们的maven依赖冲突分析利器——maven helper。
3.2.maven helper
首先是下载安装，一定要看准，别装错了，如果IDEA中没办法安装的话直接去官网上下载，然后走本地离线安装即可。
博主，这里已经提前安装好了，第一次安装的话，安装完重启一下IDEA才会生效。
安装完maven helper后，pom.xml文件的左下角会有一个dependency的选项，点击这个选项可以进入maven helper：
all dependencies选项，会展示当前项目的依赖树：
这种目录层级的依赖树，在依赖量大的情况下，比起图形来就要友善很多，其中会用红色标出被冲突掉的依赖，也就是不会被用到的依赖。
conflicts选项，可以根据依赖名来进行依赖的搜索，搜索结果会展示生效的依赖版本，点击会显示项目中该依赖的所有版本，会用红色标出被冲突掉，不生效的版本：
maven helper中右键依赖，可以排除依赖：
它会直接用exclusions来排除依赖：
<dependencies>
<dependency>
<groupId>org.example</groupId>
<artifactId>orderService</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>org.example</groupId>
<artifactId>productService</artifactId>
<version>1.0-SNAPSHOT</version>
<exclusions>
<exclusion>
<artifactId>commons-lang3</artifactId>
<groupId>org.apache.commons</groupId>
</exclusion>
</exclusions>
</dependency>
</dependencies>4.依赖路径最短优先原则
这里扩展聊一聊依赖路径最短优先原则。
依赖路径最短优先原则是一种解决依赖冲突的策略，它指定当存在多个冲突的依赖版本时，选择依赖路径最短（即嵌套层级最浅）的版本作为解决方案。这个原则通常被用于 Maven 等构建工具中，以确定在依赖关系中应该使用哪个版本的库。
以下是一个示例，说明依赖路径最短优先原则如何工作：
假设有以下依赖关系：
-
应用程序 A 依赖于库 B（版本 1.0）和库 C（版本 1.0）。
-
库 B 依赖于库 C（版本 2.0）。
根据依赖路径最短优先原则，解决冲突的方式是选择最短路径上的依赖版本。在这个例子中，库 B 的依赖路径最短，因此会选择库 C 的版本 1.0 作为解决方案。这样，库 C（版本 2.0）不会被选择，因为它的路径比较长。
这个原则的目的是最小化潜在的依赖冲突问题，因为通常情况下，更短的路径意味着更直接的依赖关系，可能更容易避免冲突。