配置缓存命中取决于构建脚本输入的确定性哈希，Gradle 对配置阶段所有输入（脚本内容、插件版本、环境变量等）生成唯一哈希，一致则复用解析结果；任一输入变化（如空格修改、-P参数变更、System.getenv调用、可变集合使用等）均导致失效；验证方式为查看--configuration-cache输出中的“reused”或构建扫描报告中的明确状态。

配置缓存命中取决于构建脚本输入的确定性哈希

Gradle 不是“记住上次 build.gradle 怎么跑的”，而是把整个配置阶段的所有输入（脚本内容、插件版本、project 属性、系统环境变量等）做一次快照，再用确定性算法生成唯一哈希值。只要这个哈希值和上次缓存里存的一致，就直接加载解析结果，跳过所有脚本执行逻辑。

哪些输入变化会导致配置缓存失效

配置缓存对“非确定性”极其敏感，以下任意一项变动都会让哈希值改变，从而强制重新解析：

• build.gradle 或 settings.gradle 文件内容有哪怕一个空格的修改
• 通过 gradle.properties 设置的 org.gradle.configuration-cache=true 被临时关闭或开启
• 命令行传入不同 -P 参数，比如 -Penv=prod vs -Penv=dev
• 脚本中调用了 System.getenv("CI")、new Date() 或未声明的外部文件读取（如 file.readText()）
• 使用了可变集合（mutableListOf）、动态修改 project.extensions 或 project.tasks 的操作

怎么验证当前是否命中了配置缓存

运行带 --configuration-cache 的构建时，关键看控制台输出：

• 命中成功：出现 Configuration cache entry stored（首次生成）或 Configuration cache entry reused（复用）
• 命中失败：出现 Configuration cache is not ready yet 或大量 Configuration cache problems 报错，说明有不兼容写法

注意：gradle --scan 生成的构建扫描报告里，“Configuration Cache” 面板会明确标出命中/未命中状态，并列出所有导致失效的具体原因行号。

Gradle 9.8.0

下载

容易被忽略的隐式输入源

很多人以为只改了 build.gradle 就万事大atter，但这些地方也参与哈希计算：

• gradle/wrapper/gradle-wrapper.properties 中的 distributionUrl（Gradle 版本变更 → 哈希变）
• settings.gradle 里动态 include 的模块路径（如 fileTree("modules").each { include(it.name) }）
• IDEA 或 Android Studio 自动注入的 JVM 参数（比如 -Dfile.encoding=UTF-8）
• 项目根目录下未被 .gitignore 排除的临时文件，若被脚本意外读取

真正稳定的配置缓存，不是靠“关掉某些功能”，而是把所有影响输入的因素显式声明、固定版本、避免副作用——它本质上要求你把构建逻辑写得像纯函数一样干净。