应选zip压缩包：它不改注册表、不写系统变量、卸载彻底、支持多版本并存且适用于CI/CD；需手动配置JAVA_HOME和PATH，但路径清晰可控，避免exe安装导致的版本冲突与残留问题。
选 zip，除非你明确需要 exe 带来的自动注册表写入或图形向导。 开发、CI/CD、多版本共存、权限受限场景下，exe 安装几乎必然带来环境变量冲突、残留路径、版本覆盖等问题；zip 虽要手动配 JAVA_HOME 和 PATH，但路径清晰、切换可控、删即干净。
exe 安装为什么容易导致 java -version 显示错版本？
它不只解压文件，还会往注册表写 HKLM\SOFTWARE\JavaSoft\JDK、静默添加 publicjre、把 bin 目录硬塞进系统 PATH 最前面——而且不告诉你塞在哪。多个 exe 安装后，PATH 里可能混着 C:\Program Files\Java\jdk-17\bin 和 C:\Program Files\Java\jdk-21\bin，而 where java 返回的只是第一个匹配项。
- 常见现象：
javac报“不是内部或外部命令”，但java -version又能运行——说明PATH里有java.exe（可能来自旧版 JRE），但没javac.exe（只在 JDK 的bin下） - 卸载后残留：exe 卸载常不清理注册表项和
PATH中的路径，下次装新版本时可能沿用旧配置 - IDE 混乱：IntelliJ 或 VS Code 读到的
JAVA_HOME可能是注册表里写的，而非你当前想用的版本
zip 解压后必须手动配哪两个环境变量？
顺序不能错，值不能错，否则 java 找不到类、javac 直接报错。
- 先设
JAVA_HOME为解压后的根目录，例如C:\dev\jdk-21—— 注意结尾不能带反斜杠\，写成C:\dev\jdk-21\会导致java -version报“找不到或无法加载主类” - 再把
%JAVA_HOME%\bin加到PATH开头，而不是直接写死完整路径（比如C:\dev\jdk-21\bin），否则换版本时要改两处 - 验证命令：
echo %JAVA_HOME%应输出路径；where java应只返回一行，且路径必须以%JAVA_HOME%\bin\java.exe结尾
CI/CD 或 Docker 构建中为什么必须用 zip？
自动化脚本不能点“下一步”，也不能依赖交互式 GUI，更不能让构建节点因权限不足卡在注册表写入上。
-
curl -O https://aka.ms/download-jdk-25-windows-x64-zip+Expand-Archive -Path jdk-25.zip -DestinationPath C:\jdks\jdk-25是幂等、可复现的操作 - Dockerfile 里写
COPY jdk-25.zip /tmp/ && unzip /tmp/jdk-25.zip -d /opt/jdks/，比调用msiexec或模拟 exe 静默安装稳定得多 - Winget 或 Chocolatey 安装看似方便，但底层仍是 exe/msi，仍受权限和注册表限制；zip 方式可完全绕过这些
真正麻烦的不是配环境变量那几步，而是当你发现 mvn compile 突然报 UnsupportedClassVersionError 时，得花半小时翻注册表、查 PATH、比对 where java 和 where javac 输出是否来自同一目录——这种排查，zip 从一开始就能避免。
