私有仓库（如nexus/artifactory）是解决构建中断最稳定可控的方式，它通过内网代理缓存、托管内部构件及安全扫描三重职责，替代不可控的外网依赖拉取，成为构建链路的“稳压器”。
直接用本地私有仓库替代外网拉取，是解决构建中断最稳定、最可控的方式。核心不是“绕开网络”，而是把依赖获取环节从不可控的公网，变成完全由你掌控的本地服务。
明确三类仓库的实际分工
构建失败常源于混淆了三者的角色：
- 本地仓库（~/.m2/repository）：只是缓存层，不提供共享能力；清空后仍需联网重下，无法解决团队或离线场景问题
- 中央仓库（repo.maven.apache.org）：默认源，但受网络、限速、合规策略影响大，不适合作为生产构建唯一依赖源
- 私有仓库（如 Nexus/Artifactory）：部署在内网，同时承担代理缓存 + 内部构件托管 + 安全扫描三重职责，才是构建链路的“稳压器”
搭建私有仓库的关键动作
不是装完软件就完事，重点在于让构建流程真正“信任”它：
- 配置 Nexus 代理远程仓库（Maven Central、Spring Plugins 等），首次请求自动缓存，后续全部走内网
- 将团队自研的二方库（common-utils、auth-sdk 等）统一 deploy 到私有仓库的 hosted 类型仓库，禁止直接 push 到本地目录
- 在项目的 settings.xml 中强制指定
<mirrorof>*</mirrorof>，确保所有依赖解析都经由私有仓库中转，不直连公网 - CI 流水线机器只配置私有仓库地址，彻底断开与中央仓库的网络通路，从机制上杜绝意外外连
应对突发外网中断的兜底策略
即使私有仓库已上线，也要准备离线保底方案：
- 定期导出私有仓库中高频使用的依赖（含传递依赖），生成离线包集合（tar.gz），存于 NAS 或 Git LFS
- 编写简易脚本，在检测到网络不可达时，自动执行
mvn install:install-file将离线包批量装入本地仓库 - Docker 构建中，改用
FROM private-registry.example.com/openjdk:17替代 public 镜像，基础镜像也走内网
验证是否真正生效
别只看构建成功，要确认流量没偷偷溜出去：
- 运行
mvn dependency:tree -Dverbose，检查所有依赖的 repository URL 是否指向私有仓库地址 - 临时关闭外网，在干净环境执行
mvn clean compile—— 若能完整跑通，说明私有仓库已承载全部依赖链 - 查看 Nexus 后台的 “Routing Rules” 和 “Repository Health Check”，确认无大量 404 或 proxy timeout 日志
构建中断的本质，是把关键路径交给了外部变量。本地私有仓库不是锦上添花的优化项，而是把控制权拿回来的必要基建。
