简介本资源为 Gradle 8.3 完整发行包面向使用 Java、Kotlin 及 Android 构建的开发者与构建工程师用于升级或搭建本地构建环境。该版本支持持久性 Java 编译器守护进程以加速 Java 编译并降低依赖解析的内存占用对 Android 等大型构建效果尤为明显同时支持在 Java 20 上运行Kotlin DSL 构建作者还可试用带有限制的 K2 编译器。包内共 2000 个文件以 1998 个 Java 源码文件为主另含 1 个 txt 与 1 个 pdf 说明文档压缩包约 190.98MB涵盖核心插件、服务注册、构建监听与源码解析等模块便于查阅实现细节。目前已有 2131 人学习下载适合需要快速获取官方发行包、研究构建机制或排查编译性能问题的中高级开发者参考使用。1. gradle-8.3-all.zip 快速下载从卡在 30% 到本地离线可用的完整路径如果你最近在跑 Android 构建或者 Java 多模块项目大概率见过这个场景gradle-8.3-all.zip卡在 30% 不动或者干脆超时重试控制台刷出一串Connection reset。这个包本身不神秘它是 Gradle 8.3 的完整发行版压缩包带源码和文档体积比-bin版本大不少但离线环境、CI 缓存、多机器复用都靠它。问题在于官方分发节点对国内网络不总是友好很多人第一次配 Gradle Wrapper 就栽在这一步。这篇笔记面向正在搭构建环境、需要把 Gradle 8.3 落到本地或内网仓库的开发者把下载、校验、配置、排错整条链路拆开讲新手能照着走熟手能直接抄参数。2. 先搞清楚 gradle-8.3-all.zip 里装了什么选型与目录结构2.1 all 和 bin 到底差在哪什么时候必须用 allGradle 发行包有三个常见变体-bin、-all、-src。-bin只有运行时二进制体积最小-all在-bin基础上多了源码、文档和完整的 API 参考-src只有源码。很多人默认用-bin就够了直到 IDE 里点进 Gradle 内部类发现没有源码或者需要离线查 DSL 文档时才后悔。gradle-8.3-all.zip解压后的目录结构大致是这样目录/文件作用是否可裁剪bin/gradle和gradle.bat启动脚本否lib/核心 jar 与依赖否docs/DSL、API、用户手册可裁剪src/核心源码可裁剪init.d/全局初始化脚本目录否LICENSE、NOTICE许可文件否选型建议很直接本地开发机、需要 IDE 源码跳转、内网无外网访问用-all纯 CI 构建节点、只跑不读源码-bin更省带宽。但如果你打算把包放进内网 Nexus 或 Artifactory 做统一分发-all一次到位省得后面有人要源码又得重新传。2.2 Wrapper 机制为什么改了distributionUrl还是走官方源Gradle Wrapper 的核心是项目根目录下gradle/wrapper/gradle-wrapper.properties里的distributionUrl。很多人改了这行以为就切源了结果构建时还是去官方拉原因是 Wrapper 的 jar 本身有缓存而且 IDE 可能用了自己维护的 Gradle 实例。先看默认配置长什么样# gradle/wrapper/gradle-wrapper.properties distributionBaseGRADLE_USER_HOME distributionPathwrapper/dists distributionUrlhttps\://services.gradle.org/distributions/gradle-8.3-all.zip zipStoreBaseGRADLE_USER_HOME zipStorePathwrapper/dists关键参数说明distributionBase和zipStoreBase都指向GRADLE_USER_HOME默认是~/.gradledistributionPath和zipStorePath决定解压和压缩包存放的子目录。distributionUrl里的反斜杠是 properties 文件对冒号的转义不能省。如果你已经把gradle-8.3-all.zip下到本地最稳的做法不是改 URL 指向某个临时地址而是直接放进 Wrapper 的缓存目录让 Gradle 认为它已经下载过。缓存路径规则是# 查看当前 GRADLE_USER_HOME echo $GRADLE_USER_HOME # 未设置时默认 ls ~/.gradle/wrapper/dists/进去后你会看到类似gradle-8.3-all/hash/的目录那个 hash 是根据distributionUrl算出来的。把 zip 放进去再手动触发一次构建Gradle 会校验并解压。这个方法的坑在于 hash 目录名必须和当前distributionUrl完全对应换一个 URL 字符串 hash 就变了所以改 URL 和放缓存二选一别混着来。3. 把 gradle-8.3-all.zip 落到本地的三种实操路径3.1 路径一直接下载后手动放置缓存这是最不依赖网络工具的方式。先拿到 zip 文件确认大小和校验值然后按 hash 目录放进去。# 1. 确认文件完整性官方提供 sha256 sha256sum gradle-8.3-all.zip # 对比官方 checksum 文件中的值不一致就别用 # 2. 找到 Wrapper 期望的缓存目录 # 先跑一次构建让它生成目录结构会失败但目录会建 ./gradlew --version || true # 3. 查看生成的 hash 目录 ls -la ~/.gradle/wrapper/dists/gradle-8.3-all/ # 4. 把 zip 复制进去假设 hash 目录为 abc123 cp gradle-8.3-all.zip ~/.gradle/wrapper/dists/gradle-8.3-all/abc123/ # 5. 重新触发Gradle 会校验并解压 ./gradlew --version逻辑说明第 2 步故意让构建失败是为了让 Wrapper 创建出目标目录和.lck、.part等标记文件这样你才知道确切的 hash 目录名。第 4 步复制进去后Gradle 下次启动会检查 zip 的完整性通过后解压到同目录下的gradle-8.3/文件夹。参数上唯一要注意的是文件权限Linux/macOS 下确保当前用户可读Windows 下路径不要有中文和空格。3.2 路径二改 distributionUrl 指向内网或本地文件服务如果团队有内网文件服务把 zip 传上去然后统一改 Wrapper 配置。这是多项目复用的推荐做法。# gradle/wrapper/gradle-wrapper.properties distributionBaseGRADLE_USER_HOME distributionPathwrapper/dists # 指向内网文件服务注意用 https 或 http 按实际环境 distributionUrlhttp\://内网文件服务地址/gradle-8.3-all.zip zipStoreBaseGRADLE_USER_HOME zipStorePathwrapper/dists改完后必须做一件事清理旧的 hash 缓存否则 Gradle 可能继续用旧目录。# 删除旧的 dists 缓存确认没有其他项目依赖后再删 rm -rf ~/.gradle/wrapper/dists/gradle-8.3-all/ # 重新触发下载 ./gradlew --version参数说明distributionUrl的协议头要和文件服务一致http 环境下部分 Gradle 版本会警告但不阻断。如果内网服务需要认证URL 里带用户名密码的方式不推荐容易泄露在版本控制里常见做法是用gradle.properties配代理或者让文件服务走匿名只读。3.3 路径三完全离线模式禁用 Wrapper 下载有些隔离环境完全不允许任何网络请求这时候要让 Gradle 直接用本地解压好的发行版绕过 Wrapper 下载逻辑。# 1. 手动解压到固定目录 unzip gradle-8.3-all.zip -d /opt/ # 得到 /opt/gradle-8.3/ # 2. 配置环境变量让 gradle 命令直接可用 export GRADLE_HOME/opt/gradle-8.3 export PATH$GRADLE_HOME/bin:$PATH # 3. 项目里不用 ./gradlew直接用 gradle gradle --version gradle build逻辑说明这种方式跳过了 Wrapper 的版本管理好处是彻底离线坏处是团队里每个人的 Gradle 版本可能不一致。常见做法是在 CI 镜像里预装好/opt/gradle-8.3然后在构建脚本里显式用绝对路径调用避免 PATH 污染。参数上注意GRADLE_HOME不要指向解压后的bin目录要指向发行版根目录。提示三种路径不要混用。手动放缓存后又改 URLhash 对不上会导致重复下载离线模式又保留./gradlew调用可能触发意外的网络请求。4. 下载与配置 gradle-8.3-all.zip 的避坑排查清单4.1 坑一zip 下到一半文件大小对但解压报错现象gradle-8.3-all.zip显示下载完成大小看起来正常但 Gradle 解压时报zip END header not found或invalid LOC header。原因下载过程中连接中断文件被截断但文件系统缓存或下载工具没有正确标记失败。部分下载工具会预分配空间导致文件大小看起来对实际内容是空的或残缺。解决永远用 sha256 校验不要只看大小。官方 checksum 文件里gradle-8.3-all.zip对应的值可以直接比对。校验不过就删掉重下别抱侥幸心理。如果反复失败换路径二的内网文件服务方式。# 校验示例输出需与官方 checksum 一致 sha256sum gradle-8.3-all.zip4.2 坑二Wrapper hash 目录对不上放了 zip 还是重新下载现象明明把 zip 放进了~/.gradle/wrapper/dists/gradle-8.3-all/下的某个目录构建时还是去网络拉。原因distributionUrl字符串变了Gradle 根据 URL 重新计算 hash生成了新的目录。你放 zip 的目录是旧 URL 对应的自然不被识别。解决先确认当前gradle-wrapper.properties里的distributionUrl完整值然后让 Gradle 跑一次生成新目录再把 zip 放进新目录。或者干脆不改 URL用默认官方地址生成目录后放 zip这样 hash 一定匹配。4.3 坑三IDE 不走 Wrapper用了内置 Gradle现象命令行./gradlew --version已经正常但 IDE 里构建还是慢或者报错。原因IDE 的 Gradle 设置里默认可能选了Use Gradle from: gradle-wrapper.properties file之外的选项比如本地安装的 Gradle 或者 IDE 捆绑版本。解决在 IDE 设置里显式指定用 Wrapper路径指向项目下的gradle/wrapper/gradle-wrapper.properties。同时确认 IDE 的Gradle user home和命令行一致否则缓存目录不同等于白配。4.4 坑四多项目共享缓存时的锁竞争现象多个项目同时构建偶尔报Timeout waiting to lock artifact cache或Unable to delete file。原因多个 Gradle 进程共用同一个GRADLE_USER_HOMEWrapper 解压和依赖缓存都有文件锁并发高时互相等待。解决CI 环境给每个并行任务配独立的GRADLE_USER_HOME用环境变量区分。本地开发一般不会遇到但如果同时开多个 IDE 窗口跑构建可以错开时间或者给不同项目配不同 home。4.5 坑五Windows 下路径过长导致解压失败现象Windows 上解压gradle-8.3-all.zip时报路径过长或者解压后部分文件缺失。原因-all包里的源码和文档目录层级深加上GRADLE_USER_HOME默认在C:\Users\用户名\.gradle总路径容易超过 260 字符限制。解决把GRADLE_USER_HOME改到盘符根目录下的短路径比如D:\gradle_home。在系统环境变量里设置然后重启终端和 IDE。这个改动对已有缓存有影响需要重新下载依赖但一劳永逸。5. 验证 gradle-8.3-all.zip 是否真正生效的进阶技巧配完之后怎么确认用的就是 8.3 的 all 版本而不是碰巧走了别的实例我一般会走一套组合验证避免“看起来好了”的假象。第一步查版本和发行版信息./gradlew --version输出里会显示Gradle 8.3但不会直接告诉你是不是 all 版本。接着看源码是否可访问# 在项目里执行打印 Gradle 核心类的源码位置 ./gradlew -q javaToolchains || true # 更直接的方式检查缓存目录下是否有 src 和 docs ls ~/.gradle/wrapper/dists/gradle-8.3-all/*/gradle-8.3/src/ ls ~/.gradle/wrapper/dists/gradle-8.3-all/*/gradle-8.3/docs/如果src/和docs/存在说明解压的是 all 包。如果只有bin/和lib/那可能是 bin 包被误放了。第二步验证构建实际使用的 Gradle 实例# 在项目根目录执行输出 Wrapper 配置和实际使用的发行版路径 ./gradlew -q properties | grep -i gradle关注gradleHome和gradleVersion两个属性。gradleHome应该指向~/.gradle/wrapper/dists/gradle-8.3-all/hash/gradle-8.3如果指向别处说明 Wrapper 没生效。第三步做一个最小构建验证确认没有隐藏的网络请求# 加 --offline 强制离线能跑通说明本地缓存完整 ./gradlew build --offline--offline模式下如果还能成功说明gradle-8.3-all.zip的解压和依赖缓存都到位了。如果报缺少依赖那是项目依赖的问题不是 Gradle 发行版的问题分开排查。一个我踩过的坑有次在 CI 上配好了缓存本地也验证通过但 CI 每次还是重新下载。后来发现 CI 的 Docker 镜像里GRADLE_USER_HOME被设成了临时目录每次构建都是全新的缓存根本没挂载进去。从那以后我每次配 CI 都强制走一遍echo $GRADLE_USER_HOME和ls $GRADLE_USER_HOME/wrapper/dists/确认缓存目录是持久化的再跑构建。这个习惯帮我省了很多次“明明配了却没用”的排查时间。希望帮到你。本文还有配套的精品资源点击获取
简介本资源为 Gradle 8.3 完整发行包面向使用 Java、Kotlin 及 Android 构建的开发者与构建工程师用于升级或搭建本地构建环境。该版本支持持久性 Java 编译器守护进程以加速 Java 编译并降低依赖解析的内存占用对 Android 等大型构建效果尤为明显同时支持在 Java 20 上运行Kotlin DSL 构建作者还可试用带有限制的 K2 编译器。包内共 2000 个文件以 1998 个 Java 源码文件为主另含 1 个 txt 与 1 个 pdf 说明文档压缩包约 190.98MB涵盖核心插件、服务注册、构建监听与源码解析等模块便于查阅实现细节。目前已有 2131 人学习下载适合需要快速获取官方发行包、研究构建机制或排查编译性能问题的中高级开发者参考使用。1. gradle-8.3-all.zip 快速下载从卡在 30% 到本地离线可用的完整路径如果你最近在跑 Android 构建或者 Java 多模块项目大概率见过这个场景gradle-8.3-all.zip卡在 30% 不动或者干脆超时重试控制台刷出一串Connection reset。这个包本身不神秘它是 Gradle 8.3 的完整发行版压缩包带源码和文档体积比-bin版本大不少但离线环境、CI 缓存、多机器复用都靠它。问题在于官方分发节点对国内网络不总是友好很多人第一次配 Gradle Wrapper 就栽在这一步。这篇笔记面向正在搭构建环境、需要把 Gradle 8.3 落到本地或内网仓库的开发者把下载、校验、配置、排错整条链路拆开讲新手能照着走熟手能直接抄参数。2. 先搞清楚 gradle-8.3-all.zip 里装了什么选型与目录结构2.1 all 和 bin 到底差在哪什么时候必须用 allGradle 发行包有三个常见变体-bin、-all、-src。-bin只有运行时二进制体积最小-all在-bin基础上多了源码、文档和完整的 API 参考-src只有源码。很多人默认用-bin就够了直到 IDE 里点进 Gradle 内部类发现没有源码或者需要离线查 DSL 文档时才后悔。gradle-8.3-all.zip解压后的目录结构大致是这样目录/文件作用是否可裁剪bin/gradle和gradle.bat启动脚本否lib/核心 jar 与依赖否docs/DSL、API、用户手册可裁剪src/核心源码可裁剪init.d/全局初始化脚本目录否LICENSE、NOTICE许可文件否选型建议很直接本地开发机、需要 IDE 源码跳转、内网无外网访问用-all纯 CI 构建节点、只跑不读源码-bin更省带宽。但如果你打算把包放进内网 Nexus 或 Artifactory 做统一分发-all一次到位省得后面有人要源码又得重新传。2.2 Wrapper 机制为什么改了distributionUrl还是走官方源Gradle Wrapper 的核心是项目根目录下gradle/wrapper/gradle-wrapper.properties里的distributionUrl。很多人改了这行以为就切源了结果构建时还是去官方拉原因是 Wrapper 的 jar 本身有缓存而且 IDE 可能用了自己维护的 Gradle 实例。先看默认配置长什么样# gradle/wrapper/gradle-wrapper.properties distributionBaseGRADLE_USER_HOME distributionPathwrapper/dists distributionUrlhttps\://services.gradle.org/distributions/gradle-8.3-all.zip zipStoreBaseGRADLE_USER_HOME zipStorePathwrapper/dists关键参数说明distributionBase和zipStoreBase都指向GRADLE_USER_HOME默认是~/.gradledistributionPath和zipStorePath决定解压和压缩包存放的子目录。distributionUrl里的反斜杠是 properties 文件对冒号的转义不能省。如果你已经把gradle-8.3-all.zip下到本地最稳的做法不是改 URL 指向某个临时地址而是直接放进 Wrapper 的缓存目录让 Gradle 认为它已经下载过。缓存路径规则是# 查看当前 GRADLE_USER_HOME echo $GRADLE_USER_HOME # 未设置时默认 ls ~/.gradle/wrapper/dists/进去后你会看到类似gradle-8.3-all/hash/的目录那个 hash 是根据distributionUrl算出来的。把 zip 放进去再手动触发一次构建Gradle 会校验并解压。这个方法的坑在于 hash 目录名必须和当前distributionUrl完全对应换一个 URL 字符串 hash 就变了所以改 URL 和放缓存二选一别混着来。3. 把 gradle-8.3-all.zip 落到本地的三种实操路径3.1 路径一直接下载后手动放置缓存这是最不依赖网络工具的方式。先拿到 zip 文件确认大小和校验值然后按 hash 目录放进去。# 1. 确认文件完整性官方提供 sha256 sha256sum gradle-8.3-all.zip # 对比官方 checksum 文件中的值不一致就别用 # 2. 找到 Wrapper 期望的缓存目录 # 先跑一次构建让它生成目录结构会失败但目录会建 ./gradlew --version || true # 3. 查看生成的 hash 目录 ls -la ~/.gradle/wrapper/dists/gradle-8.3-all/ # 4. 把 zip 复制进去假设 hash 目录为 abc123 cp gradle-8.3-all.zip ~/.gradle/wrapper/dists/gradle-8.3-all/abc123/ # 5. 重新触发Gradle 会校验并解压 ./gradlew --version逻辑说明第 2 步故意让构建失败是为了让 Wrapper 创建出目标目录和.lck、.part等标记文件这样你才知道确切的 hash 目录名。第 4 步复制进去后Gradle 下次启动会检查 zip 的完整性通过后解压到同目录下的gradle-8.3/文件夹。参数上唯一要注意的是文件权限Linux/macOS 下确保当前用户可读Windows 下路径不要有中文和空格。3.2 路径二改 distributionUrl 指向内网或本地文件服务如果团队有内网文件服务把 zip 传上去然后统一改 Wrapper 配置。这是多项目复用的推荐做法。# gradle/wrapper/gradle-wrapper.properties distributionBaseGRADLE_USER_HOME distributionPathwrapper/dists # 指向内网文件服务注意用 https 或 http 按实际环境 distributionUrlhttp\://内网文件服务地址/gradle-8.3-all.zip zipStoreBaseGRADLE_USER_HOME zipStorePathwrapper/dists改完后必须做一件事清理旧的 hash 缓存否则 Gradle 可能继续用旧目录。# 删除旧的 dists 缓存确认没有其他项目依赖后再删 rm -rf ~/.gradle/wrapper/dists/gradle-8.3-all/ # 重新触发下载 ./gradlew --version参数说明distributionUrl的协议头要和文件服务一致http 环境下部分 Gradle 版本会警告但不阻断。如果内网服务需要认证URL 里带用户名密码的方式不推荐容易泄露在版本控制里常见做法是用gradle.properties配代理或者让文件服务走匿名只读。3.3 路径三完全离线模式禁用 Wrapper 下载有些隔离环境完全不允许任何网络请求这时候要让 Gradle 直接用本地解压好的发行版绕过 Wrapper 下载逻辑。# 1. 手动解压到固定目录 unzip gradle-8.3-all.zip -d /opt/ # 得到 /opt/gradle-8.3/ # 2. 配置环境变量让 gradle 命令直接可用 export GRADLE_HOME/opt/gradle-8.3 export PATH$GRADLE_HOME/bin:$PATH # 3. 项目里不用 ./gradlew直接用 gradle gradle --version gradle build逻辑说明这种方式跳过了 Wrapper 的版本管理好处是彻底离线坏处是团队里每个人的 Gradle 版本可能不一致。常见做法是在 CI 镜像里预装好/opt/gradle-8.3然后在构建脚本里显式用绝对路径调用避免 PATH 污染。参数上注意GRADLE_HOME不要指向解压后的bin目录要指向发行版根目录。提示三种路径不要混用。手动放缓存后又改 URLhash 对不上会导致重复下载离线模式又保留./gradlew调用可能触发意外的网络请求。4. 下载与配置 gradle-8.3-all.zip 的避坑排查清单4.1 坑一zip 下到一半文件大小对但解压报错现象gradle-8.3-all.zip显示下载完成大小看起来正常但 Gradle 解压时报zip END header not found或invalid LOC header。原因下载过程中连接中断文件被截断但文件系统缓存或下载工具没有正确标记失败。部分下载工具会预分配空间导致文件大小看起来对实际内容是空的或残缺。解决永远用 sha256 校验不要只看大小。官方 checksum 文件里gradle-8.3-all.zip对应的值可以直接比对。校验不过就删掉重下别抱侥幸心理。如果反复失败换路径二的内网文件服务方式。# 校验示例输出需与官方 checksum 一致 sha256sum gradle-8.3-all.zip4.2 坑二Wrapper hash 目录对不上放了 zip 还是重新下载现象明明把 zip 放进了~/.gradle/wrapper/dists/gradle-8.3-all/下的某个目录构建时还是去网络拉。原因distributionUrl字符串变了Gradle 根据 URL 重新计算 hash生成了新的目录。你放 zip 的目录是旧 URL 对应的自然不被识别。解决先确认当前gradle-wrapper.properties里的distributionUrl完整值然后让 Gradle 跑一次生成新目录再把 zip 放进新目录。或者干脆不改 URL用默认官方地址生成目录后放 zip这样 hash 一定匹配。4.3 坑三IDE 不走 Wrapper用了内置 Gradle现象命令行./gradlew --version已经正常但 IDE 里构建还是慢或者报错。原因IDE 的 Gradle 设置里默认可能选了Use Gradle from: gradle-wrapper.properties file之外的选项比如本地安装的 Gradle 或者 IDE 捆绑版本。解决在 IDE 设置里显式指定用 Wrapper路径指向项目下的gradle/wrapper/gradle-wrapper.properties。同时确认 IDE 的Gradle user home和命令行一致否则缓存目录不同等于白配。4.4 坑四多项目共享缓存时的锁竞争现象多个项目同时构建偶尔报Timeout waiting to lock artifact cache或Unable to delete file。原因多个 Gradle 进程共用同一个GRADLE_USER_HOMEWrapper 解压和依赖缓存都有文件锁并发高时互相等待。解决CI 环境给每个并行任务配独立的GRADLE_USER_HOME用环境变量区分。本地开发一般不会遇到但如果同时开多个 IDE 窗口跑构建可以错开时间或者给不同项目配不同 home。4.5 坑五Windows 下路径过长导致解压失败现象Windows 上解压gradle-8.3-all.zip时报路径过长或者解压后部分文件缺失。原因-all包里的源码和文档目录层级深加上GRADLE_USER_HOME默认在C:\Users\用户名\.gradle总路径容易超过 260 字符限制。解决把GRADLE_USER_HOME改到盘符根目录下的短路径比如D:\gradle_home。在系统环境变量里设置然后重启终端和 IDE。这个改动对已有缓存有影响需要重新下载依赖但一劳永逸。5. 验证 gradle-8.3-all.zip 是否真正生效的进阶技巧配完之后怎么确认用的就是 8.3 的 all 版本而不是碰巧走了别的实例我一般会走一套组合验证避免“看起来好了”的假象。第一步查版本和发行版信息./gradlew --version输出里会显示Gradle 8.3但不会直接告诉你是不是 all 版本。接着看源码是否可访问# 在项目里执行打印 Gradle 核心类的源码位置 ./gradlew -q javaToolchains || true # 更直接的方式检查缓存目录下是否有 src 和 docs ls ~/.gradle/wrapper/dists/gradle-8.3-all/*/gradle-8.3/src/ ls ~/.gradle/wrapper/dists/gradle-8.3-all/*/gradle-8.3/docs/如果src/和docs/存在说明解压的是 all 包。如果只有bin/和lib/那可能是 bin 包被误放了。第二步验证构建实际使用的 Gradle 实例# 在项目根目录执行输出 Wrapper 配置和实际使用的发行版路径 ./gradlew -q properties | grep -i gradle关注gradleHome和gradleVersion两个属性。gradleHome应该指向~/.gradle/wrapper/dists/gradle-8.3-all/hash/gradle-8.3如果指向别处说明 Wrapper 没生效。第三步做一个最小构建验证确认没有隐藏的网络请求# 加 --offline 强制离线能跑通说明本地缓存完整 ./gradlew build --offline--offline模式下如果还能成功说明gradle-8.3-all.zip的解压和依赖缓存都到位了。如果报缺少依赖那是项目依赖的问题不是 Gradle 发行版的问题分开排查。一个我踩过的坑有次在 CI 上配好了缓存本地也验证通过但 CI 每次还是重新下载。后来发现 CI 的 Docker 镜像里GRADLE_USER_HOME被设成了临时目录每次构建都是全新的缓存根本没挂载进去。从那以后我每次配 CI 都强制走一遍echo $GRADLE_USER_HOME和ls $GRADLE_USER_HOME/wrapper/dists/确认缓存目录是持久化的再跑构建。这个习惯帮我省了很多次“明明配了却没用”的排查时间。希望帮到你。本文还有配套的精品资源点击获取
