今天被临时借调到其他项目组处理售后问题。启动项目时，熟悉的红色波浪线再次席卷而来——这已经是公司搬家、Nexus 私仓下线后的常规剧本了。
我们公司以前奉行"小团队快跑"的开发模式，讲究一个快字。当时的 Nexus 私仓里，不仅有常用的公共依赖，还躺着不少公司内部开发的平台级 jar 包。后来公司搬了一次家，服务器重新规划，私仓的维护人员也早已流动到其他岗位。种种原因叠加之下，私仓就这么悄无声息地"寿终正寝"了。
于是，"缺啥找同事要"成了我们的日常操作。通常是拿到 jar 包，mvn install:install-file 一把梭，装进本地仓库完事。
但今天这招不灵了。我把 pom 里报红的依赖一个一个全装进了本地仓库，IDE 里依然全篇爆红，纹丝不动。时间紧任务重，最后我索性把同事的整个 repository 目录拷了过来，在项目 pom 里直接配置成 file 协议的本地仓库才算搞定。
问题虽然解决了，但这种方式显然不够优雅。趁着今天记忆还新鲜，我把这几种配置方式记录一下，以备不时之需。
方案一改 settings.xml 全局配置
如果这种"私仓缺失"是公司常态，而你又不希望每个项目都去配一遍仓库地址，那么修改 Maven 的全局配置文件 settings.xml 会是更优雅的选择。
适用场景
- 公司私仓长期不可用，但有一套相对稳定的"依赖包合集"
- 希望一次配置，所有 Maven 项目都能受益
- 有固定的内部依赖包存放位置（比如samba共享目录）
具体配置
编辑 Maven 安装目录下的 conf/settings.xml ，在 <profiles> 标签内添加如下配置：
<settings>
<profiles>
<profile>
<id>local-repo-profile</id>
<repositories>
<repository>
<id>local-shared-repo</id>
<name>本地共享仓库</name>
<url>file:///D:/repository</url>
<releases><enabled>true</enabled></releases>
<snapshots><enabled>true</enabled></snapshots>
</repository>
</repositories>
</profile>
</profiles>
<activeProfiles>
<activeProfile>local-repo-profile</activeProfile>
</activeProfiles>
</settings>
进阶玩法：指向网络共享目录
如果团队内部有一个samba共享文件夹，可以把这个仓库目录放上去，大家统一指向同一个地址：
<url>file:////192.168.3.211/share/maven/repository</url>
这样团队里只要有一个人负责更新这个共享仓库里的 jar，其他人就能自动"蹭"到最新的依赖。
优缺点
| 优点 | 缺点 |
|---|---|
| 一次配置，全局生效 | 需要修改 Maven 全局配置 |
| 支持团队共享（配合网络路径） | 依赖版本管理依然靠人工 |
| 对项目 pom 零侵入 | 切换环境时需要注意配置冲突 |
方案二：使用 Maven 镜像（Mirror）功能
这是一个比较"取巧"的方案——利用 Maven 的镜像机制，把原本指向失效私仓的请求，全部重定向到我们准备好的本地备份仓库。
适用场景
- 项目中大量 pom 文件已经写死了失效的私仓地址（比如
http://old-nexus.company.com） - 不想逐个修改项目的历史配置
- 希望以最小的改动代价让所有项目恢复正常
实现原理
Maven 的 Mirror 功能允许你拦截对特定仓库的请求，并将其重定向到另一个地址。当私仓地址已经失效，但项目的 pom 里还保留着这个地址时，我们可以通过 Mirror 配置，把所有发往这个地址的请求"截胡"到本地仓库。
具体配置
在 settings.xml 中添加如下 Mirror 配置：
<settings>
<mirrors>
<mirror>
<id>redirect-old-nexus-to-local</id>
<name>将失效私仓请求重定向到本地备份仓库</name>
<url>file:///D:/repository</url>
<!-- 如果有共享samba共享文件夹话团队也可以配置 -->
<!-- <url>file:////192.168.3.211/share/maven/repository</url> -->
<mirrorOf>xiuji2023</mirrorOf>
<!-- mirrorOf 的值需要和项目 pom 中声明的失效仓库 id 一致 -->
</mirror>
</mirrors>
</settings>
mirrorOf 的几种用法
| 写法 | 含义 |
|---|---|
old-nexus-repo |
只拦截 id 为 old-nexus-repo 的仓库请求 |
central |
拦截 Maven 中央仓库的请求 |
* |
拦截所有仓库请求（慎用，会绕过所有其他仓库） |
*,!central |
拦截所有仓库，但排除中央仓库 |
external:* |
拦截所有外部仓库请求，本地仓库除外 |
优缺点
| 优点 | 缺点 |
|---|---|
| 无需修改项目 pom 文件 | 理解门槛稍高，容易配错 mirrorOf |
| 对历史项目极其友好 | 必须知道失效仓库的确切 id |
| 切换回正常私仓只需注释配置 | 本地仓库必须包含所有需要的依赖 |
写在最后
说到底，这些方案都只是"救急不救穷"的临时手段。一个健康的项目依赖管理体系，终究还是需要一个稳定运行的私服仓库，配合规范的版本发布流程。
但现实往往不尽如人意——人员的流动、版本的迭代，都可能让曾经运转良好的基础设施变成"历史遗留问题"。作为开发者，我们能做的就是在理想与现实之间找到那个能先把活儿干完的平衡点。
如果你也有类似的经历，欢迎在评论区分享你的办法~
