requires static 实现编译期可选、运行时强制满足的依赖策略，适用于日志适配器等插件式能力；它使编译器忽略缺失模块，但运行时若存在则必须版本匹配，并需配合 uses 声明服务查找及主动降级逻辑。
在模块化项目中，requires static 的核心价值是实现“编译期可选、运行时若存在则强制满足”的依赖策略，特别适合日志适配器这类插件式能力——你不需要所有实现都打包进应用，但一旦用户选用了某个日志框架（如 logback），它就必须兼容你的模块契约。
明确日志门面与实现的职责分离
先定义一个日志门面模块（如 com.example.logging.api），只导出统一接口和注解，不绑定任何具体实现：
- 该模块不声明对 Log4j 或 SLF4J 的
requires，仅提供LoggerFactory、LogEvent等抽象 - 每个日志实现（如
com.example.logging.logback）单独成模块，并requires门面模块 +provides具体工厂类 - 业务模块只
requires门面模块，完全不知道底层用的是哪个实现
在核心模块中声明静态依赖适配器
当你要支持“自动探测并加载可用的日志实现”时，在核心服务模块（如 com.example.service.core）中使用 requires static 声明适配器契约：
module com.example.service.core {
requires java.logging;
requires static com.example.logging.api; // 编译时不强制，但运行时若存在，必须版本匹配
uses com.example.logging.api.LoggerFactory; // 声明要查找的服务提供者
}
-
requires static让编译器忽略该模块缺失的情况，避免构建失败 -
uses指示 JVM 在运行时通过ServiceLoader查找实现了LoggerFactory的类型 - 只要部署时把
logback模块放在模块路径上，系统就会自动加载其provides的实现，无需改代码
构建时控制适配器可见性与运行时行为
为防止误用或冲突，建议配合以下实践：
- 日志适配器模块自身应使用
open module或opens关键字，允许ServiceLoader反射访问其工厂类 - 在构建脚本（如 Gradle）中，将适配器模块设为
runtimeOnly依赖，确保不参与编译期校验 - 启动时用
java --module-path mods/ --add-modules ALL-SYSTEM,com.example.logging.logback -m com.example.app显式引入所需实现 - 用
jdeps --list-deps --module-path mods/ app.jar验证是否正确识别了静态依赖关系
处理缺失适配器的降级逻辑
requires static 不提供运行时兜底机制，需主动编码防御：
- 调用
ServiceLoader.load(LoggerFactory.class)后检查迭代器是否为空 - 为空时回退到 JDK 自带的
java.util.logging.Logger，或抛出清晰提示（如 “No logging adapter found; please add com.example.logging.* module”） - 避免静默失败——这是静态依赖最容易被忽视的风险点
