Maven仓库（如jCenter、MavenCentral）宕机时的应急方案探讨

问题背景 #

多数Android项目都会引入外部依赖库，相比手动导入jar包，通过Gradle依赖的方式更便于添加、管理和更新，这些依赖一般托管在jCenter、MavenCentral这类公共仓库中。但这种方式存在明显风险——一旦公共仓库宕机或者停止服务（比如jCenter sunset后仅保留只读权限，部分依赖仅能从这里获取），项目的干净构建就会失败，直接拖慢开发效率。

大厂（Airbnb、Uber等）的应对方式 #

这类企业普遍通过搭建内部私有缓存仓库来解决问题，核心逻辑是把项目用到的所有依赖（包括直接依赖和传递性依赖）都缓存到自有仓库中：

• 配置Gradle优先从内部私有仓库拉取依赖，仅当私有仓库无对应版本时，才去公共仓库获取并同步缓存；
• 建立定期同步机制，确保私有仓库能及时更新所需依赖版本，同时会对依赖做合规性、安全性扫描，规避风险；
• 部分大厂还会维护内部组件库，将常用功能封装成内部依赖，降低对外部公共库的依赖程度。

中小公司/团队的轻量解决方案 #

不需要搭建复杂的企业级系统，以下几种方案成本低且易落地：

• 共享Gradle本地缓存：Gradle默认会在~/.gradle/caches/modules-2目录缓存已下载的依赖，可将该目录通过内网共享盘同步给团队成员。公共仓库不可用时，团队直接使用共享缓存即可构建，注意要统一依赖版本，避免缓存差异。
• 搭建轻量私有仓库：使用Nexus OSS或Artifactory Community Edition这类开源工具，配置简单、资源占用低。将私有仓库设为Gradle的优先源，公共仓库作为后备，平时依赖会自动缓存到私有仓库，公共仓库故障时直接用私有缓存构建。
• 锁定版本+离线构建：项目中明确锁定所有依赖的具体版本（禁止使用implementation 'com.example:lib:+'这类动态版本号），定期测试离线构建。公共仓库不可用时，执行./gradlew build --offline命令，基于本地缓存完成构建。
• 本地托管关键依赖：对于仅存在于即将停止服务的仓库（如jCenter）的核心依赖，手动下载对应的aar/jar包到项目libs目录，改用本地依赖方式引入，彻底摆脱对该公共仓库的依赖。

内容的提问来源于stack exchange，提问作者HBB20