ServiceLoader加载不到实现类主因是META-INF/services位置错误或接口全限定名拼写错误；必须置于classpath根目录（如Maven的src/main/resources/META-INF/services/），文件名须为接口全限定名，内容为实现类全名，且实现类需有public无参构造器；Java 9+模块化需在module-info.java中声明provides；其核心价值在于编译期解耦，运行时动态加载，支持插件扩展与多实现共存，但无优先级、条件加载等高级能力。
ServiceLoader 加载不到实现类的常见原因
不是代码写错了，大概率是 META-INF/services/ 目录没放对位置，或者接口全限定名拼错。
-
META-INF/services/必须在 classpath 根目录下，不是源码根目录；Maven 项目要放在src/main/resources/META-INF/services/，不是src/main/java - 服务配置文件名必须是接口的完整类名，比如接口是
com.example.Renderer，文件名就得是com.example.Renderer（无后缀），内容是实现类全名，如com.example.HtmlRenderer - 实现类必须有 public 无参构造器，否则
ServiceLoader实例化时抛NoClassDefFoundError或InstantiationException - 模块化（Java 9+）环境下，服务提供者所在的 module-info.java 必须声明
provides com.example.Renderer with com.example.HtmlRenderer;，否则加载为空
为什么不能直接 new 实现类，非要用 ServiceLoader
核心就一条：编译期不依赖具体实现，运行时才绑定。适合插件式扩展，比如日志框架选 slf4j + logback，或 JDBC 驱动切换。
- 调用方只依赖接口和
ServiceLoader.load()，不 import 任何实现类，彻底解耦 - 新增实现只需打包、加配置文件、丢进 classpath，无需改调用方代码
- 多个实现可共存，
ServiceLoader返回Iterator，可遍历选择（比如按优先级、按环境变量过滤） - 注意：
ServiceLoader是懒加载，iterator().next()才真正触发类加载和实例化，不会一启动就把所有实现全拉进来
ServiceLoader.reload() 的实际作用和陷阱
reload() 不会“热替换”已加载的实例，它只是清空当前缓存，下次 iterator() 时重新扫描 classpath —— 但前提是 classpath 真的变了（比如 Web 容器里重部署了 jar）。
- 普通 Java SE 应用 reload 基本无效，因为 classpath 启动后固定，
reload()后拿到的还是原来那批类 - OSGi、Spring Boot DevTools、某些容器才真正支持动态 classpath 变更，此时 reload 才有意义
- 别指望靠
reload()实现配置驱动的运行时插件开关；真要这样，得自己封装一层，结合ServiceLoader+ 配置白名单 + 缓存管理
替代方案：为什么现在更多人用 SPI + 框架（如 Spring Factories）
ServiceLoader 太原始，没优先级、没条件加载、不支持参数注入，复杂场景撑不住。
立即学习“Java免费学习笔记（深入）”；
- Spring Boot 的
META-INF/spring.factories支持 key-value 形式，能指定自动配置类、监听器、初始化器，还能按条件（@ConditionalOnClass）激活 - Guice、Dagger 这类 DI 框架直接把实现类当 binding 注册，天然支持构造器注入、生命周期管理
- 如果你只是想让两个模块松耦合，又不想引入框架，
ServiceLoader仍是最轻量、JDK 自带、零依赖的选择——但得接受它不支持延迟初始化以外的任何高级能力
真正容易被忽略的是类加载器上下文：默认用 Thread.currentThread().getContextClassLoader()，如果在 Tomcat 或 OSGi 里，这个 loader 可能看不到你的服务配置文件。必要时得显式传入正确的 ClassLoader，比如 ServiceLoader.load(MyService.class, MyService.class.getClassLoader())。
