spring boot自动配置工厂加载机制从启动时类路径扫描开始，通过springfactoriesloader读取meta-inf/spring/org.springframework.boot.autoconfigure.autoconfiguration.imports文件（2.7+弃用spring.factories），按@conditional注解筛选并排除配置类，最终在invokebeanfactorypostprocessors()阶段注册为beandefinition。
要弄清楚Spring Boot自动配置中工厂加载机制的实际运作路径，必须从启动时类路径扫描开始——它不依赖手动注册，而是靠约定文件名和固定加载入口，在应用刚初始化、甚至Bean定义还没开始解析前就已触发。
SpringFactoriesLoader如何定位并读取配置文件
Spring Boot启动时，【AutoConfigurationImportSelector】会调用SpringFactoriesLoader.loadFactoryNames()方法；该方法内部通过ClassLoader.getResources("META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports")查找所有匹配资源。
注意：Spring Boot 2.7+已弃用spring.factories，改用新路径META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports；若项目同时存在两个文件，【只会加载.imports文件，spring.factories被完全忽略】。
每个jar包只要在自己的META-INF/spring/目录下放置该文件，就能被自动发现。比如spring-boot-autoconfigure.jar里就明文列出了100+个自动配置类全限定名。
自动配置类的筛选与条件评估流程
方法一：按@Conditional注解逐个过滤
加载到的所有配置类会被送入条件评估器（ConditionEvaluator），检查是否满足@ConditionalOnClass、@ConditionalOnMissingBean等约束。例如DataSourceAutoConfiguration类顶部有@ConditionalOnClass({ DataSource.class, EmbeddedDatabaseType.class })，只要类路径里没这两个类，整个配置类立刻被跳过，连其中的@Bean方法都不会执行。
方法二：排除机制优先于加载
如果在@SpringBootApplication(exclude = {DataSourceAutoConfiguration.class})中显式排除，该类在进入条件评估前就被剔除，不会参与任何判断。这比条件注解更早生效，也更彻底。
配置类注入容器的最终执行链路
第一步：AutoConfigurationImportSelector返回的Configuration类列表，被封装为DeferredImportSelector.Group实例；
第二步：Spring容器在refresh()阶段的invokeBeanFactoryPostProcessors()环节，调用其processGroupImports()方法；
第三步：此时才真正将符合条件的@Configuration类注册为BeanDefinition，后续由ConfigurationClassPostProcessor解析@Bean、@Import等语义。
这一步不能跳过——哪怕某个自动配置类通过了所有@Conditional检查，如果它没被Spring容器识别为@Configuration类型（比如漏了这个注解），就不会触发内部@Bean方法的注册。很多自定义Starter出问题，根源就在这里。
