requires transitive是Java 9模块系统中用于声明传递性依赖的关键字：当模块A requires transitive 模块B时，所有依赖A的模块（如C）将自动获得对B的读取权限，无需显式声明requires B，从而简化公共API模块（如通用工具、DTO、上下文类）的依赖管理。
requires transitive 是 Java 9 引入的模块系统（JPMS）中的关键字，用于声明模块依赖的传递性。它本身并不直接作用于“分布式系统”或“公共变量模块”的运行时行为，也不参与网络通信、数据分片、服务发现等分布式逻辑。但它在模块化构建与依赖管理层面，能显著简化多模块协作中公共能力（如通用配置、序列化工具、监控上下文、TraceID 工具类等）的引入流程——尤其当这些能力被封装在独立的“基础模块”中时。
以下从实际场景出发，说明如何用 requires transitive 简化公共模块的使用：
公共变量/能力通常指什么
在分布式系统中，这类模块常包含：
- 跨服务传递的上下文对象（如
TraceContext、TenantContext） - 统一的异常定义（
BizException、ErrorCode枚举） - 通用 DTO 或序列化适配器（如
JsonUtils、ProtobufConverter） - 共享的配置属性类（如
CommonConfig、RetryPolicy）
它们不承载业务逻辑，但被多个业务模块（如 order-service、user-service）共同依赖。
传统非传递依赖的问题
假设你有三个模块：
-
common-core：定义TraceId工具类和ApiResponse<T> -
auth-service：依赖common-core，并导出自己的 API -
payment-service：依赖auth-service，也需要用ApiResponse
若 auth-service 的 module-info.java 写成：
module auth.service {
requires common.core; // ❌ 不加 transitive
}则 payment-service 编译时会报错：cannot find symbol ApiResponse
——因为 auth-service 没把 common-core 的 API “透传”给下游。
开发者只能手动在 payment-service 中再写一行 requires common.core;，导致：
- 每个新服务都要重复声明相同的基础依赖
- 升级
common-core版本时，需批量修改所有模块的module-info - 依赖关系扁平、隐式，难以维护
使用 requires transitive 的正确方式
在 auth-service（或任何封装了公共能力的中间模块）中声明：
module auth.service {
requires transitive common.core; // ✅ 传递依赖
}这样，只要 payment-service 声明 requires auth.service;，它就能自动访问 common.core 中的 public 类型，无需额外 requires common.core。
效果等价于：
// payment-service 自动获得： // requires common.core; ← 隐式生效 // requires auth.service;
实际建议与注意事项
-
只对真正“能力透出型”模块使用：如
common-core、infra-tracing、shared-dto。业务模块（如order-service）不应requires transitive其他业务模块。 -
避免长链传递：
A → requires transitive B → requires transitive C是允许的，但会让依赖图变模糊。建议控制在 1～2 层内。 -
配合
exports使用：common-core必须显式exports com.example.common.trace;，否则即使传递了依赖，包内类仍不可见。 - 不解决运行时问题：它不影响类加载、序列化兼容性或跨 JVM 变量共享。分布式环境中的“公共变量”仍需靠 RPC 上下文透传、线程局部变量（MDC）、或外部存储（如 Redis）实现。
-
构建工具需支持 JPMS：Maven 要启用
maven-compiler-plugin的 module 模式，并确保 JDK ≥ 9。
本质上，requires transitive 简化的不是分布式系统的运行逻辑，而是多人协作开发中模块依赖的声明成本和一致性风险。它让“谁提供能力、谁负责透出”更清晰，是微服务模块化演进中值得落地的工程实践细节。
