serviceloader 迭代异常时默认静默跳过并中断遍历，需用传统 for-each + 双异常捕获（serviceconfigurationerror 和 throwable）；必须显式指定接口类加载器以防空迭代器；建议实例化与初始化分离，并严格遵守 spi 配置规范。
ServiceLoader 迭代过程中遇到加载异常时，默认行为是静默跳过失败项并中断后续遍历，而不是挂起系统。所谓“挂起”通常是误判——真正的问题是异常未捕获、日志缺失、或错误地依赖 forEachRemaining 等一次性消费方法，导致部分插件被漏加载且无提示。
必须手动遍历 + 显式捕获两类异常
ServiceLoader 的 Iterator 是延迟加载且单次有效的。一旦某个实现类在 newInstance() 阶段抛出异常（如 NoClassDefFoundError、IllegalAccessException 或构造器内运行时异常），迭代器立即失效，后续 next() 调用会直接抛 IllegalStateException。
- 不要用
forEachRemaining()或stream().forEach()—— 它们无法捕获中间失败，也无法继续处理后续项 - 必须用传统 for-each 循环，并在每次调用
plugin.init()前包裹 try-catch - 需同时捕获
ServiceConfigurationError（SPI 专属异常，涵盖配置错误、类找不到、构造器不可访问等）和Throwable（插件自身逻辑可能抛任意运行时异常）
确保类加载器一致，避免“空迭代器”假象
返回空迭代器却不报错，90% 是类加载器不匹配：ServiceLoader 默认使用线程上下文类加载器（Thread.currentThread().getContextClassLoader()），但在 fat-jar、模块化环境或自定义 classloader 场景下，该 loader 往往看不到插件 jar 中的实现类。
- 显式传入接口所在的类加载器：
ServiceLoader.load(Plugin.class, Plugin.class.getClassLoader()) - 优先选用接口类自身的类加载器，它大概率能覆盖其实现类的路径
- 避免混用不同模块的 ClassLoader，尤其在热部署或 OSGi 场景中
主动收集可用实例，隔离初始化副作用
插件的构造函数或 init() 方法若含重量级操作（如连接池初始化、配置加载），失败后不应阻塞整个插件链。建议将实例化与初始化分离：
- 先用 ServiceLoader 加载所有实现类，仅完成
Class.forName().getDeclaredConstructor().newInstance() - 再统一调用
init()方法，并对每个插件单独 try-catch - 把成功初始化的插件缓存到
List<plugin></plugin>，失败的记录日志并跳过，不影响主流程
配置文件与实现类必须满足硬性约束
很多“异常”其实源于 SPI 约定未被遵守，导致 ServiceConfigurationError 在首次 next() 时爆发：
-
META-INF/services/com.example.Plugin必须位于 jar 包根目录，不能放在resources/META-INF下 - 文件名是接口全限定名，不能带
.class后缀 - 每行一个实现类全限定名，末尾不能有空格、
\r\n、BOM 或#注释（# 不被识别，会被当作类名的一部分） - 实现类必须是 public、非内部类、非泛型类，且声明
public Plugin()无参构造器
