ServiceLoader.load不能用于运行时确定类型的“变量接口”，因其要求接口类型编译期已知；若需按字符串名动态加载，须绕过泛型限制、显式指定类加载器并手动校验类型，或改用Spring Factories等更灵活方案。
ServiceLoader.load 不能直接用于“变量接口”——即运行时才确定类型的接口。它要求接口类型在编译期已知，否则泛型擦除会导致类型不安全，编译失败。所谓“动态发现变量接口”，本质是想根据字符串名加载任意接口的实现，这超出了 ServiceLoader 的设计边界。但可以通过组合手段达成目标，关键在于绕过泛型限制、控制类加载时机、并做好类型校验。
接口类型必须编译期固定，不能靠字符串传入
下面写法是非法的：
-
错误示例：
String ifaceName = "com.example.MyService"; Class> clazz = Class.forName(ifaceName); ServiceLoader.load(clazz);—— 编译通不过，因为load()需要Class，而clazz是原始类型，无法推导泛型参数S - ServiceLoader 的签名是
public static，JVM 必须在调用时就知道ServiceLoaderload(Classservice)S是什么具体类型（如Animal.class），才能构造带类型信息的实例 - 如果真需要按名加载，只能放弃泛型安全，走原始类型 + 手动转型路线，但必须自行保障类型正确性
按接口全限定名动态加载的可行做法
若你已知接口类名（字符串），又必须用 ServiceLoader，可这样封装：
- 先用
Class.forName("com.example.MyService")加载接口类对象 - 调用
ServiceLoader.load((Class) interfaceClass)（传原始类型，绕过泛型检查） - 遍历返回的
Iterator，对每个元素做instanceof判断或强制转型（如(MyService) obj） - 务必捕获
ClassCastException和ServiceConfigurationError，并记录日志——这是失去编译检查后必须承担的风险
模块化环境下的关键注意事项
在 Java 9+ 模块系统（JPMS）或 Spring Boot 多模块项目中，ServiceLoader 行为更敏感：
- 模块中必须显式声明
uses com.example.MyService;，否则即使配置文件存在，也不会被扫描 - 类加载器错位是“找不到实现”的最常见原因：默认使用线程上下文类加载器（
TCCL），但实现类可能由模块类加载器加载；应显式传入MyService.class.getClassLoader() - META-INF/services/com.example.MyService 文件必须位于 classpath 根路径下（不是仅在
src/main/resources里），构建工具（Maven/Gradle）需确保它被打包进最终 jar 或 classes 目录 - 接口不能是泛型接口、内部类或默认包中的类——这些在 SPI 规范中不被识别
更推荐的替代方案
如果业务场景本质是“运行时决定加载哪个接口”，建议跳出 ServiceLoader，改用更灵活的机制：
-
Spring Factories：配合
SpringFactoriesLoader.loadFactories()，配置在META-INF/spring.factories中，支持按 key 加载任意类型工厂，天然适配 Spring 生态 -
自定义 SPI 工具类：封装一层，内部用反射获取接口类 +
ServiceLoader.load()原始调用，对外提供loadByInterfaceName(String)方法，并内置类型兼容性校验和缓存逻辑 -
服务注册中心模式：启动时扫描所有
META-INF/services/下的配置，构建接口名 → 实现类列表映射表；查询时再按需加载、验证、实例化，真正实现按需与解耦
