最准、最省事的方式是直接查看 Build Scan 报告；--scan 能精确展示各任务缓存命中状态及未命中原因，而 --profile 仅粗略显示耗时分布。
直接看 Build Scan 报告，这是最准、最省事的方式。 Gradle 自带的 --profile 只能粗略看耗时分布，但缓存命中率必须靠 --scan——它会把每个任务是否命中本地/远程缓存、为什么没命中（比如输入文件时间戳变了、环境变量不一致）、甚至具体哪个输入项导致失效，全都列清楚。
用 --scan 查看缓存命中详情
执行构建时加上 --scan 参数，例如：
./gradlew assembleDebug --scan
构建完成后，终端会输出一个带超链接的 Build Scan URL。打开网页，在左侧菜单点「Build Cache」，就能看到总命中率、各任务的缓存状态图标（绿色勾是命中，红色叉是未命中），以及点击某个任务后展开的详细原因。注意：首次使用需在 gradle.properties 里加一行 org.gradle.configuration-cache=true（非必需但推荐），否则部分配置阶段的缓存信息可能缺失。
命令行快速确认是否启用缓存及基础命中情况
不需要打开网页也能快速验证：
- 运行
./gradlew build --dry-run --info | grep "Cache"，能看到类似Caching disabled for task ':app:compileDebugJavaWithJavac' because ...的提示，说明该任务因输入不稳定被排除在缓存外 - 执行
./gradlew --help | grep caching确认当前 Gradle 版本支持缓存（5.6+ 全面支持，低于此版本可能无org.gradle.caching=true选项） - 检查
gradle.properties中是否真启用了缓存：org.gradle.caching=true必须存在且未被注释，且不能和org.gradle.configuration-cache=false冲突（后者会间接禁用部分缓存）
为什么 Build Scan 显示 99% 命中，但构建还是慢？
高命中率 ≠ 高性能，常见陷阱有：
- 关键路径上的任务根本没进缓存，比如
processDebugResources或mergeDebugNativeLibs，因为它们依赖了动态生成的 R.txt 或 ABI 检测结果，输入不稳定 - 远程缓存延迟高，虽然命中了，但下载解压比本地重算还慢（尤其小任务），此时应优先优化本地缓存路径的 I/O 性能，或限制远程缓存只用于 CI
- 配置阶段耗时占比高（比如 35%），而缓存只作用于任务执行阶段——这时候再怎么调缓存参数也救不了，得先解决
build.gradle脚本里的循环 apply、重复 plugin 加载等问题
真正影响体验的，往往不是“有没有缓存”，而是“哪些任务被缓存了”和“为什么某些任务死活缓存不了”。Build Scan 的「Why not cached?」折叠栏，比任何文档都直白。
