Gradle构建缓存通过跳过未变更任务的执行而非加速编译本身来提升速度；启用org.gradle.caching=true、org.gradle.configuration-cache=true和org.gradle.parallel=true三参数后，增量构建耗时可降至原来的1/3以下，尤其适用于中大型项目、CI及频繁切分支场景。
Gradle 的构建缓存（Build Cache）不是“加快编译本身”，而是让绝大多数任务直接跳过执行——只要输入没变，就复用上次的输出结果。对中大型 Java 项目，尤其是 CI 构建或频繁切换分支的场景，启用后增量构建耗时常能降到原来的 1/3 甚至更低。
核心配置：三行关键参数
在项目根目录下的 gradle.properties 文件中添加以下内容：
- org.gradle.caching=true —— 启用构建缓存（任务输出级缓存）
- org.gradle.configuration-cache=true —— 启用配置缓存（跳过 build.gradle 解析阶段，Gradle 9+ 默认推荐）
- org.gradle.parallel=true —— 并行执行模块任务，配合缓存效果更明显
无需改代码、不侵入逻辑，保存后所有后续 ./gradlew build 就自动生效。
为什么能快这么多？关键在“跳过”而非“加速”
Gradle 构建分三阶段：初始化 → 配置 → 执行。传统慢主要卡在：
立即学习“Java免费学习笔记（深入）”；
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 配置阶段反复解析几十个 build.gradle 脚本（尤其多模块项目）
- 执行阶段重复编译、测试、打包等任务，哪怕只改了一行代码
启用后：
- 配置缓存把解析结果（依赖图、task 关系）存下来，下次直接加载，省掉数秒到十几秒
- 构建缓存把 task 输出（如
classes/目录、test 结果）存为哈希键值，输入不变就跳过整个 task
必须注意的兼容性细节
缓存不是万能开关，以下情况会自动失效或需手动处理：
- build.gradle 或 settings.gradle 有改动 → 配置缓存失效，但构建缓存仍可用
- 自定义 task 没声明 inputs/outputs → Gradle 不知道它是否可缓存，需显式标注
- 使用了
new Date()、随机数、系统时间戳等非确定性操作 → 缓存命中率暴跌 - Java 版本或 JVM 参数变更 → 可能触发重新编译（建议固定 JDK 版本）
进阶：本地 + 远程混合缓存（适合团队）
单机缓存只对本机有效。若想让 CI 和同事共享成果，可搭一个简易远程缓存服务：
- 用官方推荐的 Gradle Build Cache Node（轻量 Docker 镜像）
- 在 gradle.properties 中追加：
org.gradle.caching.remote.http.url=https://your-cache-server/cache - 首次构建上传，后续拉取，新成员 clone 后第一次构建也接近“秒级”
不需要改构建脚本，也不影响本地开发体验。
