Maven踩坑指南：依赖冲突专治不服，范围聚合玩明白！
谁说Maven只有枯燥的配置？今天咱用“唠嗑式”教学，把依赖冲突、依赖范围、项目聚合拆解得明明白白，新手也能秒懂😜
一、依赖冲突：Maven版“版本打架”怎么破？
咱先还原一个真实场景：你开开心心配了两个Spring依赖，结果项目启动就报错，一看是spring-core版本不一致——一个5.1.8，一个5.2.0，俩版本“掐架”了！
为啥会冲突？spring-context会间接依赖spring-core:5.1.8，而spring-aop会间接依赖spring-core:5.2.0，Maven蒙圈了：“我该用哪个？”
别慌，4大招教你摆平冲突：
1. 第一声明者优先：拼顺序，不拼手速
Maven规则：谁先在pom.xml里声明，就优先用谁的依赖版本。
把想要的高版本spring-aop放前面，spring-core就会跟着用5.2.0：
2. 路径近者优先：直接“钦点”核心依赖
“路径近”= 直接依赖 > 间接依赖。与其等Maven猜，不如直接声明spring-core，一步到位：
3. 排除依赖：把“捣乱”的依赖踢出去
不想让spring-context带5.1.8的spring-core？直接排除它的间接依赖，眼不见心不烦：
4. 版本锁定：一招锁死，一劳永逸（推荐！）
这是企业开发最常用的方案——用dependencyManagement统一管理版本，子依赖自动继承，再也不打架：
二、依赖范围：别让依赖“乱串门”
Maven给依赖分了“活动范围”，不同范围的依赖只在指定阶段生效，别配错了！用一张表讲清楚（附“人话翻译”）：
依赖范围 | main/java（编译） | test/java（测试） | war包（运行） | 人话翻译 |
compile（默认） | ✅ | ✅ | ✅ | 全家桶选手：编译、测试、运行都要它（比如spring-context） |
test | ❌ | ✅ | ❌ | 测试专属：只有写测试用例时才生效（比如junit） |
runtime | ❌ | ✅ | ✅ | 运行才上线：编译不用，运行/测试要（比如JDBC驱动） |
provided | ✅ | ✅ | ❌ | 服务器管饭：编译/测试用，运行时服务器自带（比如servlet-api，打包不进war） |
💡 举个栗子：
junit必须配
test：不然编译主代码时会找不到junit，纯纯浪费！servlet-api配
provided：Tomcat本身带了这个包，打包进去会冲突，纯属画蛇添足！
三、拆分与聚合：项目“分家”不分手
项目做大了，把dao、service、web全堆在一个工程里？维护起来能把人逼疯！Maven的“拆分+聚合”专治这种混乱：
核心思路：父工程统一管理，子模块各司其职
为啥要这么拆？
解耦：改service代码不影响dao，不用全量编译；
复用：dao模块能被多个service引用；
统一管理：父工程
maven_parent集中下载/管理所有依赖版本，子模块直接继承，不用重复配版本。
举个父工程的核心配置（子模块只需继承即可）：
总结
依赖冲突：优先用
dependencyManagement版本锁定，次之排除依赖/调整顺序，直接引用兜底；依赖范围：记住4个核心范围的生效阶段，test给测试包、provided给服务器自带包；
拆分聚合：父工程做依赖管理，子模块按功能拆分（dao/service/web），解耦又好维护。
💬 评论区聊聊：你踩过哪些Maven依赖的坑？是怎么解决的？