serviceloader.load()返回空迭代器却不报错，主因是类加载器隔离或路径错误：检查meta-inf/services/接口全限定名文件是否在jar根路径、文件名无.class后缀、内容无空格/bom、实现类public且含public无参构造器，并显式传入匹配的classloader。
ServiceLoader.load() 返回空迭代器却不报错，怎么排查？
这是最常卡住人的第一步：调用 ServiceLoader.load(YourInterface.class) 后遍历发现没任何实现，控制台也无异常。根本原因几乎总是类加载器隔离或路径错误。
检查要点：
- 确认
META-INF/services/com.example.YourInterface文件真实存在于 jar 包根路径（不是源码路径、不是resources子目录下）；文件名必须是接口全限定名，**不能带.class后缀** - 文件内容每行一个实现类全限定名，**末尾不能有空格、制表符或 Windows 回车符（\r\n）**，
#不被识别为注释，会直接导致NoClassDefFoundError - 实现类必须是
public、非泛型、非内部类，且声明了public YourServiceImpl()无参构造器 - 显式传入类加载器：
ServiceLoader.load(YourInterface.class, YourInterface.class.getClassLoader())—— 默认用线程上下文类加载器（Thread.currentThread().getContextClassLoader()），在 fat-jar、OSGi 或自定义 classloader 场景下极易失效
为什么 forEachRemaining() 会漏掉部分插件实例？
ServiceLoader 的 Iterator 是延迟加载 + 单次遍历的。调用 forEachRemaining() 或 stream().forEach() 时，一旦某个实现类加载失败（比如 NoClassDefFoundError、IllegalAccessException），整个迭代器立即进入失效状态，后续所有未加载项都会被跳过，且不抛出任何可捕获异常。
安全做法是手动遍历并逐个处理：
<pre class="brush:php;toolbar:false;">ServiceLoader<plugin> loader = ServiceLoader.load(Plugin.class, Plugin.class.getClassLoader());
for (Plugin plugin : loader) {
try {
plugin.init();
} catch (ServiceConfigurationError | Throwable e) {
// 记录具体哪个类加载失败，不影响其他插件
log.warn("Failed to init plugin: {}", plugin.getClass(), e);
}
}
</plugin>
注意：ServiceConfigurationError
Throwable 也要捕获，因为插件自身 init() 可能抛运行时异常。
多个插件 jar 同时存在时，加载顺序怎么控制？
ServiceLoader **不保证加载顺序**。它按 ClassLoader.getResources() 返回的 URL 列表顺序扫描 META-INF/services/ 文件，而该顺序取决于 jar 包在 classpath 中的排列位置 —— 这在不同构建工具（Maven vs Gradle）、不同打包方式（fat-jar vs exploded）、不同 JVM 启动参数下都可能变化。
若需确定顺序，必须自行干预：
- 在插件实现类中增加
int getOrder()方法或@Order注解（自己定义），加载后手动排序 - 避免依赖隐式顺序，把“谁先执行”逻辑下沉到插件协议里（例如定义
Plugin.before(Plugin other)接口） - 完全放弃顺序假设，改用事件驱动模型（如发布
PluginLoadedEvent，由监听器协调）
别试图靠 jar 文件名排序或 META-INF/MANIFEST.MF 添加顺序字段 —— ServiceLoader 不读这些。
如何让插件感知 Spring 容器但不引入 Spring Boot 依赖？
纯 ServiceLoader 无法做依赖注入，插件拿到的是裸对象。如果插件需要访问 DataSource、RestTemplate 等 Spring 托管 Bean，又不想让插件模块编译期依赖 spring-boot-starter，可行方案只有两种：
- 插件接口定义回调方法，如
void setApplicationContext(ApplicationContext ctx)，主程序在加载后主动调用，插件自行从中getBean()—— 插件只依赖spring-context（非 starter），体积小，解耦干净 - 主程序提供一个轻量级服务注册中心（如
ServiceRegistry.put("config", configMap)），插件通过静态方法或全局单例获取所需资源 —— 完全避开 Spring，适合极简场景
不要在插件里写 @Autowired 或 @Component —— 没有 Spring 容器扫描，它们只是无效注解。
ServiceLoader.load()，而是当 7 个插件 jar 同时扔进 lib/ 目录、其中两个依赖冲突、一个构造器私有、一个配置文件用了 UTF-8 BOM、还有一个在 static 目录下误放了同名 META-INF —— 这些细节不会报错，只会让插件静默消失。
