先确认远程缓存是否真正启用：Gradle默认仅开本地缓存，需显式配置org.gradle.cache.remote.url且在Build Scan中验证“Remote cache”显示“Enabled”及非零命中率。
远程缓存读写慢，先确认是不是真在用远程缓存
很多项目以为自己开了远程缓存，其实根本没生效。Gradle 默认只启用本地缓存，org.gradle.caching=true 只是打开构建缓存总开关，不等于自动连上远程服务器。org.gradle.cache.remote.url 必须显式配置，且 URL 要能被构建机访问（注意网络策略、代理、DNS 解析）。运行 ./gradlew build --scan，在 Build Scan 的 “Build Cache” 标签页里看 “Remote cache” 是否显示为 “Enabled”，命中率是否非零——如果写的是 “Not configured” 或 “Disabled”，那所有“慢”的讨论都无意义。
远程缓存慢的三大常见瓶颈点
真正拖慢远程缓存的，往往不是 Gradle 本身，而是底层基础设施或配置偏差：
- 缓存服务器响应延迟高：比如 Artifactory 实例部署在公网云上，但构建机在内网，每次请求都要绕行；或服务器磁盘是机械盘、未开启 HTTP/2、TLS 握手耗时长
- 缓存 key 冲突或频繁失效：任务输入包含时间戳、随机数、未声明的环境变量（如
System.getenv("BUILD_NUMBER")），导致相同逻辑每次生成不同 hash，无法复用 - 网络带宽或并发限制：Gradle 默认最多 4 个并发上传/下载连接（
org.gradle.internal.http.connectionTimeout和org.gradle.internal.http.socketTimeout也影响超时重试行为）
怎么调参让远程缓存真正快起来
别只改 org.gradle.caching=true，这些参数才是关键：
- 提高并发：在
gradle.properties加org.gradle.cache.remote.http.connections=16（Gradle 8.5+ 支持） - 缩短超时：加
org.gradle.internal.http.connectionTimeout=5000和org.gradle.internal.http.socketTimeout=30000，避免单个失败请求卡住整条流水线 - 强制走 HTTP/2：确保缓存服务端支持，并在 URL 中用
https://（HTTP/1.1 不支持多路复用） - 禁用校验（仅限可信内网）：加
org.gradle.cache.remote.allowInsecureProtocol=false并配合自签名证书信任链，避免 TLS 验证拖慢小文件传输
示例配置片段：
org.gradle.caching=true org.gradle.cache.remote.url=https://artifactory.internal/cache/ org.gradle.cache.remote.http.connections=16 org.gradle.internal.http.connectionTimeout=5000
比调参更有效的解法：本地 + 远程两级缓存联动
远程缓存再快也比不上本地 SSD 读取。正确做法不是放弃远程，而是让它只承担“跨机器共享”职责，高频复用仍走本地：
- CI 构建机统一挂载共享 NFS 或 SMB 卷作为
org.gradle.cache.local.directory，让同一台机器上多个 job 复用本地缓存 - 开发机保留默认本地缓存（
.gradle目录），远程缓存仅用于 pull，不 push（避免污染团队缓存） - 在 CI 脚本开头加
gradle --stop是大忌——它会 kill daemon，连带清空内存中刚预热的缓存索引，后续请求全走磁盘+网络
最容易被忽略的一点：远程缓存服务器自身的磁盘 I/O 和 JVM 堆配置。Artifactory 默认堆只有 2G，一旦缓存条目过万，GC 频繁，响应毛刺明显——这个层面的瓶颈，Gradle 端再怎么调参也补不回来。
