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<ConfigDO> 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<ConfigDO> all = configMapper.selectList(); return all.isEmpty() ? "default" : all.get(0).getValue(); } }
直接在构造函数中执行数据库操作，虽然能实现功能，但可读性和可测试性较差，且容易出现循环依赖等问题。采用 Spring 提供的标准初始化方式，可以提高代码质量和可维护性。 此外，这种方式也更利于对数据库操作进行事务管理和异常处理。
