Maven子模块的父POM应该是什么？Spring Boot多模块项目困惑

核心结论：子模块父POM完全不必是项目根POM #

Maven的聚合和继承是两个独立的机制：

• 聚合是通过根POM的<modules>标签把多个子模块绑定在一起，方便批量执行构建命令（比如mvn clean install一次性打包所有模块）
• 继承是子模块通过<parent>标签复用任意POM的配置（依赖、插件、属性等），这个父POM可以是项目内的根POM，也可以是外部公共POM（比如Spring Boot官方的父POM）

官方示例这么设计的逻辑 #

Spring官方gs-multi-module示例的结构，是为了平衡Spring Boot的快速配置能力和多模块的全局管理需求：

1. application子模块直接继承spring-boot-starter-parent的原因
   Spring Boot的父POM封装了大量开箱即用的配置：
   • 预先锁定了所有Spring Boot生态依赖的版本，不用手动指定版本号
   • 配置了默认的Java编译版本、文件编码
   • 集成了spring-boot-maven-plugin，一键打包成可执行JAR
     这些是Spring Boot项目能快速启动的核心，直接继承它比手动从零配置高效得多。
2. 根POM的核心作用
   根POM是pom类型（<packaging>pom</packaging>），主要负责：
   • 通过<modules>标签聚合所有子模块（比如application、library）
   • 在<dependencyManagement>块中声明所有子模块共用的依赖版本，子模块引用时只需写groupId和artifactId，不用重复指定版本
     就算子模块的父不是根POM，只要在子模块中导入根POM的dependencyManagement配置，就能复用这些全局版本规则。

两种常用的多模块父POM设计方案 #

方案1：官方示例的拆分模式 #

• 根POM：仅做聚合+全局依赖管理（可继承Maven默认的maven-parent，也可不继承）
• 业务启动模块（如application）：直接继承spring-boot-starter-parent，同时导入根POM的dependencyManagement以复用全局版本
• 工具类/业务库模块（如library）：继承根POM，专注于业务逻辑，无需Spring Boot的打包插件

方案2：根POM统一继承Spring Boot父 #

• 根POM：先继承spring-boot-starter-parent，再添加<modules>聚合子模块，同时在dependencyManagement中补充自定义依赖版本
• 所有子模块：继承根POM，这样既复用了Spring Boot的预配置，又统一了全局依赖规则
  这种方案更适合所有子模块都紧密依赖Spring Boot的项目

验证你没遗漏内容的方法 #

检查官方示例的两个关键文件：

• 根POM里必然有<dependencyManagement>块，声明了子模块共用的依赖版本
• application子模块要么通过<dependencyManagement>导入根POM的配置，要么直接引用根POM中管理好的依赖（看不到版本号）

内容的提问来源于stack exchange，提问作者LagSurfer