可安全删除 wrapper/dists 下指定 Gradle 版本的哈希子目录，如 ~/.gradle/wrapper/dists/gradle-8.5-bin/4z10279q066p68r3a0x1jyv7k，只需确认该目录内无完整 gradle-8.5/ 解压内容或存在 .zip.part 等损坏文件，删除后不影响其他版本，下次执行 ./gradlew 会自动重下并解压。
只删 wrapper/dists 里某个 Gradle 版本的缓存
Gradle Wrapper 下载的发行包（如 gradle-8.5-bin.zip）都存在 ~/.gradle/wrapper/dists/ 目录下，每个版本一个子目录。这些子目录名是经过哈希处理的（比如 gradle-8.5-bin/4z10279q066p68r3a0x1jyv7k），不是直接可读的版本号——但你**不需要猜哈希值**，只要定位到对应版本就能安全删除。
常见触发场景：项目切换了 gradle-wrapper.properties 中的 distributionUrl，旧版本不再使用，但磁盘空间被占满；或某次下载中断导致该版本目录里只有部分文件（如缺 gradle-8.5-bin.zip.part 或解压后缺失 gradle-8.5/ 文件夹），引发 Could not download gradle-8.5-bin.zip 类错误。
- 先查当前项目用的版本：
cat gradle/wrapper/gradle-wrapper.properties | grep distributionUrl，拿到类似https\://services.gradle.org/distributions/gradle-8.5-bin.zip - 进全局缓存目录：
ls -la ~/.gradle/wrapper/dists/，你会看到一堆以gradle-X.Y-开头的文件夹 - 逐个进可疑文件夹（比如
gradle-8.5-bin/xxxxxx），检查里面是否有完整的gradle-8.5/子目录；若只有.zip.part、空文件夹，或gradle-8.5/下明显缺bin/或lib/，就说明损坏 - 确认无误后执行：
rm -rf ~/.gradle/wrapper/dists/gradle-8.5-bin/xxxxxx（只删这一层，不影响其他版本）
为什么不能直接删整个 wrapper/dists？
因为多个项目可能依赖不同 Gradle 版本。比如 A 项目用 gradle-7.6，B 项目刚升级到 gradle-8.5，C 项目还在试 gradle-8.7-rc。全删会强制所有项目重新下载，浪费带宽和时间，还可能在离线环境直接构建失败。
更隐蔽的风险是：某些旧版 Gradle（如 gradle-4.10.3）对应的哈希目录名里含特殊字符或空格，用通配符 rm -rf ~/.gradle/wrapper/dists/gradle-4.* 可能误匹配、漏删或报错。
- 安全做法永远是「先
ls，再cd，最后rm -rf」三步手动确认 - Windows 用户注意路径：
%USERPROFILE%\.gradle\wrapper\dists\，命令用rd /s /q替代rm -rf - 删完不用重启 IDE，下次运行
./gradlew --version时会自动重下并解压新缓存
删完 wrapper 缓存后 build 还失败？检查 AGP 版本是否匹配
gradle-wrapper.properties 指定的是 Gradle 引擎版本，而 build.gradle 里 com.android.tools.build:gradle 插件（即 AGP）必须与之兼容。比如 gradle-8.5 官方支持的最高 AGP 是 8.5.0，若你写了 8.6.0，就会报 Unable to find method 'org.gradle.api.provider.Provider.get()'... 这类方法找不到错误——这跟 wrapper 缓存无关，是版本协议断裂。
- 查官方兼容矩阵：AGP-Gradle Compatibility Table
- 快速验证：
./gradlew --dry-run能提前暴露插件加载失败，比等编译到一半再崩更快 - 别靠 IDE 自动提示改 AGP 版本——它有时推荐非 LTS 版本，优先选带
.0后缀的稳定版
真正难清理的从来不是某个 zip 包，而是那些没被显式声明、却通过 transitive 依赖悄悄混进 caches/modules-2 的快照版本（-SNAPSHOT）。它们不会出现在 gradle-wrapper.properties 里，但一旦污染，连 cleanBuildCache 都清不干净。
