改了 ~/.profile 但 java -version 报错是因为该文件仅被登录 shell 读取，而非登录 shell（如多数终端、cron、systemd）不加载它；应将 JAVA_HOME 和 PATH 配置写入 /etc/profile.d/java.sh 并确保路径正确、权限为 644。
为什么改了 ~/.profile 但 java -version 还是报 command not found
因为 ~/.profile 只在登录 shell（login shell）中读取，而你日常用 SSH 连上、开个新终端、或跑脚本时，大概率启动的是非登录 shell（non-login shell），它不加载 ~/.profile。常见表现就是手动执行 source ~/.profile 就行，一关终端又失效。
- SSH 登录默认是 login shell，但很多终端模拟器（如 GNOME Terminal、iTerm2）默认开的是 non-login shell
-
sudo -i是 login shell，sudo su不一定，取决于配置 - systemd 服务、crontab、CI 脚本几乎全是 non-login shell，完全无视
~/.profile
全局生效的真正路径：优先写进 /etc/profile.d/ 而不是 /etc/profile
/etc/profile 虽然全局，但它是系统级入口脚本，直接修改容易被系统更新覆盖；/etc/profile.d/ 是设计用来放独立环境模块的目录，后缀为 .sh 的文件会被自动 source，安全且可维护。
- 新建文件必须以
.sh结尾，比如/etc/profile.d/java.sh - 文件权限设为
644（不可执行），否则某些发行版会跳过加载 - 内容只需两行：
export JAVA_HOME=/opt/jdk-17.0.1和export PATH=$JAVA_HOME/bin:$PATH - 别漏掉
$PATH原有值，否则会丢失ls、cp等基础命令
Java 安装路径选 /opt 还是 /usr/lib/jvm？
/usr/lib/jvm 是 Debian/Ubuntu 系统包管理器（apt）安装 OpenJDK 的默认位置，结构规整、有符号链接（如 default-java），适合用包管理方式维护；/opt 更适合手动解压的 Oracle JDK 或 Temurin 等第三方构建版本，语义清晰、不与系统包冲突。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 如果用
apt install openjdk-17-jdk，就用/usr/lib/jvm/java-17-openjdk-amd64（路径因架构和版本略有差异） - 如果下载 tar.gz 手动解压，推荐放
/opt/jdk-17.0.1，再建软链/opt/java → /opt/jdk-17.0.1方便后续升级 - 避免用
~/jdk或/root/jdk—— 普通用户根本访问不到，sudo -u appuser java必然失败
验证是否真生效：别只测当前终端
改完 /etc/profile.d/java.sh 后，必须新开一个完整登录会话（比如另起 SSH 连接），或用 su - $USER 模拟全新 login shell，才能确认真实效果。只在当前终端 source 是假阳性。
立即学习“Java免费学习笔记（深入）”；
- 检查
JAVA_HOME：printenv JAVA_HOME（不是echo $JAVA_HOME，后者可能被当前 shell 缓存） - 检查
PATH是否含bin：echo $PATH | grep -o '/[^:]*java[^:]*/bin' - 测试非交互场景：
bash -c 'java -version'和sudo -u nobody bash -c 'java -version'（后者更严苛） - 如果仍失败，运行
strace -e trace=execve bash -c 'java' 2>&1 | grep java看实际找的是哪个路径
环境变量这事，表面是改几行文本，实际卡点永远在 shell 类型判断、权限范围、以及谁在什么上下文里调用 Java —— 多数问题不是配错了，而是没想清楚“这个 java 命令到底由谁、在哪、以什么身份执行”。
