一、依赖冲突的原因

如果maven项目中，A依赖于B和C，B依赖于1.0版本的D，C依赖于2.0版本的D，这时候就会出现依赖冲突。

在A上加载使用D依赖的时候，maven会根据依赖路径最短优先原则，加载一个D依赖，另一个是不会被使用的。

在大多数时候，依赖冲突可能并不会对系统造成什么异常，但是，在某些特定的情况下会导致系统报错，比如，版本的变化导致API不同，或者删除了类，而正好又使用到有所变化的API或者被删除的类，那么就会导致系统报错。

二、复现一个依赖冲突场景

为了后文讲解怎么定位依赖冲突，这里我们先复现一个依赖冲突场景。

三个module：

• demo-order
• demo-goods
• demo-platform

依赖关系如下：

demo-goods的maven依赖

<dependency>
    <groupId>org.mybatis</groupId>
    <artifactId>mybatis</artifactId>
    <version>3.5.6</version>
</dependency>

demo-order的maven依赖

<dependency>
    <groupId>org.mybatis</groupId>
    <artifactId>mybatis</artifactId>
    <version>3.3.0</version>
</dependency>

demo-platform的maven依赖

<dependency>
    <groupId>org.demo</groupId>
    <artifactId>demo-goods</artifactId>
    <version>1.0-SNAPSHOT</version>
</dependency>
<dependency>
    <groupId>org.demo</groupId>
    <artifactId>demo-order</artifactId>
    <version>1.0-SNAPSHOT</version>
</dependency>

三、定位依赖冲突

maven show dependencies

IDEA中自带一个功能，maven show dependencies，右击pom文件可以调出，或者右上角的快捷键也可以调出

方式一：右击

方式二

maven show dependencies，会为我们显示一棵maven的依赖树：

蓝色箭头是正常的依赖关系，红色箭头是依赖冲突关系。

如果依赖太多，ctrl+F可以弹出依赖列表，在其中可以选择想定位到的依赖：

很遗憾的是maven show dependencies这种方式的场景实在是有限，正常的稍微上一点体量的项目，依赖树都会很大，用这种方式会把人看傻。

这里我随便拿一个博主经历过的项目上的依赖树拿出来，是长这样的：

这种依赖树，根本就没办法去看，就算定位到了，依赖路径的线条你都找不清楚。所以就没有办法了吗？当然是有的，这就是IDEA的一款插件，我们的maven依赖冲突分析利器——maven helper。

四、maven helper

首先是下载安装，一定要看准，别装错了，如果IDEA中没办法安装的话直接去官网上下载，然后走本地离线安装即可。

这里已经提前安装好了，第一次安装的话，安装完重启一下IDEA才会生效。

安装 完成之后重启idea

重启后完成安装

安装完maven helper后，pom.xml文件的左下角会有一个dependency的选项，点击这个选项可以进入maven helper：

all dependencies选项，会展示当前项目的依赖树：

这种目录层级的依赖树，在依赖量大的情况下，比起图形来就要友善很多，其中会用红色标出被冲突掉的依赖，也就是不会被用到的依赖。

conflicts选项，可以根据依赖名来进行依赖的搜索，搜索结果会展示生效的依赖版本，点击会显示项目中该依赖的所有版本，会用红色标出被冲突掉，不生效的版本：

maven helper中右键依赖，可以排除依赖：

它会直接用exclusions来排除依赖：

<dependency>
    <groupId>org.demo</groupId>
    <artifactId>demo-goods</artifactId>
    <version>1.0-SNAPSHOT</version>
</dependency>
<dependency>
    <groupId>org.demo</groupId>
    <artifactId>demo-order</artifactId>
    <version>1.0-SNAPSHOT</version>
    <exclusions>
        <exclusion>
            <artifactId>mybatis</artifactId>
            <groupId>org.mybatis</groupId>
        </exclusion>
    </exclusions>
</dependency>

五、依赖路径最短优先原则

这里扩展聊一聊依赖路径最短优先原则。

依赖路径最短优先原则是一种解决依赖冲突的策略，它指定当存在多个冲突的依赖版本时，选择依赖路径最短（即嵌套层级最浅）的版本作为解决方案。这个原则通常被用于 Maven 等构建工具中，以确定在依赖关系中应该使用哪个版本的库。

以下是一个示例，说明依赖路径最短优先原则如何工作：

假设有以下依赖关系：

应用程序 A 依赖于库 B（版本 1.0）和库 C（版本 1.0）。

库 B 依赖于库 C（版本 2.0）。

根据依赖路径最短优先原则，解决冲突的方式是选择最短路径上的依赖版本。在这个例子中，库 B 的依赖路径最短，因此会选择库 C 的版本 1.0 作为解决方案。这样，库 C（版本 2.0）不会被选择，因为它的路径比较长。

这个原则的目的是最小化潜在的依赖冲突问题，因为通常情况下，更短的路径意味着更直接的依赖关系，可能更容易避免冲突。