Java SPI 懒加载且依赖类路径顺序，Spring Bean 加载由依赖图驱动；二者在自动配置阶段交叠，常见冲突是 SPI 配置类注册过晚导致其 Bean 错失初始化时机，需分层协同控制。
java spi 和 spring bean 加载顺序看似无关，实则在复杂初始化场景中常交织影响。spi 负责框架级扩展点的发现与加载，属于“容器外”的服务注册；而 bean 加载是 spring 容器内部的实例化与依赖装配过程。两者真正产生交集的地方，往往出现在自动配置类、条件化组件或插件式 starter 的初始化阶段——比如一个基于 spring.factories 注册的 @configuration 类，其内部定义的 bean 是否能正确加载，取决于它本身被 spring 扫描和注册的时机，也受 spi 加载顺序间接制约。
Java SPI 是怎么加载的？关键在懒加载和类路径扫描
SPI 的核心是 ServiceLoader，它不一启动就加载所有实现，而是按需触发：
- 调用
ServiceLoader.load(X.class)仅返回一个Iterable，此时什么都没加载 - 第一次调用
iterator().next()时，才去扫描所有META-INF/services/com.example.X文件 - 逐行读取类名，用当前线程上下文类加载器（
Thread.currentThread().getContextClassLoader()）尝试加载并实例化 - 多个 jar 包里有同名 SPI 文件时，加载顺序取决于类路径（classpath）中 jar 的排列顺序，没有统一优先级保证
Spring Bean 加载顺序不是写在代码里的先后，而是依赖图驱动的
Spring 不按 @Bean 方法在类中声明的顺序加载，也不按 @Component 类在包里出现的顺序扫描。它的实际顺序由三类信息共同决定：
-
显式依赖：通过构造函数参数、
@Autowired字段或@DependsOn明确声明的依赖关系，被依赖的 Bean 总是先初始化 -
配置类排序：使用
@AutoConfigureBefore/@AutoConfigureAfter（适用于自动配置类），或@Order（对@Configuration类生效）可干预配置类本身的注册顺序 -
Bean 自身排序：对实现了
Ordered接口的 Bean，或标注了@Order/@Priority的@Bean方法，Spring 在注入集合（如List<handler></handler>）或执行生命周期回调（如SmartInitializingSingleton）时会按序处理
当 SPI 和 Bean 初始化撞在一起：典型冲突场景
常见问题不是“SPI 加载慢”，而是“SPI 提供的配置类太晚注册，导致它定义的 Bean 错过关键初始化时机”：
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
-
数据库监控组件未就绪，连接池却已初始化：监控 Bean 由某个 SPI 自动配置类提供，但该配置类注册晚于
DataSource相关自动配置，结果监控逻辑无法织入 -
自定义过滤器没进过滤器链：你通过
spring.factories注册了一个WebMvcConfigurer，但它被加载时，Spring MVC 的核心配置已完成，你的addInterceptors已无效 -
条件化 Bean 判断失效：SPI 加载的某个
@Configuration类里用了@ConditionalOnClass(SomeClass.class)，但SomeClass所在的 jar 是另一个 SPI 后加载的，导致条件始终不满足
实用控制手段：从 SPI 层到 Bean 层协同治理
单靠改一个地方很难根治，需分层设防：
立即学习“Java免费学习笔记（深入）”；
-
在 SPI 配置层面：确保
spring.factories中的自动配置类按逻辑依赖排序，例如把基础设施类（如日志、监控）放在文件顶部，业务扩展类放底部；避免一个 jar 同时提供多个强耦合的自动配置类 -
在配置类层面：对关键配置类使用
@AutoConfigureBefore(DataSourceAutoConfiguration.class)，明确表达前置依赖；慎用@Order修饰整个@Configuration类，它只影响配置类注册顺序，不改变其内@Bean的依赖解析逻辑 -
在 Bean 层面：对必须早于其他 Bean 初始化的组件，实现
SmartInitializingSingleton接口，在所有单例 Bean 实例化后、初始化前统一执行；或使用@PostConstruct+@DependsOn组合，强制等待某几个关键 Bean 就绪
