脚本执行前必须确认三件事：uname -m确认系统架构，ldd --version检查glibc版本是否≥2.28，java -version排查已有jdk冲突；包管理器安装虽快但路径固定且对systemd服务无效；手动解压需确保java_home指向根目录、避免classpath误配，并通过update-alternatives注册以支持多版本共存。
脚本执行前必须确认的三件事
别急着运行脚本，先检查这三项，否则90%的失败都发生在这一步：uname -m 确认是 x86_64 还是 aarch64；ldd --version 查 glibc 版本（JDK 17 要求 ≥ 2.28，CentOS 7 默认 2.17 就会报 GLIBC_2.28 not found）；java -version 看是否已有冲突版本，避免 /usr/lib/jvm/ 下多个 JDK 被 update-alternatives 混淆。
用 yum/dnf/apt 安装 OpenJDK 的真实限制
包管理器安装快，但不是万能解药：java-17-openjdk-devel（RHEL/CentOS）或 openjdk-17-jdk（Ubuntu）确实自动注册 /usr/bin/java 符号链接，也把 JAVA_HOME 写进 /etc/profile.d/java.sh，但注意：
- 路径固定为
/usr/lib/jvm/java-17-openjdk-*，不能自定义，写部署脚本时硬编码会翻车 -
source /etc/profile对 systemd 服务无效，必须在.service文件里显式加Environment="JAVA_HOME=/usr/lib/jvm/java-17-openjdk-$(ls /usr/lib/jvm | grep openjdk-17)" - Oracle JDK 不在官方仓库，
yum install oracle-java17-installer需额外 PPA 且要交互接受协议，无法静默部署
手动解压 + 脚本化配置的关键细节
真正可控的部署方式是下载 tar.gz 后用脚本解压并写环境变量，但容易错在三处：
-
JAVA_HOME必须指向解压后的**根目录**，比如/usr/local/java/jdk-17.0.9，不是/usr/local/java/jdk-17.0.9/bin，也不是带.tar.gz的路径 -
CLASSPATH在现代项目中基本不用，留空或只设$JAVA_HOME/lib/tools.jar（仅 JDK 8 需要），加.反而可能引发类加载冲突 -
/etc/profile里写完export后，必须source /etc/profile才对当前 shell 生效；批量部署时建议改用/etc/profile.d/jdk.sh，更易清理和覆盖
国内镜像一键脚本的核心逻辑
生产环境验证过的脚本，重点不在“一键”，而在容错和可追溯：
- 用
wget --spider轮询多个镜像源（华为云、清华、中科院），找到第一个可用的${MIRROR_URL}${JDK_ARCHIVE}就停，不卡死 -
set -e开关必须开启，任何命令失败立即退出，避免tar解压失败后还继续写环境变量 - 校验环节不能省：
sha256sum -c jdk-17_linux-x64_bin.tar.gz.sha256 2>/dev/null，否则镜像被篡改或下载中断会导致后续全部失效 - 最后用
update-alternatives --install注册新 JDK，而不是直接改/usr/bin/java符号链接，兼容多版本共存场景
最常被跳过的动作：脚本跑完后没验证 java -version 和 javac -version 是否一致——JDK 包里缺 javac（比如只下了 JRE）或权限没放开（chmod +x /usr/local/java/jdk-17.0.9/bin/*），都会让编译型应用启动失败。
