Java模块化是全链路依赖与封装机制，强制声明模块名、依赖和导出，module-info.java为必需身份证；未声明则视为传统classpath代码，需严格遵循语法与路径规则。
Java模块化系统不是“加个module-info.java就完事”的语法糖，而是一套从编译、运行到部署全链路重构的依赖与封装机制——它强制你回答三个问题：这个模块叫什么？它用谁？它让谁用它？
module-info.java 不是可选配置，而是模块的身份证
没有module-info.java的项目，哪怕目录结构再规整，JVM也只当它是传统类路径（classpath）下的普通代码，享受不到模块系统的任何保护或优化。
- 它必须放在模块根目录，且文件名、大小写、内容格式（如
module com.example.app { ... }）严格匹配，否则编译报错error: module not found -
requires java.base可以省略（隐式依赖），但requires com.example.utils这类自定义模块必须显式声明，否则编译期直接失败，而不是等到Class.forName时才抛NoClassDefFoundError - 导出包不等于“public类可用”：
exports com.example.api后，外部模块仍需requires该模块才能访问；没exports的包，哪怕全是public类，其他模块也完全看不见
module com.example.storage {
requires java.sql;
requires transitive com.example.core; // 子模块自动继承此依赖
exports com.example.storage.api;
opens com.example.storage.internal to com.example.test; // 仅测试模块可反射
}模块路径（--module-path）和类路径（-cp）不能混用，但能共存
很多人以为“用了模块就得抛弃-cp”，其实不是。JVM允许两者并存，但行为截然不同：
- 放在
--module-path里的JAR必须是命名模块（含module-info.class）或自动模块（无module-info的JAR会被转为自动模块，所有包默认导出，模块名通常来自JAR名） - 放在
-cp里的JAR永远处于“未模块化”状态，对模块内代码不可见——除非你把它也加进--module-path，或者用--add-modules强行拉进来 - 常见错误：
javac -cp lib/utils.jar --module-path mods/ ...→utils.jar在类路径里，模块代码根本看不到它；正确做法是把utils.jar也放进--module-path，让它成为自动模块
反射访问失败？大概率是忘了opens或open修饰符
Spring、Hibernate、Jackson这些框架重度依赖反射，而模块系统默认禁止跨模块反射访问私有成员——这不是bug，是设计。
立即学习“Java免费学习笔记（深入）”；
-
opens com.example.model：运行时开放整个包供任意模块反射（宽松，慎用） -
opens com.example.model to com.fasterxml.jackson.databind：只允许指定模块反射（推荐） -
open module com.example.app（在module-info.java中）：整个模块开放反射，等价于所有包都opens，仅用于极简原型，生产环境避免 - 如果用
setAccessible(true)仍抛InaccessibleObjectException，99%是因为目标类所在包没被opens，或目标模块没被requires
jdeps 和 jlink 是模块化落地的两个真实拐点
光写module-info.java只是开始，验证和交付才是关键。
-
jdeps --summary app.jar：看你的JAR实际依赖哪些模块，识别出意外引入的“幽灵依赖”（比如某个工具类偷偷用了java.desktop，但你本意只想用java.base） -
jlink --module-path mods/ --add-modules com.example.app --output myruntime：生成最小化JRE，里面只含真正需要的模块；如果app没声明requires java.desktop，那myruntime里就不会有AWT/Swing相关类——这点对容器部署尤其重要 - 注意：
jlink不支持自动模块，所有依赖必须是命名模块或JDK系统模块；否则会报error: module not found
模块化真正的复杂点不在语法，而在思维转换：它要求你把“能跑”变成“明确知道为什么能跑”。一个exports漏写、一个opens少配、一条requires没加，都会在编译期或启动时报错——这看似麻烦，实则是把原本藏在运行时的脆弱性，提前暴露给你。
