/etc/profile是全局环境变量唯一可靠落点，必须在此配置JAVA_HOME并export，PATH中$JAVA_HOME/bin需置于最前以确保优先调用指定JDK；/etc/environment不支持变量展开，不可替代；多版本共存时应配合update-alternatives使用符号链接。
/etc/profile 是全局环境变量的正确落点
所有用户（包括 systemd 服务、crontab、SSH 登录用户）都需要用到 JAVA_HOME 时，必须写进 /etc/profile。它不是“可选之一”，而是唯一能覆盖系统级上下文的可靠位置。
常见错误是把配置塞进 /etc/environment —— 它不支持变量展开，$JAVA_HOME 直接当字面量处理，结果 PATH 里出现未解析的字符串，java 命令依然找不到。
-
/etc/profile由 login shell 自动 source，适用于绝大多数场景（SSH、console、systemd user session） - 若想更规范，应新建
/etc/profile.d/java.sh（需确保该目录被/etc/profile加载，主流发行版默认已支持） - 别改
/etc/bashrc：它只对交互式非登录 shell 生效（比如你开个新终端但没重新登录），很多后台任务根本读不到
写法必须 export，且顺序影响 PATH 查找
JAVA_HOME 必须显式 export，否则子进程看不到；PATH 拼接顺序决定命令优先级——把 $JAVA_HOME/bin 放前面，才能确保调用的是你指定的 JDK，而不是系统自带的 OpenJDK 或旧版本。
错误示范：export PATH=$PATH:$JAVA_HOME/bin → 可能调用到 /usr/bin/java 而非你的 JDK。
- 正确写法：
export JAVA_HOME=/opt/jdk-17.0.12 -
export PATH=$JAVA_HOME/bin:$PATH（注意$JAVA_HOME/bin在前） -
CLASSPATH现代 Java 应用基本不用，留空或设为.即可；若真需要，避免硬编码dt.jar或tools.jar（JDK 9+ 已移除）
source 后仍无效？检查 shell 类型和生效范围
改完 /etc/profile 必须手动 source /etc/profile，新开终端才生效。但很多人忽略一点：当前终端可能不是 login shell，导致 /etc/profile 根本没执行。
- 验证是否生效：
echo $JAVA_HOME和which java必须同时输出预期值 - 如果是 GNOME Terminal 或 VS Code 内置终端，默认启动的是 non-login shell，它读
~/.bashrc而非/etc/profile→ 此时需在~/.bashrc里加一句source /etc/profile - Zsh 用户注意：
~/.zshrc不自动加载/etc/profile，得手动source或改用/etc/zprofile
多 JDK 共存时，/etc/profile 不适合动态切换
/etc/profile 是静态配置，一旦写死路径，所有用户都被绑定到同一版本。开发测试中常需快速切 JDK，这时全局配置反而成障碍。
- 临时切换：
export JAVA_HOME=/opt/jdk-11.0.2 && export PATH=$JAVA_HOME/bin:$PATH - 长期方案：用
update-alternatives --config java（Debian/Ubuntu）或alternatives --config java（RHEL/CentOS），再配合/etc/profile指向/usr/lib/jvm/default-jre这类符号链接 - 别在
/etc/profile里写 if-else 判断用户或主机名——维护成本高，且 systemd 服务无法执行 bash 条件语句
/etc/profile 写对了，systemd --user 服务或 cron job 仍可能拿不到 JAVA_HOME，得额外用 Environment= 显式注入。 
