企业官网建设流程全解析

谁说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给依赖分了“活动范围”，不同范围的依赖只在指定阶段生效，别配错了！用一张表讲清楚（附“人话翻译”）：

💡 举个栗子：

• junit必须配test：不然编译主代码时会找不到junit，纯纯浪费！

• servlet-api配provided：Tomcat本身带了这个包，打包进去会冲突，纯属画蛇添足！

三、拆分与聚合：项目“分家”不分手

项目做大了，把dao、service、web全堆在一个工程里？维护起来能把人逼疯！Maven的“拆分+聚合”专治这种混乱：

核心思路：父工程统一管理，子模块各司其职

为啥要这么拆？

1. 解耦：改service代码不影响dao，不用全量编译；

2. 复用：dao模块能被多个service引用；

3. 统一管理：父工程maven_parent集中下载/管理所有依赖版本，子模块直接继承，不用重复配版本。

举个父工程的核心配置（子模块只需继承即可）：

总结

1. 依赖冲突：优先用dependencyManagement版本锁定，次之排除依赖/调整顺序，直接引用兜底；

2. 依赖范围：记住4个核心范围的生效阶段，test给测试包、provided给服务器自带包；

3. 拆分聚合：父工程做依赖管理，子模块按功能拆分（dao/service/web），解耦又好维护。

💬 评论区聊聊：你踩过哪些Maven依赖的坑？是怎么解决的？