Gradle 占满 C 盘时，先确认是哪一类缓存变大，再决定删什么。Gradle 本身会定期清理旧缓存；如果现在就需要腾空间，可以停止构建进程后清理选定的缓存文件夹，但清理依赖之前要确认还能重新下载。项目源代码不在这些全局缓存里。
先找到占空间的文件夹
在文件资源管理器地址栏输入 %USERPROFILE%\.gradle。这是 Windows 10 和 11 上默认的 Gradle 用户主目录。如果设置过 GRADLE_USER_HOME 环境变量，就打开它指定的位置。分别右键点击 caches、wrapper 和 daemon，选择“属性”查看大小，不要看到 .gradle 很大就整目录删除。
caches 里放的是不同用途的数据。modules-2 保存下载的依赖及其元数据；启用本地构建缓存时，build-cache-* 保存可复用的任务输出；caches\<version> 这类目录与特定 Gradle 版本有关。其他共享缓存的目录名和末尾数字也会随版本变化，不能只凭数字判断哪个目录已经废弃。
wrapper\dists 存的是项目包装器下载的 Gradle 发行包，daemon 里有后台进程的状态和日志。它们和依赖缓存分开存放，所以删掉 modules-2 并不会缩小 wrapper。
还要看正在使用的项目目录。项目内的 .gradle 保存该项目的构建状态，build 放生成的输出。清理全局缓存不会清掉这两个目录；反过来，Gradle 的 clean 任务通常只处理项目生成的输出，并不是清空 %USERPROFILE%\.gradle\caches 的通用命令。
不着急时先让 Gradle 自动清理
Gradle 会定期移除长期不用的缓存条目和旧包装器发行包。保留多久取决于 Gradle 版本和环境中的缓存设置。如果 C 盘还有余量，可以先完成一次正常构建，让它执行例行清理，再看大小有没有变化。
依赖缓存能减少重复下载，构建输出缓存能减少重复工作。删除这些缓存不会删掉源代码，但下次构建可能更慢，还可能需要联网。如果你即将离线工作，或者项目依赖一个暂时无法访问的私有仓库，就先保留已下载的依赖。
不认识某个目录时，可查 Gradle 官方目录说明。不要照搬旧版本教程里的固定目录清单。
删除前先停止 Gradle
等当前构建结束，关闭 IDE 及其 Gradle 集成，然后在项目文件夹中打开命令提示符。如果项目带有 Gradle Wrapper，运行：
gradlew.bat --stop
如果你使用单独安装的 Gradle，则运行 gradle --stop。官方说明指出，这只会停止与当前命令所用 Gradle 版本相同的后台进程；其他项目若使用不同版本，可能仍有进程在运行。因此也要关闭那些项目。Windows 提示文件正在使用时，先找出仍在运行的 IDE 或 Gradle 进程，不要强行删除。
停止后台进程不会删除构建数据，下次构建可以重新启动它。如果之前有构建被中断，清理后重新运行该构建，并先查看正常的错误信息，不要接着乱删其他目录。
构建输出缓存过大时清理它
在文件资源管理器中打开 %USERPROFILE%\.gradle\caches，查找 build-cache-1 或其他 build-cache-* 文件夹。先通过“属性”确认它确实占用了需要回收的空间。停止构建和后台进程后，选中该文件夹，按 Delete，让 Windows 把它移入回收站；不要用 Shift+Delete。
这一步清掉的是可复用的任务输出，不是项目源代码。下次构建可能需要重新生成输出，耗时也可能增加。如果发现构建需要被删掉的数据，而且尚未清空回收站，可以在 Gradle 停止时从回收站还原该文件夹，再试一次。继续构建后缓存仍可能增长，因此这只是一次腾空间操作，不会给缓存设定永久上限。
如果这个文件夹不存在或者很小，就不要为了“清理过”而删除它；应继续寻找真正占空间的位置。
依赖缓存过大时先确认能重新下载
在 %USERPROFILE%\.gradle\caches 中查看 modules-2 的大小。删除之前，先确认网络、公开仓库以及项目所需的私有仓库都能访问。然后按照前面的步骤停止构建和后台进程，在文件资源管理器中选中 modules-2，按 Delete。等项目正常构建成功后再清空回收站。不要删除整个 .gradle 用户主目录：里面还可能有配置、初始化脚本、下载的 JDK 和包装器发行包。
主要风险是下次构建需要重新下载依赖，速度变慢，甚至因仓库无法访问而失败。离线构建如果找不到已删除的依赖，也会失败。如果仓库暂时不可用，先停止 Gradle，再从回收站还原 modules-2；如果已经永久删除，就需要恢复仓库连接后重新构建。缓存不能代替项目长期可用的依赖来源。
如果目的只是检查依赖有没有更新，而不是腾空间，可以在项目文件夹运行 gradlew.bat --refresh-dependencies。它会重新检查依赖元数据和文件，并不等于“删除全部缓存”。Gradle 官方依赖缓存说明也解释了它与 --offline 的区别。
把项目清理和全局缓存分开
对于可以重新构建的项目，可以先在项目根目录运行 gradlew.bat clean 清理生成的构建输出。这会执行该项目的 clean 任务，使用前仍应了解项目有没有自定义行为。它不以共享的用户缓存为目标。项目自己的 .gradle 如果很大，也要先停止 Gradle 再单独检查；这些状态可以重建，但下次构建可能失去增量构建带来的便利。
如果还使用其他开发工具，请分别衡量它们的缓存。npm 缓存或 pip 缓存不会因清理 Gradle 而缩小。先确认哪个目录持续增长，才能避免删掉有用的缓存却只换来一点点空间。
用 AiCleanDisk Pro 查看 Gradle 缓存
AiCleanDisk Pro 的开发者缓存清理项目包含 Gradle，需要打开“Show all items”才能看到。清理前可以查看风险级别并确认；清理方式允许时，文件默认进入回收站。扫描系统盘以及 AI 类别以外的自动清理免费；移动文件夹和 AI 分析需要授权，目前销售的是一次性付款的许可。如果只需清理某一个 Gradle 缓存，按上面的手动步骤操作即可；首页介绍了软件其他扫描和清理功能。