Spring应用中，配置类的初始化时机和方式至关重要。本文分析一个实际案例，指出其潜在风险并提供更优解。
案例： 开发者在AppConfig配置类中，于构造函数内从数据库读取配置数据：
@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 = ...; // 省略具体赋值逻辑
}
}
尽管IDE报错“could not autowire. no beans of 'configmapper' type found.”，程序却能正常运行并读取数据。这种现象暗藏风险。
问题分析： 将数据库读取置于AppConfig类的构造函数中，虽然运行正常，但与@Configuration注解的最佳实践相悖。@Configuration通常与@Bean注解配合，定义和配置Bean。而此处，AppConfig自身即为一个Bean，在构造函数中直接进行数据库操作，语义冲突。虽然Spring 4.x及以上版本允许在构造函数上省略@Autowired注解，但这种做法并非最佳实践。
更优解决方案： 为提高代码清晰度和可维护性，建议采用以下Spring提供的初始化方式：
-
使用
@Component注解替代@Configuration： 如果AppConfig并非用于配置其他Bean，则使用@Component更合适。 -
实现
InitializingBean接口，重写afterPropertiesSet()方法： 此方法在所有Bean属性注入完成后调用。 -
使用
@PostConstruct注解标记初始化方法： 该注解标记的方法会在Bean初始化后执行。 -
实现
ApplicationRunner或CommandLineRunner接口： 这两个接口提供在Spring容器启动后执行特定任务的机制。 -
使用
@Configuration+@Bean： 将数据库读取逻辑封装在一个独立的@Bean方法中，更清晰地分离关注点。
这些方法确保Spring容器启动后执行数据库读取操作，更符合Spring编码规范，提高代码可读性和可维护性，避免潜在的耦合问题。 选择哪种方式取决于具体应用场景和个人偏好。
