Spring Boot：在@Configuration类中用application.properties属性初始化Bean是否合适？

这个问题问得很好！在Spring Boot里用@Value在@Configuration类中获取属性初始化Bean，在简单场景下是完全可行的——比如你提到的用配置创建数据源的例子，小项目里这么写快速又直接，能满足基本需求。但如果项目规模变大、配置项变多，这种做法就会逐渐暴露出不少问题，长期用下来会给维护带来不小的麻烦。

持续采用这种方式可能产生的后果 #

• 可读性与维护性急剧下降：如果一个配置类里依赖多个配置项，你就得写一堆@Value注解的字段堆在类顶部。别人看代码时，很难快速关联某个Bean到底依赖哪些配置；要是配置项名称相似（比如app.api.url和app.admin.api.url），还容易搞混，后期修改配置时也容易漏改。
• 缺乏类型安全：@Value主要处理字符串或基本类型，遇到嵌套配置、一组关联属性时，没法直接映射成结构化的对象。比如你有一组Redis配置（redis.host、redis.port、redis.password），得手动定义三个@Value字段，后续新增配置项时还要重复加字段，繁琐且容易出错。
• 测试成本变高：测试配置类时，你需要给每个@Value属性单独设置测试值，不管是用@TestPropertySource还是手动注入，属性越多测试代码越冗长。如果多个Bean依赖相同配置，重复设置还容易出现不一致的问题。
• 配置校验缺失：默认情况下@Value不会校验配置的合法性——比如你把db.url写错成db.ur，只有项目运行到创建数据源的逻辑时才会抛异常，没法在启动初期就发现问题，增加了排查成本。

更优的替代方案 #

对于中大型项目或配置复杂的场景，更推荐用@ConfigurationProperties来绑定配置：

1. 先定义一个专门的配置类，集中管理一组关联的配置项：

@ConfigurationProperties(prefix = "db")
public class DbProperties {
    private String url;
    private String username;
    private String password;
    // 可以用Lombok的@Data省略getter/setter
    public String getUrl() { return url; }
    public void setUrl(String url) { this.url = url; }
    public String getUsername() { return username; }
    public void setUsername(String username) { this.username = username; }
    public String getPassword() { return password; }
    public void setPassword(String password) { this.password = password; }
}

2. 在配置类中注入这个配置类来初始化Bean：

@Configuration
@EnableConfigurationProperties(DbProperties.class)
public class MyConfig {
    private final DbProperties dbProperties;

    // 构造注入（推荐，符合依赖注入最佳实践）
    public MyConfig(DbProperties dbProperties) {
        this.dbProperties = dbProperties;
    }

    @Bean
    DataSource dataSource() {
        return DataSourceBuilder.create()
                .url(dbProperties.getUrl())
                .username(dbProperties.getUsername())
                .password(dbProperties.getPassword())
                .build();
    }
}

这种方式的好处很明显：配置项结构化集中管理，类型安全，可读性强；测试时只需要创建一个DbProperties实例传入即可；还能通过@Validated注解添加配置校验，启动时就发现非法配置。

总结 #

如果是小型项目或简单配置场景，用@Value完全没问题，快速省心。但如果项目有长期维护的需求，或者配置项较多、结构复杂，强烈建议切换到@ConfigurationProperties的方式，避免后续踩坑。

内容的提问来源于stack exchange，提问作者Vivek