exe安装包会修改注册表和系统变量，zip则纯净便携；前者易导致环境冲突，后者需手动配置但完全可控，多版本共存、ci/cd及受限环境推荐zip。
exe安装包会悄悄改注册表和系统变量，zip不会
Windows上双击jdk-21_windows-x64_bin.exe，它不只是解压文件——还会往注册表写入HKLM\SOFTWARE\JavaSoft\JDK项、自动勾选“添加到PATH”、甚至静默安装publicjre（哪怕你只想要JDK）。而jdk-21_windows-x64_bin.zip解压后就是一整个干净的文件夹，没注册表痕迹，也没后台服务，删掉就彻底消失。
常见错误现象：java -version显示旧版本，或javac报“不是内部或外部命令”，往往是因为exe安装时残留了多个JAVA_HOME指向不同路径，或者PATH里混进了两个bin目录。
- 多版本共存场景下，exe安装极易互相覆盖环境变量，zip则天然隔离——比如
C:\dev\jdk-17和C:\dev\jdk-21可并存，切换只需改JAVA_HOME - CI/CD脚本部署时，exe安装需调用
msiexec或模拟GUI点击，不可靠；zip直接tar -xzf或Expand-Archive即可，幂等性好 - 某些企业锁死注册表写权限，exe安装直接失败；zip解压完全绕过权限校验
zip必须手动配JAVA_HOME和PATH，但控制权在你手上
exe安装时勾选“Add to PATH”看似省事，实则把bin目录硬塞进系统PATH最前面，一旦后续装了其他工具（如Gradle Wrapper自带JRE、Docker Desktop的OpenJDK），容易触发UnsupportedClassVersionError——因为实际运行的不是你以为的那个JDK。
zip配置的关键是两步不颠倒：
立即学习“Java免费学习笔记（深入）”；
- 先设
JAVA_HOME为解压后的根目录，例如C:\dev\jdk-21（注意：不能带\bin） - 再把
%JAVA_HOME%\bin加到PATH开头，而不是直接把完整路径写死 - 验证用
echo %JAVA_HOME%和where java，后者应只返回一行且路径匹配JAVA_HOME
容易踩的坑：setx JAVA_HOME "C:\dev\jdk-21\"末尾多了反斜杠，会导致java -version报错“找不到或无法加载主类”；还有人把PATH里的旧JDK路径删了，却忘了刷新当前CMD窗口——得新开终端才生效。
跨平台部署和U盘开发首选zip，exe只适合单机快速尝鲜
你在Mac上写完Spring Boot，打包成.jar丢给Windows测试同事，结果对方用exe安装的JDK 8跑出ClassNotFoundException——很可能是因为exe默认装在C:\Program Files\Java\jdk-8，路径含空格，而脚本里没加引号，导致java -cp参数截断。zip解压到C:\jdk-21这种无空格路径，就避开了这问题。
- DevOps流水线中，Ansible用
unarchive模块解压zip比调用win_package执行exe稳定得多 - 带U盘去客户现场调试？zip扔进去就能用，exe安装要管理员权限，还可能被杀软拦截
- Linux/macOS用户即使在Windows子系统（WSL）里开发，也倾向用zip版——因为
/mnt/c/dev/jdk-21可直接被WSL挂载，而exe装的路径常在Program Files里，符号链接易出错
下载页面上的“Installer”和“Archive”命名有误导性
Oracle官网和Eclipse Temurin的下载页都把exe标为“Installer”，zip标为“Compressed Archive”，但别被名字骗了——jdk-21.0.2+13-jre_windows-x64_bin.zip这个zip包里其实也含JRE，和exe版功能完全一致，只是没走安装器流程。
真正要注意的是文件名后缀和大小：
-
_bin.exe文件通常100–200MB，是自解压+引导程序，体积小但功能受限（比如不支持静默安装参数/s的旧版） -
_bin.zip文件500–1000MB，是原始二进制打包，含全部src.zip、jmods、legal目录，调试和构建都更全 - 某些发行版（如Amazon Corretto）只提供zip/tar.gz，压根没exe——说明工业级使用已默认zip为事实标准
复杂点在于：有些zip包解压后bin目录里没有java.exe，只有java（无扩展名），那是Linux/macOS专用包误下了；Windows必须认准文件名含windows-x64或windows-x86的zip。
