Java 9+中，类路径内容被视为未命名模块，它自动读取所有命名模块、导出所有包但无封装性，且优先级低于模块路径；可通过上下文类加载器访问其资源，同名类以模块路径为准。
Java 9+ 中，当类路径（classpath）与模块路径（module-path）同时存在时，JVM 会把所有类路径上的内容视为一个特殊的未命名模块（Unnamed Module）。它不声明 module-info.java，没有 requires 或 exports，但能被任何命名模块以宽松方式“读取”——这是解决混合环境变量/类加载冲突的关键逻辑支点，而非隐患。
未命名模块的本质行为
未命名模块不是“无模块”，而是 JVM 的兼容性兜底机制：
- 它自动读取（
reads）所有命名模块（无需requires声明） - 它导出（
exports）所有包给所有模块（包括命名模块），但不加限制，即无封装性 - 它不能被命名模块
requires（语法报错），但可通过反射或服务加载器间接访问 - 同名类在未命名模块中出现时，永远低于模块路径中的同名类优先级，不会覆盖
利用未命名模块化解资源/配置变量冲突
常见场景：项目用模块化组织核心逻辑（如 com.example.service），但遗留的配置文件（config.properties）、脚本类（ScriptRunner.class）或插件 JAR 仍放在 -cp 下。此时它们属于未命名模块，而模块内代码又需读取这些资源——直接 Class.getResource() 可能失败，因模块默认不开放对未命名模块资源的访问。
实战解法：
-
用 ClassLoader 加载资源：未命名模块的类由
AppClassLoader（即系统类加载器）加载，调用Thread.currentThread().getContextClassLoader().getResource("config.properties")总能命中类路径资源 -
模块内显式开放对系统类加载器的访问：在
module-info.java中添加opens "com.example.config" to java.base;（若需反射读写），或更稳妥地——改用ServiceLoader.load(..., ClassLoader.getSystemClassLoader()) -
避免硬编码路径依赖：不要在模块代码里写
MyClass.class.getResource("/config.properties")，改用上下文类加载器统一入口
处理跨路径的同名类/包冲突
例如：模块 com.example.api 导出了 com.example.model.User；同时类路径下有个旧版 lib/legacy-model.jar 也含 com.example.model.User。JVM 不会报错，但运行时行为不可控。
关键控制点：
- 模块路径优先级绝对高于类路径：只要模块图完整，JVM 忽略类路径中同名类，无需额外排除
-
检查是否真被加载：启动时加
-verbose:class，观察日志中User类来自jrt:/（模块）还是file:/（类路径） -
强制隔离旧类：若必须保留旧 JAR 但禁止其类参与模块解析，可将其移出
-cp，改用URLClassLoader按需加载，完全脱离未命名模块作用域
调试与验证技巧
确认未命名模块是否按预期工作：
- 运行
java --list-modules：输出中含ALL-SYSTEM和你自己的模块，但不列出未命名模块（它隐式存在） - 打印模块信息：
System.out.println(MyClass.class.getModule());—— 类路径类返回null（即属于未命名模块）；模块内类返回module com.example.api - 用
jdeps --module-path mods --class-path libs/*.jar MyApp.class分析依赖流向，观察哪些依赖被归入“unnamed module”
