java依赖冲突本质是同全限定名类被不同版本jar提供，jvm按classpath顺序“先到先得”加载不兼容版本；需结合maven依赖树与运行时类加载器视角，通过-verbose:class、arthas等工具验证实际加载来源及版本，辅以dependencymanagement统一版本、exclusions排除、shading重命名等构建期与运行时双管齐下策略。
Java 依赖冲突的本质，是同一个全限定名的类被不同版本的 jar 提供，而 JVM 的 Application ClassLoader 按 classpath 顺序“先到先得”加载了不兼容的那个版本。要真正解决问题，不能只看 Maven 依赖树，必须结合类加载器视角验证实际运行时哪个类被加载、由谁加载、从哪来。
确认类路径顺序与加载来源
JVM 不关心“哪个版本更合理”，只按 classpath 中 jar 的排列顺序扫描。哪个 jar 先出现，里面同名类就优先被加载，后续同名类直接跳过。
- 在 IntelliJ IDEA：打开 Project Structure → Modules → Dependencies，观察 jar 列表上下顺序（越靠上，优先级越高）
- 在 Eclipse：右键项目 → Properties → Java Build Path → Order and Export，注意勾选顺序
- 运行时验证：启动时加参数
-verbose:class，输出类似Loaded com.example.Utils from file:/xxx/spring-core-5.2.9.jar，重点关注报错类首次出现的位置
定位冲突类并比对实际字节码
出现 NoSuchMethodError 或 NoClassDefFoundError 时，异常堆栈里的类名只是表象，关键要看它真实加载的是哪个版本：
- 用 Arthas 在运行中执行：
sc -d com.example.SomeService→ 查看该类由哪个 jar 和哪个 ClassLoader 加载sm com.example.SomeService methodName→ 列出当前已加载类中实际存在的方法，确认缺失方法是否真的不存在 - 若发现
spring-core-5.2.9.jar和spring-core-5.3.30.jar都在 classpath 中，且SomeService来自 5.2.9，但代码调用的是 5.3.30 才有的方法，就是典型的加载顺序导致的版本错配
区分不同类加载器层级的影响
不是所有冲突都发生在 Application ClassLoader：
- Web 应用中，Tomcat 的
CommonClassLoader可能提前加载了commons-logging，导致你应用里声明的commons-logging:1.2.1完全无效 - PandoraBoot、Spring Boot fat jar 等容器环境会引入额外 ClassLoader 层级，需检查
ClassLoader.getParent()链路 - 同一个类被两个不同 ClassLoader 加载（如 AppClassLoader 和 WebAppClassLoader），即使类名相同，JVM 也视为不同类，可能引发
ClassCastException
构建期控制 + 运行时兜底双管齐下
- 编译期锁定：在
pom.xml的<dependencymanagement></dependencymanagement>中统一声明核心依赖版本（如 Spring BOM），避免子模块各自引入不同版本 - 主动排除：对已知冲突的传递依赖，用
<exclusions></exclusions>清理，例如：<exclusion><groupid>org.springframework</groupid><artifactid>spring-core</artifactid></exclusion>
- 运行时加固：Web 应用可将关键 jar 放入
WEB-INF/lib/，并通过文件名前缀（如001-spring-core-5.3.30.jar）确保其排在 classpath 前端；Spring Boot 可配置maven-shade-plugin对内部依赖做 relocation，隔离包名
不复杂但容易忽略
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
