java.util.ServiceLoader 是 Java SPI 机制的核心实现，用于运行时按 META-INF/services/ 下配置加载接口实现类。它基于约定路径查找、解析类名、反射实例化，依赖类加载器与正确资源位置，不提供依赖注入或插件管理功能。
什么是 java.util.ServiceLoader？
ServiceLoader 是 Java 标准库中实现 SPI（Service Provider Interface）机制的核心类，它不负责定义接口，也不提供实现，只做一件事：在运行时按约定路径查找、加载并实例化 META-INF/services/ 下声明的接口实现类。
你写一个接口（比如 ImageProcessor），让不同模块提供各自的实现（JpegProcessor、PngProcessor），再在各自 JAR 包里放一个 META-INF/services/com.example.ImageProcessor 文件，内容就是实现类全限定名。然后用 ServiceLoader.load(ImageProcessor.class) 就能拿到所有可用实现。
关键点：SPI 不是“插件系统”，也不是“依赖注入”，它本质是 JDK 提供的一种弱耦合的、基于文件配置的发现机制。
为什么 ServiceLoader 加载不到我的实现类？
常见原因不是代码写错了，而是资源路径或类加载器没对上：
立即学习“Java免费学习笔记（深入）”；
Windows 桌面自动化技能，支持鼠标控制（移动/点击/拖拽/滚轮/截图）、键盘输入（文字输入/按键/组合键）、窗口管理（查找/聚焦/最大化/最小化/关闭/移动）、截图并发送文件。提供两种截图方式：Python pyautogui 截图（集成在自动化流程中）和 PowerShell + .NET 零依赖截图（支持区域截图和多显示器）。当用户需要自动化 Windows 桌面操作、控制鼠标键盘、管理窗口、执行 GUI 自动化任务、截图发送文件时使用。
-
META-INF/services/必须在 classpath 根路径下（即和com/包同级），不是放在src/main/resources就自动生效——要确认编译后该文件真出现在 JAR 或 classes 输出目录的根下 - 服务配置文件名必须是接口的**完整类名**（如
com.example.LogHandler），不能有空格、大小写错误，也不能带.class - 文件内容只能是实现类的全限定名，每行一个，末尾不能有空格或 BOM 字符（Windows 记事本容易加 BOM）
- 如果用模块系统（
module-info.java），需显式声明uses com.example.ImageProcessor;（调用方）和provides com.example.ImageProcessor with com.example.JpegProcessor;（提供方） -
ServiceLoader默认使用当前线程上下文类加载器（Thread.currentThread().getContextClassLoader()），若在 Web 容器或 OSGi 环境中，这个加载器可能看不到你的服务文件
ServiceLoader 和 ClassLoader.getSystemResources() 有什么区别？
两者都能查资源，但语义和用途完全不同：
-
ServiceLoader是高层封装：它读取META-INF/services/文件 → 解析类名 → 用指定类加载器Class.forName(...)→ 调用无参构造器实例化 → 还支持reload()和iterator()惰性加载 -
ClassLoader.getSystemResources("META-INF/services/com.example.Foo")只返回 URL 列表，你需要自己读文件、解析、反射、处理异常，且无法保证类加载器一致性 - 性能上，
ServiceLoader第一次load()会缓存结果；而手动遍历资源每次都要 IO + 解析，还容易漏掉多模块同名服务的合并逻辑 - 兼容性上，
ServiceLoader自 Java 6 引入，Java 9+ 在模块化下仍保持行为一致（只要模块声明了uses/provides）；手写资源查找在模块路径下很可能失效
Spring 的 @SPI 或 Dubbo 的 SPI 是一回事吗？
不是。Java 原生 SPI 很简单，只有加载和实例化；而 Spring、Dubbo、Apache ShardingSphere 等框架的 “SPI” 是在其基础上做的增强，通常包含：
- 支持带参数的构造器、工厂方法、依赖注入（原生 SPI 只支持无参构造）
- 支持扩展点别名（如
dubbo://对应DubboProtocol）、默认实现、条件加载（@ConditionalOnClass） - 缓存策略更细（按 key 缓存、热加载）、异常兜底（找不到实现时返回空或默认）、优先级排序
- 配置方式不局限于
META-INF/services，可能读spring.factories或自定义配置文件
所以看到框架文档说 “基于 SPI 实现”，实际用的大概率是自家重写的加载器，只是借用了“服务发现”这个概念。直接套用原生 ServiceLoader 逻辑去调试 Dubbo 扩展点，基本会失败。
真正容易被忽略的是：SPI 的“服务”不是功能模块，而是契约。接口设计是否稳定、版本如何兼容、实现类是否线程安全、是否允许重复注册——这些都得靠人来约定，ServiceLoader 本身不校验、不约束、也不报错。
