Java模块化系统（JPMS）的核心目标是实现强封装和显式依赖，通过module-info.java在编译期确立“我用谁、我给谁用、我允许谁碰我内部”的契约，解决classpath的盲搜缺陷；exports用于编译期和运行期开放API，opens仅限运行期反射访问；自动模块虽可临时兼容非模块化库，但破坏封装且不稳定，应推动升级或打补丁。
Java模块化系统（JPMS）的核心目标是实现强封装和显式依赖——不是为了“拆代码”，而是让每个模块清楚地回答三个问题：我用谁？我给谁用？我允许谁在运行时碰我内部？
为什么必须用 module-info.java 声明依赖，而不是继续靠 classpath？
类路径（classpath）本质是“盲搜”：JVM把所有 JAR 扫一遍，直到找到某个类。这导致：
- 运行时才暴露
NoClassDefFoundError或IllegalAccessError，编译期完全不报错 - 任意模块都能反射访问任意类（比如
sun.misc.Unsafe），破坏设计边界 - 无法判断哪些 JAR 真正被用到，打包臃肿、启动慢、jlink 无法定制最小 JRE
module-info.java 把这些模糊关系变成编译期契约。例如：requires java.sql; 表示“我明确需要 JDBC API”，而不仅是“我碰巧用了 Connection 类”。
exports 和 opens 的区别到底在哪？
这是最常混淆的两个指令，关键看访问时机和方式：
立即学习“Java免费学习笔记（深入）”；
-
exports com.example.api;：编译期 + 运行期都开放——其他模块能正常 import、new、调用方法 -
opens com.example.model;：仅运行期开放——只允许反射访问（如 Spring 创建实体类实例、Hibernate 绑定字段），编译期仍不可见
如果框架报 InaccessibleObjectException，优先加 opens；如果业务类要被其他模块直接使用，才用 exports。滥用 exports 等于把内部包全暴露，强封装就失效了。
第三方库没模块化怎么办？自动模块（Automatic Module）是救星还是陷阱？
把未声明 module-info.java 的 JAR 放进模块路径（--module-path），JVM 会把它转为“自动模块”，名字通常来自 JAR 文件名（如 guava-32.1.3-jre.jar → 模块名 guava）。
- ✅ 优点：能被
requires引用，模块图可构建 - ❌ 缺点：它自动导出所有包，等于没有封装；且名字不稳定（改 JAR 名就失效）；无法使用
transitive或uses/provides
实践中建议：--add-modules 临时启用，但长期应推动升级或用 moditect 插件打补丁，别把它当正式模块对待。
模块化最难的从来不是写 module-info.java，而是识别哪些包该导出、哪些该开放、哪些该彻底隐藏——这要求你真正理解代码的职责边界，而不是机械地把旧项目目录一拆了之。
