正文：
在微服务架构盛行的当下，许多团队会将共享功能拆分为独立的Spring Boot模块。这些模块作为依赖项被主应用引用时，却可能引发一个令人头疼的问题：当主应用以WAR包形式部署到Tomcat等外部容器时，这些模块的Spring Boot应用也会自动启动。最终导致同一容器内多个Spring上下文互相冲突，轻则日志混乱，重则功能异常。

---

问题根源：嵌入式容器的”幽灵”

Spring Boot的便利性源于其”约定优于配置”理念，但这也埋下了隐患。当我们直接引入一个Spring Boot模块时，其内置的嵌入式容器（如Tomcat）会作为传递依赖进入主工程。更关键的是，Spring Boot的自动配置机制（@SpringBootApplication）会无视部署环境，尝试初始化所有模块的上下文。

典型错误依赖配置：
xml
<!-- 主项目的pom.xml -->
<dependency>
<groupId>com.example</groupId>
<artifactId>common-module</artifactId>
<version>1.0</version>
</dependency>
此时若主应用打包为WAR并部署，common-module中的SpringApplication.run()会被自动触发，形成”应用中的应用”这种诡异架构。

---

解决方案一：依赖范围精准控制

核心思路：通过Maven/Gradle的依赖作用域，阻止嵌入式容器传递到WAR包。
xml


org.springframework.boot
spring-boot-starter-tomcat
provided

com.example
common-module
1.0
runtime

优势：简单直接，适合纯工具型模块
局限：若模块包含@Controller等Web组件，可能引发类加载异常

---

解决方案二：斩断自动配置链

核心思路：显式排除模块的自动配置，使其仅作为普通库存在
java
// 在主应用的启动类中排除特定模块的自动配置
@SpringBootApplication
@EnableAutoConfiguration(exclude = {
CommonModuleAutoConfiguration.class // 模块的自动配置类
})
public class MainApplication extends SpringBootServletInitializer {
// ...
}
关键技巧：
1. 在模块中创建专用的自动配置类（带@Configuration注解）
2. 通过spring.autoconfigure.exclude属性在配置文件动态排除

---

解决方案三：条件化装配策略

核心思路：通过条件注解控制模块初始化，实现”智能休眠”
java
// 在模块的配置类上添加环境判断
@Configuration
@ConditionalOnProperty(
name = “module.enabled”,
havingValue = “true”,
matchIfMissing = false // 默认不启用
)
public class CommonModuleConfig {

@Bean
public ServiceBean serviceBean() {
    return new ServiceBean();
}

}
在主应用的`application.yml`中按需激活：yaml

仅当需要该模块时启用

module:
enabled: true
进阶用法：结合@ConditionalOnWebApplication(type = Type.NONE)防止在Web环境中启动

---

防御式编程：双重保险机制

在大型项目中，建议采用组合策略强化控制：
1. 模块设计阶段：
java
// 在模块入口类添加Web环境检查
public class ModuleApplication {
public static void main(String[] args) {
if (isEmbeddedContainerEnabled()) {
SpringApplication.run(ModuleApplication.class, args);
}
}

private static boolean isEmbeddedContainerEnabled() {
    // 通过环境变量或系统属性判断
    return "true".equals(System.getProperty("module.standalone"));
}

}
2. **构建阶段**：在CI/CD流程加入部署环境检测bash

构建脚本示例

if [ “$DEPLOY_TYPE” == “war” ]; then
mvn clean package -Dmodule.standalone=false
fi

---

架构层面的思考

这个问题本质上是模块边界治理的体现。对于长期维护的系统，建议：
1. 将纯业务逻辑模块与可独立运行的Spring Boot应用严格分离
2. 采用分层架构：
– core-module：仅含POJO/工具类（无需Spring依赖）
– service-module：包含业务逻辑（可选Spring依赖）
– bootstrap-module：独立应用入口（完整Spring Boot）
3. 使用Spring Boot 2.4+的模块化启动特性：
java
// 显式定义模块别名
SpringApplicationBuilder builder = new SpringApplicationBuilder();
builder.sources(MainApp.class)
.add(SharedModule.class).profiles("shared");

通过上述策略组合，我们既能享受模块化开发的高效，又能避免部署时的”幽灵启动”现象。这种精细控制的能力，正是从初级开发迈向架构师的关键阶梯。