--module-path 是面向模块化系统（jpms）的根本升级，非 -classpath 简单替代；仅当项目含 module-info.java、按模块编译打包时才生效，否则仍走 classpath 逻辑。
java 9 引入的 --module-path（或简写为 -p）不是对 -classpath 的简单替代，而是面向模块化系统（jpms）的根本性升级。它改变了类加载机制、依赖解析逻辑和运行时可见性规则。能否“替代”，取决于你的项目是否已模块化；而所谓“优化变量搜索性能”，实际是指提升模块解析效率、减少类路径扫描开销、避免隐式依赖带来的不确定性。
明确适用前提：你的代码必须是模块化的
仅添加 --module-path 参数不会自动启用模块系统。你必须：
- 在项目根目录下提供
module-info.java，声明module名称、requires依赖、exports包等 - 编译时用
javac --module-source-path或按模块结构组织源码 - 打包为
.jmod文件或包含module-info.class的 JAR
若仍用传统 jar -cfv app.jar *.class 打包且无 module-info.class，JVM 会将其视为“未命名模块”（unnamed module），依然走 classpath 路径查找逻辑，--module-path 仅作补充，无法发挥模块优势。
路径行为差异：从线性扫描到图式解析
-classpath 是扁平化路径列表，JVM 按顺序逐个目录/JAR 查找类，遇到同名类即停止（可能导致版本冲突或遮蔽）；--module-path 则构建模块图（module graph）：
- 每个模块有唯一名称与显式依赖声明，JVM 可静态验证依赖完整性
- 类查找先定位所属模块，再在该模块内解析，避免跨模块重复扫描
- 未导出（
not exported）的包默认不可见，天然隔离，减少无效匹配
这意味着：模块路径不追求“覆盖更多”，而追求“描述更准”。例如：
java --module-path mods/ --module myapp/com.example.Main
比
java -cp "libs/*:classes/" com.example.Main
更早确定主类归属、更快拒绝非法访问、更少触发 ClassNotFoundException 回溯。
实战中提升搜索效率的关键操作
真正影响“变量（实为类/资源）搜索性能”的，不是参数本身，而是模块化后的工程实践：
-
精简 requires 声明：只声明实际用到的模块，如
requires java.sql;而非requires java.desktop;，可缩小依赖图规模 - 使用 jlink 构建最小运行镜像：排除未使用的 JDK 模块，启动时无需加载冗余类，直接降低类路径扫描总量
-
避免自动模块（Automatic Modules）：把传统 JAR 放入
--module-path会转为自动模块，其所有包默认导出且依赖模糊，削弱模块边界，拖慢解析 - 启用 --show-module-resolution：调试阶段加此参数，可观察模块解析全过程，识别循环依赖或冗余路径
过渡期兼容策略
完全迁移需时间。常见混合模式：
-
--module-path mods/ --add-modules java.xml.bind：显式启用特定平台模块（如 JAXB） -
--class-path lib/old-utils.jar --module-path mods/ --module main：将旧 JAR 置于 classpath，新模块置于 module-path，由 JVM 自动桥接（但旧 JAR 中类无法访问新模块的非导出包） - 用
jdeps --summary your-app.jar分析依赖，识别哪些库已模块化、哪些需封装或替换
这种分层加载虽保留兼容性，但无法获得完整性能收益——真正的优化来自主动设计模块边界，而非参数切换。
