Maven依赖传递
前情概要
最近在一次发版前，代码被安全扫描出有漏洞，定睛一看，原来是fastjson的版本不安全，当时用的好像是1.2.57.sec10，安全推荐的包版本是1.2.83，因此开启了我的第一次依赖版本升级之旅。
头次碰壁
之前也有过升级依赖版本的操作，但都是自己公司的内部包，操作类似于在pom文件里面把1.0.0改成1.0.1这样子就行了；
于是这次我也是这么操作的，全局搜索fastjson的依赖，手动修改 <version>1.2.83<version>；看起来好像所有的fastjson都已经被升级成了1.2.83版本
可是当我查看Maven依赖时，不仅有1.2.83版本，原版本1.2.57.sec10的包也还在
我以为是缓存之类的问题，手动移除1.2.57.sec10的包，之后重新编译，1.2.57.sec10的依赖包居然又死灰复燃导入进来了
找出真相
那么…真相只有一个，在我们的项目里面有地方导入了fastjson – 1.2.57sec10的包,结合安全扫描给出的图，对fastjson不仅有直接引用，也有间接引用
我们全局搜索并手动升级fastjson的版本，并不能改掉所有的，可是至少应该改掉直接引入里面的呀，为什么直接引入、间接引入的都还在呢？
引入依赖优先级介绍
当依赖一个jar包多个版本时，优先使用哪个版本，原则如下：
1.本级优先于上级，上级优先于下级；
2.本级依赖版本优先于管理版本；
3.同一个包中后加载的版本覆盖先加载的版本；
4.上级管理版本和本级管理版本会覆盖下级依赖版本；
5.不同下级jar中依赖了不同版本，优先使用先加载下级jar中的版本；
6.与版本号大小没有关系
7.本级无法使用下级管理版本
总结起来就两条：路径最短，申明顺序其次
参考链接：(56条消息) maven中pom依赖相同jar包优先顺序加载版本_lizz666的博客-CSDN博客_mvn parent 相同jar包