JPMS 通过 module-info.java 显式声明依赖与导出，用 requires transitive 固化传递路径、exports/qualified exports 限制包可见性、opens 控制反射权限、uses/provides 实现服务解耦，并在启动时强制验证模块图，彻底杜绝 classpath 隐式依赖风险。
模块描述符本身不用于“锁定变量库”，它锁定的是模块级依赖关系链，这是 java 平台模块系统（jpms）保障生产安全的核心机制。关键在于通过 module-info.java 显式声明、精确导出、禁止隐式访问，让整个依赖图在编译期和运行时可验证、不可绕过。
用 requires + transitive 精确控制传递依赖
普通 requires 仅声明本模块对某模块的直接依赖；而 requires transitive 表示该依赖会“透传”给所有依赖本模块的下游模块。这避免了下游模块因缺失间接依赖而出现 NoClassDefFoundError，更重要的是——它把传递路径固化在源码中，无法被 classpath 隐式补全。
- 例如：
requires transitive com.fasterxml.jackson.core;意味着任何引入你模块的项目，自动获得 Jackson core 的可见性，无需自己再写一行requires - 若误用非 transitive 依赖，下游模块反射调用或服务加载时可能失败，暴露未声明的耦合，构成安全隐患
用 exports + qualified exports 限制包可见范围
默认所有包私有。只有显式 exports 的包才对外可访问；配合 exports ... to 可限定仅被指定模块使用，实现最小暴露面。
-
exports com.example.api;：向所有模块公开接口 -
exports com.example.internal to com.example.test;：仅允许测试模块反射访问内部包，生产环境完全隔离 - 未导出的包，即使类名能被反射查到，JVM 也会在运行时抛
IllegalAccessError，从语言层阻断非法访问
禁用隐式依赖，强制模块图一致性验证
JPMS 在 JVM 启动时执行模块图解析：检查所有 requires 是否存在、是否版本兼容、是否存在循环依赖、是否有未导出却试图访问的包。一旦失败，应用根本无法启动。
- 这意味着：你无法靠“把 jar 丢进 lib 目录就跑起来”的老方式绕过依赖约束
- 第三方库若未模块化（如传统 jar），必须显式声明为
requires static或通过--add-modules强制包含，其内部依赖不会自动透传 - 这种强验证机制杜绝了 classpath 模型下常见的“jar 版本冲突”“类加载器欺骗”等运行时安全隐患
结合 opens 与服务机制实现可控反射与解耦
反射在框架场景不可避免，但 JPMS 要求必须显式 opens 才允许运行时深度反射（如序列化、DI 容器注入）。同时，uses/provides 支持模块间松耦合服务发现，替代硬编码类名加载。
-
opens com.example.config to java.desktop;：只允许 AWT/Swing 框架反射读写该包，其他模块无权触碰 -
uses com.example.spi.DataProcessor;声明本模块需消费该服务 -
provides com.example.spi.DataProcessor with com.impl.FastProcessor;声明本模块提供具体实现 - 服务查找由 JVM 保证模块边界，不依赖
Class.forName()这类易被污染的动态加载
