Gradle构建缓存caches/build-cache-1可安全删除，但清空整个.caches会导致依赖重下、构建变慢甚至CorruptConfigurationCacheException；需按用途区分：modules-2/files-2.1不可整删，transforms-2/jars-3可删，configuration-cache可删；推荐用./gradlew cleanBuildCache等命令精准清理，避免rm -rf ~/.gradle/caches；长期方案是通过GRADLE_USER_HOME迁移缓存目录。
Gradle构建缓存本身（caches/build-cache-1）可以安全删除，但盲目清空整个 .gradle/caches 会导致所有依赖重下、构建变慢，甚至触发 CorruptConfigurationCacheException。
哪些缓存能删、哪些不能碰
Gradle的caches/目录不是“一锅端”的垃圾堆，而是按用途严格分层的。关键判断依据是：是否被当前任一项目正在引用。
-
caches/build-cache-1/：构建输出缓存（如编译产物、aar解压结果），启用后生成，默认不自动清理。✅ 可直接删，下次构建会重建，不影响依赖解析 -
caches/modules-2/files-2.1/：核心依赖缓存（JAR/AAR/POM）。❌ 不建议整删——它支持多项目共享，删了所有项目都会重新下载；✅ 仅可删其中明确无引用的子路径（需先运行./gradlew dependencies --configuration implementation确认） -
caches/transforms-2/和caches/jars-3/：AAR处理、字节码转换中间产物。✅ 常见“僵尸缓存”，尤其在切换AGP版本后残留，可删 -
caches/configuration-cache/：配置缓存快照。✅ 可删，但首次复用时会慢一点（需重新生成）
用命令精准清理，避免误伤
手动进文件夹点删除风险高，推荐用Gradle自带机制触发安全清理：
- 停止所有守护进程：
./gradlew --stop（防止文件被锁） - 清理过期插件元数据：
./gradlew --no-daemon --refresh-dependencies（强制刷新依赖图，间接标记无引用缓存） - 删除构建缓存专用命令：
./gradlew cleanBuildCache（只动build-cache-1，Gradle 6.6+ 支持） - 若需深度清理，加
--no-daemon后运行：./gradlew build --scan，再检查 Build Scan 报告里的缓存命中率，确认哪些模块真没被用
为什么 rm -rf ~/.gradle/caches 是最危险的操作
这个操作看似彻底，实则破坏Gradle内部的哈希指纹链和元数据一致性协议。例如：
-
caches/modules-2/modules-2.lock被删后，Gradle无法校验已下载依赖的完整性，可能跳过验证直接复用损坏文件 -
caches/plugins/中插件元数据缺失，会导致PluginResolutionException，尤其影响自定义插件或旧版AGP - Android项目中
transforms-2缓存丢失，可能触发InvalidUserDataException，报错指向某个.aar签名验证失败
真正省空间又安全的长期方案
清理是治标，迁移才是治本。Gradle用户主目录默认在C盘，但可以通过环境变量永久重定向：
- Windows：设置系统环境变量
GRADLE_USER_HOME=D:\AndroidDev\.gradle（注意不是GRADLE_HOME） - 验证生效：
gradle properties | findstr "gradleUserHome"，输出应为新路径 - 后续所有新项目、Wrapper下载、依赖缓存都会落到D盘，原有C盘
.gradle可等新环境稳定后再手动删
迁移后仍要定期执行 cleanBuildCache，因为构建缓存不会随迁移自动转移——它只在新路径下新建，旧缓存留在原地，这才是真正该删的部分。
