在项目的开发中无法避免的遇到一些奇怪的问题尤其是Jar的管理方便更让人恼火。
依赖传递的原则
几乎所有的Jar包冲突都和依赖传递原则有关。下面说明Maven的依赖传递原则。
最短路径优先原则
假如引入了两个Jar包A、B，都依赖Z这个Jar包
A -> Y -> X -> Z(2.5)
B -> X -> Z(2.0)
那么最终生效的是Z(2.0)版本
最先声明优先原则
如果路径长短一样，优先选择先声明的那个
A -> Z(3.0)
B -> Z(3.5)
这里A最先声明，所以依赖Z(3.0)
引起冲突的原因
假设我们项目中依赖了A和B两个Jar包。而A和B各自又有以下传递依赖
A -> X -> Z(2.0)
B -> X -> Y -> Z(2.5)
那最终系统中Z包就产生了冲突，2.0和2.5两个版本冲突。但是classpath中只会依赖一个版本的Z包。根据传递依赖的最短路径优先原则，最终依赖的应该是2.0版本。
如果Y包中用了Z包2.5版本中新的method时候，当运行到这段逻辑的时候。就会报NoSuchMethodError了。因为本来依赖的是2.5版本，但是因为Jar包冲突Maven选择了2.0版本，2.0版本中又没有这个新的method，导致出错。
但要注意的是，不是所有冲突都会引起运行异常。相反，大部分公司的项目都会有一些Jar包冲突，但其实没有造成运行时的问题。
这是因为很多传递依赖的Jar包，不管是2.0版本也好，2.5版本也好，都可以运行。
当出现jar包冲突时，一般建议采用高版本的jar包，因为高版本的jar在设计时一般会考虑向下兼容。只有高版本Jar包不向下兼容才有可能导致这样的问题。
定位冲突
使用插件MavenHelper。具体使用可以参考下方连接，以后使用到则补充。
解决冲突的几个简单技巧
依赖排除法
将冲突的依赖排除。<exclusions> 使用Maven工具也可以右键->Exclude
版本锁定法
通过指定版本的方式打破2个依赖传递原则，优先级最高。
Maven 加载Jar包的优先级顺序
项目子Module对应的Jar包 > 本地仓库Jar包 > 远程仓库的Jar包
————————————————
版权声明：本文为CSDN博主「穿金头戴帽」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_41149775/article/details/127076733
