核心是通过module-info.java显式声明依赖、构建工具统一仲裁版本、必要时字节码重命名或类加载器隔离，提前暴露并阻断多版本共存。
Java 模块化项目中处理版本不兼容冲突，核心不是“绕开问题”，而是通过模块系统的能力显式控制依赖边界、隔离冲突源，并辅以构建阶段的主动治理。关键在于利用 module-info.java 的约束力 + 构建工具的版本仲裁能力 + 必要时的字节码级隔离。
明确模块名与依赖声明，堵住隐式加载漏洞
未声明 module-info.java 的第三方 JAR（如 commons-lang3-3.12.0.jar）会被 JVM 当作“自动模块”，模块名为 org.apache.commons.lang3。但这种推断不可靠，容易因文件名微调失效。
- 启动时加
--list-modules查看实际识别出的模块名，确认是否匹配预期 - 在
module-info.java中用requires org.apache.commons.lang3;显式声明，而非依赖 classpath 扫描 - 若某库被多个模块间接引入不同版本，JVM 不会自动合并——它会直接报错
ModuleResolutionException，这反而是好事，能提前暴露问题
用 dependencyManagement 统一仲裁，禁止多版本落地
模块化不改变 Maven/Gradle 的依赖解析逻辑。冲突仍发生在构建阶段，只是运行时校验更严格。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 在父 POM 的
<dependencymanagement></dependencymanagement>中锁定 Apache 等通用模块版本，例如<commons-lang3.version>3.14.0</commons-lang3.version> - 对引入旧版依赖的第三方库（如某个 SDK 强依赖
httpclient:4.5.13），在引用处用<exclusions></exclusions>排除，再单独声明项目统一版本 - 启用
maven-enforcer-plugin的banDuplicateClasses规则，让构建在发现同名类来自不同 JAR 时直接失败
对无法统一的敏感模块，做运行时隔离
当两个模块必须分别使用 httpclient:4.5 和 httpclient:5.2（二者包名相同、API 不兼容），模块系统本身不提供多版本共存能力，需外部干预：
- 用
Maven Shade Plugin对其中一个模块的 HttpClient 类重命名（如改为com.example.shaded.httpclient），并更新其内部所有引用 - 为该模块创建独立的
URLClassLoader，parent 设为系统类加载器，确保其加载的类与主模块完全隔离 - 避免使用 OSGi 或 JPMS 动态导出同名包——这违反模块系统设计原则，极易引发
IncompatibleClassChangeError
关注弃用提示与迁移路径，减少被动冲突
Apache 官方文档和 Javadoc 中的 @Deprecated、@since 及迁移指南（如 HttpClient 4.x → 5.x Migration Guide）是判断兼容性断裂点的第一手依据。
- 升级前检查新版本是否移除了旧方法、是否变更了返回类型或异常声明
- 用
mvn dependency:tree -Dverbose定位哪个传递依赖拖住了旧版本，而不是盲目升级顶层依赖 - 对已标记为
@Deprecated的 API，即使当前可用，也应视为技术债，规划替换而非长期容忍
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
