spring boot多模块依赖管理核心是统一版本管控与分层解耦：父pom用集中声明所有依赖版本，子模块仅写groupid和artifactid；各模块按职责精准引入starter，禁止循环依赖，配置与启动类仅存在于*-application模块。

Spring Boot 多模块项目的依赖管理，核心是“统一管控、分层解耦、按需传递”。关键不在加多少依赖，而在谁管版本、谁负责引入、谁禁止反向引用。

父 POM 统一声明依赖版本

所有子模块必须继承同一个父工程（packaging=pom），并在其 <dependencymanagement></dependencymanagement> 中集中定义所有第三方依赖的版本。Spring Boot 官方 starter 也应通过 spring-boot-dependencies 导入：

• 避免子模块各自写 <version></version>，防止版本不一致引发 NoSuchMethodError
• 非 Spring Boot 管理的依赖（如 Druid、MinIO SDK）必须在这里声明版本，子模块只写 groupId 和 artifactId
• 不要在父 POM 的 <dependencies></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 查看实际解析的依赖树，快速定位冲突坐标