requires transitive 通过让被依赖模块自动透传给下游使用者，减少重复 requires 声明，需结合 API 设计、分层与边界系统落地，仅对公共 API 涉及的依赖启用，避免内部依赖污染。
用 requires transitive 减少重复配置，核心是让“被依赖的模块自动透传给使用者”，从而压缩下游模块的 requires 声明数量，理清大型项目中错综复杂的依赖网。这不是加个关键字就完事，而是要结合 API 设计、模块分层和依赖边界来系统性落地。
明确哪些依赖该标记为 transitive
只对真正暴露在公共 API 签名里的依赖启用传递性。常见情况包括：
- 接口方法的参数、返回值、异常类型来自第三方模块（如
com.fasterxml.jackson.core.JsonNode） - 导出的包中公开了封装了某框架能力的类（如日志门面
LoggerFactory来自java.logging） - 你提供的 SPI 接口依赖了某个标准模块（如
java.sql中的Driver），且要求实现方直接操作它 - 避免把仅用于内部工具类的依赖（如某个 JSON 解析器只在私有方法里调用）标为 transitive，否则会污染整个依赖图
分层设计时固定 transitive 的锚点模块
在典型的三层模块结构中（API 层 → 实现层 → 基础设施层），transitive 应集中在 API 层模块：
-
API 模块（如
com.example.api）：导出接口，requires transitive java.logging、requires transitive com.fasterxml.jackson.core -
Impl 模块（如
com.example.impl）：只 requires com.example.api 和 requires org.slf4j（内部实现用，不透传） -
App 模块（如
com.example.app）：只需 requires com.example.impl，即可直接 newLoggerFactory、解析JsonNode，无需再写一遍requires java.logging或requires com.fasterxml.jackson.core
用 module-info.java 验证依赖可见性
编译期就能发现 transitive 是否生效。例如，在 App 模块中尝试写：
import java.util.logging.Logger; // 若未声明 requires java.logging，但 API 模块用了 transitive，则此处不报错
如果报错 error: package java.util.logging is not visible，说明 transitive 没起作用，检查两点：
- 上游模块是否真的用了
requires transitive java.logging（不是普通requires） - 该模块是否导出了使用
Logger的包（exports不影响 transitive，但若没导出任何包，下游其实也用不到它的 API）
警惕 transitive 带来的隐式耦合风险
过度使用会让依赖网变得“看不见但跑不掉”。建议配合以下做法控制影响：
- 每个 transitive 依赖都加注释，说明为什么必须透传（例：
// required in public return type ServiceResponse<t></t>） - 定期用
jdeps --multi-release 17 --print-module-deps扫描项目，生成依赖图，识别被意外透传的模块 - 对基础库（如日志、JSON）做统一门面模块，集中管理 transitive，而不是在每个业务模块里各自声明
