gradle升级后构建变慢大概率是daemon未复用、配置缓存失效或agp/jdk版本不兼容所致，需通过gradle --status、--scan报告及--no-configuration-cache等手段精准定位隐性退化根因。
Gradle 升级后构建变慢，大概率不是“变慢”，而是某些关键机制失效或配置错位导致的隐性退化。直接调大 org.gradle.jvmargs 只会掩盖问题，甚至让线程竞争更严重。
看一眼 daemon 是否真的在复用
升级后最常被忽略的点：Gradle Daemon 没生效，每次都是冷启动。
- 执行
gradle --status，如果输出里没有正在运行的 daemon，或者Uptime显示只有几秒，说明它没常驻 - 检查
gradle.properties是否误删了org.gradle.daemon=true（IDEA 升级有时会重置该文件） - 确认没在 CI 或命令行脚本里写
gradle --stop或pkill -f gradle—— 这会让 daemon 彻底失效 - Daemon 复用失败时，
gradle --info日志开头会反复出现Starting Gradle daemon，这是最直接的证据
对比 build scan 中的 task 执行耗时分布
Gradle 8+ 默认支持 build scan，能暴露升级后真正拖慢的环节，而不是笼统说“整体慢”。
- 加参数跑一次：
gradle build --scan，打开生成的 URL，重点看Configuration和Execution两栏耗时 - 如果
Configuration时间暴涨（比如从 2s → 15s），说明插件或脚本初始化逻辑有问题，常见于自定义init.gradle或过时的第三方插件 - 如果
Execution中大量compileJava或kapt耗时翻倍，要检查 JDK 版本是否匹配新 Gradle（例如 Gradle 8.6 要求 JDK 17+，用 JDK 11 会触发降级兼容路径） - 注意
Up-to-date checks是否大面积失效：升级后build目录结构或输入路径变更，会导致增量编译全量触发
检查本地缓存是否被绕过或污染
Gradle 升级后默认启用新的缓存策略（如 configuration-cache、build-cache），但旧项目往往没适配，反而引发重复解析。
- 运行
gradle --dry-run，观察是否有大量:module:compileJava UP-TO-DATE突然变成EXECUTING - 确认
~/.gradle/caches/下是否存在多个版本的modules-*/目录，升级后 Gradle 可能新建缓存目录而弃用旧的，但脚本里硬编码了路径就会失效 - 禁用配置缓存测试：
gradle build --no-configuration-cache，如果速度明显回升，说明项目里用了不兼容的 API（比如在build.gradle里直接访问project.files） - 别盲目删整个
~/.gradle/caches—— 先删~/gradle/caches/modules-*，保留transforms-*和jars-，避免重新下载全部依赖
验证 AGP / JDK / 插件三者是否对齐
Gradle 升级只是表象，真正卡住的往往是下游工具链不兼容，尤其是 Android 项目。
- 查官方兼容矩阵：Gradle 8.6 对应 AGP 8.4+，JDK 17；若仍用 AGP 7.4，Gradle 会自动启用兼容模式，但所有 Kotlin 编译器任务都会降级为单线程
- 执行
gradle --version和./gradlew -v，确认两者输出一致 —— IDE 有时会用自己的 Gradle wrapper，和命令行不一致 - 禁用非必要插件测试：
gradle build -Pandroid.useAndroidX=true -Pandroid.enableJetifier=false --no-daemon，排除插件桥接异常干扰 - 留意
buildSrc或自定义 plugin：如果它们基于旧版 Gradle API（如ProjectLayout改名、Provider返回类型变更），升级后可能 silently fallback 到低效路径
真正麻烦的从来不是“哪里慢”，而是“为什么慢得不明显”——比如 daemon 假死、缓存静默失效、AGP 降级却不报 warning。这些都不会抛红字，只会让你默默多等一分半钟。
