在开发过程往往一个大项目中有多个子工程，每个子工程模块都会有自己的依赖，但是依赖的jar包中往往都还会有依赖，所有就有可能产生依赖冲突；依赖冲突就有可能会对生产有影响，所以需要定位和解决；
依赖冲突常见现象出现以下现象就需要考虑出现依赖冲突了：
java.lang.NoSuchMethodError java.lang.ClassNotFoundException java.lang.NoClassDefFoundError
确定实际开发中出现冲突的类、方法发生在哪个依赖包中；多数同学说查看mvn的依赖关系图就可以查看出冲突的包，以下是查看依赖关系图命令
mvn -U dependency:tree -Dverbose 完整的依赖关系图，且会告诉你哪个包产生了冲突 mvn -U dependency:tree 项目中实际的依赖关系图。
但是在实际开发中，这中方式往往不能快速定位出产生冲突的包和版本，所以本人还建议结合阿里开源的工具Arthas查看运行时，实际冲突的jar包；
依赖冲突产生原因如图所示，E包1.0.0版本有one一个类，1.0.1版本有one和oneone两个类；项目A依赖了B和C两个jar包，B依赖了E的1.0.0版本，C依赖了D，D依赖了E的1.0.1版本，这样在A中看似是依赖了E包的两个版本，但是实际上根据最短路径原则maven只会引入E包的1.0.0版本；但是A中使用到了oneone类时，运行期就会报错。
依赖冲突是发生在运行阶段，而不是编译阶段，所以问题都是在运行阶段切定位起来比较麻烦；
Maven依赖原则最短路径原则，先声明先夹在原则
冲突解决1、排除掉不要的版本
2、需要的依赖在pom中放在前面优先加载（类的加载顺序是根据pom中的依赖的顺序一致的）
