Java模块化通过module-info.java定义运行时可验证、编译期可约束的结构契约，核心在于显式声明可见性（exports/opens）、依赖（requires）、服务（uses/provides）和唯一模块名，实现强封装、可验证依赖与服务解耦。
Java模块化不是简单地把代码按文件夹拆开，而是通过module-info.java建立一套运行时可验证、编译期可约束的结构契约。它的核心不是“怎么分”，而是“谁可见、谁依赖、谁负责”。
模块是比包更严格的封装边界
包（package）只控制类名空间和访问修饰符；模块则强制要求：未exports的包，即使声明为public，其他模块也完全无法访问——连反射都不行（除非显式opens）。这意味着：
- 内部工具类、配置类、DTO实现类默认彻底隐藏
- API演进只需维护
exports列表，不担心被意外调用 - IDE和编译器能即时发现非法跨模块调用，提前拦截错误
依赖必须显式声明且可验证
JPMS废除了隐式类路径（classpath）信任机制。每个requires语句都意味着：
- 编译时检查目标模块是否存在、版本是否兼容
- 运行
时JVM加载该模块并验证其导出包是否满足当前需求
- 禁止循环依赖（A→B→A），倒逼接口抽象与分层设计
例如：requires transitive logging.api表示：不仅本模块用它，所有依赖本模块的模块也能“透传”使用它，避免下游重复声明。
服务解耦靠uses与provides驱动
模块之间不直接new实现类，而是通过标准服务接口协作：
- 一个模块用
uses com.example.spi.PaymentService声明自己需要支付能力 - 另一个模块用
provides com.example.spi.PaymentService with com.alipay.impl.AlipayService声明自己提供该能力 - 运行时由JVM自动绑定，无需硬编码或Spring配置
这种机制天然支持插件化、灰度替换和多厂商适配。
模块名即身份，不可重复也不可省略
模块名不是目录名，也不是Maven artifactId，而是全局唯一标识符，遵循反向DNS规范（如com.example.order）。它参与：
- JVM模块图构建与冲突检测
- 自定义运行时镜像（jlink）的裁剪依据
- 模块化JDK中100+系统模块的组织基础
一旦命名，就成为模块契约的一部分，改名等于发布新模块。
