Java SPI机制本质是“让接口自动找到它的实现”，通过约定目录结构（META-INF/services/接口全限定名）、配置文件（含实现类名）和ServiceLoader协同工作，实现解耦与扩展。
Java SPI 机制本质是“让接口自动找到它的实现”，不用硬编码、不改调用代码，就能换实现或加新功能。它不是运行时反射随便找类，而是靠一套严格约定的目录结构 + 配置文件 + ServiceLoader 协同工作。
核心三要素必须齐备
缺一不可，否则 ServiceLoader 就找不到实现：
-
定义一个服务接口：比如
public interface Codec { byte[] encode(String data); }，放在核心模块里，不带任何实现 -
在 META-INF/services/ 下建配置文件：路径必须是
META-INF/services/全限定接口名（例如META-INF/services/com.example.Codec），文件内容只写一行：实现类的完整类名（如com.example.JsonCodec） -
用 ServiceLoader 加载：调用
ServiceLoader.load(Codec.class)，然后遍历获取实例——注意它不会立即加载所有类，而是迭代时才反射创建
加载过程其实是懒加载+按需实例化
ServiceLoader 不是一启动就把所有实现类全加载进内存。它内部用 LazyIterator，真正调用 iterator.next() 或增强 for 循环第一次取值时，才会：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 扫描 classpath 所有
META-INF/services/com.example.Codec文件（支持多个 jar 包里都有） - 逐行读取实现类名，用当前线程上下文类加载器（Thread.currentThread().getContextClassLoader()）尝试加载该类
- 通过无参构造器反射创建实例，并检查是否确实实现了目标接口
- 缓存已创建的实例，后续遍历直接返回
常见踩坑点和应对方式
很多问题不是 SPI 不好用，而是约定没守牢：
立即学习“Java免费学习笔记（深入）”；
-
配置文件名大小写/路径错一点就失效：必须是
META-INF/services/接口全限定名，不能多空格、不能用反斜杠、不能漏包名 -
类加载器不一致导致找不到实现：默认用上下文类加载器，如果服务提供方 jar 是由自定义类加载器加载的，得显式传入：
ServiceLoader.load(Codec.class, yourClassLoader) - 多个实现共存时怎么选：SPI 默认全加载，你得自己加逻辑判断——比如看实现类上的注解、读配置开关、或按某种优先级排序再取第一个
-
实现类抛异常导致整个迭代中断：ServiceLoader 遇到单个实现初始化失败会吞掉异常并跳过，但建议在实现构造器或
init()方法里做轻量校验，避免运行时才暴露问题
真实场景中怎么配合框架用
单纯用 ServiceLoader 写业务逻辑较少，更多是被框架封装后间接使用：
-
JDBC 驱动注册：
java.sql.Driver接口由 JDK 定义，MySQL 的com.mysql.cj.jdbc.Driver在自己的 jar 里放了META-INF/services/java.sql.Driver，你连数据库时 DriverManager 就靠它自动发现驱动 -
SLF4J 绑定日志实现：SLF4J API 只定义接口，Logback 在 jar 中提供
META-INF/services/org.slf4j.spi.SLF4JServiceProvider，启动时自动接入 - Dubbo 扩展点：Dubbo 大量基于 SPI 自定义协议、序列化、集群策略，它扩展了原生 SPI，支持 @SPI 注解、自适应加载、分组激活等，但底层仍依赖 ServiceLoader 基础能力
