目录一、先明确核心前提Maven依赖优先级的核心原则二、单模块Maven依赖优先级基础模式必吃透2.1 模式1直接依赖 传递依赖核心优先级2.2 模式2同一层级声明顺序优先2.3 模式3依赖范围scope的优先级3.1 compile默认范围优先级最高3.2 provided次高优先级3.3 runtime次低优先级3.4 test最低优先级2.4 补充system范围的特殊说明三、多模块Maven依赖优先级重点实战高频3.1 模式1子模块直接声明 父模块声明覆盖优先父模块pom.xml依赖管理子模块xxx-servicepom.xml3.2 模式2跨模块依赖就近优先路径越短优先级越高3.3 模式3子模块嵌套子子模块继承覆盖优先级四、Spring Boot BOM依赖管理优先级实战重点必懂4.1 BOM依赖的两种引入方式优先级不同方式1继承spring-boot-starter-parent推荐优先级高方式2在dependencyManagement中引入spring-boot-dependencies灵活优先级低4.2 BOM依赖的核心优先级规则实战必记4.3 BOM依赖避坑点高频问题五、传递依赖的特殊优先级避坑重点5.1 传递依赖的“路径长度优先”5.2 传递依赖的“声明顺序优先”5.3 排除传递依赖打破优先级六、依赖优先级实战避坑冲突解决技巧6.1 高频避坑点必记6.2 依赖冲突解决技巧实战必备七、总结实战重点回顾♂️ 个人主页Java开发与君同行✍作者简介Java学习者 希望大家多多支持我们一起进步如果文章对你有帮助的话欢迎评论 点赞 收藏 加关注前言作为Java程序员我们日常开发中几乎每天都在和Maven依赖打交道——引入依赖、排查依赖冲突、调整依赖版本而这一切的核心都离不开「依赖优先级」。很多开发者遇到“依赖冲突、明明引入了依赖却找不到类、多模块中依赖版本不一致、Spring Boot BOM依赖不生效”等问题本质上都是没吃透Maven依赖优先级的规则。Maven依赖优先级并非杂乱无章而是有明确的规则体系涵盖「单模块依赖、多模块依赖、依赖范围、传递依赖、Spring Boot BOM依赖继承」等所有高频场景。本文结合多年Java实战经验从“核心优先级规则、单模块场景、多模块场景、传递依赖优先级、BOM依赖管理优先级、依赖冲突解决”6个核心维度拆解所有依赖优先级模式搭配实操案例和避坑技巧全程干货无空洞理论新手能快速吃透老鸟可查漏补缺完全适配CSDN技术文章“实战避坑”的核心风格。提示本文适用于所有Java Maven项目单模块、多模块SpringBoot/SpringCloud项目均适用重点解决“依赖优先级怎么判断、多模块中依赖怎么继承、传递依赖为什么失效、BOM依赖怎么生效、冲突怎么解决”五大核心痛点建议收藏遇到依赖问题直接对照查询。一、先明确核心前提Maven依赖优先级的核心原则在讲解具体优先级规则前先记住3个核心原则这是理解所有优先级模式的基础避免走偏就近优先依赖的引入路径越短优先级越高比如直接引入的依赖比通过其他依赖传递引入的优先级高声明优先在同一引入路径下依赖在pom.xml中声明的位置越靠前优先级越高覆盖优先子模块直接声明的依赖 父模块声明的依赖直接引入的依赖 传递依赖BOM管理的依赖版本可被直接声明的版本覆盖。补充Maven依赖优先级的本质是“解决依赖冲突”——当同一依赖出现多个版本时Maven会根据优先级规则选择一个“最优版本”引入项目避免重复引入导致的类加载异常、方法找不到等问题。另外Spring Boot项目中常用的BOMBill of Materials依赖管理本质是“统一版本优先级”并非打破Maven核心优先级规则。二、单模块Maven依赖优先级基础模式必吃透单模块项目无父模块/子模块的依赖优先级主要分为「直接依赖vs传递依赖」「依赖范围优先级」「声明顺序优先级」3种模式是多模块、BOM依赖优先级的基础逐一拆解2.1 模式1直接依赖 传递依赖核心优先级这是最基础、最常用的优先级规则项目中直接在pom.xml中引入的依赖直接依赖优先级高于通过其他依赖传递引入的依赖传递依赖。实操案例避坑重点!-- 直接依赖项目中直接引入fastjson2版本2.0.32 -- dependency groupIdcom.alibaba/groupId artifactIdfastjson2/artifactId version2.0.32/version /dependency !-- 传递依赖引入xxx-service该依赖传递引入fastjson2版本2.0.20 -- dependency groupIdcom.xxx/groupId artifactIdxxx-service/artifactId version1.0.0/version /dependency结论此时项目中生效的fastjson2版本是2.0.32直接依赖优先级高于传递依赖即使传递依赖的版本更低/更高也会被直接依赖覆盖。避坑点很多开发者误以为“传递依赖的版本更高就会生效”实则不然——无论传递依赖版本如何只要有直接依赖就优先使用直接依赖的版本。2.2 模式2同一层级声明顺序优先当两个「直接依赖」是同一层级无父子依赖关系且引入的是同一个依赖的不同版本时在pom.xml中声明位置越靠前的依赖优先级越高。实操案例!-- 声明在前面的依赖版本2.0.32 -- dependency groupIdcom.alibaba/groupId artifactIdfastjson2/artifactId version2.0.32/version /dependency !-- 声明在后面的依赖版本2.0.40 -- dependency groupIdcom.alibaba/groupId artifactIdfastjson2/artifactId version2.0.40/version /dependency结论此时项目中生效的fastjson2版本是2.0.32声明在前的优先级更高而非版本更高的2.0.40。避坑点不要误以为“版本越高优先级越高”——Maven的依赖优先级和版本高低无关同一层级下只看声明顺序。2.3 模式3依赖范围scope的优先级依赖范围scope不仅决定了依赖的生效阶段也间接影响依赖优先级核心优先级顺序从高到低结合生效场景拆解避免记混compile provided runtime test逐一代码场景解析结合实操案例一看就懂3.1 compile默认范围优先级最高生效阶段编译、测试、运行全程生效是项目核心依赖的首选范围如Spring核心、MyBatis、工具类等。优先级最高无论其他范围的同依赖版本如何compile范围的依赖都会优先生效。3.2 provided次高优先级生效阶段编译、测试运行时由容器提供如Tomcat提供servlet-api不参与项目打包。实操案例!-- provided范围servlet-api运行时由Tomcat提供 -- dependency groupIdjakarta.servlet/groupId artifactIdjakarta.servlet-api/artifactId version6.0.0/version scopeprovided/scope /dependency !-- test范围同依赖版本5.0.0 -- dependency groupIdjakarta.servlet/groupId artifactIdjakarta.servlet-api/artifactId version5.0.0/version scopetest/scope /dependency结论编译、测试阶段生效的是provided范围的6.0.0版本优先级高于test运行时不加载该依赖由容器提供。3.3 runtime次低优先级生效阶段测试、运行编译时不生效无需参与编译仅运行时需要典型场景数据库驱动MySQL、Oracle驱动。优先级低于compile、provided高于test——若存在compile范围的同依赖会被compile覆盖。3.4 test最低优先级生效阶段仅测试阶段如JUnit、Mockito不参与编译和运行优先级最低。避坑点test范围的依赖无法在主代码中使用编译时不生效若其他范围有同依赖test范围的版本会被覆盖。2.4 补充system范围的特殊说明除了上述4个常用范围还有一个system范围本地依赖需指定systemPath其优先级与provided一致但不推荐使用依赖本地文件移植性差容易导致团队协作问题。三、多模块Maven依赖优先级重点实战高频多模块项目父模块子模块的依赖优先级是实战中最容易踩坑的场景——核心是“继承覆盖”结合Maven核心原则拆解3种核心模式覆盖所有多模块场景父模块聚合、子模块嵌套、跨模块依赖。先明确多模块基础架构后文案例基于此架构xxx-project父模块pom打包仅管理依赖和聚合子模块├─ xxx-common子模块公共工具模块├─ xxx-service子模块业务逻辑模块依赖common└─ xxx-web子模块展示层模块依赖service、common3.1 模式1子模块直接声明 父模块声明覆盖优先核心规则子模块会继承父模块的依赖父模块dependencyManagement或dependencies中声明的依赖但子模块直接在pom.xml中声明的依赖优先级高于父模块声明的依赖子模块可覆盖父模块的依赖版本。实操案例父模块子模块父模块pom.xml依赖管理project modelVersion4.0.0/modelVersion groupIdcom.xxx/groupId artifactIdxxx-project/artifactId version1.0.0/version packagingpom/packaging modules modulexxx-common/module modulexxx-service/module modulexxx-web/module /modules !-- 父模块依赖管理统一版本子模块可直接引用 -- dependencyManagement dependencies dependency groupIdcom.alibaba/groupId artifactIdfastjson2/artifactId version2.0.32/version !-- 父模块统一版本 -- /dependency /dependencies /dependencyManagement /project子模块xxx-servicepom.xmlproject parent groupIdcom.xxx/groupId artifactIdxxx-project/artifactId version1.0.0/version /parent modelVersion4.0.0/modelVersion artifactIdxxx-service/artifactId !-- 子模块直接声明fastjson2版本2.0.40 -- dependencies dependency groupIdcom.alibaba/groupId artifactIdfastjson2/artifactId version2.0.40/version!-- 覆盖父模块版本 -- /dependency /dependencies /project结论xxx-service模块中生效的fastjson2版本是2.0.40子模块直接声明 父模块声明其他未直接声明的子模块如xxx-common若引用fastjson2会使用父模块的2.0.32版本。避坑点父模块的dependencyManagement标签仅“管理版本”不自动引入依赖子模块需手动引入依赖无需写version若子模块写了version会覆盖父模块的版本。3.2 模式2跨模块依赖就近优先路径越短优先级越高多模块中子模块之间会相互依赖如web依赖serviceservice依赖common此时依赖优先级遵循“就近优先”——直接依赖的子模块比间接依赖的子模块中的传递依赖优先级高。实操案例xxx-common模块子模块引入fastjson2版本2.0.20直接依赖xxx-service模块子模块依赖xxx-common传递引入fastjson2 2.0.20同时直接引入fastjson2 2.0.32xxx-web模块子模块依赖xxx-service传递引入fastjson2 2.0.32未直接声明。依赖路径分析xxx-web → xxx-service → fastjson2 2.0.32路径长度2xxx-web → xxx-service → xxx-common → fastjson2 2.0.20路径长度3。结论xxx-web模块中生效的fastjson2版本是2.0.32路径更短优先级更高。3.3 模式3子模块嵌套子子模块继承覆盖优先级若项目存在子子模块如xxx-service下有service-user、service-order子模块优先级规则不变核心子子模块直接声明 父模块xxx-service声明 根父模块xxx-project声明。避坑点子子模块的依赖优先继承直接父模块如service-user继承xxx-service再继承根父模块若子子模块直接声明依赖会覆盖所有父模块的版本。四、Spring Boot BOM依赖管理优先级实战重点必懂Java开发者几乎都用Spring Boot而Spring Boot的核心依赖管理方式是「BOMBill of Materials」——通过spring-boot-starter-parent或spring-boot-dependencies统一管理所有Spring Boot相关依赖的版本其优先级有特殊规则也是高频踩坑点。先明确Spring Boot BOM的核心作用是“统一依赖版本简化依赖引入”它不打破Maven核心优先级规则而是在“依赖版本管理”层面提升优先级。4.1 BOM依赖的两种引入方式优先级不同Spring Boot项目引入BOM有两种常用方式优先级有差异重点区分方式1继承spring-boot-starter-parent推荐优先级高spring-boot-starter-parent本身就是一个BOM继承它后子模块会自动继承所有Spring Boot官方依赖的版本优先级父模块spring-boot-starter-parent依赖版本 手动引入的BOM版本。!-- 继承Spring Boot BOMspring-boot-starter-parent -- parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version3.2.9/version !-- BOM统一版本 -- /parent dependencies !-- 无需写version自动继承BOM中的版本3.2.9对应的spring-web版本 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency /dependencies方式2在dependencyManagement中引入spring-boot-dependencies灵活优先级低若项目无法继承spring-boot-starter-parent如已有自定义父模块可在dependencyManagement中引入BOM优先级自定义父模块依赖版本 BOM版本。!-- 自定义父模块 -- parent groupIdcom.xxx/groupId artifactIdxxx-project/artifactId version1.0.0/version /parent dependencyManagement dependencies !-- 引入Spring Boot BOM -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-dependencies/artifactId version3.2.9/version typepom/type scopeimport/scope /dependency !-- 自定义父模块声明的依赖优先级高于BOM -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId version3.2.8/version!-- 覆盖BOM的3.2.9版本 -- /dependency /dependencies /dependencyManagement4.2 BOM依赖的核心优先级规则实战必记结合Maven核心原则Spring Boot BOM依赖的优先级顺序从高到低项目直接声明的依赖带version无论BOM中版本如何直接声明的依赖版本优先生效覆盖BOM版本继承spring-boot-starter-parent的依赖版本若未直接声明优先使用父模块BOM中的版本dependencyManagement中引入的BOM版本若未继承父模块BOM且未直接声明使用该BOM版本传递依赖版本若以上都未配置使用传递依赖的版本。4.3 BOM依赖避坑点高频问题坑点1“引入BOM后依赖版本仍不生效”——原因是BOM仅管理版本需手动引入依赖无需写version不引入则不生效坑点2“直接声明依赖版本却被BOM覆盖”——不可能直接声明的依赖带version优先级高于BOM若不生效检查是否有拼写错误groupId/artifactId错误坑点3“多模块中部分子模块BOM版本不统一”——需确保所有子模块都继承同一个BOM如统一继承spring-boot-starter-parent避免子模块单独引入不同版本的BOM。五、传递依赖的特殊优先级避坑重点传递依赖是依赖冲突的主要来源除了“直接依赖 传递依赖”“就近优先”还有3个特殊优先级规则实战中经常遇到逐一拆解5.1 传递依赖的“路径长度优先”当同一个依赖通过多个不同路径传递引入时路径长度越短优先级越高路径长度依赖层级数。案例web模块依赖A和B两个依赖A传递引入fastjson2 2.0.32路径web→A→fastjson2长度2B传递引入fastjson2 2.0.40路径web→B→C→fastjson2长度3此时生效版本是2.0.32路径更短。5.2 传递依赖的“声明顺序优先”当同一个依赖的传递路径长度相同时传递依赖的“源头依赖”在pom.xml中声明越靠前优先级越高。案例web模块同时依赖A和BA传递引入fastjson2 2.0.32B传递引入fastjson2 2.0.40路径长度都是2web→A→fastjson2、web→B→fastjson2若A在pom.xml中声明在B前面生效版本是2.0.32。5.3 排除传递依赖打破优先级若传递依赖的版本不兼容可通过exclusions标签排除传递依赖此时排除后该传递依赖失效优先级最低相当于被“删除”。!-- 引入xxx-service排除其传递引入的fastjson2 -- dependency groupIdcom.xxx/groupId artifactIdxxx-service/artifactId version1.0.0/version exclusions exclusion groupIdcom.alibaba/groupId artifactIdfastjson2/artifactId /exclusion /exclusions /dependency !-- 直接引入fastjson2版本2.0.32 -- dependency groupIdcom.alibaba/groupId artifactIdfastjson2/artifactId version2.0.32/version /dependency结论排除xxx-service传递的fastjson2后仅生效直接引入的2.0.32版本。六、依赖优先级实战避坑冲突解决技巧结合前面的所有规则整理10个实战高频避坑点冲突解决技巧遇到依赖问题直接对照高效解决6.1 高频避坑点必记优先级和版本高低无关不要误以为“版本越高优先级越高”Maven只看“路径、声明顺序、是否直接引入”子模块覆盖父模块子模块直接声明的依赖无论版本高低都覆盖父模块的依赖BOM不自动引入依赖引入BOM后需手动引入依赖无需写version否则依赖不生效传递依赖路径越短越好尽量减少传递依赖的层级避免路径过长导致的冲突多模块统一BOM所有子模块尽量继承同一个BOM避免版本混乱。6.2 依赖冲突解决技巧实战必备排查冲突执行mvn dependency:tree -Dverbose查看依赖树找到冲突的依赖标注“omitted for conflict with xxx”的就是被排除的版本解决冲突优先方案直接引入需要的依赖版本直接依赖覆盖传递依赖解决冲突备选方案排除不兼容的传递依赖通过exclusions标签多模块冲突在父模块的dependencyManagement中统一依赖版本所有子模块引用时不写versionBOM冲突直接声明需要的依赖版本覆盖BOM中的版本。七、总结实战重点回顾Maven依赖优先级的核心始终围绕“就近优先、声明优先、覆盖优先”三大原则无论是单模块、多模块还是Spring Boot BOM依赖都没有脱离这三大原则——所有特殊场景如BOM、传递依赖都是在这三大原则的基础上延伸的。核心优先级总排序实战直接对照项目直接声明的依赖带version 父模块/BOM声明的依赖 传递依赖路径短的优先 传递依赖路径长的声明在前的优先补充依赖范围的优先级compile provided runtime test仅在“同一引入方式、同一路径”下生效。对于Java程序员来说吃透Maven依赖优先级能快速解决90%的依赖冲突问题提升开发效率避免因依赖问题导致的项目启动失败、功能异常。本文覆盖了所有高频场景单模块、多模块、BOM、传递依赖搭配实操案例和避坑技巧建议收藏遇到依赖问题直接对照查询。如果觉得有用欢迎点赞关注持续分享Java Maven、Spring Boot实战干货若有具体的依赖冲突场景如多模块BOM冲突可在评论区留言我帮你拆解解决方案资料获取更多粉丝福利关注下方公众号获取
Java程序员必懂：Maven依赖优先级全解析（多模块+BOM管理+所有模式，避坑指南）
发布时间：2026/7/29 19:37:31
目录一、先明确核心前提Maven依赖优先级的核心原则二、单模块Maven依赖优先级基础模式必吃透2.1 模式1直接依赖 传递依赖核心优先级2.2 模式2同一层级声明顺序优先2.3 模式3依赖范围scope的优先级3.1 compile默认范围优先级最高3.2 provided次高优先级3.3 runtime次低优先级3.4 test最低优先级2.4 补充system范围的特殊说明三、多模块Maven依赖优先级重点实战高频3.1 模式1子模块直接声明 父模块声明覆盖优先父模块pom.xml依赖管理子模块xxx-servicepom.xml3.2 模式2跨模块依赖就近优先路径越短优先级越高3.3 模式3子模块嵌套子子模块继承覆盖优先级四、Spring Boot BOM依赖管理优先级实战重点必懂4.1 BOM依赖的两种引入方式优先级不同方式1继承spring-boot-starter-parent推荐优先级高方式2在dependencyManagement中引入spring-boot-dependencies灵活优先级低4.2 BOM依赖的核心优先级规则实战必记4.3 BOM依赖避坑点高频问题五、传递依赖的特殊优先级避坑重点5.1 传递依赖的“路径长度优先”5.2 传递依赖的“声明顺序优先”5.3 排除传递依赖打破优先级六、依赖优先级实战避坑冲突解决技巧6.1 高频避坑点必记6.2 依赖冲突解决技巧实战必备七、总结实战重点回顾♂️ 个人主页Java开发与君同行✍作者简介Java学习者 希望大家多多支持我们一起进步如果文章对你有帮助的话欢迎评论 点赞 收藏 加关注前言作为Java程序员我们日常开发中几乎每天都在和Maven依赖打交道——引入依赖、排查依赖冲突、调整依赖版本而这一切的核心都离不开「依赖优先级」。很多开发者遇到“依赖冲突、明明引入了依赖却找不到类、多模块中依赖版本不一致、Spring Boot BOM依赖不生效”等问题本质上都是没吃透Maven依赖优先级的规则。Maven依赖优先级并非杂乱无章而是有明确的规则体系涵盖「单模块依赖、多模块依赖、依赖范围、传递依赖、Spring Boot BOM依赖继承」等所有高频场景。本文结合多年Java实战经验从“核心优先级规则、单模块场景、多模块场景、传递依赖优先级、BOM依赖管理优先级、依赖冲突解决”6个核心维度拆解所有依赖优先级模式搭配实操案例和避坑技巧全程干货无空洞理论新手能快速吃透老鸟可查漏补缺完全适配CSDN技术文章“实战避坑”的核心风格。提示本文适用于所有Java Maven项目单模块、多模块SpringBoot/SpringCloud项目均适用重点解决“依赖优先级怎么判断、多模块中依赖怎么继承、传递依赖为什么失效、BOM依赖怎么生效、冲突怎么解决”五大核心痛点建议收藏遇到依赖问题直接对照查询。一、先明确核心前提Maven依赖优先级的核心原则在讲解具体优先级规则前先记住3个核心原则这是理解所有优先级模式的基础避免走偏就近优先依赖的引入路径越短优先级越高比如直接引入的依赖比通过其他依赖传递引入的优先级高声明优先在同一引入路径下依赖在pom.xml中声明的位置越靠前优先级越高覆盖优先子模块直接声明的依赖 父模块声明的依赖直接引入的依赖 传递依赖BOM管理的依赖版本可被直接声明的版本覆盖。补充Maven依赖优先级的本质是“解决依赖冲突”——当同一依赖出现多个版本时Maven会根据优先级规则选择一个“最优版本”引入项目避免重复引入导致的类加载异常、方法找不到等问题。另外Spring Boot项目中常用的BOMBill of Materials依赖管理本质是“统一版本优先级”并非打破Maven核心优先级规则。二、单模块Maven依赖优先级基础模式必吃透单模块项目无父模块/子模块的依赖优先级主要分为「直接依赖vs传递依赖」「依赖范围优先级」「声明顺序优先级」3种模式是多模块、BOM依赖优先级的基础逐一拆解2.1 模式1直接依赖 传递依赖核心优先级这是最基础、最常用的优先级规则项目中直接在pom.xml中引入的依赖直接依赖优先级高于通过其他依赖传递引入的依赖传递依赖。实操案例避坑重点!-- 直接依赖项目中直接引入fastjson2版本2.0.32 -- dependency groupIdcom.alibaba/groupId artifactIdfastjson2/artifactId version2.0.32/version /dependency !-- 传递依赖引入xxx-service该依赖传递引入fastjson2版本2.0.20 -- dependency groupIdcom.xxx/groupId artifactIdxxx-service/artifactId version1.0.0/version /dependency结论此时项目中生效的fastjson2版本是2.0.32直接依赖优先级高于传递依赖即使传递依赖的版本更低/更高也会被直接依赖覆盖。避坑点很多开发者误以为“传递依赖的版本更高就会生效”实则不然——无论传递依赖版本如何只要有直接依赖就优先使用直接依赖的版本。2.2 模式2同一层级声明顺序优先当两个「直接依赖」是同一层级无父子依赖关系且引入的是同一个依赖的不同版本时在pom.xml中声明位置越靠前的依赖优先级越高。实操案例!-- 声明在前面的依赖版本2.0.32 -- dependency groupIdcom.alibaba/groupId artifactIdfastjson2/artifactId version2.0.32/version /dependency !-- 声明在后面的依赖版本2.0.40 -- dependency groupIdcom.alibaba/groupId artifactIdfastjson2/artifactId version2.0.40/version /dependency结论此时项目中生效的fastjson2版本是2.0.32声明在前的优先级更高而非版本更高的2.0.40。避坑点不要误以为“版本越高优先级越高”——Maven的依赖优先级和版本高低无关同一层级下只看声明顺序。2.3 模式3依赖范围scope的优先级依赖范围scope不仅决定了依赖的生效阶段也间接影响依赖优先级核心优先级顺序从高到低结合生效场景拆解避免记混compile provided runtime test逐一代码场景解析结合实操案例一看就懂3.1 compile默认范围优先级最高生效阶段编译、测试、运行全程生效是项目核心依赖的首选范围如Spring核心、MyBatis、工具类等。优先级最高无论其他范围的同依赖版本如何compile范围的依赖都会优先生效。3.2 provided次高优先级生效阶段编译、测试运行时由容器提供如Tomcat提供servlet-api不参与项目打包。实操案例!-- provided范围servlet-api运行时由Tomcat提供 -- dependency groupIdjakarta.servlet/groupId artifactIdjakarta.servlet-api/artifactId version6.0.0/version scopeprovided/scope /dependency !-- test范围同依赖版本5.0.0 -- dependency groupIdjakarta.servlet/groupId artifactIdjakarta.servlet-api/artifactId version5.0.0/version scopetest/scope /dependency结论编译、测试阶段生效的是provided范围的6.0.0版本优先级高于test运行时不加载该依赖由容器提供。3.3 runtime次低优先级生效阶段测试、运行编译时不生效无需参与编译仅运行时需要典型场景数据库驱动MySQL、Oracle驱动。优先级低于compile、provided高于test——若存在compile范围的同依赖会被compile覆盖。3.4 test最低优先级生效阶段仅测试阶段如JUnit、Mockito不参与编译和运行优先级最低。避坑点test范围的依赖无法在主代码中使用编译时不生效若其他范围有同依赖test范围的版本会被覆盖。2.4 补充system范围的特殊说明除了上述4个常用范围还有一个system范围本地依赖需指定systemPath其优先级与provided一致但不推荐使用依赖本地文件移植性差容易导致团队协作问题。三、多模块Maven依赖优先级重点实战高频多模块项目父模块子模块的依赖优先级是实战中最容易踩坑的场景——核心是“继承覆盖”结合Maven核心原则拆解3种核心模式覆盖所有多模块场景父模块聚合、子模块嵌套、跨模块依赖。先明确多模块基础架构后文案例基于此架构xxx-project父模块pom打包仅管理依赖和聚合子模块├─ xxx-common子模块公共工具模块├─ xxx-service子模块业务逻辑模块依赖common└─ xxx-web子模块展示层模块依赖service、common3.1 模式1子模块直接声明 父模块声明覆盖优先核心规则子模块会继承父模块的依赖父模块dependencyManagement或dependencies中声明的依赖但子模块直接在pom.xml中声明的依赖优先级高于父模块声明的依赖子模块可覆盖父模块的依赖版本。实操案例父模块子模块父模块pom.xml依赖管理project modelVersion4.0.0/modelVersion groupIdcom.xxx/groupId artifactIdxxx-project/artifactId version1.0.0/version packagingpom/packaging modules modulexxx-common/module modulexxx-service/module modulexxx-web/module /modules !-- 父模块依赖管理统一版本子模块可直接引用 -- dependencyManagement dependencies dependency groupIdcom.alibaba/groupId artifactIdfastjson2/artifactId version2.0.32/version !-- 父模块统一版本 -- /dependency /dependencies /dependencyManagement /project子模块xxx-servicepom.xmlproject parent groupIdcom.xxx/groupId artifactIdxxx-project/artifactId version1.0.0/version /parent modelVersion4.0.0/modelVersion artifactIdxxx-service/artifactId !-- 子模块直接声明fastjson2版本2.0.40 -- dependencies dependency groupIdcom.alibaba/groupId artifactIdfastjson2/artifactId version2.0.40/version!-- 覆盖父模块版本 -- /dependency /dependencies /project结论xxx-service模块中生效的fastjson2版本是2.0.40子模块直接声明 父模块声明其他未直接声明的子模块如xxx-common若引用fastjson2会使用父模块的2.0.32版本。避坑点父模块的dependencyManagement标签仅“管理版本”不自动引入依赖子模块需手动引入依赖无需写version若子模块写了version会覆盖父模块的版本。3.2 模式2跨模块依赖就近优先路径越短优先级越高多模块中子模块之间会相互依赖如web依赖serviceservice依赖common此时依赖优先级遵循“就近优先”——直接依赖的子模块比间接依赖的子模块中的传递依赖优先级高。实操案例xxx-common模块子模块引入fastjson2版本2.0.20直接依赖xxx-service模块子模块依赖xxx-common传递引入fastjson2 2.0.20同时直接引入fastjson2 2.0.32xxx-web模块子模块依赖xxx-service传递引入fastjson2 2.0.32未直接声明。依赖路径分析xxx-web → xxx-service → fastjson2 2.0.32路径长度2xxx-web → xxx-service → xxx-common → fastjson2 2.0.20路径长度3。结论xxx-web模块中生效的fastjson2版本是2.0.32路径更短优先级更高。3.3 模式3子模块嵌套子子模块继承覆盖优先级若项目存在子子模块如xxx-service下有service-user、service-order子模块优先级规则不变核心子子模块直接声明 父模块xxx-service声明 根父模块xxx-project声明。避坑点子子模块的依赖优先继承直接父模块如service-user继承xxx-service再继承根父模块若子子模块直接声明依赖会覆盖所有父模块的版本。四、Spring Boot BOM依赖管理优先级实战重点必懂Java开发者几乎都用Spring Boot而Spring Boot的核心依赖管理方式是「BOMBill of Materials」——通过spring-boot-starter-parent或spring-boot-dependencies统一管理所有Spring Boot相关依赖的版本其优先级有特殊规则也是高频踩坑点。先明确Spring Boot BOM的核心作用是“统一依赖版本简化依赖引入”它不打破Maven核心优先级规则而是在“依赖版本管理”层面提升优先级。4.1 BOM依赖的两种引入方式优先级不同Spring Boot项目引入BOM有两种常用方式优先级有差异重点区分方式1继承spring-boot-starter-parent推荐优先级高spring-boot-starter-parent本身就是一个BOM继承它后子模块会自动继承所有Spring Boot官方依赖的版本优先级父模块spring-boot-starter-parent依赖版本 手动引入的BOM版本。!-- 继承Spring Boot BOMspring-boot-starter-parent -- parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version3.2.9/version !-- BOM统一版本 -- /parent dependencies !-- 无需写version自动继承BOM中的版本3.2.9对应的spring-web版本 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency /dependencies方式2在dependencyManagement中引入spring-boot-dependencies灵活优先级低若项目无法继承spring-boot-starter-parent如已有自定义父模块可在dependencyManagement中引入BOM优先级自定义父模块依赖版本 BOM版本。!-- 自定义父模块 -- parent groupIdcom.xxx/groupId artifactIdxxx-project/artifactId version1.0.0/version /parent dependencyManagement dependencies !-- 引入Spring Boot BOM -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-dependencies/artifactId version3.2.9/version typepom/type scopeimport/scope /dependency !-- 自定义父模块声明的依赖优先级高于BOM -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId version3.2.8/version!-- 覆盖BOM的3.2.9版本 -- /dependency /dependencies /dependencyManagement4.2 BOM依赖的核心优先级规则实战必记结合Maven核心原则Spring Boot BOM依赖的优先级顺序从高到低项目直接声明的依赖带version无论BOM中版本如何直接声明的依赖版本优先生效覆盖BOM版本继承spring-boot-starter-parent的依赖版本若未直接声明优先使用父模块BOM中的版本dependencyManagement中引入的BOM版本若未继承父模块BOM且未直接声明使用该BOM版本传递依赖版本若以上都未配置使用传递依赖的版本。4.3 BOM依赖避坑点高频问题坑点1“引入BOM后依赖版本仍不生效”——原因是BOM仅管理版本需手动引入依赖无需写version不引入则不生效坑点2“直接声明依赖版本却被BOM覆盖”——不可能直接声明的依赖带version优先级高于BOM若不生效检查是否有拼写错误groupId/artifactId错误坑点3“多模块中部分子模块BOM版本不统一”——需确保所有子模块都继承同一个BOM如统一继承spring-boot-starter-parent避免子模块单独引入不同版本的BOM。五、传递依赖的特殊优先级避坑重点传递依赖是依赖冲突的主要来源除了“直接依赖 传递依赖”“就近优先”还有3个特殊优先级规则实战中经常遇到逐一拆解5.1 传递依赖的“路径长度优先”当同一个依赖通过多个不同路径传递引入时路径长度越短优先级越高路径长度依赖层级数。案例web模块依赖A和B两个依赖A传递引入fastjson2 2.0.32路径web→A→fastjson2长度2B传递引入fastjson2 2.0.40路径web→B→C→fastjson2长度3此时生效版本是2.0.32路径更短。5.2 传递依赖的“声明顺序优先”当同一个依赖的传递路径长度相同时传递依赖的“源头依赖”在pom.xml中声明越靠前优先级越高。案例web模块同时依赖A和BA传递引入fastjson2 2.0.32B传递引入fastjson2 2.0.40路径长度都是2web→A→fastjson2、web→B→fastjson2若A在pom.xml中声明在B前面生效版本是2.0.32。5.3 排除传递依赖打破优先级若传递依赖的版本不兼容可通过exclusions标签排除传递依赖此时排除后该传递依赖失效优先级最低相当于被“删除”。!-- 引入xxx-service排除其传递引入的fastjson2 -- dependency groupIdcom.xxx/groupId artifactIdxxx-service/artifactId version1.0.0/version exclusions exclusion groupIdcom.alibaba/groupId artifactIdfastjson2/artifactId /exclusion /exclusions /dependency !-- 直接引入fastjson2版本2.0.32 -- dependency groupIdcom.alibaba/groupId artifactIdfastjson2/artifactId version2.0.32/version /dependency结论排除xxx-service传递的fastjson2后仅生效直接引入的2.0.32版本。六、依赖优先级实战避坑冲突解决技巧结合前面的所有规则整理10个实战高频避坑点冲突解决技巧遇到依赖问题直接对照高效解决6.1 高频避坑点必记优先级和版本高低无关不要误以为“版本越高优先级越高”Maven只看“路径、声明顺序、是否直接引入”子模块覆盖父模块子模块直接声明的依赖无论版本高低都覆盖父模块的依赖BOM不自动引入依赖引入BOM后需手动引入依赖无需写version否则依赖不生效传递依赖路径越短越好尽量减少传递依赖的层级避免路径过长导致的冲突多模块统一BOM所有子模块尽量继承同一个BOM避免版本混乱。6.2 依赖冲突解决技巧实战必备排查冲突执行mvn dependency:tree -Dverbose查看依赖树找到冲突的依赖标注“omitted for conflict with xxx”的就是被排除的版本解决冲突优先方案直接引入需要的依赖版本直接依赖覆盖传递依赖解决冲突备选方案排除不兼容的传递依赖通过exclusions标签多模块冲突在父模块的dependencyManagement中统一依赖版本所有子模块引用时不写versionBOM冲突直接声明需要的依赖版本覆盖BOM中的版本。七、总结实战重点回顾Maven依赖优先级的核心始终围绕“就近优先、声明优先、覆盖优先”三大原则无论是单模块、多模块还是Spring Boot BOM依赖都没有脱离这三大原则——所有特殊场景如BOM、传递依赖都是在这三大原则的基础上延伸的。核心优先级总排序实战直接对照项目直接声明的依赖带version 父模块/BOM声明的依赖 传递依赖路径短的优先 传递依赖路径长的声明在前的优先补充依赖范围的优先级compile provided runtime test仅在“同一引入方式、同一路径”下生效。对于Java程序员来说吃透Maven依赖优先级能快速解决90%的依赖冲突问题提升开发效率避免因依赖问题导致的项目启动失败、功能异常。本文覆盖了所有高频场景单模块、多模块、BOM、传递依赖搭配实操案例和避坑技巧建议收藏遇到依赖问题直接对照查询。如果觉得有用欢迎点赞关注持续分享Java Maven、Spring Boot实战干货若有具体的依赖冲突场景如多模块BOM冲突可在评论区留言我帮你拆解解决方案资料获取更多粉丝福利关注下方公众号获取
![[ERROR] Failed to convert PaddlePaddle model: (Unimplemented) the 0th elementwise MUST be ir::FloatA](http://pic.xiahunao.cn/yaotu/[ERROR] Failed to convert PaddlePaddle model: (Unimplemented) the 0th elementwise MUST be ir::FloatA)
