在spring boot多模块应用中，当一个依赖模块（如module 2）本身是一个spring boot应用，并被另一个主应用模块（如module 3）作为依赖引入并打包为war部署时，可能出现依赖模块意外启动的问题。本文将深入探讨此问题的原因，并提供两种主要解决方案：推荐的模块重构方法，以及通过maven配置显式指定主类的替代方案，旨在帮助开发者构建更清晰、更可控的多模块spring boot应用。
问题描述
在复杂的企业级应用开发中，采用多模块结构是一种常见的实践。例如，一个典型的Spring Boot项目可能包含以下结构：
-
root
- module 1 (纯粹的类库，无Spring Boot应用特性)
- module 2 (一个独立的Spring Boot应用，可能包含服务、控制器等)
- module 3 (主Spring Boot应用，依赖于module 2)
当我们将module 3打包成WAR文件并部署到如Tomcat这样的Servlet容器时，预期的行为是只有module 3作为主应用启动。然而，有时module 2这个依赖模块也会意外地作为自己的Spring Boot应用启动。这不仅可能导致资源浪费、端口冲突，还会使应用行为变得不可预测。开发者通常希望module 3仅仅使用module 2中定义的类和组件，而不是启动module 2作为一个独立的应用实例。
问题根源分析
Spring Boot应用通过@SpringBootApplication注解或包含main方法的类来标识其启动入口。当spring-boot-maven-plugin或其他构建工具处理项目时，它会扫描classpath来查找这些入口点。在多模块项目中，如果一个依赖模块（如module 2）自身也是一个完整的Spring Boot应用，其@SpringBootApplication注解或main方法会存在于最终打包的WAR文件的classpath中。
当WAR文件部署到Servlet容器时，Spring Boot的自动配置机制可能会发现并尝试启动所有它能识别的Spring Boot应用上下文。如果module 3没有明确地指定其主类，或者配置不当，容器可能会“看到”module 2的启动类，并尝试将其也初始化为一个独立的Spring Boot应用。
解决方案一：模块重构（推荐）
最清晰、最符合“关注点分离”原则的解决方案是将依赖模块进行重构。如果module 2既包含可复用的核心业务逻辑/类，又包含一个独立的Spring Boot应用（例如，它自身可以独立运行一个服务），那么应该将其拆分为两个独立的模块：
- module 2-core: 包含纯粹的Java类、接口、模型、服务接口、工具类等，不包含任何Spring Boot应用相关的注解（如@SpringBootApplication、@RestController等，除非它们是接口定义）。
- module 2-app: 包含module 2-core的依赖，并实现module 2-core中的接口，同时包含@SpringBootApplication注解、控制器、配置类以及任何使它成为一个独立Spring Boot应用的代码。
重构后的依赖关系：
-
root
- module 1 (纯粹的类库)
- module 2-core (纯粹的类库，包含核心逻辑)
- module 2-app (Spring Boot应用，依赖于 module 2-core)
- module 3 (主Spring Boot应用，仅依赖于 module 2-core)
Maven配置示例：
在module 3的pom.xml中，仅引入module 2-core作为依赖：
<dependency>
<groupId>com.company</groupId>
<artifactId>module2-core</artifactId>
<version>1.0.0-SNAPSHOT</version>
<scope>compile</scope>
</dependency>优点：
- 清晰的职责分离： module 2-core只提供可复用的组件，module 2-app和module 3则分别作为独立的应用程序。
- 避免冲突： module 3的classpath中不再包含module 2-app的Spring Boot启动类，从而彻底避免了意外启动的问题。
- 更好的可维护性： 模块结构更易于理解和管理。
解决方案二：Maven配置显式指定主类（替代方案）
如果模块重构在短期内不可行，或者由于历史原因难以实施，可以通过Maven配置来明确告诉Spring Boot哪个类是主应用程序的启动类。这通常涉及到在module 3的pom.xml中配置spring-boot-maven-plugin，显式指定其mainClass。
当使用spring-boot-maven-plugin打包WAR文件时，它可以生成一个可执行的WAR，其中包含应用程序的元数据，包括主类信息。通过明确指定module 3的主类，可以确保只有module 3的Spring Boot上下文被初始化。
Maven配置示例：
在module 3的pom.xml中，找到或添加spring-boot-maven-plugin配置，并设置mainClass：
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<!-- 明确指定 module 3 的主启动类 -->
<mainClass>com.company.module3.Module3Application</mainClass>
</configuration>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
</plugin>
<!-- 如果您同时使用 maven-war-plugin，请确保其配置不会与 Spring Boot 插件冲突 -->
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>3.2.3</version>
<configuration>
<attachClasses>true</attachClasses>
<classesClassifier>classes</classesClassifier>
<!-- 如果需要，可以在这里进一步配置，但通常 Spring Boot 插件会处理主类 -->
</configuration>
</plugin>
</plugins>
</build>注意事项：
- mainClass的准确性： 确保com.company.module3.Module3Application是module 3中带有@SpringBootApplication注解的实际启动类。
- repackage目标： spring-boot-maven-plugin的repackage目标会创建一个可执行的JAR或WAR，并嵌入必要的元数据。
- 依赖排除： 虽然在module 3中排除module 2的spring-boot-starter-tomcat（如问题描述中尝试的）有助于避免module 2引入其自身的嵌入式Tomcat，但这并不能阻止module 2的Spring应用上下文被初始化。它只是避免了端口冲突等问题，但应用逻辑仍然可能启动。因此，排除Starter通常不是解决此问题的根本方法。
总结与最佳实践
处理Spring Boot多模块应用中依赖模块意外启动的问题，核心在于明确各个模块的职责和启动意图。
- 推荐策略：模块重构。 将包含独立应用功能的模块拆分为核心库模块和应用模块。主应用只依赖核心库模块。这是最干净、最符合软件工程原则的解决方案，能够从根本上消除问题，并提升项目的可维护性和可扩展性。
- 替代策略：Maven配置。 如果重构不可行，通过在主应用的spring-boot-maven-plugin中显式指定mainClass，可以强制Spring Boot只启动预期的主应用。这种方法虽然有效，但可能不如模块重构那样彻底和优雅。
在设计多模块Spring Boot应用时，始终牢记“关注点分离”原则，并仔细规划模块间的依赖关系，将有助于避免此类问题的发生，并构建出健壮、易于管理的应用系统。
