Java module requires transitive 如何影响下游编译

如果 com.example.facade 对 com.example.logging 使用了 requires transitive，那么依赖 facade 的 com.example.app 会获得对 logging 的隐式可读性，编译时可以解析 logging 导出的公开类型。它不会让 logging 的所有包自动公开，也不会替代运行时的模块路径配置；下游若直接使用这个类型，仍要接受 facade 把它作为 API 组成的一部分。

官方文档：https://docs.oracle.com/en/java/javase/26/docs/specs/jls/jls-7.html

先看懂 requires transitive 改变了什么

普通 requires B 只表达“当前模块 A 依赖 B”。如果写成 requires transitive B，依赖 A 的模块也会被视为隐式依赖 B。这个“传递”作用在模块可读性图上，前提仍是 B 导出了相关包；它不是 Java 类路径时代那种把依赖里的全部类无条件塞进下游。

因此要同时看两个边界：模块声明决定谁能读谁，exports 决定哪些包可以被读到。把 exports 漏掉时，requires transitive 也救不了访问错误。

用三模块例子定位下游为什么能直接编译

假设 facade 是稳定门面，logging 是它公开返回值中的类型，而 app 是业务入口。三个模块的声明可以这样表达：

// com.example.facade 的 module-info.java：把 logging 作为公开依赖的一部分
module com.example.facade {
    requires transitive com.example.logging;
    exports com.example.facade.api;
}

// com.example.logging 的 module-info.java：只导出下游确实要使用的包
module com.example.logging {
    exports com.example.logging.api;
}

// com.example.app 的 module-info.java：这里没有直接 requires logging
module com.example.app {
    requires com.example.facade;
}

此时 app 代码若调用 facade，并接收 com.example.logging.api.LogRecord，编译器可以沿着 facade 的传递依赖读取 logging。注意，真正可见的是 com.example.logging.api 中被导出的类型，未导出的内部包依旧不可见。

改成普通 requires 后哪些代码会失败

如果 facade 改成 requires com.example.logging，app 仍只声明 requires com.example.facade，那么 app 不再自动读取 logging。凡是 app 的源码、公开方法签名或泛型参数直接出现 LogRecord 的地方，都应把 logging 视为自己的直接依赖并补上声明。

这里不建议只为“让编译通过”盲目加回传递依赖。若 logging 只是 facade 内部实现，普通 requires 更能隐藏实现细节；若 logging 的类型出现在 facade 的公开 API，传递依赖才有清晰的契约理由。模块升级时，优先检查公开方法的参数、返回值、异常类型和父接口。

编译和运行分别怎么检查

排查时先固定源目录和输出目录，再观察是哪一个边界报错。下面的命令是复现用的检查示意，不把未执行的输出当作运行证据：

# 编译 app、facade 和 logging，模块源目录按模块名分层
javac -d out --module-source-path src -m com.example.app,com.example.facade,com.example.logging

# 运行 app，确保 out 中的模块都位于模块路径
java --module-path out -m com.example.app/com.example.app.Main

# 需要看解析关系时打开模块解析信息
java --show-module-resolution --module-path out -m com.example.app/com.example.app.Main

javac 阶段出现“包不可见”时，先看 exports；出现模块不可读时，再看 app 是否有直接 requires 或 facade 是否使用了 requires transitive。运行阶段的“找不到模块”则优先检查 --module-path，不要用修改 module-info.java 的方式掩盖部署目录错误。

常见问题

requires transitive 会自动导出依赖模块的包吗？

不会。它只扩展模块之间的隐式依赖，包是否可访问仍由目标模块的 exports 决定。

下游没有直接使用底层类型，还需要 transitive 吗？

通常不需要。若底层模块只是实现细节，普通 requires 更能保持 API 边界稳定。

为什么 IDE 能补全，javac 却报模块不可读？

IDE 可能仍按类路径或缓存索引工作；用与构建系统一致的 --module-source-path、--module-path 和模块列表重新编译，才能得到可靠结论。

判断 requires transitive 的关键不是“下游现在能不能编译”，而是底层模块是否已经成为中间模块公开 API 的一部分。先看类型是否跨模块边界，再决定传递依赖，最后用编译期和运行期两套参数分别复查。