简介gradle-7.2-all.zip 是 Gradle 7.2 版本的完整发行包面向使用 Android Studio 进行 Java 与 Android 项目开发的工程师尤其适合网络环境不稳定、在线下载 Gradle 速度过慢的开发者。该包内含 Gradle 运行时、库文件及相关工具可解压后在 Android Studio 中指定本地 Gradle 路径从而加快项目编译速度。压缩包为 zip 格式整体约 149.73MB上游未提供具体文件数量与类型明细但作为 all 发行版其内容覆盖构建脚本执行、依赖管理、多项目构建与插件支持等核心能力。已有 1465 人学习下载说明该版本在 Android 开发社区中具有较高的使用需求。借助本地化部署开发者可避免因网络波动导致的编译延迟更专注于依赖管理、自定义构建逻辑与 APK、AAR 等产物的生成提升整体开发效率。1. gradle-7.2-all.zip 到底是什么一次下载省掉后面所有等待如果你在 Android Studio 里点过 Sync然后盯着进度条卡在Download https://services.gradle.org/distributions/gradle-7.2-all.zip十几分钟不动那你已经踩到了这篇要讲的核心问题。gradle-7.2-all.zip是 Gradle 7.2 这个构建工具的完整发行包和常见的-bin.zip相比它额外打包了源码和文档体积更大但离线查阅 API、排查构建脚本报错时更省事。真正让国内开发者头疼的不是它是什么而是从官方地址拉这个包经常龟速甚至超时于是「gradle离线包」「gradle国内镜像」成了高频搜索词。这篇笔记面向的是被 Gradle 下载卡住、想彻底把构建环境本地化、又不想每次换项目重来一遍的 Android 和 Java 后端工程师。我会从包的区别讲到本地落地再到版本冲突和 DSL 报错的排查让你一次配好、长期受用。很多人第一次接触 Gradle 是被 Android Studio 带着走的根本没意识到构建工具本身也是要单独管理的。项目里的gradle-wrapper.properties决定了用哪个版本wrapper 负责去下载对应发行包。默认走官方 CDN国内网络下这个环节就是整个构建链路上最玄学的一段。理解这一点后面的所有操作才有落脚点我们不是去改项目代码而是去改「包从哪来、放在哪」这件事。2. all 与 bin 怎么选wrapper 又是怎么找包的2.1 三种发行包的区别与选型Gradle 官方给每个版本提供几种发行包名字后缀不同用途差别很大。搞混了会导致你下了半天发现根本用不上或者该有的东西没有。发行包后缀包含内容体积量级适用场景-bin.zip仅二进制可执行文件最小纯命令行构建、CI 环境-all.zip二进制 源码 文档最大本地开发、需要看源码和离线文档-src.zip仅源码中等只想读源码不跑构建选型逻辑很直接本地开发机、需要经常翻 Gradle 内部实现或者离线查文档就选-allCI 流水线、镜像体积敏感就选-bin。gradle-7.2-all.zip属于前者它多出来的源码对排查插件冲突、理解 task 执行顺序很有帮助。我一般本地一律用 all服务器一律用 bin这个习惯帮我省过不少「为什么本地能跑 CI 跑不了」的排查时间。2.2 wrapper 的解析顺序与本地缓存目录Gradle Wrapper 找包的顺序是有明确规则的搞清楚它你才知道该把离线包放哪。当你在项目根目录执行./gradlew时wrapper 会先读gradle/wrapper/gradle-wrapper.properties里的distributionUrl然后检查本地缓存目录里有没有对应版本没有才去下载。本地缓存目录默认在用户主目录下# Linux / macOS 默认缓存位置 ~/.gradle/wrapper/dists/ # Windows 默认缓存位置 C:\Users\你的用户名\.gradle\wrapper\dists\这个目录下的结构是按「版本 哈希」分层的比如gradle-7.2-all/一串哈希/里面才是解压后的文件和那个 zip 包。哈希是根据 distributionUrl 算出来的所以只要你改了 URL缓存目录名就会变旧的缓存不会被复用。这是很多人换了镜像却发现「怎么又下载了」的根本原因。# 查看当前项目声明的 Gradle 版本和下载地址 cat gradle/wrapper/gradle-wrapper.properties # 典型输出 # distributionBaseGRADLE_USER_HOME # distributionPathwrapper/dists # distributionUrlhttps\://services.gradle.org/distributions/gradle-7.2-all.zip # zipStoreBaseGRADLE_USER_HOME # zipStorePathwrapper/dists上面这段配置里distributionUrl是唯一决定「从哪下、下哪个版本」的字段。distributionBase和distributionPath拼出缓存根目录zipStoreBase和zipStorePath决定 zip 包存哪。默认它们指向同一个地方一般不用动。你要做的是把distributionUrl换成能快速拿到的地址或者干脆手动把包塞进缓存目录让 wrapper 以为已经下好了。提示改distributionUrl时注意转义properties 文件里冒号要写成\:否则解析会出问题。3. 把 gradle-7.2-all.zip 落到本地镜像替换与手动放置3.1 用国内镜像替换 distributionUrl最省事的做法是把下载地址换成国内镜像。常见做法是使用各大高校或云厂商提供的 Gradle 发行包镜像把distributionUrl指向对应版本的 all 包。改完之后执行一次./gradlew --versionwrapper 就会从新地址拉包。# gradle/wrapper/gradle-wrapper.properties # 把官方地址替换为国内镜像地址版本号保持 7.2 不变 distributionBaseGRADLE_USER_HOME distributionPathwrapper/dists distributionUrlhttps\://mirrors.cloud.tencent.com/gradle/gradle-7.2-all.zip zipStoreBaseGRADLE_USER_HOME zipStorePathwrapper/dists这里的关键是版本号必须和项目原本声明的完全一致gradle-7.2-all.zip就对应 7.2不能写成 7.2.1 或 7.2.0否则缓存目录哈希对不上等于白改。镜像地址只负责「从哪拿」不改变「拿哪个版本」。改完 properties 后建议先删掉旧的缓存目录再执行避免 wrapper 在旧目录里找到半成品。# 删除指定版本的旧缓存强制重新拉取 rm -rf ~/.gradle/wrapper/dists/gradle-7.2-all # 触发 wrapper 重新解析并下载 ./gradlew --version--version这个命令很轻只做版本解析和打印不会触发完整构建适合用来验证下载链路是否通了。如果它能在几十秒内打印出 Gradle 7.2 的版本信息说明镜像替换成功。3.2 完全离线手动放置 zip 包有些内网环境连镜像都访问不了那就只能手动放置。做法是先把gradle-7.2-all.zip通过其他途径拿到本地然后放进 wrapper 期望的缓存目录。难点在于那个哈希目录名它不能随便起。# 第一步先让 wrapper 尝试下载一次它会创建好哈希目录哪怕下载失败 ./gradlew --version # 第二步找到刚创建的目录里面通常有一个 .part 或 .lck 文件 ls -la ~/.gradle/wrapper/dists/gradle-7.2-all/ # 第三步把准备好的 zip 放进哈希目录并确保文件名正确 # 假设哈希目录是 abc123def cp /path/to/gradle-7.2-all.zip ~/.gradle/wrapper/dists/gradle-7.2-all/abc123def/ # 第四步wrapper 检测到完整 zip 后会自行解压 ./gradlew --version这个流程的逻辑是wrapper 先按 URL 算出哈希目录下载失败时目录已经建好了你把包塞进去它下次启动时发现 zip 存在且完整就直接解压使用不再联网。文件名必须严格是gradle-7.2-all.zip不能带(1)这种后缀。如果 wrapper 仍然尝试下载检查目录里是不是残留了.part文件删掉再试。注意手动放置时 zip 包要完整下载中断的半包会导致解压失败报错通常比较隐晦表现为「Could not install Gradle distribution」。3.3 全局配置让所有项目共用一份如果你机器上有多个项目都用 Gradle 7.2逐个改 properties 太累。可以在用户主目录下建一个全局的gradle.properties或者利用GRADLE_USER_HOME环境变量统一缓存位置。更彻底的做法是在~/.gradle/init.gradle里做全局仓库和分发配置但分发地址这块 wrapper 读的是项目级 properties全局覆盖能力有限所以常见做法还是统一缓存目录让多个项目共享同一份已下载的发行包。# 设置统一的 GRADLE_USER_HOME所有项目缓存都落这里 export GRADLE_USER_HOME/data/gradle-home # 之后所有 wrapper 下载都会进这个目录多项目复用 ls $GRADLE_USER_HOME/wrapper/dists/把GRADLE_USER_HOME固定下来团队里可以约定同一个路径甚至把已下载好的 dists 目录打包分发新人拿到就能直接用省掉每人各自下载的时间。这是我在团队里推行的做法比写一堆文档教人配镜像靠谱得多。4. 版本冲突与 DSL 报错那些让你构建失败的坑4.1 避坑与常见问题排查这一节集中讲几个高频翻车现场每条按现象、原因、解决来写都是我在实际项目里撞过的。现象一报错Could not install Gradle distribution from gradle-8.13-bin.zip但项目明明写的是 7.2。原因通常是 Android Studio 的 Gradle 设置里勾了「使用本地 Gradle 分发」或者 IDE 缓存了另一个版本的 wrapper 配置IDE 用自己的默认版本去拉包绕过了项目里的 properties。解决是打开 Settings → Build → Gradle确认使用的是「Gradle Wrapper」而不是本地分发然后 File → Invalidate Caches 清一次缓存。现象二error: gradle dsl method not found: minSdkVersion()。这是典型的 DSL 语法在新版本里被移除导致的。Gradle 7.x 配合较新的 Android Gradle Plugin 时minSdkVersion这种老写法在defaultConfig里已经不被识别要改成minSdk。原因是你升级了 Gradle 或 AGP但 build.gradle 还是老模板。解决是把minSdkVersion 21改成minSdk 21targetSdkVersion同理改成targetSdk。现象三deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0。这是警告不是错误但很多人忽略它等到升 Gradle 8 时集中爆发。原因是构建脚本或某个插件用了已废弃的 API。解决是加--warning-mode all跑一次定位到具体是哪个脚本哪一行逐个替换成新 API。别拖拖到升级时一起改成本更高。现象四you are applying Flutters main Gradle plugin imperatively using the apply script method。Flutter 项目里常见原因是用了老的apply from:方式引入 Flutter 的 Gradle 插件新版要求用 plugins DSL。解决是改成在settings.gradle里用pluginManagement声明或者按 Flutter 官方迁移指引改成声明式引入。这个报错不影响构建但会一直刷屏建议尽早处理。现象五换了镜像地址后仍然从官方下载。原因是distributionUrl改了但缓存目录哈希没变wrapper 在旧目录里找到了之前下载的残留文件或者 IDE 有自己的下载逻辑。解决是删掉对应版本的缓存目录命令行执行./gradlew --version验证确认走的是新地址再回 IDE。4.2 版本对齐Gradle、AGP、JDK 三者的关系gradle-7.2-all.zip不是孤立存在的它和 Android Gradle Plugin、JDK 版本之间有兼容矩阵。Gradle 7.2 通常搭配 AGP 7.0.x 到 7.1.xJDK 要求 11 及以上。如果你把 Gradle 升到 7.2 但 AGP 还是 4.x构建大概率失败。Gradle 版本推荐 AGP 版本最低 JDK7.07.0.x117.27.0.x - 7.1.x117.47.2.x118.08.0.x17对齐方法是在项目根目录的build.gradle里确认 AGP 版本在gradle-wrapper.properties里确认 Gradle 版本在 IDE 设置里确认 JDK 版本三者必须落在同一行兼容区间。我一般升级时先查这张表再动手改能避免大部分「升完就崩」的情况。// 项目根目录 build.gradle确认 AGP 版本 buildscript { dependencies { // 与 Gradle 7.2 搭配这里用 7.0.4 classpath com.android.tools.build:gradle:7.0.4 } }上面这段里classpath的版本就是 AGP 版本它和 Gradle 版本是两套独立的版本号但必须兼容。改 Gradle 版本时别忘了同步检查这里。5. 验证离线包是否真正生效以及一个长期习惯配完之后怎么确认真的用上了本地包而不是「看起来好了其实还在偷偷下载」我一般用三个动作验证。第一断网执行./gradlew --version能打印版本说明完全走本地。第二看缓存目录里 zip 是否已解压成文件夹解压后的目录里有bin、lib等子目录。第三跑一次./gradlew tasks --offline--offline强制离线模式如果任务列表能正常输出说明依赖和发行包都在本地齐了。# 强制离线模式跑一次任务列表验证本地包完整性 ./gradlew tasks --offline # 如果报「No cached version available for offline mode」 # 说明还有依赖没缓存需要先联网拉一次依赖--offline这个参数很实用它让 Gradle 完全不碰网络任何缺失的依赖都会直接报错而不是默默去下。用它来验证离线环境是否可用比断网测试更可控。注意它验证的是「发行包 依赖」整体如果只是发行包在本地但依赖没缓存仍然会失败这时候需要先联网跑一次完整构建把依赖拉齐。一个长期习惯是把GRADLE_USER_HOME固定到一个独立磁盘分区定期备份wrapper/dists目录。换机器或者重装系统时把这个目录拷回去所有项目的 Gradle 发行包直接复用省掉重复下载。我自己的这个目录攒了七八个常用版本从 6.x 到 8.x 都有新项目无论声明哪个版本基本都能秒开。这个习惯看起来笨但比每次临时找镜像、改配置要省心得多尤其是团队协作时一份打包好的 dists 目录能让新人当天就跑起来。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/9/25 23:59:13 · 阅读 1.2k Gradle 7.2 离线包配置指南：国内镜像与手动放置
简介gradle-7.2-all.zip 是 Gradle 7.2 版本的完整发行包面向使用 Android Studio 进行 Java 与 Android 项目开发的工程师尤其适合网络环境不稳定、在线下载 Gradle 速度过慢的开发者。该包内含 Gradle 运行时、库文件及相关工具可解压后在 Android Studio 中指定本地 Gradle 路径从而加快项目编译速度。压缩包为 zip 格式整体约 149.73MB上游未提供具体文件数量与类型明细但作为 all 发行版其内容覆盖构建脚本执行、依赖管理、多项目构建与插件支持等核心能力。已有 1465 人学习下载说明该版本在 Android 开发社区中具有较高的使用需求。借助本地化部署开发者可避免因网络波动导致的编译延迟更专注于依赖管理、自定义构建逻辑与 APK、AAR 等产物的生成提升整体开发效率。1. gradle-7.2-all.zip 到底是什么一次下载省掉后面所有等待如果你在 Android Studio 里点过 Sync然后盯着进度条卡在Download https://services.gradle.org/distributions/gradle-7.2-all.zip十几分钟不动那你已经踩到了这篇要讲的核心问题。gradle-7.2-all.zip是 Gradle 7.2 这个构建工具的完整发行包和常见的-bin.zip相比它额外打包了源码和文档体积更大但离线查阅 API、排查构建脚本报错时更省事。真正让国内开发者头疼的不是它是什么而是从官方地址拉这个包经常龟速甚至超时于是「gradle离线包」「gradle国内镜像」成了高频搜索词。这篇笔记面向的是被 Gradle 下载卡住、想彻底把构建环境本地化、又不想每次换项目重来一遍的 Android 和 Java 后端工程师。我会从包的区别讲到本地落地再到版本冲突和 DSL 报错的排查让你一次配好、长期受用。很多人第一次接触 Gradle 是被 Android Studio 带着走的根本没意识到构建工具本身也是要单独管理的。项目里的gradle-wrapper.properties决定了用哪个版本wrapper 负责去下载对应发行包。默认走官方 CDN国内网络下这个环节就是整个构建链路上最玄学的一段。理解这一点后面的所有操作才有落脚点我们不是去改项目代码而是去改「包从哪来、放在哪」这件事。2. all 与 bin 怎么选wrapper 又是怎么找包的2.1 三种发行包的区别与选型Gradle 官方给每个版本提供几种发行包名字后缀不同用途差别很大。搞混了会导致你下了半天发现根本用不上或者该有的东西没有。发行包后缀包含内容体积量级适用场景-bin.zip仅二进制可执行文件最小纯命令行构建、CI 环境-all.zip二进制 源码 文档最大本地开发、需要看源码和离线文档-src.zip仅源码中等只想读源码不跑构建选型逻辑很直接本地开发机、需要经常翻 Gradle 内部实现或者离线查文档就选-allCI 流水线、镜像体积敏感就选-bin。gradle-7.2-all.zip属于前者它多出来的源码对排查插件冲突、理解 task 执行顺序很有帮助。我一般本地一律用 all服务器一律用 bin这个习惯帮我省过不少「为什么本地能跑 CI 跑不了」的排查时间。2.2 wrapper 的解析顺序与本地缓存目录Gradle Wrapper 找包的顺序是有明确规则的搞清楚它你才知道该把离线包放哪。当你在项目根目录执行./gradlew时wrapper 会先读gradle/wrapper/gradle-wrapper.properties里的distributionUrl然后检查本地缓存目录里有没有对应版本没有才去下载。本地缓存目录默认在用户主目录下# Linux / macOS 默认缓存位置 ~/.gradle/wrapper/dists/ # Windows 默认缓存位置 C:\Users\你的用户名\.gradle\wrapper\dists\这个目录下的结构是按「版本 哈希」分层的比如gradle-7.2-all/一串哈希/里面才是解压后的文件和那个 zip 包。哈希是根据 distributionUrl 算出来的所以只要你改了 URL缓存目录名就会变旧的缓存不会被复用。这是很多人换了镜像却发现「怎么又下载了」的根本原因。# 查看当前项目声明的 Gradle 版本和下载地址 cat gradle/wrapper/gradle-wrapper.properties # 典型输出 # distributionBaseGRADLE_USER_HOME # distributionPathwrapper/dists # distributionUrlhttps\://services.gradle.org/distributions/gradle-7.2-all.zip # zipStoreBaseGRADLE_USER_HOME # zipStorePathwrapper/dists上面这段配置里distributionUrl是唯一决定「从哪下、下哪个版本」的字段。distributionBase和distributionPath拼出缓存根目录zipStoreBase和zipStorePath决定 zip 包存哪。默认它们指向同一个地方一般不用动。你要做的是把distributionUrl换成能快速拿到的地址或者干脆手动把包塞进缓存目录让 wrapper 以为已经下好了。提示改distributionUrl时注意转义properties 文件里冒号要写成\:否则解析会出问题。3. 把 gradle-7.2-all.zip 落到本地镜像替换与手动放置3.1 用国内镜像替换 distributionUrl最省事的做法是把下载地址换成国内镜像。常见做法是使用各大高校或云厂商提供的 Gradle 发行包镜像把distributionUrl指向对应版本的 all 包。改完之后执行一次./gradlew --versionwrapper 就会从新地址拉包。# gradle/wrapper/gradle-wrapper.properties # 把官方地址替换为国内镜像地址版本号保持 7.2 不变 distributionBaseGRADLE_USER_HOME distributionPathwrapper/dists distributionUrlhttps\://mirrors.cloud.tencent.com/gradle/gradle-7.2-all.zip zipStoreBaseGRADLE_USER_HOME zipStorePathwrapper/dists这里的关键是版本号必须和项目原本声明的完全一致gradle-7.2-all.zip就对应 7.2不能写成 7.2.1 或 7.2.0否则缓存目录哈希对不上等于白改。镜像地址只负责「从哪拿」不改变「拿哪个版本」。改完 properties 后建议先删掉旧的缓存目录再执行避免 wrapper 在旧目录里找到半成品。# 删除指定版本的旧缓存强制重新拉取 rm -rf ~/.gradle/wrapper/dists/gradle-7.2-all # 触发 wrapper 重新解析并下载 ./gradlew --version--version这个命令很轻只做版本解析和打印不会触发完整构建适合用来验证下载链路是否通了。如果它能在几十秒内打印出 Gradle 7.2 的版本信息说明镜像替换成功。3.2 完全离线手动放置 zip 包有些内网环境连镜像都访问不了那就只能手动放置。做法是先把gradle-7.2-all.zip通过其他途径拿到本地然后放进 wrapper 期望的缓存目录。难点在于那个哈希目录名它不能随便起。# 第一步先让 wrapper 尝试下载一次它会创建好哈希目录哪怕下载失败 ./gradlew --version # 第二步找到刚创建的目录里面通常有一个 .part 或 .lck 文件 ls -la ~/.gradle/wrapper/dists/gradle-7.2-all/ # 第三步把准备好的 zip 放进哈希目录并确保文件名正确 # 假设哈希目录是 abc123def cp /path/to/gradle-7.2-all.zip ~/.gradle/wrapper/dists/gradle-7.2-all/abc123def/ # 第四步wrapper 检测到完整 zip 后会自行解压 ./gradlew --version这个流程的逻辑是wrapper 先按 URL 算出哈希目录下载失败时目录已经建好了你把包塞进去它下次启动时发现 zip 存在且完整就直接解压使用不再联网。文件名必须严格是gradle-7.2-all.zip不能带(1)这种后缀。如果 wrapper 仍然尝试下载检查目录里是不是残留了.part文件删掉再试。注意手动放置时 zip 包要完整下载中断的半包会导致解压失败报错通常比较隐晦表现为「Could not install Gradle distribution」。3.3 全局配置让所有项目共用一份如果你机器上有多个项目都用 Gradle 7.2逐个改 properties 太累。可以在用户主目录下建一个全局的gradle.properties或者利用GRADLE_USER_HOME环境变量统一缓存位置。更彻底的做法是在~/.gradle/init.gradle里做全局仓库和分发配置但分发地址这块 wrapper 读的是项目级 properties全局覆盖能力有限所以常见做法还是统一缓存目录让多个项目共享同一份已下载的发行包。# 设置统一的 GRADLE_USER_HOME所有项目缓存都落这里 export GRADLE_USER_HOME/data/gradle-home # 之后所有 wrapper 下载都会进这个目录多项目复用 ls $GRADLE_USER_HOME/wrapper/dists/把GRADLE_USER_HOME固定下来团队里可以约定同一个路径甚至把已下载好的 dists 目录打包分发新人拿到就能直接用省掉每人各自下载的时间。这是我在团队里推行的做法比写一堆文档教人配镜像靠谱得多。4. 版本冲突与 DSL 报错那些让你构建失败的坑4.1 避坑与常见问题排查这一节集中讲几个高频翻车现场每条按现象、原因、解决来写都是我在实际项目里撞过的。现象一报错Could not install Gradle distribution from gradle-8.13-bin.zip但项目明明写的是 7.2。原因通常是 Android Studio 的 Gradle 设置里勾了「使用本地 Gradle 分发」或者 IDE 缓存了另一个版本的 wrapper 配置IDE 用自己的默认版本去拉包绕过了项目里的 properties。解决是打开 Settings → Build → Gradle确认使用的是「Gradle Wrapper」而不是本地分发然后 File → Invalidate Caches 清一次缓存。现象二error: gradle dsl method not found: minSdkVersion()。这是典型的 DSL 语法在新版本里被移除导致的。Gradle 7.x 配合较新的 Android Gradle Plugin 时minSdkVersion这种老写法在defaultConfig里已经不被识别要改成minSdk。原因是你升级了 Gradle 或 AGP但 build.gradle 还是老模板。解决是把minSdkVersion 21改成minSdk 21targetSdkVersion同理改成targetSdk。现象三deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0。这是警告不是错误但很多人忽略它等到升 Gradle 8 时集中爆发。原因是构建脚本或某个插件用了已废弃的 API。解决是加--warning-mode all跑一次定位到具体是哪个脚本哪一行逐个替换成新 API。别拖拖到升级时一起改成本更高。现象四you are applying Flutters main Gradle plugin imperatively using the apply script method。Flutter 项目里常见原因是用了老的apply from:方式引入 Flutter 的 Gradle 插件新版要求用 plugins DSL。解决是改成在settings.gradle里用pluginManagement声明或者按 Flutter 官方迁移指引改成声明式引入。这个报错不影响构建但会一直刷屏建议尽早处理。现象五换了镜像地址后仍然从官方下载。原因是distributionUrl改了但缓存目录哈希没变wrapper 在旧目录里找到了之前下载的残留文件或者 IDE 有自己的下载逻辑。解决是删掉对应版本的缓存目录命令行执行./gradlew --version验证确认走的是新地址再回 IDE。4.2 版本对齐Gradle、AGP、JDK 三者的关系gradle-7.2-all.zip不是孤立存在的它和 Android Gradle Plugin、JDK 版本之间有兼容矩阵。Gradle 7.2 通常搭配 AGP 7.0.x 到 7.1.xJDK 要求 11 及以上。如果你把 Gradle 升到 7.2 但 AGP 还是 4.x构建大概率失败。Gradle 版本推荐 AGP 版本最低 JDK7.07.0.x117.27.0.x - 7.1.x117.47.2.x118.08.0.x17对齐方法是在项目根目录的build.gradle里确认 AGP 版本在gradle-wrapper.properties里确认 Gradle 版本在 IDE 设置里确认 JDK 版本三者必须落在同一行兼容区间。我一般升级时先查这张表再动手改能避免大部分「升完就崩」的情况。// 项目根目录 build.gradle确认 AGP 版本 buildscript { dependencies { // 与 Gradle 7.2 搭配这里用 7.0.4 classpath com.android.tools.build:gradle:7.0.4 } }上面这段里classpath的版本就是 AGP 版本它和 Gradle 版本是两套独立的版本号但必须兼容。改 Gradle 版本时别忘了同步检查这里。5. 验证离线包是否真正生效以及一个长期习惯配完之后怎么确认真的用上了本地包而不是「看起来好了其实还在偷偷下载」我一般用三个动作验证。第一断网执行./gradlew --version能打印版本说明完全走本地。第二看缓存目录里 zip 是否已解压成文件夹解压后的目录里有bin、lib等子目录。第三跑一次./gradlew tasks --offline--offline强制离线模式如果任务列表能正常输出说明依赖和发行包都在本地齐了。# 强制离线模式跑一次任务列表验证本地包完整性 ./gradlew tasks --offline # 如果报「No cached version available for offline mode」 # 说明还有依赖没缓存需要先联网拉一次依赖--offline这个参数很实用它让 Gradle 完全不碰网络任何缺失的依赖都会直接报错而不是默默去下。用它来验证离线环境是否可用比断网测试更可控。注意它验证的是「发行包 依赖」整体如果只是发行包在本地但依赖没缓存仍然会失败这时候需要先联网跑一次完整构建把依赖拉齐。一个长期习惯是把GRADLE_USER_HOME固定到一个独立磁盘分区定期备份wrapper/dists目录。换机器或者重装系统时把这个目录拷回去所有项目的 Gradle 发行包直接复用省掉重复下载。我自己的这个目录攒了七八个常用版本从 6.x 到 8.x 都有新项目无论声明哪个版本基本都能秒开。这个习惯看起来笨但比每次临时找镜像、改配置要省心得多尤其是团队协作时一份打包好的 dists 目录能让新人当天就跑起来。希望帮到你。本文还有配套的精品资源点击获取