有些微服务是使用父子模块的形式进行开发的，那么依赖的管理是必不可少的
原理
在Maven的多模块项目中，依赖管理是一个重要的问题。以下是一些关于如何有效管理多模块依赖的建议：
公共依赖抽象：在父项目中创建一个itoo-base-parent模块，用来管理所有子项目的公共依赖。通过这个模块，你可以统一管理所有子项目引用的依赖版本，避免版本冲突和重复引入。
DependencyManagement：在父项目的pom文件中，使用dependencyManagement元素来声明依赖版本号。Maven会沿着父子层次向上走，直到找到一个拥有dependencyManagement元素的项目，然后它就会使用在这个dependencyManagement元素中指定的版本号。这样，子项目只需要引用一个依赖而不需要显示列出版本号。
依赖传递：当一个模块引入了一个依赖，这个依赖会被自动引入给所有依赖于该模块的其他模块。这样可以避免重复引入相同的依赖。
模块间依赖：如果模块间存在相互依赖关系，建议将相互依赖的模块放在同一个父项目下，这样可以方便地管理它们的依赖关系。
外部依赖：对于外部库的依赖，尽量使用Maven中央仓库的依赖，避免不必要的重复上传。
统一管理：对于跨多个模块的依赖，建议将这些依赖放在一个独立的模块中，然后在其他模块中引用这个模块。这样可以统一管理这些依赖，避免混乱和冲突。
以上是在Maven多模块项目中管理依赖的一些基本策略
依赖管理
可选继承
将向下继承设置为可选，A模块引用B模块，B模块引用C模块，默认情况下，A会将B、C全部引用，但是这样可能会有问题，因为有些模块可能不需要，这样的话还需要排除依赖，是很不方便的
利用
<optional>true</optional>实例
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-openfeign</artifactId>
<version>3.0.1</version>
<optional>true</optional>
</dependency>如果有需要引用的，就需要重新声明，直接依赖了。
单个排除依赖
同依赖过滤直接处理：可以过滤一个或者多个，如果过滤多个要写多个<exclusion>。这个也解决不了我的问题，或者说解决太麻烦，我那里知道hbase要依赖那些包，记不住。<dependency>
<groupId>org.apache.hbase</groupId>
<artifactId>hbase</artifactId>
<version>0.94.17</version>
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>多排除依赖
<dependency>
<groupId>org.apache.hbase</groupId>
<artifactId>hbase</artifactId>
<version>0.94.17</version>
<exclusions>
<exclusion>
<groupId>*</groupId>
<artifactId>*</artifactId>
</exclusion>
</exclusions>
</dependency>思路
1.将公用的依赖，抽象在父类pom中引入
2.公用依赖版本统一在父类pom中管理
3.子模块pom只引入各自需要的，尽量复用父类的版本
在父项目pom中引入spring-boot-starter-parent
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.1.9.RELEASE</version>
<relativePath/> <!-- lookup parent from repository -->
</parent>spring-boot-starter-parent的引入相当于引入一个父类版本的jar库,公共使用的可以在父类的pom中使用,子类中的不用写version版本号，会自动匹配父类中的版本。
2.在父项目pom中通过dependencyManagement统一声明和管理依赖版本号
dependencyManagement作用：通过它来管理jar包的版本，让子项目中引用一个依赖而不用显示的列出版本号。Maven会沿着父子层次向上走，直到找到一个拥有dependencyManagement元素的项目，然后它就会使用在这个dependencyManagement元素中指定的版本号。
元素既能让子模块继承到父模块的依赖配置，又能保证子模块依赖使用的灵活性。
使用声明的依赖即不会引入依赖，也不会给他的子模块引入依赖。但这段配置是可以继承的。
在子类中，依赖配置较原来就简单了。可以在子类中只配置groupId和artifactId ，省去了version。因为完整的依赖声明已经包含在父POM中。 这样可以统一项目范围中依赖的版本，帮助降低依赖冲突的几率。
如果子模块不声明依赖的使用，即使该依赖已经在父POM的dependencyManangement中声明了，也不会产生任何实际的效果。
如果想要在某个模块中使用和另一个模块中完全一样的dependencyManagement配置，除了赋值和继承外，还可以使用import范围依赖将这一配置导入。
这样做的好处：统一管理项目的版本号，确保应用的各个项目的依赖和版本一致，才能保证测试的和发布的是相同的成果，因此，在顶层pom中定义共同的依赖关系。同时可以避免在每个使用的子项目中都声明一个版本号，这样想升级或者切换到另一个版本时，只需要在父类容器里更新，不需要任何一个子项目的修改；如果某个子项目需要另外一个版本号时，只需要在dependencies中声明一个版本号即可。子类就会使用子类声明的版本号，不继承于父类版本号。
