SPI是JDK自带的运行时自动查找接口实现类机制，依赖ServiceLoader和META-INF/services/配置文件；常见问题包括类加载器不匹配、配置路径/格式错误、懒加载导致异常延迟暴露及跨类加载器失效。
SPI 就是运行时自动找接口实现类的机制，靠 ServiceLoader + META-INF/services/ 配置文件驱动，不是“框架功能”，而是 JDK 自带的底层能力。
为什么 ServiceLoader.load(X.class) 找不到你的实现类？
这是最常卡住的地方：它不报错，但迭代器为空。根本原因不是代码写错了，而是类路径和加载时机没对上。
-
ServiceLoader默认用当前线程的上下文类加载器（Thread.currentThread().getContextClassLoader()），不是你直觉里的“当前类的类加载器” - 如果在 Web 容器（如 Tomcat）或 Spring Boot 启动早期调用，
getContextClassLoader()可能指向AppClassLoader，而你的 SPI 实现 jar 包实际由WebappClassLoader加载 —— 类加载器隔离导致找不到 - 配置文件名必须是接口全限定名，比如接口是
com.example.LogService，文件路径必须是META-INF/services/com.example.LogService，内容只能写一行：实现类全名（如com.example.Slf4jLogService），末尾不能有空格或换行 - 配置文件必须在
resources目录下，且打包后要真实出现在 jar 的根路径里；IDE 中若用 Maven 多模块，确保spi-impl模块的resources被正确包含进最终 jar
ServiceLoader 是懒加载，别在 for 循环外就假设对象已创建
它内部用 LazyIterator，只有调用 iterator.hasNext() 或 next() 时才真正尝试加载、实例化类。这意味着：
- 异常不会在
load()时抛出，而是在遍历时才暴露 —— 比如ClassNotFoundException、NoClassDefFoundError或构造函数抛异常 - 如果你只调用
serviceLoader.iterator()却没遍历，什么都不会发生，也不会缓存任何实例 - 每次调用
iterator()都会新建一个迭代器，重复解析配置文件、重复反射创建对象；不要把它当单例缓存使用
JDBC 驱动是 SPI 最典型的“反直觉”案例
你从没显式调用 ServiceLoader.load(Driver.class)，但 DriverManager.getConnection() 内部用了它 —— 这就是为什么加了 mysql-connector-java 依赖就能连 MySQL，不用手动 Class.forName("com.mysql.cj.jdbc.Driver")（老写法）。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
立即学习“Java免费学习笔记（深入）”；
- MySQL 8+ 的驱动 jar 包里自带
META-INF/services/java.sql.Driver，内容是com.mysql.cj.jdbc.Driver -
DriverManager在静态块中调用ServiceLoader.load(Driver.class)，一启动就扫描所有实现 - 注意：JDBC 规范要求驱动类必须有无参构造函数，且需在构造时向
DriverManager注册自己 —— 这是 SPI 之外的额外契约，不是所有 SPI 接口都这样
Spring Boot 的 spring.factories 不是原生 SPI，但思路同源
它模仿了 SPI 的“外部配置驱动加载”思想，但实现完全独立：SpringFactoriesLoader 专门读取 META-INF/spring.factories，支持键值对（如 org.springframework.boot.autoconfigure.EnableAutoConfiguration=com.example.MyAutoConfig），还能按 key 分组、支持条件化加载。
- 别指望把
spring.factories放到META-INF/services/下让ServiceLoader识别 —— 它俩文件路径、格式、加载逻辑都不同 - 如果你在写 SDK，想兼容 Spring Boot 自动装配，就得同时提供
spring.factories；想被通用 Java 环境识别，才需要标准 SPI 配置 - Dubbo 的 SPI 更进一步：支持 @SPI 注解定义默认实现、@Adaptive 动态代理、加载顺序控制 —— 原生
ServiceLoader连“优先级”“别名”都没有
真正容易被忽略的是类加载器边界问题：SPI 的“解耦”只在代码层面成立，一旦跨了类加载器（比如 OSGi、Tomcat 多应用、JRebel 热替换），ServiceLoader 就失效了 —— 它不会跨加载器搜索，也不会帮你做类委托。这时候要么统一类加载策略，要么换用更可控的加载方式（如手动 Class.forName(name, true, loader)）。
