/etc/environment不是万能解法，因其仅支持静态KEY="value"格式，不解析$VAR、不执行shell语法，故无法展开$JAVA_HOME/bin到PATH，导致javac等工具不可用；推荐改用支持shell语法的/etc/profile。
为什么/etc/environment不是万能解法
很多人直接往 /etc/environment 里写 JAVA_HOME="/usr/lib/jvm/java-17-openjdk-amd64" 就以为完事了，结果 java -version 正常，但 mvn compile 报错说找不到 javac。问题出在：这个文件只加载键值对，不执行 shell 解析，所以 $JAVA_HOME/bin 不会被展开，PATH 也不会自动追加 bin 目录。
它适合纯静态变量（比如数据库地址），不适合需要路径拼接的 JAVA_HOME 场景。
-
/etc/environment不支持$VAR展开、不支持命令替换、不支持条件逻辑 - 它由 PAM 在登录时读取，不经过 shell，因此
export、PATH=...这类语法会直接报错或被忽略 - 即使写对了，Maven、Gradle 等工具仍可能因
PATH未包含$JAVA_HOME/bin而找不到javac
/etc/profile 是更稳妥的全局配置入口
所有登录 shell（包括 SSH 登录、图形终端启动的 bash）都会 source /etc/profile，它支持完整 shell 语法，能可靠设置 JAVA_HOME 并更新 PATH。
操作步骤很明确：
立即学习“Java免费学习笔记（深入）”；
- 用 root 权限编辑：
sudo nano /etc/profile - 在文件末尾添加两行（注意路径必须真实存在，且含
bin和lib子目录）：export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64 export PATH=$JAVA_HOME/bin:$PATH
- 保存后，新登录的用户或新开终端即生效；已有终端需手动
source /etc/profile
验证时别只看 echo $JAVA_HOME，一定要连着跑：javac -version ——只有这个通过，才说明 PATH 真的连上了。
确认 JDK 安装路径比写对 export 更关键
配错 JAVA_HOME 的根本原因，90% 是路径本身就不对。Linux 下 OpenJDK 常见路径有三类，不能靠猜：
- Debian/Ubuntu：
/usr/lib/jvm/java-17-openjdk-<code>$(dpkg --print-architecture)（如amd64或arm64） - RHEL/CentOS/Fedora：
/usr/lib/jvm/java-17-openjdk（无架构后缀）或/usr/lib/jvm/jre-17-openjdk（注意这是 JRE，不含javac） - 手动解压 JDK：
/opt/jdk-17.0.2或/usr/local/jdk-17，需确认该目录下有bin/java和bin/javac
最保险的做法是先执行：
readlink -f $(which java)然后往上推两级（去掉
/bin/java），得到的就是真实 JDK 根目录。例如输出是 /usr/lib/jvm/java-17-openjdk-amd64/bin/java，那 JAVA_HOME 就该设为 /usr/lib/jvm/java-17-openjdk-amd64。
多版本共存时，/etc/profile 里的硬编码会失效
如果你后续要切换 JDK 版本（比如从 17 切到 11），直接改 /etc/profile 不仅麻烦，还容易引发权限和同步问题。这时候真正的复杂点就浮现了：全局配置的本质是“统一”，但开发需求常是“隔离”。
建议把 JAVA_HOME 的动态选择逻辑交给用户层或工具链：
- 保留
/etc/profile中的默认值，但用update-alternatives --config java管理系统级 Java 二进制软链 - 让每个用户在自己的
~/.bashrc里用export JAVA_HOME=...覆盖全局值（shell 加载顺序保证用户配置优先） - CI/CD 或容器环境直接在启动脚本里指定，不依赖系统级变量
硬编码在 /etc/profile 里看似一劳永逸，实则把灵活性锁死了——这才是最容易被忽略的代价。
