使用 Maven 工具，带给开发者最直观的好处就是：

比如，在项目中引入 easyexcel 后：

我们使用 Maven Helper 插件，查询依赖树：

可以看到：

通过查看 External Libraries 列表可以得到验证：

思考一个问题，由于 Maven 的依赖性传递特性，如果有多个jar包同时都依赖一个jar包，且版本不一样的时候，如下图：那么 Maven 该使用jarC 1.1的包还是 jarC 1.2的包呢？

这时会遵循两个规则，分别是最短路径原则和最先声明原则。

如上图：

Maven 项目最终会使用 1.1 的 C 。

那么当最短路径一样的时候该怎么办？  这时就需要最先声明原则，且最先声明原则就是在最短路径相同的时候生效，如下图所示：

由上图可以看出，依赖路径如下：

现在最短路径是一样的，则就需要看谁先声明的。  在工程的pom.xml里，可以看到是先引入的 jarA，那么根据规则，则jarC(1.2)生效，Maven 会使用jarC(1.2)来进行编译和打包。

软件开发通常都是会有不断的版本迭代，如果：

则此时工程就有可能会产生jar包冲突，下面将通过图解举例介绍。

假如jarC 版本升级，由1.1 版本 升级到 1.2后，G.class由于被修改而不存在了：

我们知道，Maven编译时会把业务代码编译成class文件。 比如下面这种场景，业务代码DemoController.java类引入了jarA中的A1.class，maven 编译时会将业务代码DemoController.java类编译为DemoController.class：

备注：

项目部署成功后，当接收到前端发起的一次请求，需要调用selectList接口查询数据时，会因为在项目依赖的jar包里找不到G.class类而报错，一个详细的流程如下图所示：

备注：

问题来了，jarC 版本升级，由1.1 版本 升级到 1.2后，G.class类的begin方法由于逻辑优化而不存在了，改为begin1：

备注：

备注：

可以借助相关工具去帮助排查jar冲突原因（后边会以实例介绍解决思路）：

欢迎访问更多关于消息中间件的原创文章：