Spring应用的配置类初始化时机至关重要。本文分析一种在配置类构造函数中读取数据库配置的写法，并探讨其潜在风险以及更优的替代方案。
问题描述：
示例代码中，AppConfig 类使用 @Configuration 注解，并在构造函数中通过 @Autowired 注入 ConfigMapper，从数据库读取配置信息。尽管 IDE 报错“could not autowire. no beans of 'ConfigMapper' type found.”，程序却能正常运行并获取数据。这种方法存在哪些风险？
代码示例：
@Configuration
@Data
public class AppConfig {
private String some;
@Autowired
public AppConfig(ConfigMapper configMapper) {
System.out.println("---------------");
List all = configMapper.selectList(); //假设ConfigDO是数据库实体类
System.out.println(all);
this.some = all.isEmpty() ? "default" : all.get(0).getValue(); //示例赋值
}
}
问题分析与解决方案：
虽然代码运行成功，但 @Configuration 注解与构造函数注入 ConfigMapper 的组合方式并不理想。@Configuration 注解通常与 @Bean 注解配合使用，定义 Bean。在 @Configuration 类中直接使用构造函数注入，虽然 Spring 4.x 及以上版本支持，但可读性差，建议改为 @Component 注解。
代码能够运行的原因是 Spring 容器在实例化 AppConfig 时，根据构造函数参数自动注入了 ConfigMapper。但这并非最佳实践。Spring 提供多种更优雅的初始化方式，例如：
-
实现
InitializingBean接口，重写afterPropertiesSet()方法： 此方法确保在所有属性设置完成后执行初始化逻辑。 -
使用
@PostConstruct注解： 该注解标记的方法会在 Bean 初始化完成后自动执行。 -
实现
ApplicationRunner或CommandLineRunner接口： 这两个接口提供在 Spring 容器启动后执行初始化逻辑的机制，适合需要在应用启动时完成数据库连接或其他初始化操作的场景。 -
使用
@Configuration+@Bean： 将数据库读取逻辑封装在@Bean方法中，更清晰地定义 Bean 的创建过程，并方便测试。
推荐使用 @Configuration + @Bean 方法，示例如下：
@Configuration
public class AppConfig {
@Autowired
private ConfigMapper configMapper;
@Bean
public String someConfig() {
List all = configMapper.selectList();
return all.isEmpty() ? "default" : all.get(0).getValue();
}
}
直接在构造函数中执行数据库操作，虽然能实现功能，但可读性和可测试性较差，且容易出现循环依赖等问题。采用 Spring 提供的标准初始化方式，可以提高代码质量和可维护性。 此外，这种方式也更利于对数据库操作进行事务管理和异常处理。
