模块化系统通过模块路径替代类路径，以显式requires声明、包导出控制、模块图验证和jlink定制镜像，从源头杜绝类重复加载与静态变量异常。
模块化系统本身不解决“类路径重复导致的变量加载异常”——因为一旦启用模块系统（JPMS），类路径（Classpath）就不再主导类加载逻辑，取而代之的是模块路径（Module Path）。所谓“类路径重复”引发的问题（如同名类被不同 JAR 加载、静态变量多次初始化、ClassLoader 冲突等），本质是传统 Classpath 机制下无边界、无声明、无隔离的副作用。模块系统通过显式依赖 + 强封装 + 模块图验证，从源头规避这类异常，而非在类路径上打补丁。
明确模块边界，阻断隐式类可见性
在 module-info.java 中，每个 requires 都是精确声明：只允许当前模块读取目标模块中已导出（exports）的包。未导出的包即使存在，也无法被访问——这直接切断了因 JAR 并列放置导致的“意外类泄露”。
- 例如，两个库 A.jar 和 B.jar 都含
com.example.util.Config类，若未模块化，JVM 可能按 classpath 顺序加载其中一个，造成行为不一致；但若 A 和 B 分别是模块mod.a和mod.b，且均未导出com.example.util，则任何第三方模块都无法访问该类，更不会发生冲突。 - 即使某模块导出了该包，也仅限于
requires它的模块可读——不存在“全 classpath 可见”的混沌状态。
用 requires 替代 classpath 并置，消除加载顺序依赖
传统 classpath 中，-cp lib/a.jar:lib/b.jar 的顺序决定同名类优先级；而模块路径下，--module-path mods/a@1.0/mods/b@2.0 不影响类解析顺序——模块图在编译和启动时就被验证，同一类名若出现在两个可读模块中，JVM 直接报错：java.lang.module.ResolutionException，拒绝启动。这不是异常兜底，而是编译期/启动期的强制校验。
- 这意味着：你不可能在运行时才发现“为什么 Config.INSTANCE 是 null”——如果两个模块都试图提供同一个服务接口实现，模块系统会在
java --module-path ... --module xxx阶段就失败，提示冲突。 - 所有静态变量初始化都严格限定在模块自己的
ClassLoader下，且模块间类加载器隔离，避免跨模块静态状态污染。
精准 requires 声明，避免传递性暴露内部状态
滥用 requires transitive 会把内部依赖变成公共契约，间接扩大潜在冲突面。真正要规避变量加载异常，关键是只声明必需依赖，且不向下游透传无关模块。
- 若模块
com.example.service内部用org.apache.commons.lang3.StringUtils做字符串处理，但 API 不暴露任何 Lang3 类型，则应写requires org.apache.commons.lang3;，而非requires transitive。 - 若其方法返回
org.json.JSONObject，则必须用requires transitive org.json;——这是为了让调用方能编译通过，但同时也意味着该依赖已成为模块契约的一部分，版本需受控。 - 这种粒度控制，让每个模块的“静态上下文”清晰独立，不会因下游无意引入另一个 JSON 库而触发
LinkageError或静态块重复执行。
配合 jlink 构建最小运行时，根除冗余类干扰
模块系统支持 jlink 工具生成定制 JDK 镜像，只包含应用实际依赖的模块（如 java.base、java.sql，不含 java.desktop）。这不仅减小体积，更重要的是：镜像中根本不存在那些可能引发冲突的类（比如旧版 javax.xml.bind 在 JDK 8 中存在、JDK 9+ 被移至 java.xml.bind 模块，若未声明 requires，它就不会进镜像，彻底避免绑定冲突）。
- 命令示例：
jlink --module-path $JAVA_HOME/jmods:out --add-modules java.base,java.logging,com.example.service --output myruntime - 生成的
myruntime中，没有 rt.jar 的庞杂类集合，也没有未声明模块的任何类——变量加载环境干净、确定、可重现。
