结论：exclusion 表示对传递性依赖进行排除，排除后当前项目的依赖jar中，就不会包含该传递性依赖。
扩展：项目中的jar 都会在classpath下，排除后的传递性依赖，相当于在classpath下清除掉了。所以排除后，可能会引出一些问题。
问题1：本项目显式使用的依赖被排除了，编译报错。这种可以及时修改。
问题2：本项目未显式使用的依赖被排除了，编译正常。启动服务报错（因为启动服务时使用到了被排除的依赖）。
如：排除前的依赖
排除后的依赖
模拟服务启动报错：启动类创建一个类型为PredefinedScopeHibernateValidator的对象。
错误分析：下图中标记1对应的依赖存在，而标记3对应的依赖已经被排除了，即classpath中不会存在ValidationProvider.class。而启动服务时，要求加载ValidationProvider类，所以启动服务报找不到类。
问题3：本项目未显式使用的依赖被排除了，服务启动正常。某个方法在运行时，会调用被排除掉的依赖，就会出现找不到的报错。
如下方法，被调用时，触发PredefinedScopeHibernateValidator进一步，依赖ValidationProvider，最终导致找不到报错。
（问题3和问题2本质是一样的，只是问题3在开发时候，不容易发现）
老鸟建议：
1、升级依赖版本时，尽量不要排除，除非发现问题，如依赖冲突，或者非常明确这个排除的含义。
2、像springboot、spring 等这种框架级依赖，一般要升级其传递性依赖时，建议直接升级框架主依赖版本，主版本一般会包含新版本的传递性依赖。不建议，直接排除框架级依赖的传递性依赖，再显式升级该传递性依赖。或者直接显式的升级，maven 依据最短路径原则，会解析显式升级的依赖。