最稳妥方式是tar.gz解压+手动配置环境变量；优先选jdk-21_linux-x64_bin.tar.gz，解压至/usr/local/java或/opt/jdk，JAVA_HOME须指向含版本号的完整路径（如/usr/local/java/jdk-21.0.5），并执行source /etc/profile验证java/javac/version及类路径。
Linux 下安装 JDK 21 LTS，最稳妥的方式是用 tar.gz 解压 + 手动配置环境变量；包管理器（如 apt）虽快，但只提供 OpenJDK 版本且路径/符号链接行为不统一，容易和已有 Java 冲突。
怎么选下载包：tar.gz 还是 .deb / .rpm？
优先选 jdk-21_linux-x64_bin.tar.gz（或 aarch64，取决于 CPU 架构）：
-
.deb/.rpm安装后通常把 JDK 放进/usr/lib/jvm/，并自动注册/usr/bin/java软链接——但若系统已有旧版 Java（比如 CentOS 自带的 OpenJDK 1.8），update-alternatives可能混乱，java -version和javac -version显示不一致 -
tar.gz解压路径完全可控，推荐放在/usr/local/java或/opt/jdk，避免空格、中文、符号，也绕过包管理器的路径劫持 - Oracle JDK 的
.deb包在部分 Ubuntu 版本中会因依赖缺失失败，需额外运行sudo apt-get install -f，不如解压干净
export JAVA_HOME 必须指向解压后的完整 JDK 目录，不能只到 /usr/local/java
常见错误是把 JAVA_HOME 设成解压父目录，例如：
export JAVA_HOME=/usr/local/java # ❌ 错误：这里只是个空文件夹或软链接
正确写法必须包含版本子目录，比如：
立即学习“Java免费学习笔记（深入）”；
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
export JAVA_HOME=/usr/local/java/jdk-21.0.5 export PATH=$JAVA_HOME/bin:$PATH
验证方式不是只看 java -version，还要检查：
-
echo $JAVA_HOME—— 输出应为完整路径，不含bin -
which java—— 应返回$JAVA_HOME/bin/java -
readlink -f $(which javac)—— 最终应指向$JAVA_HOME/bin/javac，而非系统默认路径
为什么 /etc/profile 配置后 java 仍不生效？
三个高频原因：
- 没执行
source /etc/profile，仅修改文件不会立即生效；新终端才自动加载，当前 shell 需手动重载 -
/etc/profile末尾漏了export JAVA_HOME PATH，只写了JAVA_HOME=...和PATH=...，变量未导出，子进程不可见 - 用户级配置（如
~/.bashrc）里有旧的JAVA_HOME覆盖了系统级设置，尤其在非 root 用户下运行java时更明显；建议统一用/etc/profile并确保它被所有 shell 读取（某些发行版默认不加载）
验证必须跑三步，缺一不可
只输 java -version 不够，因为系统可能缓存了旧命令或用了别名。真正有效的验证顺序是：
-
java -version—— 确认 JVM 运行时版本是 21.x -
javac -version—— 确认 JDK 编译器可用，排除只有 JRE 的情况 -
java --show-version -cp . HelloWorld（假设有HelloWorld.class）—— 实际跑一次字节码，确认类路径与运行时兼容性
特别注意：如果用的是 Oracle JDK（非 OpenJDK），java -version 输出里会有 Java(TM) SE Runtime Environment 字样；OpenJDK 则显示 OpenJDK Runtime Environment。两者 API 兼容，但商业部署需留意 Oracle 许可条款。
