最稳方式是用包管理器安装OpenJDK 17或21，自动处理依赖与路径；JAVA_HOME需通过readlink -f $(which java) | sed "s:/jre/bin/java::"获取真实路径，不可硬猜；推荐解压至/usr/lib/jvm以符合FHS标准。
直接用包管理器装 OpenJDK 17 或 21 是最稳的，不用操心路径、权限和环境变量写错的问题；手动解压 tar.gz 包虽灵活，但 JAVA_HOME 写错一格、source 忘执行、或者 PATH 顺序颠倒，都会导致 java -version 正常但 javac 找不到。
用 apt/dnf/yum 安装 OpenJDK 后，JAVA_HOME 路径怎么找？
包管理器不会自动设 JAVA_HOME，必须自己查。别猜 /usr/lib/jvm/java-17-openjdk 这类路径——不同发行版、架构、更新后目录名可能带 -amd64、-x64 或版本补丁号。
- 运行
readlink -f $(which java) | sed "s:/jre/bin/java::"，输出就是真实JAVA_HOME值 - 或用
update-java-alternatives -l（Debian/Ubuntu）或alternatives --config java（RHEL/CentOS），看列出的路径 - 验证：执行
echo $JAVA_HOME应为空，说明还没设；设完再echo才有输出
手动解压 JDK tar.gz 时，/opt/jdk 和 /usr/lib/jvm 哪个目录更合适？
选 /usr/lib/jvm。这不是习惯问题，而是 Linux FHS（文件系统层次结构标准）规定该路径专用于 JVM 安装，且多数 Java 工具（如 Maven、IDEA、systemd 服务）默认在此查找 JDK。
-
/opt/jdk适合临时测试或隔离部署，但需额外确保所有用户、服务都有读取权限（sudo chmod -R a+rX /opt/jdk） - 解压后建议建软链接：
sudo ln -sfn /usr/lib/jvm/jdk-17.0.1+12 /usr/lib/jvm/java-17，避免硬编码路径随版本升级失效 - 别把 JDK 解压到
$HOME下——普通用户无权让系统服务（如 Tomcat）读取该路径
配置 JAVA_HOME 和 PATH 时最容易踩的三个坑
环境变量不是写对就完事，生效逻辑和 shell 加载顺序决定它到底管不管用。
立即学习“Java免费学习笔记（深入）”；
-
export JAVA_HOME=...必须写在export PATH=...之前，否则$JAVA_HOME/bin会扩展为空 - 写入
~/.bashrc只对交互式 bash 生效；用nohup启动的服务、cron 任务、systemd 单元默认不加载它——生产环境务必写进/etc/profile.d/java.sh或/etc/environment -
PATH=$JAVA_HOME/bin:$PATH中冒号前不能有空格，PATH = $JAVA_HOME/bin:$PATH会导致整个PATH被清空（bash 把等号当命令了）
验证时 javac 找不到，但 java -version 正常，为什么？
说明 java 命令来自系统自带 JRE（比如 /usr/bin/java），而 javac 只存在于 JDK 的 bin/ 目录里。这是最典型的“PATH 冲突”信号。
- 执行
which java和which javac，看两者是否指向同一父目录 - 执行
ls -l $(which java)，若指向/usr/bin/java，大概率是系统预装的 JRE；真正的 JDKjava应在$JAVA_HOME/bin/java - 临时修复：运行
export PATH=/usr/lib/jvm/java-17-openjdk-amd64/bin:$PATH再试；长期解决请检查PATH是否被其他配置文件（如/etc/profile里的旧设置）覆盖
真正麻烦的从来不是解压或写 export，而是不同 shell（bash/zsh）、不同登录方式（ssh/login/tmux）、不同进程上下文（shell 脚本 vs systemd service）对环境变量的加载规则不一致。哪怕 echo $JAVA_HOME 在终端里显示正确，也得在实际运行 Java 应用的环境中再验一次。
