摘要
maven依赖问题作为开发者应该是经常遇到的问题，在个人单独开发单独维护的项目里，可能体现不那么明显，一是自己对导入的jar大部分都很明确，二是出现问题第一解决发现也很快，问题就没那么严重，而在多人协调开发的项目里，则可能会出现很严重的问题，而这些问题很多时候出现频率相当高，而一些隐匿的问题也多纠其本质，主要是1.开发规范缺失（大小公司不可避免）2.对maven构建把握的细节不够，3.开发者习惯等原因，所以本文主要针对2,3中的常见的问题进行列举和提出相应的解决方式。
背景
从公司的项目中可以经常看到maven依赖爆红，而一般也不会影响项目的运行，可能大多数使用的是高低版本兼容性比较好的jar包，所以maven包依赖冲突的解决也被常常忽略，而有些时候可能前任开发者的不规范，会给你后续的解决冲突挖下一个巨大的坑，比如jar包没有被升级，实现却改了，比如升级后，接口没有改，前任实现者将实现方式改了，而且还会导致后来出现一些没有及时被发现的bug，反正出现的原因可能有很多。
常见问题及解决
前置概念
直接依赖：项目中直接导入的jar包，就是直接依赖 传递依赖：项目中没有直接导入的包，可以通过项目直接依赖jar包传递到项目中,就如下文提到的二级以及多级jar的导入。
解决原则
第一声明优先原则：哪个jar包的坐标在靠上的位置，这个jar包就是先声明的，先声明的包坐标下的依赖jar可以优先进入项目中。
第二原则：路径最短优先原则。
第三原则：exclusion原则，推荐使用
当我们要排除某个jar包下依赖包，在配置exclusion标签的时候，内部可以不写版本号，因为此时依赖包使用的版本默认和本jar包一样。
第四原则：使用dependencyManagement
maven工程是可以分父子依赖关系的，凡是依赖别的项目后，拿到的项目的依赖包都是传递依赖，比如当前项目A，被项目B依赖，那么项目A中所有的jar包都会传递到B项目中，B项目开发者，如果再在B项目中导入一套SSM框架的jar包，对于B项目是直接依赖，那么直接依赖的jar包就会把我们A项目传递过去的jar包覆盖掉，为了防止以上情况的出现。我们可以把项目中主要jar包的坐标锁住，那么其他依赖该项目的项目中，即便是有同名jar包直接依赖，也不会覆盖。需要注意的是，使用此标签的pom一般是管理项目版本，做父项目使用，而不能直接作为父项目的直接依赖，父项目若使用jar，需要特别的定义，另外子项目依赖时候也需要声明出来，只不过不需要版本号。它与dependencys的区别就是子项目被动接受与统一接受版本。
树立良好的maven开发习惯
目的更好让用户理解，尽量不要自己调整依赖的先后顺序，新加jar包不要影响别的jar依赖顺序，导入进去看一看，看的原则，是你放入最后一个jar可能依赖的二级jar（低版本），就会覆盖原来的你上面的同二级jar（高版本）或者原来的大于二级的jar（高版本），然后如果不是编译时候，而是实现时候的jar升级依赖，可能在编译时候发现不了问题在运行时候会报错误的问题。