requires transitive用于让下游模块自动继承指定依赖，仅当api签名暴露第三方类型时才应使用，需配合exports精确控制可见包，并通过构建工具统一锁定版本以避免冲突。
直接用 requires transitive 能让公共变量库的依赖“自动穿透”到下游微服务，省去每个服务重复声明日志、配置、序列化等基础模块的麻烦。关键不在加不加，而在加得准、加得少、加得有依据。
只对真正暴露在 API 签名里的依赖使用 transitive
公共变量库（如 common-consts 或 shared-models）如果导出了一个返回 org.slf4j.Logger 的方法，或字段类型是 com.fasterxml.jackson.databind.JsonNode，那它就必须把对应模块标记为 transitive——否则调用方编译会失败。
- ✅ 正确：接口中用了第三方类型 →
requires transitive slf4j.api - ❌ 错误：仅内部工具类用
commons-lang3做字符串处理 → 用普通requires即可 - ⚠️ 风险：把内部 JSON 序列化工具类的实现依赖（如
jackson-core）也设为 transitive，会把不该暴露的底层包泄漏出去
分层暴露，避免“全链透传”
大型微服务群通常有清晰分层：基础常量库 → 通用模型库 → 业务网关库。不要让最底层的 common-consts 直接 requires transitive java.desktop，而应由上层模型库按需承接。
- 基础库（
shared-consts）：只导出String、int等 JDK 原生类型，无需任何transitive - 模型库（
shared-dto）：若含@JsonProperty注解或LocalDateTime字段，才requires transitive jackson.annotations和java.time - 网关库（
api-gateway-common）：整合前两者，并统一透传关键依赖，成为下游服务唯一需requires的入口模块
配合 exports 精确控制可见边界
requires transitive 解决的是“谁能用”，exports 解决的是“能用什么”。二者必须协同，否则会出现“能访问模块但看不到类”的矛盾。
- 即使声明了
requires transitive jackson.databind，也必须exports com.example.shared.dto，且该包内类的 public 方法不能引用未导出的子包（如com.fasterxml.jackson.databind.node） - 建议将 DTO 类集中放在独立包（如
com.example.shared.dto），并在module-info.java中只导出该包，不导出internal或util子包 - 构建时开启
--check-module-dependencies可提前发现导出包中意外引用了未透传模块的类型
用版本锚点锁定传递依赖的一致性
微服务群中多个服务可能间接通过不同路径引入同一模块（如 A→B→C 和 A→D→C）。若 B 和 D 对 C 使用了不同版本的 requires transitive，运行时可能因模块解析冲突失败。
- 在统一的父 POM 或 Gradle Version Catalog 中，为所有
transitive依赖指定强制版本，例如：logging-api = "2.0.12" - 公共变量库的
module-info.java中只写模块名，不写版本（Java 模块系统本身不支持版本号），版本由构建工具统一注入 - 上线前执行
jdeps --multi-release 21 --print-module-deps检查各服务实际加载的模块图，确认关键依赖（如日志、JSON）是否收敛到同一版本
