文章目录一、自动配置解决了什么问题二、SpringBootApplication 拆解三、加载流程四步四、条件注解家族五、DataSource 实例拆解六、自定义自动配置实战七、排查与调试八、常见问题九、总结摘要Spring Boot 自动配置是面试高频考点。本文从 SpringBootApplication 拆解开始讲清 AutoConfiguration.imports 加载流程、条件注解家族并以 DataSource 为例拆解真实实现最后给出自定义自动配置的完整代码与排查方法。一、自动配置解决了什么问题传统 Spring 时代每个 Bean 都要手动声明XML 或 JavaConfig。Spring Boot 的目标是约定优于配置引入依赖就能跑少量配置覆盖默认值。自动配置的本质启动时扫描所有 starter 上报的自动配置类清单逐个用条件注解判断是否装配。二、SpringBootApplication 拆解SpringBootConfiguration// Configuration 的变体EnableAutoConfiguration// 核心开启自动配置ComponentScan// 扫描当前包组件自动配置部分由EnableAutoConfiguration触发底层通过AutoConfigurationImportSelector加载类清单。三、加载流程四步EnableAutoConfiguration触发导入读取每个 starter 的META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports2.7 之前为spring.factories的EnableAutoConfiguration键逐个评估自动配置类上的Conditional条件条件满足则装配默认 Bean用户自定义 Bean 优先ConditionalOnMissingBean。四、条件注解家族注解判断内容典型场景ConditionalOnClass类是否在 classpath依赖缺失跳过ConditionalOnMissingBean用户是否未定义 Bean用户配置优先ConditionalOnProperty属性是否存在配置开关ConditionalOnWebApplication是否 Web 应用Web/非 Web 区分ConditionalOnExpressionSpEL 表达式复杂条件ConditionalOnResource资源是否存在按资源装配五、DataSource 实例拆解AutoConfigurationConditionalOnClass(DataSource.class)ConditionalOnMissingBean(DataSource.class)EnableConfigurationProperties(DataSourceProperties.class)publicclassDataSourceAutoConfiguration{...}执行逻辑classpath 存在 HikariCP → 条件成立用户未自定义 DataSource → 自动创建默认 HikariDataSourcespring.datasource.*属性经DataSourceProperties自动绑定。没写配置也能跑的真相starter 引入依赖自动配置检测依赖存在即装配默认 Bean用户配置只是覆盖默认值。六、自定义自动配置实战做一个问候语自动配置AutoConfigurationConditionalOnProperty(namedemo.greeting.enabled,havingValuetrue,matchIfMissingtrue)publicclassGreetingAutoConfiguration{BeanConditionalOnMissingBeanpublicGreetingServicegreetingService(){returnnewGreetingService(你好我是自动配置出来的);}}注册清单Spring Boot 2.7META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports com.demo.GreetingAutoConfiguration启动后无需任何Bean声明GreetingService即自动可用demo.greeting.enabledfalse可关闭。标准的 starter 结构是两个模块autoconfigure模块放自动配置代码starter模块只依赖 autoconfigure 并引入必要依赖本身通常不写代码、只有一个 pom。这样使用方引入一个依赖自动配置和依赖就都齐了。七、排查与调试手段用法用途启动日志--debug启动查看 Auto-configuration Report 的 matched/excludedActuator/actuator/conditions实时查看条件判断结果排除SpringBootApplication(exclude...)或spring.autoconfigure.exclude禁用不需要的自动配置八、常见问题Q1为什么自动配置不生效优先查条件依赖是否在 classpath、属性是否满足、Bean 是否被用户自定义占用。用--debug或 conditions 端点定位。Q2自动配置的 Bean 会不会覆盖我的 Bean不会。ConditionalOnMissingBean保证用户自定义优先。Q32.7 前后注册方式有什么变化2.7 起用AutoConfiguration.imports文件之前用spring.factories的EnableAutoConfiguration键。Q4为什么不要在业务代码里用 ConditionalOnMissingBean该注解设计给自动配置类使用在用户 Bean 定义之后评估业务代码里用容易产生顺序依赖问题。Q5自动配置类为什么不直接用 Component 注册自动配置类需要经过 AutoConfigurationImportSelector 统一加载、按条件判断、并保证在用户 Bean 之后处理直接 Component 会在条件判断前就被注册无法保证用户自定义优先。九、总结自动配置全部秘密清单 条件。清单starter 通过AutoConfiguration.imports上报条件Conditional家族决定何时生效原则用户自定义优先。
文章目录一、自动配置解决了什么问题二、SpringBootApplication 拆解三、加载流程四步四、条件注解家族五、DataSource 实例拆解六、自定义自动配置实战七、排查与调试八、常见问题九、总结摘要Spring Boot 自动配置是面试高频考点。本文从 SpringBootApplication 拆解开始讲清 AutoConfiguration.imports 加载流程、条件注解家族并以 DataSource 为例拆解真实实现最后给出自定义自动配置的完整代码与排查方法。一、自动配置解决了什么问题传统 Spring 时代每个 Bean 都要手动声明XML 或 JavaConfig。Spring Boot 的目标是约定优于配置引入依赖就能跑少量配置覆盖默认值。自动配置的本质启动时扫描所有 starter 上报的自动配置类清单逐个用条件注解判断是否装配。二、SpringBootApplication 拆解SpringBootConfiguration// Configuration 的变体EnableAutoConfiguration// 核心开启自动配置ComponentScan// 扫描当前包组件自动配置部分由EnableAutoConfiguration触发底层通过AutoConfigurationImportSelector加载类清单。三、加载流程四步EnableAutoConfiguration触发导入读取每个 starter 的META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports2.7 之前为spring.factories的EnableAutoConfiguration键逐个评估自动配置类上的Conditional条件条件满足则装配默认 Bean用户自定义 Bean 优先ConditionalOnMissingBean。四、条件注解家族注解判断内容典型场景ConditionalOnClass类是否在 classpath依赖缺失跳过ConditionalOnMissingBean用户是否未定义 Bean用户配置优先ConditionalOnProperty属性是否存在配置开关ConditionalOnWebApplication是否 Web 应用Web/非 Web 区分ConditionalOnExpressionSpEL 表达式复杂条件ConditionalOnResource资源是否存在按资源装配五、DataSource 实例拆解AutoConfigurationConditionalOnClass(DataSource.class)ConditionalOnMissingBean(DataSource.class)EnableConfigurationProperties(DataSourceProperties.class)publicclassDataSourceAutoConfiguration{...}执行逻辑classpath 存在 HikariCP → 条件成立用户未自定义 DataSource → 自动创建默认 HikariDataSourcespring.datasource.*属性经DataSourceProperties自动绑定。没写配置也能跑的真相starter 引入依赖自动配置检测依赖存在即装配默认 Bean用户配置只是覆盖默认值。六、自定义自动配置实战做一个问候语自动配置AutoConfigurationConditionalOnProperty(namedemo.greeting.enabled,havingValuetrue,matchIfMissingtrue)publicclassGreetingAutoConfiguration{BeanConditionalOnMissingBeanpublicGreetingServicegreetingService(){returnnewGreetingService(你好我是自动配置出来的);}}注册清单Spring Boot 2.7META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports com.demo.GreetingAutoConfiguration启动后无需任何Bean声明GreetingService即自动可用demo.greeting.enabledfalse可关闭。标准的 starter 结构是两个模块autoconfigure模块放自动配置代码starter模块只依赖 autoconfigure 并引入必要依赖本身通常不写代码、只有一个 pom。这样使用方引入一个依赖自动配置和依赖就都齐了。七、排查与调试手段用法用途启动日志--debug启动查看 Auto-configuration Report 的 matched/excludedActuator/actuator/conditions实时查看条件判断结果排除SpringBootApplication(exclude...)或spring.autoconfigure.exclude禁用不需要的自动配置八、常见问题Q1为什么自动配置不生效优先查条件依赖是否在 classpath、属性是否满足、Bean 是否被用户自定义占用。用--debug或 conditions 端点定位。Q2自动配置的 Bean 会不会覆盖我的 Bean不会。ConditionalOnMissingBean保证用户自定义优先。Q32.7 前后注册方式有什么变化2.7 起用AutoConfiguration.imports文件之前用spring.factories的EnableAutoConfiguration键。Q4为什么不要在业务代码里用 ConditionalOnMissingBean该注解设计给自动配置类使用在用户 Bean 定义之后评估业务代码里用容易产生顺序依赖问题。Q5自动配置类为什么不直接用 Component 注册自动配置类需要经过 AutoConfigurationImportSelector 统一加载、按条件判断、并保证在用户 Bean 之后处理直接 Component 会在条件判断前就被注册无法保证用户自定义优先。九、总结自动配置全部秘密清单 条件。清单starter 通过AutoConfiguration.imports上报条件Conditional家族决定何时生效原则用户自定义优先。
概念介绍)
