exports是落实接口分离原则的关键声明手段：它通过仅导出接口包、隐藏实现包，配合调用方只依赖接口的实践，实现编译期隔离与契约约束。
exports 指令本身不“实现”接口分离，而是**落实接口分离原则的关键声明手段**：它明确告诉模块系统——哪些包（即哪些类型定义）是对外公开的契约，哪些必须隐藏。真正完成接口与实现隔离的，是“导出接口包 + 不导出实现包 + 调用方只依赖接口”的组合实践。
一、明确划分接口包与实现包
在源码结构上，强制将抽象定义（接口、抽象类、DTO）和具体实现（服务类、工具类、DAO）放在不同包中：
- 接口包如 com.example.user.api：存放
UserService接口、User数据类等，设计目标是稳定、小而精 - 实现包如 com.example.user.internal 或 com.example.user.impl：存放
JdbcUserService、CacheDecorator等，可随时重构或替换 - 模块描述文件
module-info.java中只导出接口包：module com.example.user { exports com.example.user.api; } - 实现包不声明 exports，天然被封装，其他模块编译期就无法 import 或 new 实例
二、用 exports 锁定调用方的可见范围
exports 不是“让别人能用”，而是“只让别人用你允许的部分”。一旦导出，其他模块只能通过该包访问你的能力，无法穿透到内部细节：
- 若误将
com.example.user.impl也 exports，调用方可能直接 newJdbcUserService()，导致强耦合、无法热替换 - 若未导出
com.example.user.api，哪怕接口写得再规范，其他模块连import都会报错——这反而成了最硬的隔离防线 - 配合
requires声明依赖时，也只写requires com.example.user.api;，而非整个模块名
三、变量细节必须彻底隐藏在实现包内
接口分离不只是类的隔离，更是状态与行为的收敛。所有可变状态、缓存、连接池、配置对象，都不得暴露在导出包中：
- 导出的接口方法返回值应为不可变对象（如
Record、ImmutableList）或只读视图（如Collections.unmodifiableList()） - 避免在接口中暴露
Map<string object></string>这类泛型容器——它等于开放了内部结构；改用明确字段的 DTO 类 - 实现类中的私有字段（如
private final Cache<long user> userCache;</long>）完全不出现在导出包里，调用方既看不到，也无法访问 - 工厂类或 ServiceLoader 的 SPI 入口，也应定义在接口包中（如
UserServiceProvider），但其实现类仍放在 impl 包里
四、验证隔离是否生效的三个检查点
每次修改模块后，快速确认接口分离是否真正落地：
-
编译检查：在另一个模块中尝试
import com.example.user.impl.*;—— 应该编译失败 -
运行时检查：用
ModuleLayer或Module.getPackages()查看该模块实际导出的包列表，确认只有api存在 -
依赖图检查：用
jdeps --module-path ... --list-deps com.example.user，确保下游模块的依赖路径止步于api，未穿透到impl
