Spring Boot依赖版本冲突本质是多个版本抢占同一位置，需通过mvn dependency:tree定位冲突源，结合IDE可视化工具或运行时错误反推，再用删version、dependencyManagement统一或exclude排除三种方式解决。

Spring Boot 依赖版本冲突不是代码写错了，而是工程环境里“多个版本抢一个位置”导致的。核心思路就一条：先定位哪个包被重复引入、谁带进来的、各自用了什么版本，再决定留谁、压谁、排除谁。

看依赖树：用命令揪出冲突源头

最直接有效的方法是让 Maven 把整个依赖关系摊开来看：

• 在项目根目录运行：mvn dependency:tree —— 查看全量依赖结构
• 只查某个库（比如 okhttp3）：mvn dependency:tree -Dincludes=okhttp3
• 导出到文件方便搜索：mvn dependency:tree > tree.txt

重点找同一 artifactId（如 com.squareup.okhttp3:okhttp）出现多次、版本号不一致的地方。比如看到一行是 3.14.9，另一行是 4.12.0，冲突就坐实了。

用 IDE 可视化辅助判断

IntelliJ IDEA 打开 pom.xml 后右键 → Maven → Show Dependencies，会弹出图形化依赖图。红色虚线标注的就是存在版本冲突的节点，点进去能看到每个版本由谁引入、路径多深。比纯文本更直观，适合快速扫描。

Java注释规范Skills

当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。

下载

运行时报错反推冲突点

很多冲突不会编译失败，而是在启动或调用时才暴露。典型报错有三类：

• NoClassDefFoundError：比如 okhttp3/internal/http/RealInterceptorChain 找不到 → 说明加载的 okhttp jar 缺少内部类，大概率是版本太低或被裁剪过
• NoSuchMethodError：比如 RequestBody.create(String, MediaType) 方法不存在 → SDK 编译时用的是高版本 okhttp，但运行时加载的是低版本
• ClassNotFoundException：比如 javax.xml.bind.JAXBException → JDK 11+ 默认不带 JAXB，但某个老依赖仍强引用它，需要手动加兼容包

遇到这类错误，不要急着改代码，先根据报错类名去 dependency:tree 里搜是谁引入了这个类所在的 jar，再顺藤摸瓜查版本。

锁定并统一版本

找到冲突后，常见处理方式有三种，按推荐顺序排列：

• 删掉手动写的 version：比如你写了 <version>4.12.0</version> 引入 okhttp，而 Spring Boot 2.7.x 自带的是 3.14.x —— 直接删掉这行，交给 BOM 管理
• 用 dependencyManagement 强制指定：在 pom 的 <dependencymanagement></dependencymanagement> 块中声明你要的版本，这样所有子模块都会继承该版本
• exclude 排除干扰项：如果某个 starter（比如 elasticsearch-rest-client）带了你不想要的 okhttp，就在它的 dependency 里加 <exclusions><exclusion><groupid>com.squareup.okhttp3</groupid><artifactid>okhttp</artifactid></exclusion></exclusions>