JDK 9模块化系统以模块路径替代类路径，通过module-info.class构建依赖图实现结构化加载；它解决类路径三大缺陷：运行时才暴露依赖缺失、封装失效、版本冲突难控，并强制显式声明依赖与导出，提升安全、可维护性及启动性能。
JDK 9 的模块化系统（Project Jigsaw）不是简单升级类路径，而是用“结构化契约”替代“扁平化搜索”，从根本上重构了 Java 的依赖发现与加载逻辑。
类路径机制的三大硬伤被直接击中
传统 Classpath 把所有 JAR 当作一个无序大池子，JVM 按顺序扫描加载——这带来不可控的隐性风险：
-
依赖不可见：编译时不报错，运行到某行才抛
NoClassDefFoundError，问题延迟暴露 -
封装形同虚设：哪怕类是
private或包私有，反射仍可随意访问内部 API - 冲突无法预防：两个版本的同一工具类共存时，谁先出现在 classpath 就被加载，结果随机且难复现
模块路径（--module-path）成为新主干
模块系统不再靠“搜”，而是靠“查图”：
- JVM 启动时就解析
module-info.class，构建完整的模块依赖图 - 类加载前先查它属于哪个模块；若属于
java.base，直接交由 BootstrapClassLoader，跳过父委派链 -
--module-path是模块系统的入口，-cp（即 classpath）退为兼容通道，仅用于匿名模块
类加载行为发生结构性偏移
不是抛弃双亲委派，而是把“委派决策权”从加载器层级转移到模块归属：
- AppClassLoader 不再盲目向上委托，而是先查目标类是否在已知模块中
- 具名模块只能访问
requires明确声明的模块，连 JDK 自带模块也要显式依赖 - 来自 classpath 的类自动归入匿名模块，它能看到一切，但其他模块看不到它
开发与运维方式同步转向
模块化倒逼工程实践升级：
- 必须写
module-info.java声明导出包、依赖模块、开放反射包（opens） - 用
jlink可定制最小运行镜像，剔除未使用的 JDK 模块，部署体积大幅下降 - 反射访问受限类时，若目标模块未
opens对应包，会直接抛IllegalAccessException，而非静默失败
