uses用于声明模块可能使用某服务接口，是被动提示而非主动加载；真正加载由ServiceLoader在运行时通过META-INF/services配置动态完成。
在 Java 模块系统（JPMS）中，uses 关键字不是用来“声明消费需求”的主动动作，而是模块描述符（module-info.java）中用于**声明本模块会使用某服务接口类型**的被动指示。它本身不触发加载，也不保证服务可用；真正负责发现、加载和实例化服务实现的是 ServiceLoader。掌握二者配合逻辑，关键在于理解「声明」与「加载」的分工：前者是编译期/运行期的契约提示，后者是运行时的动态查找机制。
uses 的真实作用：告诉模块系统“我依赖这个服务类型”
uses 出现在 module-info.java 中，仅表示当前模块在运行时**可能通过 ServiceLoader.load() 获取该接口的实现**。它不导入包，不强制依赖提供方模块，也不校验实现是否存在——只是为模块系统提供元信息，用于更精准的模块图分析（如 jlink、jdeps 工具可据此识别潜在服务依赖）。
- 写法示例：
uses com.example.LogService;—— 表明本模块可能加载LogService接口的实现 - 注意：
uses后必须是接口（或抽象类），且该类型需在模块路径上可访问（通常通过requires引入其所在模块） - 常见误区：以为写了
uses就能自动注入或调用服务——实际仍需手动调用ServiceLoader.load(MyService.class)
ServiceLoader 加载逻辑：按约定路径扫描 + 双亲委派式查找
ServiceLoader 的加载行为不依赖 uses，但二者常协同使用。其核心逻辑是：在类路径（ClassPath）或模块路径（ModulePath）下，查找 META-INF/services/全限定接口名 文件，并解析其中列出的实现类名进行实例化。
- 对于模块化环境：若服务接口定义在模块 A，实现类在模块 B，则模块 B 必须在
module-info.java中用provides com.example.Service with com.impl.ServiceImpl;声明提供关系 - 加载时，
ServiceLoader.load(Service.class)会按以下顺序查找实现：- 先查当前线程上下文类加载器（Context ClassLoader）能加载的
META-INF/services/...文件 - 再查
Service.class所在类加载器（通常是模块系统类加载器）对应的路径 - 模块路径下，还会检查提供方模块是否已导出（exports）实现类所在的包
- 先查当前线程上下文类加载器（Context ClassLoader）能加载的
- 每个
ServiceLoader实例是懒加载的：调用iterator()或stream()时才真正读取配置、加载类、实例化对象
实战要点：声明、提供、加载三步缺一不可
一个完整的服务消费流程需要三方配合，uses 只是其中一环：
-
服务接口模块（API）：定义接口，导出包（
exports com.example;），无需uses -
服务实现模块（Impl）：依赖 API 模块（
requires），声明提供关系（provides ... with ...），并在META-INF/services/下写实现类全名（模块化下该文件可省略，因provides已替代） -
服务消费模块（App）：依赖 API 模块（
requires），声明使用意图（uses com.example.Service;），并在代码中显式调用ServiceLoader.load(Service.class)获取实例
调试技巧：验证服务是否被正确发现
当 ServiceLoader.load() 返回空迭代器，不要只盯着 uses，应逐层排查：
- 确认接口类能否被消费模块的类加载器加载（
Class.forName("com.example.Service")是否成功） - 检查实现模块是否在运行时模块路径中（
java --list-modules | grep impl） - 用
jdeps --list-deps your-app.jar看是否包含服务提供方模块 - 临时去掉模块化，退回到传统 classpath 模式，验证
META-INF/services/文件是否规范（一行一个实现类全名，无空格、注释）
