Java 模块系统中 opens 和 exports 有什么区别

在 Java 模块系统里，exports 和 opens 都是在模块边界上“放行”一个包，但放行的对象不同：exports 解决其他可读模块对公开类型和成员的普通访问，opens 解决运行时反射，范围可以深入到非公开类型和成员。遇到依赖编译失败、IllegalAccessException 或框架绑定不到字段时，先按这个边界判断，通常就不会把两个关键字混用。

记忆方法：代码要直接调用公开 API，用 exports；框架要在运行时反射私有字段或构造器，用 opens。它们可以分别用 to 限定目标模块。

先把两个关键字放在同一张模块声明里

假设模块 orders.core 有一组稳定 API，还有只给序列化框架使用的模型包：

module orders.core {
    // 对外提供可编译、可直接调用的公开 API
    exports com.example.orders.api;

    // 只允许指定框架对模型做运行时深反射
    opens com.example.orders.model to framework.core;
}

exports 的对象是包的公开 API。目标模块必须能读到 orders.core，才能在编译或普通链接时使用导出的公开类型；它不会因此获得任意私有字段的反射写入能力。

opens 的对象是反射访问。打开后，指定目标模块可以检查包内类型及其成员，包括非公开成员，前提仍是反射 API 和运行时访问规则允许这样做。它不等于把包变成可在源码中直接导入的 API。

用访问场景判断应该写 exports 还是 opens

可以把问题拆成三个检查：

一个常见误区是：看到框架提示“包未导出”就直接加 opens。如果框架只是调用包中的公开类型，应该先确认模块声明里是否有 exports，以及调用方是否声明了 requires。相反，若错误发生在 setAccessible、构造器绑定或字段注入阶段，问题更接近 opens。

用限定开放收窄模块边界

无条件的 exports com.example.orders.api; 会向所有能读取该模块的模块开放普通 API；限定形式则只给列出的模块：

module orders.core {
    // 只有报告模块能在源码中使用这个公开包
    exports com.example.orders.report to report.app;

    // 只有序列化框架能对模型包做深反射
    opens com.example.orders.model to framework.core;
}

如果想让模块中的所有包都对反射开放，可以声明 open module orders.core { ... }，但它不是普通 API 的替代品：开放模块仍然需要用 exports 决定源码层面的包可见性。生产项目通常优先使用包级、目标明确的 opens，这样更容易发现哪个框架真正需要内部访问。

命令行补丁只解决启动边界

迁移旧框架时，可以暂时用启动参数补足模块描述符：

# 允许旧客户端访问未导出的公开类型；这里只是临时兼容补丁
java --add-exports orders.core/com.example.orders.internal=legacy.app \
     --add-opens orders.core/com.example.orders.model=framework.core \
     -m orders.app/com.example.orders.Main

--add-exports 对应普通公开类型访问，--add-opens 对应运行时深反射；目标若是类路径上的未命名模块，可写成 ALL-UNNAMED。两者都不是把权限永久写回 module-info.java，因此要把参数放进实际启动脚本并记录回收计划。若问题发生在编译阶段，javac 也有对应的 --add-exports 选项，但它不能替代运行时的反射开放。

最后可按“源码能否直接引用”“是否只需要公开成员”“是否要触达非公开成员”“目标是否应收窄”四个问题复查。源码依赖选 exports，深反射选 opens，能限定目标就不要无条件开放。

相关问题

opens 会自动让其他模块可以 import 这个包吗？

不会。opens 解决的是运行时反射边界，源码层面的普通访问仍要看 exports 和模块读取关系。

exports 能让框架访问 private 字段吗？

不能把它当作深反射授权。需要访问非公开成员时，应检查目标模块和包是否通过 opens 获得了对应开放范围。