@EnableAutoConfiguration 是自动装配的引导入口，通过 AutoConfigurationImportSelector 加载 spring.factories 中的配置类，并结合 @Conditional 注解按需激活，实现启动时一次性、可覆盖的智能装配。
@EnableAutoConfiguration 是 Spring Boot 自动装配的启动开关，它本身不直接注册 Bean，而是触发一整套按需加载机制；spring.factories 是它的“配置清单”，告诉 Spring Boot “有哪些自动配置类可选”；两者配合，最终实现“有依赖才加载、有缺失才补全、有冲突可覆盖”的智能装配。
@EnableAutoConfiguration 的真实作用是“调度器”
它不是一个功能型注解，而是一个引导入口。真正干活的是它通过 @Import(AutoConfigurationImportSelector.class) 导入的这个选择器类：
- 启动时，AutoConfigurationImportSelector.selectImports() 被调用
- 该方法内部调用 getCandidateConfigurations() 获取候选配置类列表
- 再层层深入到 loadSpringFactories()，去扫描所有 META-INF/spring.factories 文件
- 只提取其中键为 org.springframework.boot.autoconfigure.EnableAutoConfiguration 对应的值（即自动配置类全名）
spring.factories 是第三方和官方配置类的“注册表”
每个 Starter（比如 spring-boot-starter-jdbc）或自定义模块，只要在自己的 resources/META-INF/spring.factories 中写入：
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\ com.example.MyDataSourceAutoConfiguration,\ com.example.MyCacheAutoConfigurationSpring Boot 启动时就会发现这些类，并把它们纳入候选名单。这个机制基于 JDK 的 SPI 思想，但由 Spring 自己的 SpringFactoriesLoader 实现，支持多 jar 并存、无侵入扩展。
立即学习“Java免费学习笔记（深入）”；
按需加载靠的是 @Conditional 系列注解
即使一个 AutoConfiguration 类被读进来了，也不代表它一定会生效。它必须通过“条件门禁”检查：
-
@ConditionalOnClass(DataSource.class)：只有项目引入了 HikariCP 或 Druid 的 jar，类路径里真有
DataSource，这个配置才参与 -
@ConditionalOnMissingBean(DataSource.class)：如果开发者自己写了
@Bean DataSource，那这个自动配置就跳过，不抢你位置 - @ConditionalOnProperty(name = "myapp.cache.enabled", havingValue = "true")：配置文件里明确开了缓存，才加载缓存相关 Bean
- 多个条件是“与”关系，全部满足才激活该配置类
整个流程是启动时一次性决策，不是运行时动态切换
自动配置发生在 Spring 容器刷新（refresh()）早期阶段，在用户自定义 @Configuration 执行之后、Bean 实例化之前。这意味着：
- 你可以用自定义
@Bean覆盖默认自动配置的 Bean（因为后注册的同类型 Bean 会替换先注册的） - 也可以用
spring.autoconfigure.exclude在 application.properties 中主动排除某个 AutoConfiguration 类 - 但不能在应用运行中临时“打开”或“关闭”某个自动配置——它是启动快照式决策
