ServiceLoader 通过读取 META-INF/services/ 下以接口全限定名命名的文本文件来加载实现类，文件每行一个实现类全限定名，需严格匹配包名和大小写；load() 仅解析配置，next() 才触发 Class.forName 和实例化，使用线程上下文类加载器，默认非单例。
ServiceLoader 不是“自动扫描类路径”，它只读 META-INF/services/ 下的配置文件，然后按需加载实现类——没配就找不到，配错名就 ClassNotFound。
ServiceLoader 从哪读实现类列表
它只看 META-INF/services/ 目录下以接口全限定名命名的文本文件（比如 java.sql.Driver 接口对应文件路径是 META-INF/services/java.sql.Driver）。该文件每行写一个实现类的全限定名，例如：
com.mysql.cj.jdbc.Driver org.postgresql.Driver
注意：文件名必须和 ServiceLoader.load(Xxx.class) 中传入的接口类型完全一致（包括包名），大小写敏感；文件内容不能有空格、注释或空行，否则解析失败或跳过。
load() 后不立即实例化，next() 才触发 Class.forName + newInstance
ServiceLoader 是懒加载的。调用 ServiceLoader.load(Interface.class) 只解析配置文件、缓存类名，不加载任何类。真正触发类加载和实例化的是迭代时调用 iterator().next() 或 forEach()：
立即学习“Java免费学习笔记（深入）”；
- 第一次
next()会执行Class.forName("com.example.MyImpl")，再调用其无参构造器 - 如果类不存在、无 public 无参构造、构造抛异常，
next()直接抛ServiceConfigurationError - 已加载过的实现类不会重复加载，但每次
next()都新建实例（不是单例）
ClassLoader 用谁的？默认是当前线程上下文类加载器
ServiceLoader 构造时默认使用 Thread.currentThread().getContextClassLoader()，不是 ServiceLoader.class.getClassLoader()。这意味着：
- 在 Web 容器（如 Tomcat）中，若服务提供方 JAR 放在
WEB-INF/lib，而 SPI 接口在容器共享类路径，可能因类加载器隔离导致找不到实现类 - 显式指定类加载器可规避问题：
ServiceLoader.load(Interface.class, myClassLoader) - 模块化（Java 9+）环境下，服务提供者必须在
module-info.java中声明provides Interface with Impl;，否则即使配置文件存在也会被忽略
常见故障点：文件名拼错、类名拼错、没加 public 无参构造
最常卡在这三处，错误现象通常是 NoSuchElementException（迭代为空）或 ServiceConfigurationError: Provider xxx not found：
- 检查
META-INF/services/文件名是否与接口类全限定名一字不差（含包名） - 检查文件内类名是否拼写正确、是否带包名、是否多写了分号或空格
- 确认实现类是 public 的，且存在 public 无参构造器（哪怕只是
public MyImpl() {}） - 打包后用
jar -tf your.jar | grep services确认文件确实被打进了 JAR 根路径
SPI 机制本身极简，但它的脆弱性全藏在这些细节里：不报错、不警告、只是默默不返回任何实现。调试时别猜，先翻 JAR 包里的 META-INF/services/。
