Java 9模块系统（JPMS）不支持跨模块直接传递对象或运行时契约验证，module-info.java仅声明静态可见性契约；对象传递需通过ServiceLoader等运行时机制实现，契约验证需结合接口、注解与显式校验。
Java 9 引入的模块系统（JPMS）本身不支持跨模块直接传递对象变量或运行时契约验证。module-info.java 的作用是声明模块的依赖、导出、开放等静态元数据，它在编译期和启动期生效，不提供对象共享机制或动态契约检查能力。真正实现“跨模块对象传递”和“契约验证”，需结合模块声明 + 运行时协作设计。
module-info.java 只负责“可见性契约”，不负责“对象传递”
模块系统通过 exports 和 opens 控制包级访问权限，这是编译/加载阶段的静态契约：
-
exports com.example.api;：允许其他模块使用该包下的 public 类型（如接口、DTO） -
exports com.example.api to com.example.service;：精准导出，仅限指定模块可见 -
opens com.example.config to java.desktop;：仅对反射开放（如 JavaFX 序列化），不用于常规对象传递
⚠️ 注意：即使导出成功，模块 A 中 new 出的对象仍需通过明确的 API（如接口、工厂、服务）被模块 B 获取——module-info 本身不做实例创建或传递。
用服务（ServiceLoader）实现松耦合的对象契约与传递
这是 JPMS 推荐的跨模块协作方式：定义接口在 API 模块，实现类在服务模块，通过 provides/uses 声明契约，运行时按需加载。
- API 模块（
com.example.api）中定义接口：public interface DataProcessor { DataResult process(DataInput input); } - API 模块的
module-info.java：module com.example.api { exports com.example.api; } - 服务模块（
com.example.impl）实现接口，并声明：module com.example.impl { requires com.example.api; provides com.example.api.DataProcessor with com.example.impl.DefaultProcessor; } - 调用方模块（
com.example.app）使用：ServiceLoader.load(DataProcessor.class).findFirst()→ 得到具体实例，完成对象传递
✅ 契约由接口定义（编译期检查），对象由 ServiceLoader 实例化（运行时解耦），module-info 确保模块间依赖合法。
用模块层契约 + 运行时校验补足“强契约验证”
若需验证对象内容是否符合业务规则（如非空、范围、格式），module-info 无法胜任，但可配合以下方式：
- 在 API 模块定义带 JSR-303 注解的 DTO（如
@NotNull,@Min(1)），并导出校验逻辑工具类 - 服务模块接收对象后，显式调用
Validator.validate(obj)；失败则抛出ConstraintViolationException - 模块声明中确保校验库（如 Hibernate Validator）被正确 require 和 open（若需反射访问私有字段）
例如：module com.example.api { requires java.validation; exports com.example.dto; }
此时契约 = 接口 + 注解 + 显式校验调用，module-info 仅保障校验能力可用。
避免常见误区：不要试图绕过模块边界
以下做法违背 JPMS 设计初衷，易导致不可预测行为：
- 用
--add-opens打开所有包给所有模块（破坏封装） - 在 module-info 中
opens整个包只为传对象（应只开放必要反射场景） - 让模块 B 直接 new 模块 A 的实现类（违反封装，且模块 A 未导出实现包）
- 把 DTO 放在主模块里，其他模块都 require 主模块（形成中心化依赖，失去模块自治）
正确的思路是：模块只暴露契约（接口/注解/工厂方法），隐藏实现；对象传递走定义好的通道（服务、工厂、回调），module-info 是这个通道的“路标”而非“运输车”。
