简介gradle-8.6-all.zip 是 Gradle 8.6 完整发行压缩包面向 Java、Android 及 JVM 生态开发者用于快速获取并部署新版构建工具省去官方下载缓慢或配置繁琐的问题。资源共 2000 个文件以 1962 个 java 源码与类文件为主附带 34 个 properties 配置文件、3 个 txt 说明文档和 1 个 pdf 文档压缩包整体约 209.99MB解压后即可配合 CLI 或 Wrapper 脚本使用。版本重点包含自定义加密密钥配置缓存、构建初始化脚手架改进、构建创作 API 扩展等特性并针对依赖解析与缓存操作做了性能优化适合需要升级构建链路或评估新特性的团队与个人。已有 1665 人学习下载资源包目录结构完整可作为离线安装、插件开发验证或构建环境标准化的基础素材。 每次在 Android Studio 里新建项目十有八九都要经历一次漫长的等待Gradle 在后台下载 gradle-8.6-all.zip。网络好的时候几分钟网络不好的时候直接报Could not install Gradle distribution项目还没开始写先跟构建工具干一架。说真的这个问题坑了我很多年后来我干脆把离线包、镜像源、本地配置这套东西彻底梳理了一遍总算把每次都要下载 Gradle这个痛点按死了。这篇文章就是我的完整实操记录。内容包括怎么快速拿到 gradle-8.6-all.zip怎么把它装好、配置好以及怎么让 Android Studio 不再每次新建项目都重新下载一遍。适合被 Gradle 下载折磨过的 Android 开发者也适合需要给团队搭建统一构建环境的同学。我尽量把每个步骤背后的原因也讲清楚而不是单纯甩链接因为只有理解了原理换任何版本你都能自己搞定。1. 先说结论为什么 gradle-8.6-all.zip 值得提前备着很多人以为快速下载的关键是找一个快的下载源其实只对了一半。下载源只是第一步真正决定你后续是否省心的是版本选型、安装方式、以及 wrapper 和 Android Studio 的配置。这篇文章的顺序就是按实际排查路径来的先搞懂要哪个包再下载装好最后把它和你的构建流程彻底整合起来。Gradle 8.6 是 2024 年 2 月发布的版本距今已经算成熟版本不是新版也不是旧版。它之所以高频出现是因为 AGP 8.4.x 这一代 Android 构建工具链明确要求 Gradle 最低版本是 8.6而 Jellyfish、Koala 时期的 Android Studio 新项目模板也经常默认指向它。所以你只要还在维护 2024 年前后的 Android 项目就大概率绕不开这个 zip。提前备好它至少能省下每次开新项目时干等下载的时间。2. 快速下载前先搞懂你要的到底是哪个包2.1 all 包和 bin 包怎么选很多人看到 gradle-8.6-all.zip 就直接下载其实 Gradle 官方分发文件分两种-bin和-all。bin 是精简版只有运行时必需的东西all 是在 bin 的基础上多带了源码和文档体积大不少。gradle-8.6-all.zip 差不多 200MB 上下bin 大概 130MB 左右。如果你只是为了跑构建bin 完全够用但如果你要读 Gradle 插件源码、写自定义 Task或者想在 IDE 里跳转到 Gradle 内部实现那 all 包会有更好的体验。我自己的习惯是本机开发装 all 包CI 或者 Docker 里用 bin 包。因为 CI 环境只需要执行构建源码注释没有任何意义多下 70MB 纯属浪费。这里有个细节Android Studio 默认的 wrapper 配置经常把distributionUrl指向gradle-8.6-all.zip所以你如果只是想解决 AS 卡下载那就老老实实下 all 包别自己换成 bin否则 Gradle 会觉得版本和 wrapper 不一致又要重新下载。2.2 Gradle 8.6 与 AGP/Android Studio 的兼容关系Gradle 升级不是越高越好要看 AGP 的脸色。我整理了一张常用对应表基于我踩过的坑和 Google 官方兼容性说明组件推荐版本备注Gradle8.6发行版 gradle-8.6-all.zip / binAGP8.4.x要求最低 Gradle 8.6Java17 / 21JDK 17 最稳21 可用Android StudioJellyfish / Koala新项目模板常用 Gradle 8.6如果你的项目里com.android.tools.build:gradle是 8.4.x那 wrapper 配置 8.6 是很稳的。但如果你还在用 AGP 8.1 这种老版本它对应的 Gradle 可能是 8.0强行升到 8.6 反而会触发各种不兼容。反过来AGP 8.5 建议搭 Gradle 8.7 以上你用 8.6 跑大概率也能过但没必要在边缘试探。另外Gradle 8.6 对 Java 21 的支持已经比较完善能用 JDK 21 跑构建。不过保守环境下我仍然推荐 JDK 17因为很多老插件和代码生成器在 17 下的表现更稳定。这个选择不是越新越好而是不给自己找麻烦。3. 三种快速下载 gradle-8.6-all.zip 的方案实测3.1 腾讯和华为云镜像国内速度最快的路径Gradle 官方地址在services.gradle.org国内访问经常不稳定所以优先用镜像。我在实践中最常用的是腾讯软件源和华为云镜像格式都很好记https://mirrors.cloud.tencent.com/gradle/gradle-8.6-all.zip https://mirrors.huaweicloud.com/gradle/gradle-8.6-all.zip注意一下这两个镜像的路径里没有版本子目录直接拼文件名即可。用浏览器直接打开就能下载速度基本能跑到内网级别。如果遇到 404大概率是镜像同步延迟这时候去该镜像的 gradle 目录页手动确认文件列表看看 Gradle 官方发布 8.6 之后镜像跟没跟上。附带提一句清华 TUNA 镜像也收录 Gradle 发行版格式类似https://mirrors.tuna.tsinghua.edu.cn/gradle/可以作为备选。我实际用下来腾讯和华为的稳定性最好TUNA 偶尔因为流量高峰会变慢。提示所有镜像都有同步延迟如果发现某个镜像缺文件别硬等换个源试试十秒内解决问题。3.2 命令行下载与断点续传如果你是 Linux 服务器或者想自动化下载用 wget 加-c参数wget -c https://mirrors.cloud.tencent.com/gradle/gradle-8.6-all.zip-c是断点续传下载中断后重新执行同一命令可以从上次的位置继续不用重头再来。Windows 上如果你有 Git Bash 或者 WSL同样命令可用。如果你只有 PowerShell可以用curl.exe -L -o gradle-8.6-all.zip https://mirrors.cloud.tencent.com/gradle/gradle-8.6-all.zipPowerShell 里的curl其实是Invoke-WebRequest的别名行为和参数跟 Linux curl 完全不同很容易踩坑所以一定要用curl.exe强制调用原生 curl。这个细节我吃过亏不加.exe的时候经常下载出一堆乱七八糟的 HTML 文件。3.3 局域网离线包的另类思路如果团队里有多个人都要这个包不要每个人都从外网拉。更好的做法是下载一次放到团队内部的 HTTP 服务、公司 NAS 或者对象存储上然后所有人的distributionUrl都指向内网地址。我在公司就是这么干的一个 200MB 的包存在内网20 个同事同时构建也就是瞬间的事而且完全不依赖外网稳定。这个思路背后其实是 Gradle 本身的设计Wrapper 只是根据distributionUrl把压缩包下载到GRADLE_USER_HOME/wrapper/dists然后验证校验和并解压。只要这个 URL 能拿到文件它是官方域名还是内网地址根本不关心。这种机制决定了离线包分发其实非常简单。4. 下载之后手动安装与全局配置4.1 解压与校验不校验你就等着被坑下载完成后别急着解压先对一下 SHA-256。Gradle 官方每个发行版都有一个.sha256文件镜像站点通常也会同步。校验方式很简单# Linux/macOS shasum -a 256 gradle-8.6-all.zip # Windows PowerShell Get-FileHash gradle-8.6-all.zip -Algorithm SHA256然后把输出的哈希值和官方站点公布的值对比。这一步很多人跳过但它非常重要因为 Gradle 在解压前会自动校验一次哈希如果文件不完整或者被篡改它会在解压阶段报错到时候你还是得回头重新下载。提前校验能省一个来回。顺带说一个容易混淆的知识点安卓项目里经常说的获取 SHA1和校验文件用的 SHA-256 完全是两回事。打包签名证书的 SHA1 可以用./gradlew signingReport拿到是给 Google Maps、Firebase 之类的服务配 key 用的。别把这两个概念混在一起。4.2 GRADLE_HOME 与 PATH 配置我建议把 Gradle 解压到一个不含空格、路径不要太深的目录。Windows 我一般放在D:\dev\gradle-8.6macOS/Linux 放在/opt/gradle/gradle-8.6。环境变量配置GRADLE_HOMED:\dev\gradle-8.6 PATH%GRADLE_HOME%\bin;%PATH%Linux/macOS 加到~/.bashrc或~/.zshrcexport GRADLE_HOME/opt/gradle/gradle-8.6 export PATH$GRADLE_HOME/bin:$PATH配置完重新开终端执行gradle -v能正常输出版本信息就说明装好了。注意gradle -v输出的第一行是 Gradle 版本下面的 JVM 信息是当前终端用的 JDK这两个要分清很多人把 JDK 版本当成 Gradle 版本造成误会。注意环境变量配置完后务必重新打开终端再执行gradle -v同一个终端窗口不重新加载配置容易觉得是白配了。4.3 让 Android Studio 用上本地 GradleAndroid Studio 默认走 wrapper 下载但你可以强制它用本地安装的 Gradle 发行版。打开Settings - Build, Execution, Deployment - Build Tools - Gradle把Gradle distribution从Wrapper改成Local installation然后选中你解压出来的目录。这样 IDE 不会再尝试通过网络拉发行版老项目基本能秒开。不过这里有个经验如果项目里配置的是 gradle-8.6-all.zip而你本地只有 bin建议先用 wrapper 方式让它下载一次或者把本地包换成 all否则可能因为版本不匹配出现各种奇怪问题。这个坑我踩过几次后来干脆固定用 all 包省心。5. 让离线包真正生效wrapper 指向与本地仓库5.1 改 distributionUrl一行配置解决重复下载项目根目录的gradle/wrapper/gradle-wrapper.properties是核心文件。默认配置长这样distributionBaseGRADLE_USER_HOME distributionPathwrapper/dists distributionUrlhttps\://services.gradle.org/distributions/gradle-8.6-all.zip要指向本地发行版可以改成distributionUrlfile\:///D:/dev/gradle-8.6-all.zipLinux 下类似distributionUrlfile\:///opt/gradle/gradle-8.6-all.zip改完之后执行./gradlew buildGradle Wrapper 会从本地文件解压而不是网络下载。这样即使新 clone 的项目只要本地有这个 zip也一样秒过Could not install的坎。补充一个细节file://后面是绝对路径Windows 下盘符和斜杠的写法容易错file\:///D:/path这个三斜杠格式是最稳的。注意 URL 中冒号要转义成\:这是 Java Properties 文件的规则忘写了会解析失败。5.2 统一镜像仓库不用每个项目改 sources离线发行版解决了 Gradle 本身的下载但项目依赖的 Maven 包依然要下载所以还得配置仓库镜像。最方便的做法是在GRADLE_USER_HOME/init.d/下放一个init.gradle文件内容大致如下allprojects { repositories { maven { url https://maven.aliyun.com/repository/public } maven { url https://maven.aliyun.com/repository/google } maven { url https://maven.aliyun.com/repository/gradle-plugin } mavenCentral() google() } }这个文件会全局生效对所有项目统一注入镜像仓库。需要注意过度的全局配置可能会修改项目原本的仓库优先级遇到仓库冲突时要谨慎建议先用maven { url ... }放在最前面让依赖优先从国内镜像拉取。阿里云镜像比较全Google 仓库的 AndroidX 依赖和 AGP 也都有镜像。如果你有自定义模块要发布到本地 Maven 仓库可以在build.gradle里应用maven-publish插件然后执行./gradlew publishToMavenLocal。它会在~/.m2/repository下生成 jar/aar 和对应的 pom 文件之后在全局仓库配置里加一个mavenLocal()就能直接引用。这个操作很适合团队内部沉淀公共组件。5.3 完全离线构建--offline 与 gradle 缓存如果你已经在本机把依赖都拉过一遍还可以使用--offline参数让构建不请求任何远程仓库./gradlew assembleDebug --offline加上这个参数后Gradle 只从本地缓存解析依赖不走网络。对于出差、断网环境下继续开发来说很实用。这条命令在 CI 上其实也比较常见有专门的缓存机预热依赖然后给构建机挂载本地缓存目录硬生生把编译时间降下来。Gradle 的依赖缓存目录默认在GRADLE_USER_HOME/caches如果你要备份所有本地依赖直接把整个目录拷走就行。把 caches 目录拷给同事配合相同的仓库配置基本可以达到复制即用的效果。这个操作比每次重新拉依赖靠谱得多。6. 高频报错与排查记录6.1 Could not install Gradle distribution大概率是网络这个错误非常典型本质就是 wrapper 从distributionUrl下载失败。排查顺序我建议这样先看错误信息里带的 URL 是什么如果是官方域名先改成镜像如果用了镜像还不行就手动 curl 一下这个 URL看是不是 404 或者超时如果本机能下载但 Gradle 下载超时多半是网络代理配置问题检查系统代理和GRADLE_OPTS里的https.proxyHost等属性。这个错误还有一个隐藏原因磁盘空间不足。GRADLE_USER_HOME/wrapper/dists默认在用户目录下如果 C 盘满了解压到一半就会报错。检查一下磁盘剩余空间顺便养成把GRADLE_USER_HOME指到大分区的习惯。比如我机器上export GRADLE_USER_HOME/data/gradle-home这样可以把几百 GB 的缓存和发行版都放到项目盘避免系统盘爆掉。6.2 Deprecated features 警告看不懂也别慌新版 Gradle 在构建日志里经常出现Deprecated Gradle features were used in this build, making it incompatible with the upcoming version这句话的意思是项目里某个插件或配置使用了新版本不推荐的老 API未来可能移除。它只是一个警告不影响构建成功但如果你的项目计划升 Gradle 大版本这些警告最终会变成错误。排查方法是用--warning-mode all重新构建让 Gradle 列出具体的弃用信息然后逐个修复。常见来源是老版 AGP、Kotlin DSL 脚本里的旧写法、以及自定义插件里用project.compile()这类已经不推荐的方法。这里额外提一句如果你在使用 Flutter 项目时看到类似applying Flutters main Gradle plugin imperatively的报错那是 Flutter 的 Gradle 插件还停留在旧写法通常在 Flutter 升级后会一并修复可以暂时忽略但要留意 Flutter 版本的更新提示。6.3 Android Studio 每次新建项目都下载 Gradle用本地缓存解决这个问题其实和 Android Studio 的模板项目有关。AS 每次新建项目都会生成一个新的gradle-wrapper.properties里面的distributionUrl指向官方源它不会智能地发现你本地已经装了 Gradle。所以哪怕你本机gradle -v正常新项目照样下载。解决方案有两个方向一是统一改本地的distributionUrl默认值二是提前把 gradle-8.6-all.zip 放到GRADLE_USER_HOME/wrapper/dists对应目录下让 wrapper 检测到已经存在就不再下载。第二个方向有个坑dists 目录下的子目录命名带着哈希值这个哈希是根据 distributionUrl 算出来的路径放错位置 Gradle 也认不出来。与其手工构造目录不如用gradle wrapper --gradle-distribution-url这种命令生成标准结构或者干脆把项目模板里的 wrapper 改成内网地址。6.4 升级 AGP 的迁移错觉别把 Gradle 升级当解药老项目从com.android.tools.build:gradle:4.2.0往上升第一反应往往是顺便把 Gradle wrapper 升到最新结果一堆兼容性问题。正确做法是逐步推进先升 AGP 到 8.4.x同时把 Gradle 升到 8.6两者配套不要跨太多大版本。升级后如果遇到 namespace 缺失、packagingOptions被替换为packaging、buildTypes里proguardFiles写法变更等问题都说明你升级的还是太急。建议每升一个版本就构建一次把错误逐个解决而不是等着攒一堆一起修。迁移的过程中顺手把.gradle目录清掉让 Gradle 重新解析依赖也能避免老缓存把项目状态搞乱。这个小步快跑的思路比一次性大版本跳跃靠谱得多。我自己在一次团队迁移中就被 Gradle 下载这个问题卡了一下午后来把解决方案整理成一份文档顺便做了离线包的本地镜像。从那以后所有同事新建项目时基本不会再遇到构建瘫痪的情况。最后再分享一个小技巧如果你经常需要处理不同项目的 Gradle 版本可以把常用版本的 zip 离线包统一放在一个目录里然后写一个简单的脚本根据gradle-wrapper.properties自动匹配版本并放到 dists 目录。这个思路可以延伸出很多自动化玩法把下载这一步从每天重复折腾变成一次到位你的开发体验会完全不一样。本文还有配套的精品资源点击获取