当前位置：首页 > java >正文

Spring普通配置类 vs 自动配置类-笔记

java 2025/5/15 6:58:02

1.简要版

@Configuration和@Bean，既可以用于普通配置类，也可以用于自动配置类。二者的区别和联系是什么呢？

区别：

@Configuration和@Bean是Spring框架本身的注解，用于定义配置类和生成Bean。
而自动配置通常是Spring Boot的概念，比如通过@EnableAutoConfiguration和条件注解来实现的。

联系：

自动配置类本质上也是普通配置类，只是：
- 被 Spring Boot 自动加载
- 使用了条件注解控制 Bean 的创建
普通配置类可以覆盖自动配置类的 Bean，例如通过 @Primary 或在 application.properties 中设置属性来改变默认行为。

2.详情版

2.1 基本定义

类型	定义
普通配置类	使用 `@Configuration` 注解的类，内部通过 `@Bean` 方法显式定义 Bean。这类配置类是开发者手动编写的，用于构建应用所需的依赖关系。
自动配置类	是 Spring Boot 提供的一种特殊配置类，通常也使用 `@Configuration` 和 `@Bean`，但结合了条件注解（如 `@ConditionalOnClass`、`@ConditionalOnMissingBean` 等），由 Spring Boot 在启动时自动加载并按需启用。

2.2 加载机制

项目	普通配置类	自动配置类
加载方式	显式声明：通过组件扫描（`@ComponentScan`）或 `@Import` 加载	隐式加载：由 `@EnableAutoConfiguration` 触发，从 `spring.factories` 或自动配置元数据中读取
控制权	完全由开发者控制	由 Spring Boot 根据环境自动判断是否启用
是否可覆盖	可以被覆盖或替换	通常不可覆盖，除非手动定义相同 Bean 并设置为优先级更高

2.3 条件化配置

项目	普通配置类	自动配置类
是否支持条件化	不支持	支持多种条件注解（如 `@ConditionalOnClass`, `@ConditionalOnProperty` 等）
目的	用于显式创建 Bean	用于按需启用/禁用配置，实现“智能配置”

⚠️ 自动配置类的核心优势在于其“条件化”能力。它可以根据类路径、配置属性、已注册的 Bean 等条件，决定是否启用某个配置或创建某个 Bean。

2.4 使用场景

类型	适用场景
普通配置类	开发者手动定义的 Bean、自定义组件、业务逻辑相关的配置等
自动配置类	用于 Spring Boot 内部或第三方库提供的默认配置，如数据库连接、Web 容器、邮件服务等

2.5 两者的关系

自动配置类本质上也是普通配置类，只是：
- 被 Spring Boot 自动加载
- 使用了条件注解控制 Bean 的创建
普通配置类可以覆盖自动配置类的 Bean，例如通过 @Primary 或在 application.properties 中设置属性来改变默认行为。

2.6 示例对比

1. 普通配置类: 该类需要被组件扫描或显式导入，才能生效。

@Configuration
public class MyConfig {@Beanpublic MailService mailService() {return new MailServiceImpl();}
}

2. 自动配置类:该类只有当 javax.mail.Session 存在，且未手动注册 MailService 时才会生效。

@Configuration
@ConditionalOnClass(Session.class)
public class MailAutoConfiguration {@Bean@ConditionalOnMissingBean(MailService.class)public MailService mailService() {return new MailServiceImpl();}
}

2.7 使用建议

场景	建议
自定义 Bean	使用普通配置类
第三方库集成	使用自动配置类（由库提供者定义）
修改默认配置	使用普通配置类覆盖自动配置类的 Bean
自定义自动配置	实现 `@Configuration` + 条件注解，注册到 `spring.factories`

2.8 总结

项目	普通配置类	自动配置类
是否自动加载	否	是（Spring Boot 控制）
是否支持条件判断	否	是
是否可被覆盖	是	通常不可直接覆盖
适用场景	自定义逻辑、显式配置	自动化配置、默认行为