要用好 requires transitive，核心是判断下游是否需看见该依赖：若 public API 签名（方法返回值、参数、异常等）暴露了其他模块类型，则必须用 requires transitive；否则仅内部使用时用普通 requires。
要用好 requires transitive，核心不是“加不加”，而是“该不该让下游看到这个依赖”。它本质是模块契约的一部分：你暴露的 API 类型是否把另一个模块的类型“带出去”了。一旦带出去，就必须传递；没带出去，就该藏住。
看方法签名，决定是否用 transitive
这是最直接、最可靠的判断依据。只要你的 public 方法、接口、异常类或返回值/参数中出现了其他模块的类型，那个模块就必须用 requires transitive 声明。
-
要传递：比如你定义了一个日志门面接口
LoggerFacade，它的create(String name)方法返回java.util.logging.Logger——这个返回类型来自java.logging模块，调用方必须能访问它，所以必须requires transitive java.logging -
不传递：如果你只在私有工具方法里用
java.logging打印调试日志，所有日志调用都封装在内部，API 签名里完全不出现它的任何类型，那就用普通requires即可
分层暴露，避免依赖污染
大型微服务中常见“基础库 → 通用组件 → 业务模块”的三层结构。如果通用组件（如 common-utils）盲目对所有依赖加 transitive，业务模块就会被拖进一堆用不到的依赖里，编译慢、启动慢、版本冲突风险高。
- 只对真正构成你模块“对外契约”的依赖使用
transitive，比如 JSON 序列化库（若你提供了toJson(T)方法且返回com.fasterxml.jackson.databind.JsonNode） - 对仅用于内部实现的依赖（如测试辅助类、配置解析器、缓存清理线程），一律用普通
requires - 可考虑拆分子模块：把纯工具类（
utils-core）和带公共 API 的扩展（utils-json-api）分开，后者才声明requires transitive jackson-core
解决深层变量引用的可见性问题
所谓“深层变量引用”，典型场景是：A 模块调用 B 模块的方法，B 返回一个对象，该对象的字段类型来自 C 模块（比如 User 类有个 LocalDateTime birthday 字段）。这时 A 能否访问 LocalDateTime？答案取决于 B 是否把 java.time 传递给了 A。
- 如果 B 的 module-info.java 中写了
requires transitive java.time，A 就可以直接读取user.getBirthday()并调用其方法，无需自己声明依赖 - 如果没写
transitive，A 编译时会报错：error: cannot access LocalDateTime，因为虽然 B 能用，但 A 看不见java.time - 注意：即使 B 的
User类只是“持有”LocalDateTime字段（没在方法签名中暴露），只要 A 代码里直接访问该字段（而非通过 B 提供的 getter），A 仍需自己依赖java.time——transitive解决的是“API 层级的类型可见性”，不是“反射或字段直读”的可见性
实战检查清单
上线前快速过一遍，能避开 90% 的传递性误用：
- 打开你的
module-info.java，逐行检查每个requires transitive后面的模块名 - 反向查：这个模块的类型，是否出现在你
exports包内任意 public 类、接口、枚举、注解的 方法签名、泛型边界、异常声明、继承关系 中？ - 如果答案是否定的，立刻删掉
transitive，改用普通requires - 如果模块同时导出多个包，确认
transitive依赖只服务于那些真正需要它的包，而不是为整个模块“一刀切”
