应从安装阶段就隔离路径、显式注册并禁用自动清理：ubuntu/debian用独立包名并存，centos/rhel 8+支持多版本共存，手动安装须放/opt/java/等非标准路径并带明确版本号，统一用update-alternatives注册各版本，回退前验证lib/modules完整性。
直接保留旧版 OpenJDK 用于回退，关键不是“安装后再想办法留着”，而是从安装阶段就避免覆盖、冲突和自动清理——系统默认不会帮你存档旧版本，必须主动隔离路径、显式注册、禁用自动卸载。
安装时就分隔路径，别让包管理器覆盖
用 apt 或 dnf 安装多个 JDK 版本时，只要不指定 --force 或手动 remove，旧包默认保留。但要注意：
- Ubuntu/Debian：每个版本对应独立包名（如
openjdk-11-jdk、openjdk-17-jdk），安装新版本不会删旧版，ls /usr/lib/jvm/能看到全部 - CentOS/RHEL 8+：
java-17-openjdk-devel和java-21-openjdk-devel是并存的，但 CentOS 7 的yum源里没有 OpenJDK 21，强行装需手动解压到非标准路径 - 风险点：运行
sudo apt autoremove或dnf autoremove可能顺手把“未被标记为依赖”的旧 JDK 包删掉——尤其当你只用过一次就切走了
手动安装的 JDK 必须放自定义目录
从 Adoptium 下载的 tar.gz 包，绝不能解压到 /usr/lib/jvm/ 下与包管理器混用，否则 update-alternatives 注册混乱，且下次 apt upgrade 可能误删整个目录。正确做法：
- 统一用
/opt/java/或/usr/lib/jvm-custom/这类非标准路径 - 解压后确保目录名明确带版本号，例如：
/opt/java/jdk-17.0.1+12、/opt/java/jdk-21.0.1+12 - 不要用软链接覆盖已有路径（如
/opt/java/latest → jdk-17.0.1+12），回退时容易误删源目录
用 update-alternatives 注册所有版本，不依赖环境变量切换
JAVA_HOME 环境变量只能设一个，靠它来回切版本本质是手动改配置+重登录，不可靠也不适合脚本。真正可回退的机制是 update-alternatives：
- 每装一个 JDK（无论包管理器还是手动），都执行一次注册：
sudo update-alternatives --install /usr/bin/java java /opt/java/jdk-17.0.1+12/bin/java 1700sudo update-alternatives --install /usr/bin/javac javac /opt/java/jdk-17.0.1+12/bin/javac 1700 - 数字优先级（如
1700）要错开，高版本用更高值，避免自动选错 - 切换时只需：
sudo update-alternatives --config java，交互选编号即可，立刻生效，不影响其他用户或服务 - 验证是否生效：
java -version和readlink -f $(which java)必须指向目标 JDK 的bin/java
回退前务必确认旧版本的 modules 是否完整
OpenJDK 回退失败最常见原因不是二进制找不到，而是 /lib/modules 缺失或不匹配。特别是手动安装的 JDK：
- 检查路径是否存在：
ls /opt/java/jdk-11.0.22+7/lib/modules（注意不是jre/lib） - 如果用
java --list-modules报错No module definition found，说明该 JDK 不完整，不能用于生产回退 - Temurin 构建的 JDK 默认带完整模块，但某些精简版（如
-jre后缀）不含java.base等核心模块，不能当 full JDK 用 - 安全起见，回退前在测试环境跑一次
java -XshowSettings:properties -version，确认java.home和java.library.path指向预期位置
真正可靠的回退能力，来自路径隔离 + 显式注册 + 模块完整性验证——而不是指望“上次装的还在”。一旦发现某个旧版本启动报 Could not create the Java Virtual Machine，大概率是 lib/modules 损坏或路径被硬编码污染，这时就得重新下载验证过的 tar.gz 包，而不是试图修复。
