点击上方名片关注我，为你带来更多踩坑案例
引导
当你没时间阅读厚厚的书籍
或者厌倦了长篇大论的面经
那么这个系列适合你
只需要在地铁上、吃饭时、厕所里，几分钟的时间就可以获得一个小知识
每天一点小进步，日积月累之下你会感谢自己
请关注我，持续为您带来更新
小知识
你是否遇到过依赖冲突呢？
特别是在创建新的项目或者引入新的依赖的时候
No Such Method XXX
上面的报错相信大家都遇到过
90%的情况是因为依赖冲突导致jar包版本不一致的情况导致的
(剩下10%的情况，就是自己写错了)
依赖冲突
简单的叙述一下依赖冲突：
你项目pom中依赖了A、B两个jar包
A依赖了X，且依赖的X版本为1.2.0
B依赖了Z,Z又依赖了X，且依赖的X版本是1.1.0
这个时候A和B就是依赖冲突了，因为依赖是有传递性的
那么依赖冲突又会导致什么问题呢？
这时候你想使用X中的一个方法method，但是method报错，找不到该方法
那么你去看看相应的jar包，你引用的X绝对是1.2.0，且1.2.0中的method的方法应该已经被移除了。因为依赖冲突的时候，是会有一个冲突管理策略的
按照以下优先级：
1. 优先dependencyManagement，也就是你项目pom中直接引用的jar包版本，相应的这也是一个解决依赖冲突的方法，在自己的pom中明确定义要使用的有冲突的jar包版本
2. 优先最短路径，也就是上文中，A->1.2.0X，B->Z->1.1.0X，最后引用的是1.2.0X
3. 同一pom中，优先声明原则，谁在上面引用谁
排查依赖冲突
上述法则可以让你出现问题的时候，有据可依的解决问题，那么如果想排查一个项目下有可能存在的依赖冲突，又该怎么做呢？
推荐一个idea插件-Maven-Helper
它的一大作用就是可视化分析并解决项目中的依赖冲突
比如装好以后
以上图中fastjson为例，1.2.69是当前使用的版本，也是项目pom中明确引用的版本，飘黄的1.2.83则是spring-boot所依赖的
像这种情况尽量使用高版本，把自己pom中的1.2.69->1.2.83
再来举一个例子
像这种的，就是依赖的jar包比我项目中明确引用的jar包版本要低，可以右键-exclude，一键排除掉
类似的情况都可以通过它来排除，让你的项目变得更健壮，杜绝隐患
当然，他还有其他用途，比如项目启动的时候，发现一个警告
c.n.c.sources.URLConfigurationSource : No URLs will be polled as dynamic configuration sources.这个警告就是说你eureka下有一个动态配置中心archaius组件，它配置有问题。
但是我这里并不想用eureka下的这个组件，因为已经有spring-config了
这个时候就需要把它剔除掉
就可以在maven-helper界面搜索
然后轻轻松松剔除
快去检查一下你的项目下是否有依赖冲突吧！