Microsoft JDK 已安装，Gradle 工具链却找不到它

Windows 上已经通过 Microsoft OpenJDK 的 MSI 安装 JDK 25，Gradle 却提示找不到匹配工具链，甚至试图再下载一份。若 javaToolchains 只列出正在运行 Gradle 的旧 JDK，先检查安装发现入口，而不是重复安装同一个包。

Gradle 9.8.2 的 Windows 自动探测会读取若干 Java 注册表位置，但没有枚举 Microsoft MSI 使用的 HKLM\SOFTWARE\Microsoft\JDK。因此，JDK 文件存在、Windows 注册表也登记了它，并不保证它进入 Gradle 的工具链候选集合。

为现有安装增加明确入口

可以用工具链环境变量提供安装根目录，避免把每台机器的绝对路径写进仓库。先确认目录内存在所需的 bin\java.exe，且确实是 JDK 安装根，而不是它的上一级目录。

在实际被 Gradle 读取的 gradle.properties 中增加：

org.gradle.java.installations.fromEnv=MS_JDK25

然后在启动这次构建的 PowerShell 中设置本机真实路径：

$env:MS_JDK25 = 'C:\Program Files\Microsoft\jdk-25.0.4.101-hotspot'
.\gradlew.bat -q javaToolchains

路径只是安装形状示例，应替换为本机实际版本目录。若 fromEnv 已列出其他变量，把新变量加入逗号列表，不覆盖原有入口。也可以使用 org.gradle.java.installations.paths 提供根目录列表；Gradle 不会递归寻找其中的子目录。

这些配置增加候选位置，不是强制选择开关。语言版本、vendor、实现类型以及当前运行 JVM 的优先规则，仍然影响最终选择。不要因为列表里出现 Microsoft JDK，就假定每个编译任务或 daemon 都已经采用它。

分别核对发现和选择

先确认 javaToolchains 显示新增安装的真实路径、语言版本与发行商，再检查原失败任务实际采用的编译器或 launcher。若项目使用 daemon JVM criteria，也要验证它要求的版本在本次启动环境可见；终端、IDE 和 CI 必须能够得到相应变量。

不必为此全局修改 JAVA_HOME、伪造其他发行商的注册键，或删除 Gradle 已下载的全部工具链。运行 Gradle 的 JVM 与任务工具链职责不同，更换运行 JVM可能引入新的兼容问题。

保留原属性和环境配置，使用项目允许的正常构建入口复查。只有安装能被发现、满足原条件、原任务真实采用它且构建通过，才算完成。若列表已正确而任务仍选错 JDK，再检查任务自身的 javaCompiler 或 javaLauncher 绑定，不能继续把它归为自动发现失败。