java 9+模块化下需用modulelayer+serviceloader.withmodulelayer()实现类型安全服务加载，模块须显式声明provides/uses并导出包，避免反射和meta-inf/services依赖。
Java 9+ 模块化（JPMS）环境下，原生 ServiceLoader 无法直接跨模块加载服务实现，因为模块系统默认不导出 META-INF/services 资源，也不自动开放对服务类的反射访问。此时单纯靠传统 SPI 会触发 ClassNotFoundException 或 IllegalAccessException。真正可行的类型安全变量注入，需结合模块声明中的 provides…with 语句与模块化感知的加载逻辑，而非依赖反射硬编码。
模块声明必须显式导出服务并绑定实现
在 module-info.java 中，不能只写 uses MyService，还必须由提供方模块明确声明：
-
服务接口所在模块（如
api.module）需导出接口包：exports com.example.ai; -
实现模块（如
openai.impl）需声明：provides com.example.ai.LlmProvider with com.example.openai.OpenAiProvider; -
调用模块（如
app.module）需声明依赖并使用：requires api.module;和uses com.example.ai.LlmProvider;
运行时加载必须用 ModuleLayer + ServiceLoader.withModuleLayer()
传统 ServiceLoader.load() 默认使用上下文类加载器，在模块化下不可靠。正确做法是获取当前模块层并显式传入：
- 获取当前模块所在的
ModuleLayer：ModuleLayer layer = ModuleLayer.boot().parents().get(0);（或通过Module.getLayer()） - 使用模块感知加载器：
ServiceLoader<llmprovider> loader = ServiceLoader.load(layer, LlmProvider.class);</llmprovider> - 遍历时可直接获得类型安全实例，无需强制转型：
for (LlmProvider p : loader) { String result = p.chat("Hello"); }
避免常见陷阱：资源可见性与服务发现范围
provides…with 不会自动让 META-INF/services/ 文件对其他模块可见。该文件仅用于非模块化场景或向后兼容；模块化下它被忽略。关键点在于：
- 模块路径（
--module-path）中所有模块都会参与provides声明的注册，无需额外配置文件 - 若实现类未被其模块导出（
exports），即使provides正确，也会因封装失败而加载失败 - 多个模块提供同一接口时，
ServiceLoader按模块层顺序返回，无默认优先级，需业务代码自行筛选
类型安全注入的实用模式：构造器参数自动解析
若希望进一步解耦调用方，可配合依赖注入思想——不手动遍历 ServiceLoader，而是将服务实例作为构造器参数注入：
- 定义一个工厂类，接受
ServiceLoader<llmprovider></llmprovider>为参数 - 在模块启动时，由引导类获取
ServiceLoader实例并传入 - 工厂内部按策略选择实现（如根据
System.getProperty("llm.provider")），返回具体实例 - 整个过程保持泛型擦除前的类型信息，编译期即可捕获不匹配错误
