ServiceLoader.load() 找不到实现类的根本原因是其仅识别 META-INF/services/ 下以接口全限定名命名的配置文件，且内容须为无空格、无注释、无多余换行的实现类全限定名；常见错误包括路径未打包、文件名错误、实现类非 public、Java 9+ 模块中缺失 uses/provides 声明或 requires/export 不足。
ServiceLoader.load() 为什么总找不到实现类
根本原因不是代码写错了，而是 ServiceLoader.load() 只认 META-INF/services/ 下的配置文件，且文件名必须是接口全限定名，内容必须是实现类的全限定名（不能带空格、注释或多余换行）。常见错误包括：把配置文件放在 src/main/resources 但没打包进 jar；文件名写成 MyService 而不是 com.example.MyService；实现类没声明为 public；或者用了模块系统（Java 9+）却没在 module-info.java 中用 uses 声明依赖。
- 确认 jar 包里真有
META-INF/services/com.example.MyService，用jar -tf your.jar | grep services检查 - 配置文件内容只写一行：
com.example.MyServiceImpl，末尾不要回车 - 如果用 Maven，确保
resources目录被正确包含，且没有被filtering意外修改 - Java 9+ 模块中，服务提供方模块需在
module-info.java写provides com.example.MyService with com.example.MyServiceImpl;
ServiceLoader.reload() 的实际作用很有限
reload() 不会重新扫描 classpath 或检测新 jar，它只是清空当前已缓存的实例列表，下次 iterator() 时会重新加载——但加载逻辑和首次一样，仍走原来的类加载器和已加载的 jar。它对热替换、插件动态更新毫无帮助。真正想做到运行时发现新实现，得自己配合文件监听 + 自定义 ClassLoader + 手动调用 ServiceLoader.load(..., newClassLoader)。
-
reload()后再遍历，只会重新实例化已知的那些实现类，不会发现新加入的 jar - 多次调用
load()返回不同实例，但每个实例都来自同一个ClassLoader，无法隔离 - 若需插件热加载，别依赖
reload()，改用URLClassLoader加载外部 jar，再传给ServiceLoader.load(service, classLoader)
ServiceLoader.iterator() 返回的 Iterator 不支持 remove()
调用 iterator().remove() 会直接抛 UnsupportedOperationException。这不是 bug，是设计使然：SPI 是只读发现机制，不提供运行时剔除某实现的能力。想跳过某个实现？只能在遍历时手动判断过滤，或提前用 StreamSupport.stream() 转成流再 filter()。
- 以下写法会崩溃：
loader.iterator().remove() - 安全做法是收集后过滤：
StreamSupport.stream(loader.spliterator(), false).filter(...).collect(...) - 注意
iterator()是懒加载，每次调用都可能触发新实例化，避免反复遍历
Java 9+ 模块系统下 ServiceLoader 行为变化明显
模块路径（--module-path）取代 classpath 后，ServiceLoader 默认只查当前模块和其 requires 的模块，不再自动扫描所有 jar。如果服务接口在模块 A，实现类在模块 B，但 A 没 requires B，那 load() 就看不到 B 的实现——哪怕 jar 就在模块路径里。
立即学习“Java免费学习笔记（深入）”；
- 服务使用方模块（A）必须
requires服务提供方模块（B），否则无法访问其实现类 - 服务提供方模块（B）必须在
module-info.java显式exports实现类所在包，并provides接口 - 启动时若用
--class-path混用传统 jar，模块系统会退化为 classpath 模式，但此时ServiceLoader可能漏掉模块路径里的实现
requires 缺失或 exports 不足。 
