选压缩包而非安装包，因其解压即用、多版本共存灵活、CI/CD和容器化部署可控；安装包适合单版本新手场景，但权限依赖强、卸载易残留。
选压缩包还是安装包，取决于你敲 java -version 时，是想立刻看到结果，还是想立刻知道它从哪来、能不能删干净、换版本会不会崩。
需要多版本共存或 CI/CD 自动化部署？必须用压缩包
安装包在 Windows 上写注册表、在 macOS 上改 launchservices、在 Linux 上可能塞进 /usr/lib/jvm，这些路径被系统级工具（如 update-alternatives）绑定后，多个 JDK 版本容易互相覆盖或残留。而压缩包解压即用：tar -xzf openjdk-21_linux-x64_bin.tar.gz -C /opt/jdks/，目录结构完全自主，JAVA_HOME 指哪就用哪。CI 脚本里 curl + 解压 + export，不卡权限、不依赖交互、不污染宿主环境。
- 同一台机器可并存
jdk8、jdk17、jdk21，只需切换JAVA_HOME - Dockerfile 中推荐用
COPY jdk-21.0.2+13 /opt/java而非apt install，避免镜像层缓存导致版本漂移 - ARM 服务器（如 aarch64）上，很多发行版源里没有新版 OpenJDK，
openjdk-21_linux-aarch64_bin.tar.gz是唯一可控路径
只用一个 JDK 版本且不碰命令行？安装包更省事
Windows 的 .exe 或 macOS 的 .pkg 会自动配置 JAVA_HOME、把 bin 加进 PATH、甚至给 IntelliJ 或 VS Code 写好 SDK 路径。装完打开终端就能跑 javac。但代价明显：需要管理员/root 权限；卸载后 PATH 可能还留着旧路径；升级时旧版本残留的 bin 文件夹可能被新安装程序跳过清理。
- 新手教学、标准化办公桌面、临时演示环境适用
- 不推荐用于 Jenkins agent、K8s initContainer、国产信创服务器等权限受限或需审计的场景
- 若已装过安装包又想切压缩包，务必手动检查并清除系统级
PATH中的旧jdk-xx路径，否则java -version仍可能调用错版本
环境变量配错是压缩包最常踩的坑
压缩包本身没毛病，90% 的“command not found”都出在 PATH 没生效或 JAVA_HOME 指向了错误层级。正确做法是：解压后得到类似 jdk-21.0.2+13 的目录，JAVA_HOME 必须指向该目录（不是它的 bin 子目录），然后 PATH 加的是 $JAVA_HOME/bin。
- Linux/macOS：写入
~/.bashrc或~/.zshrc，别写/etc/profile（除非所有用户都要用） - Windows：用系统属性 → 高级 → 环境变量，设用户变量而非系统变量，避免影响其他账户
- 验证顺序：先
echo $JAVA_HOME，再ls $JAVA_HOME/bin/java，最后java -version
混合策略最实用：主开发用安装包，工程化用压缩包
很多团队实际是两头兼顾：本地 IDE 用安装包快速起步，同时在 C:\dev\jdks 或 /usr/local/jdks 下长期维护多个压缩包版本，再用 sdkman（Linux/macOS）或批处理脚本（Windows）切换。IDE 设置里也统一指向压缩包路径——这样既保底又灵活，升级 JDK 时也不用重装整个开发环境。
真正难的不是选哪种格式，而是意识到：一旦开始写构建脚本、配流水线、上容器，JAVA_HOME 就不再是“配一次就完事”的事，而是每个环节都要显式声明、隔离、验证的确定性依赖。
