点击dependency analyzer之后就会进入到下面的页面
从图中可以看出有哪些jar存在冲突，存在冲突的情况下最终采用了哪个依赖的版本。标红的就是冲突版本，白色的是当前的解析版本。
如果我们想保留标红的版本，那我们可以标白区域右击选择排除(Exclude)
然后我们再来看pom文件,发现在org.apache.poi中已经移除了poi了。
<dependency>
<groupId>org.apache.poi</groupId>
<artifactId>poi-ooxml</artifactId>
<version>3.10.1</version>
<exclusions>
<exclusion>
<artifactId>poi</artifactId>
<groupId>org.apache.poi</groupId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>easyexcel</artifactId>
<version>2.2.6</version>
</dependency>
我们再来看最终引用的poi版本是哪个？
我们发现最终的版本最终已经变成3.17版本，现在再启动就不会报错了，成功解决依赖冲突问题。
一般我们在解决依赖冲突的时候，都会选择保留jar高的版本，因为大部分jar在升级的时候都会做到向下兼容，所以只要保留高的版本就不会有什么问题。
但是有些包，版本变化大没法去做向下兼容，高版本删了低版本的某些类或者某些方法，那么这个时候就不能一股脑的去选择高版本，但也不能选择低版本。
就比如下面这个案例
依赖链路一：A -> B -> C -> X(1.0)
依赖链路二：F -> D -> X(2.0)
X(2.0) 没有对 X(1.0) 做向下兼容也就是说可能存在排除哪个都不行，那怎么办我们只能考虑升级A的版本或者降低F的版本。比如A升级到A(2.0),使它依赖的X版本
变成X(2.0)这样的话就解决依赖冲突。
但话有说回来 A升级到A(2.0) 可能会影响许许多多的地方，比如自己项目中代码是否需要改变，或者因为 A升级到A(2.0) 导致 B和C的版本有所改变，这些影响点都需要我
们去考虑的。所以说为什么说一个大型项目稳定后，pom文件的升级是件繁琐的事情，那是因为考虑的东西是在太多了，稍有不慎就会因为依赖冲突而导致系统报错。
