聚合仅统一构建顺序，不解决依赖；模块间依赖必须显式声明，且版本须严格一致；用于集中管理版本，子模块需声明才生效。

聚合本身不解决模块间依赖关系，它只负责统一构建顺序；模块间的依赖必须靠 显式声明，否则编译会直接失败。

聚合 pom.xml 里只写 ，不写依赖

根项目的 pom.xml 中的 标签只是告诉 Maven “这些目录要一起 build”，它不产生任何依赖传递。常见错误是以为在根 pom 里加了 polymerization-common 就能让 polymerization-service 自动用上它——不会。

• 根 pom 的 列表必须是子模块的相对路径（如 polymerization-common），不能带 / 开头或 .jar 后缀
• 子模块的 groupId 通常继承自父 pom，但 artifactId 必须唯一且与模块目录名一致，否则 mvn clean install 时会找不到模块
• 如果某个模块没出现在 里，它不会被聚合构建，但也不影响你单独进该目录执行 mvn 命令

子模块之间依赖必须显式写

比如 polymerization-service 要用 polymerization-common 里的工具类，就必须在它的 pom.xml 里声明：

<dependency><groupid>com.riemann</groupid><artifactid>polymerization-common</artifactid><version>1.0-SNAPSHOT</version></dependency>

注意：这里的 必须和 polymerization-common 自己 pom 中定义的版本严格一致（通常是 1.0-SNAPSHOT），Maven 不会自动从父工程“猜”版本。

• 依赖声明后，Maven 会在本地仓库查找对应 jar；如果是刚改完 polymerization-common，需先在它的目录下运行 mvn install，否则 polymerization-service 会报 Could not find artifact
• Web 模块（war）依赖 Java 模块（jar）是合法的；反过来——Java 模块依赖 Web 模块——会导致循环依赖，Maven 会拒绝构建
• IDEA 中有时不自动刷新依赖，可右键项目 → Maven → Reload project 强制同步

用 统一管理版本，避免冲突

当多个子模块都依赖同一个库（比如 spring-boot-starter-web），但各自写了不同版本，就会触发依赖冲突。这时不要在每个子 pom 里硬编码版本号，而是在父 pom 的 中集中声明：

<dependencymanagement><dependencies><dependency><groupid>org.springframework.boot</groupid><artifactid>spring-boot-starter-web</artifactid><version>3.2.12</version></dependency></dependencies></dependencymanagement>

子模块只需写 groupId + artifactId，不用写 version：

<dependency><groupid>org.springframework.boot</groupid><artifactid>spring-boot-starter-web</artifactid></dependency>

• 只控制版本，不引入实际依赖；子模块不声明 ，就不会有该 jar
• 若子模块自己写了 version，会覆盖 的设定，失去统一管控意义
• Spring Boot 项目建议优先用 spring-boot-dependencies bom，而不是手动写一堆

真正容易被忽略的是：聚合只是构建调度层，模块是否能编译通过、运行正常，完全取决于每个子模块自己的 pom.xml 是否正确定义了 、 和版本对齐。一个模块漏掉 ，整个聚合 build 就会卡在那个模块上，报错信息往往只显示“package xxx does not exist”，而不是直接指出“你忘了加依赖”。