sudo 不继承用户环境变量，而是重置为 root 的最小化环境（如 secure_path），导致 JAVA_HOME、PATH 等失效，故 sudo java -version 常显示系统级默认 JDK 版本而非用户配置版本。
这是因为 sudo 启动的 shell 默认不继承当前用户的环境变量（尤其是 JAVA_HOME 和 PATH），而是使用 root 用户的环境配置，而 root 的 PATH 通常只包含 /usr/bin、/bin 等系统路径——这些路径下指向的是 update-alternatives 管理的系统级默认 Java，和你用户态手动设的 JAVA_HOME 完全无关。
sudo 下 java -version 显示不同版本的典型现象
你在普通终端执行 java -version 得到 JDK 17，但执行 sudo java -version 却显示 JDK 11 或 8。这不是 bug，是 Linux 权限隔离机制的自然结果：
-
sudo会重置大部分用户环境变量（JAVA_HOME、PATH、HOME等），仅保留少数白名单变量（如TERM） - root 用户的
PATH一般不含你自定义的 JDKbin目录（比如/opt/java/jdk-21/bin） - root 的
/usr/bin/java是由update-alternatives配置的，和你用户 shell 中改的PATH没有同步关系 - 即使你用
jenv切换版本，它只作用于当前用户 shell，sudo进程完全看不到 jenv 的 hook
如何验证 sudo 实际调用的是哪个 java
别只信 java -version，直接查路径：
which java # 用户态下看到的 sudo which java # sudo 下实际走的路径 ls -l /usr/bin/java # 通常是个指向 update-alternatives 的 symlink sudo update-alternatives --config java # 查看当前系统级默认选中项
你会发现 sudo which java 输出基本就是 /usr/bin/java，而它最终 resolve 到的正是 update-alternatives 注册的那个版本。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
不想每次 sudo 都切错 Java？三个实用办法
根据使用场景选一种，别硬改 root 的环境变量（容易引发系统工具异常）：
- 临时指定：用完整路径运行，比如
sudo /opt/java/jdk-21/bin/java -jar app.jar - 临时注入 PATH：
sudo PATH="/opt/java/jdk-21/bin:$PATH" java -version（注意引号，避免 shell 展开） - 长期可信场景（如 CI 脚本或部署任务）：在
/etc/environment或/etc/profile.d/java.sh中统一设置JAVA_HOME和PATH，这样sudo和 root 登录都生效
最常被忽略的一点：很多构建工具（如 Maven、Gradle）在 sudo 下运行时，会读取 JAVA_HOME；但如果你没在系统级配置里设它，它们就会 fallback 到 update-alternatives 的结果——这解释了为什么 sudo mvn compile 有时突然报 “source level 21 not supported”。
