serviceloader 是轻量级服务发现机制，基于 meta-inf/services 配置动态加载接口实现类，不支持变量级自动注入；它实现多实现动态选择、运行时插件加载与调用方解耦。
ServiceLoader 本身不是依赖注入容器，它不提供变量级的自动装配能力，比如不能像 Spring 那样把一个 String 配置值或 int port 直接注入到字段中。它的核心职责是**服务接口的发现与加载**——即根据一个公共接口，动态加载并实例化所有已注册的实现类。
ServiceLoader 的本质定位
它是一个标准、轻量、无第三方依赖的服务发现机制，基于 META-INF/services/xxx.InterfaceName 文件驱动。它只管“有哪些实现”，不管“怎么配置参数”或“如何注入具体值”。因此，“轻量级变量依赖注入”这个说法容易引发误解。准确来说，ServiceLoader 实现的是：
- 接口契约下的多实现动态选择（如：日志策略、序列化器、校验规则）
- 运行时插件加载（如：新增一种验证码生成器，无需改主程序）
- 解耦调用方与具体实现（调用方只依赖接口，不 import 任何实现类）
如何“模拟”变量级注入效果
虽然 ServiceLoader 不直接注入变量，但可通过组合设计模式，在服务实现内部封装配置逻辑，达到类似效果：
- 让每个服务实现类自己读取配置（如通过
System.getProperty()、Config.fromEnv()或注入一个共享的ConfigBean） - 定义带参数的构造函数或初始化方法，由调用方在获取实例后手动传入变量（例如：
new SmsSender(config.get("sms.timeout"))） - 结合 DI 容器做桥接：用 Spring 的
ServiceLoaderFactoryBean将服务加载为 Bean，再利用@Value向其实例注入配置项
关键使用前提与避坑点
要让 ServiceLoader 正常工作，必须满足几个硬性条件：
- 服务接口必须是
public，且对当前类加载器可见（模块化项目需exports或opens对应包） - 实现类必须有 public 无参构造函数（否则
ServiceLoader实例化失败） -
META-INF/services/下的文件名必须严格等于接口全限定名，内容为实现类全限定名（一行一个），末尾不能有多余空格或 BOM - 不要在循环中反复调用
ServiceLoader.load()—— 它每次都会重新扫描和加载，影响性能；应缓存结果或使用单例包装
一个典型轻量集成示例
假设你有一个短信发送接口：
public interface SmsProvider {<br> void send(String phone, String content);<br>}
在 META-INF/services/com.example.SmsProvider 中写入：
com.example.aliyun.AliyunSmsProvider<br>com.example.tencent.TencentSmsProvider
主程序中这样使用：
ServiceLoader<smsprovider> loader = ServiceLoader.load(SmsProvider.class);<br>for (SmsProvider provider : loader) {<br> if ("aliyun".equals(System.getProperty("sms.provider"))) {<br> provider.send("138...", "hello");<br> break;<br> }<br>}</smsprovider>
这里的 System.getProperty("sms.provider") 就是“变量注入”的实际载体——由外部控制流程，而非框架自动完成。
