要用好 requires transitive，核心是让依赖可见性与 API 使用边界严格对齐：仅当 public 方法签名、导出类的字段/参数/返回值直接使用被依赖模块类型，或封装门面暴露组合型 API 时才启用；否则应坚持普通 requires，避免隐式耦合。
要用好 requires transitive，核心不是“多加几个关键字”，而是让依赖的可见性与 API 的使用边界严格对齐——它解决的是“下游模块该不该、能不能直接用某个类型”的问题，而不是“当前模块能不能用”。用对了，路径变短、引用清晰；用错了，反而埋下隐式耦合和版本冲突的隐患。
明确判断：哪些依赖必须声明为 transitive
只在以下情况才启用传递性：
-
你的 public 方法签名里直接用了对方模块的类或接口，比如返回
JsonNode（来自 Jackson）、接收Logger（来自 java.logging）或参数是ServiceLoader<plugin></plugin>（而Plugin来自你依赖的 SPI 模块） - 你导出的包中，public 类的字段、构造器或方法参数/返回值类型属于被依赖模块，此时调用方不访问那个模块就无法编译通过
- 你封装的是一个轻量级门面（facade），目标是屏蔽底层实现但暴露统一接口，例如工具模块统一包装了日志、配置、序列化能力，并把它们作为组合型 API 对外提供
避免常见误用：不该传的别传
这些情形下应坚持用普通 requires，否则会污染下游环境：
-
仅在 private 或 package-private 方法中使用的依赖，比如内部用
org.apache.commons.lang3.StringUtils做字符串处理，但所有 public API 都不暴露任何 Commons 类型 -
运行时动态加载的实现类，如通过
ServiceLoader.load(Processor.class)加载插件，Processor接口是你自己定义并导出的，实现类由用户提供——此时只需requires，无需transitive -
测试专用依赖（如 JUnit、Mockito）或构建工具插件，绝对不能出现在
module-info.java中，更别说加transitive
配合 exports 实现最小暴露面
requires transitive 必须和 exports 协同设计。它不自动导出包，只开放对被依赖模块的“可读性（readability）”。下游能否真正访问其类型，还取决于那个模块是否 exports 了对应包：
- 假设模块
A写了requires transitive B;，但B只导出b.api，没导出b.impl——那么A的使用者只能用b.api.*，不会意外拿到实现类 - 若
B本身没做任何exports，即使A声明了transitive，下游也无法访问B的任何类型（编译失败） - 所以，真正可控的路径简化，来自“
transitive+exports”的双重收敛：既让下游能读，又只让它读到你允许的部分
实战效果：从三层引用变成直连
没有 transitive 时：
- 应用模块
app→ 依赖工具模块utils→utils依赖logging - 但
app要写日志，还得自己加一行requires java.logging;，否则Logger.getLogger(...)编译不过
用了 transitive 后：
-
utils声明requires transitive java.logging;，且导出封装好的LogService接口（该接口方法返回/接收java.util.logging.Logger） -
app只需requires utils;，就能直接 newLogService()并调用其方法，也能在需要时直接用Logger——路径从“绕过 utils 看 logging”变成“通过 utils 直达 logging” - 维护性提升：日后
utils切换底层日志实现（如换成 SLF4J），只要保持LogService接口不变，app完全无感
