Linux发行版包管理器分三大主流家族：Debian/Ubuntu系用apt（.deb包），RHEL/CentOS/Fedora系用yum或dnf（.rpm包），Arch系用pacman；命令语法、依赖机制和配置文件路径各不相同，需先通过cat /etc/os-release确认系统ID再选用对应工具。
确认系统发行版和包管理器类型
不同 Linux 发行版用的包管理命令不一样，装错命令会直接报 command not found 或找不到包。别猜，先看清楚：
- 运行
cat /etc/os-release，重点看ID（如ubuntu、centos、almalinux）和VERSION_ID（如"22.04"、"8"） - CentOS 7 及更早用
yum，CentOS 8+、AlmaLinux 8+、Fedora 默认用dnf - Ubuntu/Debian 系列统一用
apt，但注意 Ubuntu 22.04+ 的openjdk-17-jdk包名和 18.04 不同
检查 CPU 架构与系统位数
OpenJDK 官方构建只提供 x86_64 和 aarch64（ARM64）两种主流架构。装错架构的包会导致 cannot execute binary file: Exec format error。
- 执行
uname -m：输出x86_64表示标准 64 位 Intel/AMD；aarch64表示 ARM 服务器（如 AWS Graviton、华为云鲲鹏） - 不要依赖
arch命令，它在某些容器或精简镜像中可能不可靠 - 如果你用的是阿里云轻量应用服务器或腾讯云 CVM，默认大概率是
x86_64，但 ARM 实例正快速普及，务必实测
验证基础依赖和磁盘空间
OpenJDK 运行时依赖 glibc 和 zlib，老系统或最小化安装可能缺失；磁盘不足则解压失败或 java -version 启动卡住。
- 检查 glibc 版本：
ldd --version，OpenJDK 11+ 要求glibc >= 2.17（CentOS 7 起步线），低于此版本必须手动编译或换发行版 - 查可用空间：
df -h /usr（包管理安装默认路径）和df -h /tmp（临时解压用），留出 ≥500MB 空闲 - 内存不是硬门槛，但
java -Xms启动参数若设得过高，而物理内存
排查已有 Java 环境干扰
多个 Java 版本共存本身不致命，但 java 命令软链接指向错误版本、JAVA_HOME 残留旧路径、或者 /usr/bin/java 是 shell wrapper 脚本，都会让 java -version 显示和实际 javac 或运行时行为不一致。
- 运行
which java和readlink -f $(which java)，看真实二进制路径是否落在/usr/lib/jvm/下 - 检查是否被 alternatives 管理：
update-alternatives --list java（Debian/Ubuntu）或alternatives --display java（RHEL/CentOS） - 留意
/etc/profile.d/java.sh或用户级~/.bashrc中硬编码的JAVA_HOME，它们可能覆盖包管理器设置的默认值
真正容易被忽略的是：包管理器安装的 OpenJDK（如 openjdk-17-jdk）默认不写入 JAVA_HOME 环境变量，但很多脚本（比如 Spring Boot 的 spring-boot-maven-plugin 打包逻辑）会读它。别等 CI 报错才想起来补。
