requires transitive仅控制依赖的可见性传递，不管理版本升级；它确保下游模块能编译和运行时访问被暴露的类型，但版本统一需依赖BOM或构建工具约束。
requires transitive 本身不负责版本升级的自动波及，它只控制模块依赖的可访问性传递（即编译期和运行期的符号可见性），而非版本管理或依赖更新。想让底层库变量（如类、方法、常量）的升级“自动波及所有依赖模块”，关键不在 transitive 的声明方式，而在于如何设计模块边界 + 配合构建工具行为。以下是真正可行的实战路径：
✅ 明确目标：什么才算“自动波及”？
- 下游模块编译不报错（能解析新类型/新方法）
- 运行时不抛
NoSuchMethodError或NoClassDefFoundError - 不要求每个下游模块手动改
module-info.java或pom.xml
这三点，requires transitive 能帮上第一个和第二个；第三个则需构建系统配合。
✅ 场景一：API 层暴露了底层库的类型（必须用 transitive）
当你在公共接口中直接使用了第三方模块的类，比如：
// com.example.api 模块导出的接口
public interface UserService {
// 返回值是 Jackson 的 JsonNode → 调用方必须能访问 jackson-databind
JsonNode getUserProfile(String userId);
}
此时，com.example.api 必须声明：
module com.example.api {
requires transitive com.fasterxml.jackson.databind;
exports com.example.api;
}
✅ 效果：
任何 requires com.example.api 的模块（如 com.example.web），无需再写 requires com.fasterxml.jackson.databind，就能编译通过并调用 getUserProfile()，也能安全访问返回的 JsonNode。
⚠️ 注意：
如果底层库（如 Jackson）升级了 JsonNode 的 API（例如新增了 getOptionalString() 方法），你的 com.example.api 模块必须重新编译，否则下游模块即使能访问旧版 JsonNode，也无法调用新方法——transitive 不会“注入”新字节码，它只是打开访问通道。
✅ 场景二：统一依赖版本锚点（靠构建工具，非 transitive）
requires transitive 不解决版本同步问题，但你可以结合 Maven BOM 或 Gradle Platform 实现“一处升级、全局生效”：
-
在根
pom.xml中定义 BOM：<dependencymanagement><dependencies><dependency><groupid>com.fasterxml.jackson</groupid><artifactid>jackson-bom</artifactid><version>2.17.0</version><type>pom</type><scope>import</scope></dependency></dependencies></dependencymanagement>
-
所有子模块只需声明：
<dependency><groupid>com.fasterxml.jackson.core</groupid><artifactid>jackson-databind</artifactid><!-- 无 version → 继承 BOM 中的 2.17.0 --></dependency>
✅ 效果：
升级 BOM 版本后，所有子模块自动使用新版 Jackson —— 包括被 requires transitive 引用的模块。transitive 确保它们能用，BOM 确保它们用的是同一版。
✅ 场景三：避免“假性波及”——防止运行时行为不一致
requires transitive 只管“能访问”，不管“用哪个版本”。若不同模块间接拉入不同版本的同一库（如 A 传入 2.15，C 直接引入 2.16），JVM 可能加载冲突类。
✔️ 正确做法：
- 在应用级模块（如
com.example.app）显式声明核心依赖，并设为compile范围（Maven）或implementation（Gradle），作为“版本仲裁者” - 配合模块系统：用
--limit-modules或--add-reads在启动时强制统一可见性（适用于严格隔离场景）
❌ 常见误区（务必避开）
- 把
requires transitive junit写进生产模块 → 测试依赖污染，下游编译失败或包冲突 - 对内部工具类使用的 Guava 声明
transitive→ 暴露实现细节，破坏封装 - 认为加了
transitive就不用管版本 → 实际仍需构建工具统一收敛
不复杂但容易忽略：requires transitive 是门“可见性开关”，不是“版本同步器”。它让升级后的类型能被看见、能被编译、能被运行，但让所有人看到同一个新版，还得靠 BOM、平台约束或发布流程兜底。
