配置缓存命中取决于构建脚本输入的确定性哈希，Gradle 对配置阶段所有输入（脚本内容、插件版本、环境变量等）生成唯一哈希，一致则复用解析结果；任一输入变化（如空格修改、-P参数变更、System.getenv调用、可变集合使用等）均导致失效；验证方式为查看--configuration-cache输出中的“reused”或构建扫描报告中的明确状态。
配置缓存命中取决于构建脚本输入的确定性哈希
Gradle 不是“记住上次 build.gradle 怎么跑的”，而是把整个配置阶段的所有输入（脚本内容、插件版本、project 属性、系统环境变量等）做一次快照，再用确定性算法生成唯一哈希值。只要这个哈希值和上次缓存里存的一致，就直接加载解析结果，跳过所有脚本执行逻辑。
哪些输入变化会导致配置缓存失效
配置缓存对“非确定性”极其敏感，以下任意一项变动都会让哈希值改变，从而强制重新解析：
-
build.gradle或settings.gradle文件内容有哪怕一个空格的修改 - 通过
gradle.properties设置的org.gradle.configuration-cache=true被临时关闭或开启 - 命令行传入不同
-P参数，比如-Penv=prodvs-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” 面板会明确标出命中/未命中状态，并列出所有导致失效的具体原因行号。
容易被忽略的隐式输入源
很多人以为只改了 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排除的临时文件，若被脚本意外读取
真正稳定的配置缓存，不是靠“关掉某些功能”，而是把所有影响输入的因素显式声明、固定版本、避免副作用——它本质上要求你把构建逻辑写得像纯函数一样干净。
