JPMS通过requires transitive显式控制第三方依赖传递边界，确保下游仅可见API所需类型；自动模块不可transitive，需封装或升级；配合exports/opens精细暴露，构建工具统一版本仲裁。
Java 模块化系统（JPMS）中管理第三方依赖的传递边界，核心在于**显式控制模块间的可见性与依赖传播范围**，避免下游模块意外获得不该访问的类或版本混乱。关键不是“要不要传递”，而是“谁该看到、在什么条件下看到”。
明确 requires transitive 的使用场景
当你的模块向外部暴露了某个 API，而该 API 的签名中直接用到了第三方库的类型（比如方法返回 AmazonS3、参数是 ObjectMapper），就必须用 requires transitive 声明该依赖：
- 下游模块编译时才能解析这些类型，否则会报 “cannot find symbol”
- 运行时 JVM 才能正确链接到该第三方模块，避免 NoClassDefFoundError
- 例如：一个封装 S3 操作的工具模块，若 public 方法返回
S3Client，就必须requires transitive software.amazon.awssdk.s3
区分自动模块与原生模块的处理方式
大多数第三方 JAR（如 log4j、jackson-databind）尚未原生模块化，JVM 会将其视为“自动模块”（Automatic-Module-Name 来自 MANIFEST.MF）：
- 自动模块默认可被 requires，但不能被 requires transitive —— 因为它没有 module-info.java，无法保证导出稳定性
- 若你强行写
requires transitive com.fasterxml.jackson.databind，编译会通过，但运行时可能因包未导出而失败 - 稳妥做法：升级至已模块化的替代品（如 AWS SDK v2、slf4j-api + jul-to-slf4j），或在自己的
module-info.java中用requires+ 显式exports封装调用逻辑，不把第三方类型暴露出去
用 exports + opens 精细控制包可见性
即使启用了传递依赖，也不能让整个第三方库对下游开放。应只导出真正需要的接口：
立即学习“Java免费学习笔记（深入）”；
-
exports com.company.s3.api;—— 让下游能访问你定义的公共契约 -
opens com.company.s3.internal to java.desktop;—— 仅对特定模块开放反射访问（如序列化），不破坏封装 - 不导出任何第三方包（如
com.amazonaws.*），防止下游绕过你的抽象直接操作底层 SDK
配合构建工具统一版本与排除冗余
JPMS 负责运行时模块图验证，但版本仲裁和依赖裁剪仍需 Gradle/Maven 协同：
- 在根项目的
build.gradle中用resolutionStrategy.force锁定关键第三方版本，防止不同模块引入冲突的自动模块 - 对非必需的传递依赖，用
exclude group: 'org.slf4j'主动剔除，避免模块图膨胀 - 用
./gradlew dependencies --configuration runtimeClasspath检查实际加载的模块链，确认传递路径符合预期
