本文详解如何在jpms（java platform module system）下合理设计基于serviceloader的模块化架构，重点解决api模块导出策略的选择问题：为何应使用无限制exports而非exports to，以及这种设计如何兼顾扩展性与封装性。
本文详解如何在jpms（java platform module system）下合理设计基于serviceloader的模块化架构，重点解决api模块导出策略的选择问题：为何应使用无限制exports而非exports to，以及这种设计如何兼顾扩展性与封装性。
在构建可扩展的模块化Java应用时，采用基于接口定义 + ServiceLoader发现机制（SPI） 的逻辑分层架构是一种被广泛验证的最佳实践。其核心思想是将契约（API）与实现（Implementation）彻底解耦，并通过模块系统进行边界管控。典型结构如下：
- app.view 模块：定义 app.view.View 接口，声明UI抽象能力；
- app.engine 模块：定义 app.engine.Engine 接口，封装核心业务逻辑契约；
- app 主模块：声明 requires app.view; requires app.engine; uses app.view.View; uses app.engine.Engine;，负责组合服务、触发SPI加载并驱动运行。
关键设计决策在于：app.view 和 app.engine 模块是否应使用 exports 还是 exports to？
✅ 正确做法是：无限制导出接口包
// module-info.java of app.view
module app.view {
exports app.view; // ✅ 允许任意第三方模块提供实现
}
❌ 不推荐使用 exports to（如 exports app.view to app），原因如下：
- exports to 会将接口可见性严格限定于指定模块列表，导致 第三方扩展模块无法编译通过——因为它们无法访问 View 或 Engine 类型，更无法实现这些接口；
- 这违背了SPI“开放扩展”的本质目标：服务提供者（Provider）模块需能独立编译、部署和替换，而不依赖主应用模块的显式授权；
- JPMS的模块可访问性遵循显式依赖原则：即使 app.view 使用 exports，其他无关模块（如 com.example.logging）默认不可见其内容，除非该模块主动声明 requires app.view。模块系统不会自动传递依赖（即无 requires transitive 时，依赖不具传染性）。
? 补充说明：requires transitive 才会导致“传递可见性”。例如若 app 声明 requires transitive app.view，则依赖 app 的模块才可能间接看到 app.view ——但本场景中 app 仅需 uses，绝不需要 transitive。
因此，“exports 导致接口被所有模块随意访问”的担忧是误解。真正的封装控制权始终在调用方模块自身：它必须主动 requires 才能访问，而服务提供方只需实现接口并注册 META-INF/services/ 文件即可完成插拔。
? 实践建议：
- API模块（如 app.view, app.engine）应仅包含接口、注解、DTO等契约类型，禁止包含具体实现或外部依赖；
- 实现模块（如 app.engine.impl.postgresql）需在 module-info.java 中声明 provides app.engine.Engine with com.example.pg.PGEngine;；
- 主模块 app 的 module-info.java 必须包含对应 uses 子句，否则 ServiceLoader.load() 将无法识别服务类型；
- 构建时确保所有模块（含SPI实现）均置于模块路径（--module-path），而非类路径。
综上，面向开放扩展的模块化架构，无限制 exports 是SPI模式的必要前提。它不是设计缺陷，而是模块系统赋予开发者“按需可见”的精准控制能力——既保障了API的广泛可实现性，又未牺牲任何封装安全性。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
