ServiceLoader 通过读取 META-INF/services/ 下与接口全限定名同名的文件加载实现类，按 classpath 顺序查找、不去重、懒加载实例，需手动处理类加载冲突与异常。
ServiceLoader 是怎么加载接口实现的
Java 的 ServiceLoader 不是靠反射扫描全类路径，也不是自动读取任意配置文件——它只认准一个地方：META-INF/services/ 目录下、与接口全限定名完全一致的文件。比如你定义了接口 com.example.LogHandler，那必须在 jar 包里放 META-INF/services/com.example.LogHandler，文件内容是一行一个实现类的全名（如 com.example.Slf4jLogHandler）。
- 类加载器只会用当前线程上下文类加载器（
Thread.currentThread().getContextClassLoader()）去加载这个文件和其中的类，不是用ServiceLoader所在类的类加载器 - 文件名大小写必须严格匹配接口名，哪怕多一个空格或换行，
ServiceLoader.load()就会静默跳过该实现 - 多个 jar 提供同一接口的不同实现时，
ServiceLoader按 classpath 顺序遍历，**不保证唯一性**，也不会去重——你得自己判断哪个该用
为什么 new 实例失败但没报错
常见现象：调用 serviceIterator.next() 报 NoClassDefFoundError 或 InstantiationException，但前面 hasNext() 返回 true，日志里还看不到堆栈。这是因为 ServiceLoader 的懒加载机制：它只在 next() 时才真正尝试 Class.forName() + newInstance()（Java 9+ 是 getDeclaredConstructor().newInstance()），而 hasNext() 只解析配置文件、校验类名是否存在，不触发类加载。
- 如果实现类依赖了某个 jar 里的类，但该 jar 没进 classpath，
next()就会炸，且异常被吞掉一部分（尤其在 for-each 循环里） - 实现类构造器抛异常、非 public、无无参构造器，都会导致实例化失败
- 建议永远用 try-catch 包住
next()，并打印完整异常，别依赖hasNext()做安全判断
插件化开发中如何避免 ClassLoader 冲突
当你的主程序和插件 jar 都依赖同一个三方库（比如 org.slf4j:slf4j-api），但版本不同，就容易出现 LinkageError 或方法找不到。SPI 本身不解决这个问题，它只是个发现工具，类加载责任仍在你手上。
- 插件 jar 应该 **shaded**（重命名包）自己的依赖，或者声明为
provided（由宿主提供），不能直接打包冲突的 jar - 不要让插件使用
AppClassLoader加载自身；推荐为每个插件创建独立的URLClassLoader，并显式设置 parent 为Thread.currentThread().getContextClassLoader() -
ServiceLoader.load(serviceInterface, pluginClassLoader)—— 必须传入插件自己的类加载器，否则它会去主程序里找实现，根本加载不到插件里的类
和 Spring 的 @Conditional、Dubbo 的 ExtensionLoader 有啥区别
别把 ServiceLoader 当成“轻量 Spring”。它没有条件装配、没有优先级排序、不支持参数注入、也不缓存实例——每次 next() 都 new 一个新对象。
立即学习“Java免费学习笔记（深入）”；
-
@Conditional是编译期/启动期决策，基于环境、类存在性、属性值等做开关；ServiceLoader是纯运行时按约定查文件，毫无逻辑可言 - Dubbo 的
ExtensionLoader支持 SPI 文件里写name=class映射、支持自适应扩展、支持 IOC 注入，而原生ServiceLoader的配置文件里只能写类名，连别名都没有 - 如果你需要热插拔、卸载、版本隔离、依赖检查，
ServiceLoader一步都做不到，得自己补一整套类加载 + 生命周期管理
真正用起来，ServiceLoader 就是个启动时的“配置文件驱动的工厂”，别指望它扛起插件系统的全部重量。最易被忽略的是：它不处理实现类之间的依赖关系，也不管你初始化顺序——这些全得自己兜底。
