Gradle依赖解析慢的根源在于仓库查询链路：按repositories声明顺序逐个发起HTTP请求，直至命中；jcenter已关停却仍保留会导致30秒超时等待，私有仓库置末位或同质镜像并存均加剧耗时，应按命中率排序、精简冗余仓库。
Gradle 依赖解析慢，根源在仓库查询链路
Gradle 每次解析一个依赖（比如 implementation 'com.squareup.okhttp3:okhttp:4.12.0'），不是直接去某个仓库“取”，而是按 repositories{} 块中声明的顺序，逐个仓库发起 HTTP 请求，直到找到该坐标对应的 .pom 和 .jar。仓库越多、顺序越乱，失败重试和网络等待就越多。
多个仓库导致的典型耗时场景
常见问题不是“找不到”，而是“找得太久”：
-
jcenter()已于 2021 年关停，但很多老项目仍保留该行 —— Gradle 会真实发起 DNS 查询 + TCP 握手 + TLS 握手，超时后才切到下一个仓库，单次超时默认约 30 秒 - 内部私有仓库（如 Nexus）配置在列表末尾，而绝大多数依赖其实都来自它 —— 每次都要先白跑 2～3 个外部仓库，再回到内部源
- 同一组织多个镜像（
maven{ url 'https://maven.aliyun.com' }和maven{ url 'https://maven.tuna.tsinghua.edu.cn' }同时存在）—— 实际只用一个，另一个纯属冗余等待
怎么验证仓库是否拖慢构建
不用猜，用 --scan 看真实行为：
执行 ./gradlew build --scan，打开生成的 Build Scan 页面，在 “Dependency Resolution” 标签页下，点开任意一个慢依赖，能看到每个仓库的请求耗时、是否命中、是否超时。如果某仓库显示 “Failed to resolve” 或 “Timed out”，它就是瓶颈。
更轻量的方式是加日志：./gradlew build -Dorg.gradle.internal.http.verbose=true，控制台会打印每次 HTTP 请求的 URL 和状态码。
精简仓库配置的实操原则
目标不是“删仓库”，而是让高频依赖以最小跳转拿到：
- 删掉已废弃的仓库：彻底移除
jcenter()和mavenCentral() // legacy这类注释误导项 - 按命中率排序：把公司私有仓库放第一位（90%+ 依赖在此）、
mavenCentral()第二位（剩余开源依赖主力）、第三方源（如 JitPack）最后 - 避免同质镜像并存：阿里云、清华、华为镜像选其一即可；国内项目优先用
maven{ url 'https://maven.aliyun.com/repository/public' } - 对 CI 环境额外加锁：在 CI 脚本里用
-Pandroid.useAndroidX=true等参数触发一次构建后，再检查~/.gradle/caches/modules-2/metadata-目录下实际下载了哪些仓库的元数据，反向验证配置有效性
真正影响速度的，从来不是“有没有镜像”，而是“Gradle 在哪一步开始浪费时间”。仓库顺序错一位，可能让每个模块多等 2 秒 —— 30 个模块就是整整一分钟。
