ImportSelector是配置类的“调度员”，负责在Spring容器加载前生成需导入的@Configuration类全限定名数组；AutoConfigurationImportSelector通过DeferredImportSelector延后执行，确保条件注解生效，最终读取META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports并过滤后返回有效配置类。

要弄清楚SpringBoot自动配置中ImportSelector到底干了什么，得从@SpringBootApplication启动那一刻开始追踪——它不直接注册Bean，而是决定“哪些配置类该被Spring容器加载”，这个筛选决策过程全由ImportSelector及其子接口DeferredImportSelector驱动。

ImportSelector是配置类的“调度员”

ImportSelector接口本身只定义了一个selectImports方法，它的职责非常明确：接收当前被@Import标注的类的注解元数据（AnnotationMetadata），返回一串需要被Spring容器加载的@Configuration类的全限定名数组。

这一步不做任何Bean注册，也不解析类内容，只做“名单生成”。就像快递分拣站只负责把包裹贴上目的地标签，不拆箱、不投递。

如果实现类直接 implements ImportSelector，selectImports会在所有@Configuration类解析前立即执行，容易因依赖未就绪而判断失准。

SpringBoot实际用的是DeferredImportSelector

AutoConfigurationImportSelector没有直接实现ImportSelector，而是实现了它的子接口DeferredImportSelector——这才是关键差异。

DeferredImportSelector让selectImports的调用时机延后到所有普通@Configuration类加载完毕、条件上下文（Environment、已注册Bean等）完全就位之后。

这保证了@ConditionalOnClass、@ConditionalOnMissingBean这类条件注解能真实生效：比如只有当HikariCP在classpath里时，DataSourceAutoConfiguration才被纳入名单。

【必须等所有基础配置加载完再执行selectImports，否则条件判断会失效】

AutoConfigurationImportSelector的核心执行链

第一步：Spring容器扫描到@EnableAutoConfiguration → 触发@Import(AutoConfigurationImportSelector.class)

第二步：容器识别出这是DeferredImportSelector实现类 → 暂缓执行，登记为“延迟导入项”

第三步：等全部@Configuration类解析完成、ApplicationContext刷新前期工作就绪 → 批量触发所有DeferredImportSelector.selectImports()

第四步：AutoConfigurationImportSelector.selectImports()内部调用getAutoConfigurationEntry() → 读取META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件 → 获取全部候选配置类全限定名 → 逐个应用@Conditional系列注解过滤 → 返回最终通过校验的类名数组

第五步：Spring容器将返回的类名作为@Configuration类正式加载、解析、注册Bean