覆盖安装jdk在windows上极易引发版本混乱，根本原因是旧残留未清理：system32中的java.exe、javasoft注册表项及残留环境变量仍被系统优先调用，导致java与javac版本不一致或jvm.cfg错误。
覆盖安装 JDK 在 Windows 上看似省事，但实际极易引发 java -version 显示旧版本、javac 找不到、IDE 识别错乱，甚至 Error: could not open `...jvm.cfg` 这类底层报错。根本原因不是“装了新版本”，而是旧残留没清理干净——系统仍从注册表、System32 或旧 JAVA_HOME 路径加载旧 JVM。
覆盖安装前必须清理的三个位置
Windows 不像 Linux 那样靠 PATH 顺序决定优先级，它会主动从多个地方“抢注” Java 运行时：
-
C:\Windows\System32下的java.exe、javaw.exe、javaws.exe—— 这些是系统级代理，哪怕你卸载了旧 JDK，它们也常被遗留，且优先级高于 PATH； - 注册表键
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment及其子项（如1.8、11、17）—— 里面存着JavaHome和RuntimeLib，JVM 启动时会读取； - 用户或系统环境变量中残留的
JAVA_HOME、PATH条目，尤其指向已删除路径的条目，会导致命令行行为不一致。
为什么不能直接双击新安装包覆盖？
Oracle 官方安装包（jdk-xx_xxx_windows-x64_bin.exe）默认不会覆盖旧注册表项，也不会删 System32 中的文件，更不会修改你手动配置的环境变量。它只做两件事：解压到新目录、把新 bin 加进 PATH（如果勾选了“Add to PATH”）。结果就是：java -version 可能调用的是 System32 里的旧版 java.exe，而 javac 却来自新 JDK 的 bin 目录——出现“java 和 javac 版本不一致”的经典问题。
- 如果你之前装过 JDK 8/11/17，又直接运行 JDK 18.0.2.1 安装包，大概率触发
jvm.cfg错误，因为旧java.exe仍试图加载已被删除的jre\bin\server\jvm.dll； - .msi 安装包（如 Adoptium 或 Microsoft OpenJDK）比 .exe 稍好，会尝试清理同版本注册表项，但对跨版本（如 JDK 11 → JDK 18）依然无能为力；
- “更改安装路径”不等于“覆盖”，只是换个目录解压，旧路径残留照旧生效。
安全覆盖的实操步骤（推荐顺序执行）
别跳步，每一步都对应一个真实故障点：
- 先关闭所有终端、IDE、Maven/Gradle 进程，避免文件被占用；
- 手动删除
C:\Windows\System32下的java.exe、javaw.exe、javaws.exe（需管理员权限）； - 用
regedit打开注册表，定位到HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft，删掉所有带版本号的子项（如Java Runtime Environment\1.8、Java Development Kit\17.0.1），只保留新 JDK 安装后自动生成的那个； - 检查系统环境变量：确认
JAVA_HOME指向新 JDK 根目录（如D:\Java\jdk-18.0.2.1），PATH中只有一条%JAVA_HOME%\bin，且没有其他硬编码的 JDKbin路径； - 最后再运行新 JDK 安装包，并**取消勾选“Add to PATH”**——由你自己通过
JAVA_HOME控制，更可控。
验证是否真正干净覆盖
打开全新命令提示符（不要复用旧窗口），逐条执行：
where java where javac echo %JAVA_HOME% java -version javac -version
四条命令输出的路径必须全部指向同一新 JDK 目录，版本号完全一致。如果 where java 返回 C:\Windows\System32\java.exe，说明第一步没清干净；如果 java -version 和 javac -version 不一致，说明 PATH 或注册表还有干扰。最隐蔽的问题往往出在注册表残留和 System32 文件上，这两处漏掉任何一项，后续调试成本远高于重装。
