JPMS不解决版本冲突，但通过显式声明依赖和模块边界，在编译期或启动期暴露问题：自动模块名冲突导致依赖缺失，同名模块无法共存需重命名隔离，构建工具负责版本收敛，模块系统负责访问控制。
Java 模块化项目中处理版本冲突和依赖缺失，核心在于显式控制模块边界与分层干预依赖来源。模块系统（JPMS）本身不解决版本冲突，但它把问题暴露得更早、更明确——编译期或启动期就报错，而不是运行时崩溃。
一、依赖缺失：从“自动模块”到显式声明
大多数第三方库尚未自带 module-info.class，JVM 会将其视为“自动模块”（Automatic Module）。它的模块名通常由 JAR 文件名推断（如 jackson-databind-2.15.2.jar → com.fasterxml.jackson.databind）。
- 用
java --list-modules | grep jackson查看实际模块名 - 在
module-info.java中必须写requires com.fasterxml.jackson.databind;，不能只靠 classpath - 若多个 JAR 推导出相同模块名（比如两个不同版本的 Jackson），JVM 只加载其中一个，另一个被静默忽略——这就是依赖缺失的根源
二、版本冲突：模块系统不管理版本，但能帮你隔离
JPMS 不提供版本选择机制，它只认模块名。所以 com.fasterxml.jackson.databind 和 com.fasterxml.jackson.databind.v2 是两个不同的模块；而 com.fasterxml.jackson.databind v2.15 和 v2.17 在模块层面是“同名冲突”，无法共存。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 构建工具（Maven/Gradle）负责版本收敛，模块系统负责访问控制——二者分工明确
- 若必须共存多版本（如插件系统），需借助字节码重命名工具（如
jarjar）生成带版本后缀的新模块名 - 例如将旧版 Jackson 重命名为
com.fasterxml.jackson.databind.v214，再在对应模块中requires它
三、实战建议：构建期 + 运行期双校验
光靠 module-info.java 不够，必须配合构建流程：
立即学习“Java免费学习笔记（深入）”；
- Maven 中统一用
<properties>锁定关键依赖版本，并用<exclusions>清理传递污染 - 启动时加参数
--illegal-access=deny --add-modules ALL-SYSTEM强制暴露非法反射访问，提前发现问题 - 用
jdeps --multi-release 17 --module-path mods/ -s your-module分析模块间真实依赖链 - 对无模块信息的老 JAR，可手动补一个
module-info.java（仅导出必要包，避免过度暴露）
四、常见误操作与规避方式
很多问题其实源于对模块语义的误解：
- 误以为
requires static能解决可选依赖的版本问题——它只影响编译期检查，不改变运行时模块图 - 在
module-info.java中写requires java.desktop却忘了该模块在最小化 JRE 中可能未包含——应搭配jlink显式组装运行时镜像 - 用
opens开放包给所有模块（opens pkg;）代替精确指定（opens pkg to module.name;），导致反射漏洞和模块图膨胀
