Gradle Daemon复用失败的典型信号是“Starting a Gradle Daemon, X incompatible and Y stopped Daemons could not be reused”，表明Gradle主动判定现有Daemon因JVM版本、Gradle版本、jvmargs配置或IDE环境不一致而不兼容，必须启动新实例，而非单纯未启用Daemon。
Gradle Daemon 复用失败的典型日志信号
看到 Starting a Gradle Daemon, 1 incompatible and 2 stopped Daemons could not be reused 这类输出，就说明当前构建拒绝复用已有 Daemon。这不是警告，是明确的结果——Gradle 主动判定现有 Daemon 不可用，必须启动新实例。
根本原因不是“没开启 Daemon”，而是“已有 Daemon 被判为 incompatible”。常见触发点包括：
-
org.gradle.java.home配置变更后未重启 Daemon（比如从 JDK 8 切到 JDK 17，但旧 Daemon 还在跑） - Gradle 版本升级（如从 7.5 升到 8.2），旧版本 Daemon 不兼容新构建逻辑
- 项目根目录
gradle.properties中新增了影响 JVM 启动参数的配置（如org.gradle.jvmargs增加了-XX:MaxMetaspaceSize），导致缓存键不匹配 - IDE（如 IntelliJ）在后台静默触发了一次不同参数的构建，残留了一个带冲突参数的 Daemon
为什么 gradle --status 显示 Daemon 在运行却仍不被复用
gradle --status 只告诉你进程存在，不告诉你它是否“可复用”。一个 Daemon 进程可能存活，但因以下任一条件不满足而被跳过：
- JVM 版本与当前构建请求不一致（
org.gradle.java.home指向的 JDK major version 不同） - Gradle 版本号不完全匹配（
7.6和7.6.1视为不同，Daemon 不共享） - 构建参数差异：比如一次用了
--no-configuration-cache，另一次没加，缓存作用域不兼容 - 项目路径哈希变化：某些插件或脚本读取了绝对路径变量，导致构建环境指纹改变
最常被忽略的一点：IntelliJ 默认启用 Build, Execution, Deployment > Build Tools > Gradle > Use Gradle from: wrapper，但它可能偷偷把 IDE 自带的 JDK 当作 Daemon JVM，和你 gradle.properties 里写的 org.gradle.java.home 冲突。
如何强制让 Daemon 复用生效
不是靠“多试几次”，而是要消除复用判定中的不一致项：
- 统一指定
org.gradle.java.home，且确保该路径下java -version输出的 major version 与项目sourceCompatibility匹配（例如 Java 8 → major version 52） - 避免在命令行临时传入
-Dorg.gradle.java.home=...，这会生成独立缓存键；所有 JVM 配置应固化在gradle.properties - CI 环境中禁用
gradle --stop或pkill -f gradle，它们清掉的是进程，不是“不兼容”的根源；真正要清的是~/.gradle/daemon/下对应版本号的子目录（如8.2/） - 验证复用是否成功：执行两次
./gradlew build，第二次日志里不应再出现Starting a Gradle Daemon，只应有Using daemon提示
Daemon 复用失效时最容易误操作的三件事
很多团队在排查时反而加重问题：
- 反复执行
gradle --stop—— 它只是杀进程，不解决“为什么新启的 Daemon 又立刻被标为 incompatible” - 盲目升级 Gradle Wrapper —— 如果
android Gradle plugin版本不配套，新 Daemon 会因插件 API 不兼容直接拒载 - 在
build.gradle里写gradle.startParameter.setDaemon(true)—— 这个 API 已废弃，Gradle 7+ 忽略它，且干扰默认复用逻辑
Daemon 复用不是开关，是状态协商。真正关键的不是“有没有 Daemon”，而是“有没有一个和当前构建请求完全对齐的 Daemon 实例”。任何一处参数、路径、版本的微小错位，都会让它变成“不可复用”的僵尸进程。
