当前位置：首页 > news >正文

【Spring Boot Starter 设计思考：分离模式是否适用于所有场景】

news 2025/11/1 9:20:59

Spring Boot Starter 设计思考：分离模式是否适用于所有场景？

在 Spring Boot 生态中，starter + autoconfigure 的分离设计已成为广泛采用的标准模式。但当我们深入分析其在实际项目中的应用时，或许可以思考一下：这种设计是否真的是恰当的？

一、当前模式的分析

1. 官方及绝大多数流行框架的模式

当前大多数 Starter 采用这样的结构，其中 Starter 本身是一个空的聚合包，不包含任何实际代码：

<!-- mybatis-spring-boot-starter (空壳聚合包) -->
<dependencies><dependency><groupId>org.mybatis.spring.boot</groupId><artifactId>mybatis-spring-boot-autoconfigure</artifactId></dependency><dependency><groupId>org.mybatis</groupId><artifactId>mybatis</artifactId></dependency>
</dependencies>

同时在 autoconfigure 模块中需要重新声明依赖：

<!-- mybatis-spring-boot-autoconfigure -->
<dependencies><dependency><groupId>org.mybatis</groupId><artifactId>mybatis</artifactId><optional>true</optional></dependency>
</dependencies>

这种设计带来的现象：

Starter 模块作为纯粹的依赖聚合空壳，不包含任何业务逻辑
实际的自动配置逻辑位于独立的 autoconfigure 模块
相同的依赖需要在两个位置声明，造成配置冗余

2. 自动配置类独立存在的思考

以 Redis 自动配置为例：

// org.springframework.boot.autoconfigure.data.redis.RedisAutoConfiguration

考虑这样的使用场景：

<!-- 用户只引入了基础库，未使用完整 starter -->
<dependency><groupId>org.springframework.data</groupId><artifactId>spring-data-redis</artifactId>
</dependency>

可能出现的情况：

自动配置类检测到基础类存在，开始配置流程
但由于缺少某些必要组件，配置可能无法完全生效
这种"部分配置"的状态可能带来不确定性

二、自动配置类的本质思考

1. 自动配置类与 Starter 的天然联系

从功能角度看，自动配置类与 Starter 之间存在着紧密的关联：

自动配置类的目的是让 Starter 能够开箱即用
Starter 的价值很大程度上通过自动配置类来体现
两者在逻辑上是一个完整的功能单元

2. 关于 Condition 注解的思考

在当前的分离模式下，条件注解看起来是必要的：

@ConditionalOnClass({RedisTemplate.class, JedisConnection.class})

但如果我们换一个角度思考：当自动配置类位于 Starter 内部时，这些条件检查是否还有必要？

如果自动配置类直接放在 Starter 包内：

@Configuration
public class RedisAutoConfiguration {// 由于 Starter 已经包含了所有必要依赖，// @ConditionalOnClass 可能变得冗余
}

个人看法：
用户引入 Starter 的行为本身就表明了使用意图，Starter 的依赖管理已经确保了所需类的存在。在这种情况下，过多的 @ConditionalOnClass 检查反而可能增加了不必要的复杂性。

三、社区现状的分析

1. 广泛采用的模式

MyBatis、MyBatis-Plus、PageHelper 等流行项目都采用了与 Spring 官方相似的结构：

<!-- mybatis-spring-boot-starter -->
<dependencies><dependency><groupId>org.mybatis.spring.boot</groupId><artifactId>mybatis-spring-boot-autoconfigure</artifactId></dependency><dependency><groupId>org.mybatis</groupId><artifactId>mybatis</artifactId></dependency>
</dependencies>

这种一致性主要基于：

学习成本考虑：开发者已经熟悉这种组织结构
生态一致性：保持与其他组件的统一结构
风险规避：遵循经过验证的实践方案

2. Spring 官方的特殊考量

Spring 团队采用集中式的 autoconfigure 设计，可能基于以下考虑：

统一管理：协调大量第三方库的适配
版本控制：统一管理配置类的兼容性
框架生态：维护整个 Spring Boot 生态的一致性

但这种针对框架级别的设计考量，并不一定适用于所有的自研 Starter 场景。

四、自研 Starter 的替代方案思考

1. 内聚式设计

对于自研的 Starter，可以考虑采用更加内聚的设计：

company-spring-boot-starter/
├── src/main/java
│   └── com/company/autoconfigure/
│       ├── CompanyAutoConfiguration.java
│       └── CompanyProperties.java
├── src/main/resources
│   └── META-INF
│       ├── spring.factories
│       └── spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports
└── pom.xml

2. 简化的依赖管理

只需要在 Starter 中声明一次依赖：

<dependencies><dependency><groupId>com.company</groupId><artifactId>company-core</artifactId></dependency><!-- 其他运行时依赖 -->
</dependencies>

这样可以避免：

独立的 autoconfigure 模块创建和维护
重复的依赖声明
optional 依赖的复杂管理

3. 合理的条件注解使用

在内聚式设计中，可以更加有选择地使用条件注解：

@Configuration
@AutoConfigureAfter(DataSourceAutoConfiguration.class)
public class CompanyAutoConfiguration {@Bean@ConditionalOnMissingBean  // 保留：允许用户自定义public CompanyService companyService() {return new DefaultCompanyService();}@Bean@ConditionalOnProperty(prefix = "company", name = "feature.enabled")public FeatureService featureService() {return new FeatureService();}
}