Maven 虐我千百遍，我待 Maven 如初恋！(1)，springcloud 实战演练

Maven 仓库

本地仓库路径配置

你要 jar 包，不可能每次都要联网去下载吧，多费劲，所以本地仓库就是相当于加了一层 jar 包缓存，先到这里来查。如果这里查不到，那么就去私服上找，如果私服也找不到，那么去中央仓库去找，找到 jar 后，会把 jar 的信息同步到私服和本地仓库中。

私服，就是公司内部局域网的一台服务器而已，你想一下，当你的工程 Project-A 依赖别人的 Project-B 的接口，怎么做呢？没有 Maven 的时候，当然是 copy Project-B jar 到你的本地 lib 中引入，那么 Maven 的方式，很显然需要其他人把 Project-B deploy 到私服仓库中供你使用。因此私服中存储了本公司的内部专用的 jar！不仅如此，私服还充当了中央仓库的镜像，说白了就是一个代理！

中央仓库：该仓库存储了互联网上的 jar，由 Maven 团队来维护，比如地址是类似这样的：https://repo1.maven.org/XXXX。

需要更多大厂面试资料的话也可以[点击直接进入，免费获取！](

)暗号：CSDN

[](

)Q2：关于< dependency >的使用

依赖管理

![在这里插入图片描述](https://img-blog.csdnimg.cn/20210124160554469.png?x-oss-process=image/watermark,type_ZmFuZ3poZW

【一线大厂Java面试题解析+核心总结学习笔记+最新架构讲解视频+实战项目源码讲义】
浏览器打开：qq.cn.hn/FTf 免费领取

5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80OTUyNzMzNA==,size_16,color_FFFFFF,t_70)

其实这个标签揭示了 jar 的查找坐标：groupId、artifactId、version。

一般而言，我们可以到私服上输入 artifactId 进行搜索，或者到http://search.maven.org/、http://mvnrepository.com/上进行查找确定坐标。

version 分为开发版本（Snapshot）和发布版本（Release），那么为什么要分呢？

在实际开发中，我们经常遇到这样的场景，比如 A 服务依赖于 B 服务，A 和 B 同时开发，B 在开发中发现了 BUG，修改后，将版本由 1.0 升级为 2.0，那么 A 必须也跟着在 POM.XML 中进行版本升级。过了几天后，B 又发现了问题，进行修改后升级版本发布，然后通知 A 进行升级…可以说这是开发过程中的版本不稳定导致了这样的问题。

Maven，已经替我们想好了解决方案，就是使用 Snapshot 版本，在开发过程中 B 发布的版本标志为 Snapshot 版本，A 进行依赖的时候选择 Snapshot 版本，那么每次 B 发布的话，会在私服仓库中，形成带有时间戳的 Snapshot 版本，而 A 构建的时候会自动下载 B 最新时间戳的 Snapshot 版本！

[](

)Q3：既然 Maven 进行了依赖管理，为什么还会出现依赖冲突？处理依赖冲突的手段是？

依赖的版本？

首先来说，对于 Maven 而言，同一个 groupId 同一个 artifactId 下，只能使用一个 version！

根据上图的依赖顺序，将使用 1.2 版本的 jar。

现在，我们可以思考下了，比如工程中需要引入 A、B，而 A 依赖 1.0 版本的 C，B 依赖 2.0 版本的 C，那么问题来了，C 使用的版本将由引入 A、B 的顺序而定？这显然不靠谱！如果 A 的依赖写在 B 的依赖后面，将意味着最后引入的是 1.0 版本的 C，很可能在运行阶段出现类（ClassNotFoundException）、方法（NoSuchMethodError）找不到的错误（因为 B 使用的是高版本的 C）！

这里其实涉及到了 2 个概念：依赖传递（transitive）、Maven 的最近依赖策略。

依赖传递：如果 A 依赖 B，B 依赖 C，那么引入 A，意味着 B 和 C 都会被引入。

Maven 的最近依赖策略：如果一个项目依赖相同的 groupId、artifactId 的多个版本，那么在依赖树（mvn dependency:tree）中离项目最近的那个版本将会被使用。（从这里可以看出 Maven 是不是有点小问题呢？能不能选择高版本的进行依赖么？据了解，Gradle 就是 version+策略）

现在，我们可以想想如何处理依赖冲突呢？

想法 1：要使用哪个版本，我们是清楚的，那么能不能不管如何依赖传递，都可以进行版本锁定呢？

使用< dependencyManagement> [这种主要用于子模块的版本一致性中]

想法 2：在依赖传递中，能不能去掉我们不想依赖的？

使用 [在实际中我们可以在 IDEA 中直接利用插件帮助我们生成]

想法 3：既然是最近依赖策略，那么我们就直接使用显式依赖指定版本，那不就是最靠近项目的么？

使用< dependency>