本文探讨了在多模块Spring Boot应用中，将一个Spring Boot模块作为依赖项引入另一个Spring Boot模块并打包成WAR时，依赖模块意外启动的问题。文章提供了两种解决方案：推荐的模块重构方法，将核心逻辑与应用入口分离；以及在无法重构时的替代方案，通过Maven配置明确指定主应用入口，以确保只有预期的Spring Boot应用启动。
引言：多模块Spring Boot应用中的依赖启动困境
在构建复杂的企业级应用时，采用多模块（Multi-module）架构是一种常见的实践。它有助于代码组织、职责分离和团队协作。然而，在使用Spring Boot构建多模块应用并最终以WAR包形式部署到如Tomcat这样的Servlet容器时，开发者可能会遇到一个令人困惑的问题：作为依赖引入的Spring Boot模块，在父模块部署时，其自身的Spring应用上下文也会意外启动。
具体来说，当一个结构如下的应用：
- root
- module1 (纯Java类库)
- module2 (Spring Boot应用) -> 依赖 module1
- module3 (Spring Boot应用) -> 依赖 module2
将 module3 打包成WAR并部署到Tomcat时，期望只有 module3 这个主应用启动。但实际情况却是 module2 这个依赖模块的Spring应用上下文也随之启动了。这不仅浪费了系统资源，还可能导致端口冲突、重复的定时任务执行或其他不可预测的行为。
问题分析：为何依赖模块会意外启动？
Spring Boot应用在WAR包中部署到Servlet容器时，通常通过 SpringBootServletInitializer 类来引导。这个初始化器会扫描应用的classpath，查找带有 @SpringBootApplication 注解的类，并尝试启动相应的Spring应用上下文。
当 module2 本身就是一个完整的Spring Boot应用时，它会包含自己的 @SpringBootApplication 注解（或等效的Spring Boot启动类）以及所有必要的Spring Boot启动器依赖。当 module3 将 module2 作为依赖引入时，module2 的所有类和资源都会被打包到 module3 的WAR包中。此时，SpringBootServletInitializer 在扫描classpath时，会发现两个潜在的Spring Boot应用入口（module2 和 module3），并可能尝试初始化两个独立的Spring应用上下文，从而导致 module2 的意外启动。
解决方案一：推荐的模块重构策略
解决此问题的最根本和最推荐的方法是遵循“职责单一原则”，对模块进行重构，明确区分“纯类库”和“独立应用”。
核心思想
将模块的功能职责明确分离。如果一个模块仅仅是提供给其他模块复用的业务逻辑、数据模型、工具类等，那么它就不应该是一个完整的Spring Boot应用，不应包含 @SpringBootApplication 注解或Spring Boot启动器依赖。
具体实践
-
将 module2 拆分为两个模块：
- module2-core (纯Java类库)： 包含所有核心业务逻辑、实体类、服务接口、数据访问层接口等，不引入任何Spring Boot启动器依赖。它的 pom.xml 中 packaging 应为 jar，且只包含必要的Spring Framework（如果需要）或其他纯Java库依赖。
- module2-app (独立的Spring Boot应用)： 这是一个完整的Spring Boot应用，负责提供 module2 的独立运行能力（例如，通过REST API暴露服务）。它将依赖 module2-core，并包含 @SpringBootApplication 注解以及所有Spring Boot启动器依赖。
-
调整 module3 的依赖：
- module3 不再依赖 module2 (原Spring Boot应用)，而是仅依赖 module2-core。这样，module3 就能复用 module2 的核心逻辑，而不会引入 module2-app 的Spring Boot启动机制。
优点
- 架构清晰： 模块职责明确，易于理解和维护。
- 避免不必要的启动： module3 的WAR包中不再包含 module2-app 的Spring Boot启动类，从而避免了 module2 应用上下文的意外启动。
- 资源优化： 减少了不必要的Spring上下文初始化，节省了内存和启动时间。
- 更好的复用性： module2-core 可以被任何其他Java项目或Spring Boot项目作为纯类库复用，而无需承担Spring Boot应用的负担。
概念性Maven配置示例
假设 module2 被重构为 module2-core 和 module2-app。
module2-core/pom.xml (纯类库)
4.0.0 com.company module2-core1.0.0-SNAPSHOT jar
module3/pom.xml (主Spring Boot应用，WAR包)
4.0.0 org.springframework.boot spring-boot-starter-parent2.7.18 com.company module31.0.0-SNAPSHOT war org.springframework.boot spring-boot-starter-weborg.springframework.boot spring-boot-starter-tomcatprovided com.company module2-core1.0.0-SNAPSHOT org.springframework.boot spring-boot-maven-pluginmaven-war-plugin
解决方案二：通过Maven配置明确主应用入口（替代方案）
如果模块重构在短期内不可行或成本过高，可以尝试通过Maven配置来明确指定主应用入口，以减少Spring Boot在classpath扫描时的歧义。
原理
通过配置 spring-boot-maven-plugin，我们可以显式地告诉Maven和Spring Boot哪个类是应用的唯一启动类。这会影响最终WAR包的 MANIFEST.MF 文件中的 Start-Class 属性，为Spring Boot的启动机制提供更明确的指引。虽然对于部署到外部Tomcat的WAR包，SpringBootServletInitializer 是主要入口，但明确的 Start-Class 仍可能有助于避免混淆。
操作步骤
在 module3 (主应用) 的 pom.xml 中，确保 spring-boot-maven-plugin 配置了正确的 mainClass。
Maven配置示例
org.springframework.boot spring-boot-maven-plugincom.company.module3.Module3Application 
repackage
