Spring Boot多模块依赖管理核心是统一版本管控与分层解耦：父POM用<dependencyManagement>集中声明所有依赖版本，子模块仅写groupId和artifactId；各模块按职责精准引入starter，禁止循环依赖，配置与启动类仅存在于*-application模块。
Spring Boot 多模块项目的依赖管理，核心是“统一管控、分层解耦、按需传递”。关键不在加多少依赖，而在谁管版本、谁负责引入、谁禁止反向引用。
父 POM 统一声明依赖版本
所有子模块必须继承同一个父工程（packaging=pom），并在其 <dependencyManagement> 中集中定义所有第三方依赖的版本。Spring Boot 官方 starter 也应通过 spring-boot-dependencies 导入：
- 避免子模块各自写
<version>，防止版本不一致引发 NoSuchMethodError - 非 Spring Boot 管理的依赖（如 Druid、MinIO SDK）必须在这里声明版本，子模块只写 groupId 和 artifactId
- 不要在父 POM 的
<dependencies>中直接写依赖——那是子模块的事
子模块按职责精准引入 starter
每个子模块只引入自己真正需要的 starter，且不重复引入父模块已提供的能力：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
*-domain模块保持纯 Java，不依赖 Spring，不引入任何 starter -
*-infrastructure引入spring-boot-starter-data-jpa或spring-boot-starter-data-redis，但不引入 web 相关 starter -
*-application是唯一引入spring-boot-starter-web的模块，也是唯一含@SpringBootApplication的模块 - 跨模块调用接口（如 Feign Client、DTO）应抽到
*-api模块，并由调用方依赖该 jar
禁止循环依赖与配置冲突
依赖关系必须单向：上层模块可依赖下层，下层绝不反向依赖上层。同时规避常见陷阱：
- 子模块不能有
application.yml或application.properties—— 所有运行时配置只由主启动模块（*-application）提供 - 测试专用配置（如
application-test.yaml）可保留在对应模块的src/test/resources下，不影响主应用 - 若某子模块被多个项目复用，可将其打包为自定义 starter（含
spring.factories），而非直接暴露 Spring 配置类
IDEA 与 Maven 协同验证
光写对 pom 不够，还需工具链确认依赖真实生效：
- 在任意子模块中写一个
@SpringBootTest，尝试@Autowired另一模块的 Service —— 若报NoSuchBeanDefinitionException，说明 Maven 依赖未正确传递或组件扫描范围不对 - IDEA 中右键模块 → “Add Framework Support → Spring Boot”，确保绿色启动图标出现
- 执行
mvn dependency:tree -Dverbose查看实际解析的依赖树，快速定位冲突坐标
