欢迎阅读我的文章！更多精彩内容，欢迎关注：
• B站主页：小枫Geek
• 微信公众号：Procode  

---

在很多 Spring Boot 项目里，随着功能增加，配置类往往会迅速膨胀： 一个 Config 文件几百行，既有数据源配置、又有缓存配置、还有线程池和第三方 SDK。刚开始写的时候很爽，后期维护就像在一个巨大的抽屉里找螺丝——理论上都在里面，但找起来痛苦。

工程经验告诉我们：配置类和业务代码一样，需要结构设计。

下面聊聊在实际开发中，配置类通常应该怎么拆分。

1

一、按“技术组件”拆分配置

最常见、也最稳定的一种拆法：一个技术组件，一个配置类。

例如：

config
 ├── RedisConfig
 ├── MybatisConfig
 ├── ThreadPoolConfig
 ├── JacksonConfig
 └── SwaggerConfig

示例：

@Configuration
public class RedisConfig {

    @Bean
    public RedisTemplate<String, Object> redisTemplate(
            RedisConnectionFactory factory) {
        RedisTemplate<String, Object> template = new RedisTemplate<>();
        template.setConnectionFactory(factory);
        return template;
    }
}

这种拆分方式有几个明显好处：

• 配置职责清晰

• 代码搜索更容易

• 不同模块互不影响

一个简单的判断标准：

如果一个配置类的 Bean 明显属于不同技术领域，那就该拆。

1

二、按“业务模块”拆分配置

有些配置并不是纯技术型，而是 和业务模块强绑定。

例如：

user
 ├── UserConfig
 ├── UserService
 └── UserController

order
 ├── OrderConfig
 ├── OrderService
 └── OrderController

例如：

@Configuration
public class OrderConfig {

    @Bean
    public OrderIdGenerator orderIdGenerator() {
        return new SnowflakeOrderIdGenerator();
    }
}

这种方式适用于：

• 模块化项目

• 微服务

• DDD 分层项目

好处是： 配置跟着业务走，而不是散落在全局 config 目录。

1

三、按“配置类型”拆分

另一种常见方式是：区分 Bean 配置 与 属性配置。

在 Spring Boot 生态里，通常会配合 @ConfigurationProperties 使用。

例如：

config
 ├── properties
 │    └── OssProperties
 └── bean
      └── OssConfig

属性类：

@ConfigurationProperties(prefix = "oss")
@Data
public class OssProperties {

    private String endpoint;
    private String accessKey;
    private String secretKey;
}

配置类：

@Configuration
@EnableConfigurationProperties(OssProperties.class)
public class OssConfig {

    @Bean
    public OssClient ossClient(OssProperties properties) {
        return new OssClient(
            properties.getEndpoint(),
            properties.getAccessKey(),
            properties.getSecretKey()
        );
    }
}

这样做的优点很明显：

配置来源与 Bean 初始化逻辑分离。 1

四、复杂项目里的推荐结构

在实际企业项目里，一个比较健康的结构通常是：

config
 ├── datasource
 │    └── DataSourceConfig
 ├── redis
 │    └── RedisConfig
 ├── web
 │    └── WebMvcConfig
 ├── thread
 │    └── ThreadPoolConfig
 └── properties
      └── XxxProperties

拆分原则可以总结为一句话：

让每个配置类只有一个清晰的职责。

如果一个配置类：

• 同时配置 Redis

• 又配置线程池

• 又配置 JSON

那基本可以断定：它已经过度生长了。

1

五、一个很容易踩的坑

很多项目喜欢写一个：

GlobalConfig
AppConfig
CommonConfig

然后所有 Bean 都往里面塞。

短期看似方便，长期会产生两个问题：

1. 配置类越来越大

2. 新人根本不知道该把配置写在哪里

工程系统有一个奇妙的规律： 结构模糊的地方，复杂度会指数增长。

---

六、一个实战经验规则

在团队开发里可以定一个简单规范：

一个配置类不超过 200 行。

一旦超过，基本就说明：

• 职责过多

• 应该拆分

这不是语法规则，而是一种工程“嗅觉”。

软件架构有点像整理工具箱。 螺丝刀、扳手、电钻混在一起时，任何东西都很难找； 当每种工具都有自己的位置时，系统就会变得安静而清晰。

配置类的拆分，本质上就是在给系统建立这种秩序。