XStream小于1.4.11远程代码执行高危漏洞问题

依赖树mvn dependency:tree

• 起因：
  接手了公共服务的众多项目后，这种线上的远程代码执行漏洞问题，上一个是fastjson的问题，没有什么体验，升级了版本号就上线了，这次到了XSteam，依旧按照这个流程来，但是上线前，师父问了我一句，你知道怎么判断这个依赖的添加对项目造成的影响吗？
  后续说了什么就不重要了，重点记录下，这个问题后，我得到的答案和收获的体验

• 1
  首先，项目中，没有对XSteam依赖明显的调用，无从下手这个版本过低会造成什么样的影响，也不知道之前为什么会添加这个依赖

• 2
  接下来，就是重点了mvn dependency:tree 在Terminal界面中，输入该指令，会获得当前项目下，所有项目依赖的树状图（当然，只是结构，不是真的图）。

• 3
  搜索了全文，也没有调用过XStream这个依赖，但是Exrenal Libraries中却是明显存在的，那么问题来了，这个依赖是怎么添加进来的。

• 4
  在POM文件中未添加XStrem依赖前，输入指令mvn dependency:tree ，得到的值是这些（如果执行完后，只有个各种依赖的下载，那么再执行一次）：
  
  如图，根据指令的返回值，可以看出，第一个依赖是ccs-base，第二个依赖是ccs-zkdata-load，对比pom文件发现这个顺序是正确的。而截图中1代表着这个依赖是pom中显式添加的依赖，2代表着的是这个依赖下又使用了其他的依赖，因此如果想要使用1中的依赖，2中的依赖也是需要自动导入进来的，但是无需显式添加在pom中，而是pom自动下载需要依赖的依赖。而2中两个前缀不同的原因是：作为最后的依赖，需要将+更换为\。由此也可知，要修改的XSream是怎么添加进来的了：pom中某个依赖，依赖于XSream！

截图太长，截不下了：但是意思就是：XStream是spring-cloud-starter-eureka依赖下的子依赖。XSteam的版本又取决于spring-cloud-starter-eureka的版本。如果直接改动根依赖的版本号或许会造成其他未知影响，因此选择只修改XSream的版本。

可以看出，在pom文件中手动添加了XStream的依赖以及版本号后，原来作为注册中心的依赖的子依赖消失了，并在最后加入了一个与注册中心依赖同级的XStream依赖。

1. 依赖的优先级：
   深度不同的情况下，以深度浅的优先
   深读相同的情况下：以顺序在前的为准
2. 如何判断一个依赖的修改是否会造成未知影响：
   1，功能是否正常
   2，新添加依赖后，查看新老依赖树的对比

附加额外点：

版本号在开发界默认的潜规则： 例如，1.4.12版本

1：大版本，一般不会轻易更新，如果出现了更新，一般是质变，很少往下兼容。

4，小版本，更新频率较低，一般是有重大更新或者功能上线，更新往往是向下兼容的。

12，小版本号，更新频率较高，往往更新是各种打补丁，补bug或者更新一些比较细碎的边角。更新幅度往往不会很大，同时也向下兼容

最后，感谢师父的指点！！！