Java中模块路径（--module-path）与类路径（-cp）并行存在、职责分明：前者专载含module-info.class的命名模块，后者负责普通JAR、.class文件及资源；混合使用时需用--add-modules显式启用自动模块，且module-path不支持通配符。
Java 在混合应用中同时使用模块路径（--module-path）和类路径（-cp 或 --class-path）是完全可行的，关键在于理解两者的分工与协作边界——它们并行存在、互不替代，也不能混用。
明确职责：module-path 管模块，classpath 管非模块化代码
自 Java 9 起，模块系统引入独立的 --module-path，专用于定位含 module-info.class 的模块化 JAR 或目录；而传统 -cp 仍负责加载：普通 JAR（无 module-info）、独立 .class 文件、资源文件（如 properties、XML），以及自动模块（即放在 module-path 中但未声明模块的 JAR，JVM 会将其视为“自动模块”，但默认不导出、不可被显式 requires）。
若一个 JAR 有 module-info.class，必须放 --module-path；若没有，只能放 -cp。强行把模块化 JAR 放进 -cp，它会被当作自动模块加载，但无法被其他命名模块 requires，除非用 --add-modules 显式启用。
命令行中正确组合两者
运行时可同时指定两个路径，顺序无关，但语义必须清晰：
立即学习“Java免费学习笔记（深入）”；
-
语法示例（Linux/macOS）：
java --module-path mods/:lib/my-module.jar --class-path "lib/*:." com.example.Main -
Windows 注意分隔符：用分号
;分隔 classpath 内部路径，module-path 内部也用分号；整个命令中两者用空格分开 -
当前目录需显式加入 -cp：一旦使用
--class-path，默认的.就被覆盖，若需加载当前目录下的类，必须写--class-path ".:..." -
通配符支持：
lib/*在 classpath 中有效（Java 6+），但在 module-path 中无效——module-path 不支持通配符，需列出具体 JAR 或用脚本展开
处理跨类型依赖：比如模块代码调用传统库
若你的主模块（在 --module-path 中）需要使用一个老版本的 commons-lang（无 module-info，只在 -cp 中），JVM 默认不会让它可见。此时必须：
- 在模块声明中添加
requires static org.apache.commons.lang3;（静态依赖，仅编译期检查） - 运行时加参数：
--add-modules org.apache.commons.lang3，告诉 JVM 把该 JAR 当作自动模块启用 - 确保该 JAR 真实存在于
-cp中，且名称匹配（如commons-lang3-3.12.0.jar的模块名默认为org.apache.commons.lang3）
构建工具中的实际落地（Maven / Gradle）
现代项目极少手写路径，而是靠构建工具协调：
-
Maven：用
maven-compiler-plugin配置<useModulePath>true</useModulePath>启用模块编译；依赖按是否含module-info自动分发到不同路径；运行插件（如exec-maven-plugin）支持分别配置modulepath和classpath -
Gradle：通过
java { modularity.inferModulePath = true }启用模块推断；第三方库默认走 classpath，显式声明为模块的则走 modulepath；run任务自动组装两者 - IDE（IntelliJ/Eclipse）：无需手动设环境变量；在 Project Structure 或 Build Path 中添加的库，底层由 IDE 根据是否模块化，生成对应 JVM 启动参数
混合应用不是非此即彼的选择，而是渐进式迁移的常态。只要守住“模块路径只放命名模块、类路径承载遗留资产、跨层访问靠 --add-modules 衔接”这条线，就能平稳共存。
