本文探讨了在spring boot多模块项目中，将包含spring boot应用的模块作为依赖项引入主应用并以war包部署时，依赖模块意外启动的问题。文章提供了两种核心解决方案：推荐的模块重构策略，即将核心业务逻辑与spring boot应用分离；以及在不重构的情况下，通过精确配置主应用的springapplication和maven打包来控制启动行为，确保只有主应用上下文被初始化。
引言：Spring Boot多模块应用中的依赖启动困境
在构建复杂的Spring Boot应用时，多模块项目结构是常见的选择。这种结构有助于代码组织、职责分离和重用。然而，当一个模块本身是一个完整的Spring Boot应用（例如，包含@SpringBootApplication注解和相应的自动配置），但却被另一个主应用模块作为普通依赖引入时，可能会出现意料之外的行为。
具体来说，当主应用（如module3）被打包为WAR文件并部署到外部Servlet容器（如Tomcat）时，如果其依赖的模块（如module2）也是一个Spring Boot应用，那么module2的Spring应用上下文可能会被意外地初始化或启动。这通常是由于Spring Boot的组件扫描和自动配置机制在主应用启动时，扫描到了依赖模块中的Spring Boot相关配置和入口点，导致其被误识别为需要启动的独立应用上下文。这种行为不仅浪费资源，还可能导致端口冲突、重复的服务注册或其他运行时问题。
本文将深入探讨如何解决这一问题，提供两种主要的策略，以确保只有预期的主应用上下文被正确启动。
方案一：推荐的模块重构策略——解耦与清晰
解决此问题的最根本和推荐的方法是对模块进行重构，明确区分“核心业务逻辑”和“独立可执行应用”的职责。这种方法遵循了“单一职责原则”，从设计层面避免了依赖模块作为应用启动的副作用。
核心思想： 将包含Spring Boot应用的模块（例如module2）拆分为两个独立的模块：
- 核心类库模块： 仅包含业务逻辑、数据模型（POJOs）、接口、服务实现等纯Java代码，不包含任何Spring Boot启动器、@SpringBootApplication注解或Web相关依赖。
- 应用启动模块： 仅包含核心类库模块作为依赖，并提供main方法和@SpringBootApplication注解，用于独立运行该应用。
重构步骤示例：
假设原始结构为：
- root
- module1 (纯类库)
- module2 (Spring Boot应用) -> 依赖 module1
- module3 (Spring Boot应用) -> 依赖 module2
重构后，module2将被拆分：
-
创建 module2-core 模块：
- 这是一个普通的Maven jar 项目。
- 将原 module2 中所有非Spring Boot应用启动相关的代码（如服务接口、实现、实体类、工具类等）迁移到此模块。
-
module2-core/pom.xml 示例：
4.0.0 com.company module2-core1.0.0-SNAPSHOT jar com.company module11.0.0-SNAPSHOT org.springframework spring-context
-
创建 module2-app 模块：
- 这是一个Spring Boot jar 项目。
- 将 module2-core 作为其依赖。
- 包含 module2 原有的 main 方法和 @SpringBootApplication 注解。
-
module2-app/pom.xml 示例：
4.0. 
0com.company module2-app1.0.0-SNAPSHOT jar org.springframework.boot spring-boot-starter-parent2.7.18 com.company module2-core1.0.0-SNAPSHOT org.springframework.boot
0