linux下java环境变量失效主因是source文件错配、path顺序错误或shell类型不匹配；需确认shell类型，优先配置对应rc文件，将$java_home/bin置于path最前，并验证java_home、which java及javac三者一致。
Linux上Java环境变量配不生效，90%不是因为写错了JAVA_HOME，而是source没对文件、PATH顺序错、或者用户权限/Shell类型不匹配。直接看关键点。
为什么java -version还是报command not found
常见现象是改了/etc/profile却没生效，或改了~/.bashrc但用的是zsh。根本原因是Shell启动时加载的配置文件不同：
- 登录Shell（如SSH登录）默认读
/etc/profile和~/.bash_profile（bash）或~/.zprofile（zsh） - 非登录Shell（如终端里新开一个tab）只读
~/.bashrc或~/.zshrc -
/etc/profile里export的变量，不会自动继承到子Shell的~/.bashrc中
实操建议：
- 先确认当前Shell：
echo $SHELL，再查它实际加载哪个文件：ps -p $$看进程名 - 如果用bash，优先改
~/.bashrc并执行source ~/.bashrc；全局部署才动/etc/profile - 改完立刻验证：
echo $JAVA_HOME必须有输出，which java必须指向你解压的bin目录
JAVA_HOME路径写错的三种典型情况
路径错误不会报错，但java命令会静默失败或调用系统旧版本。最常踩的坑：
- 路径末尾多加了
/bin：正确是export JAVA_HOME=/opt/jdk-17.0.1，错写成/opt/jdk-17.0.1/bin - 用了软链接未解析真实路径：
readlink -f $(which java)能帮你确认JVM实际位置，避免/usr/bin/java指向系统OpenJDK - 路径含空格或中文：Linux下绝对不要把JDK解压到
/root/我的jdk/这类路径，会导致CLASSPATH解析失败
验证方法：ls $JAVA_HOME/bin/java必须返回可执行文件，$JAVA_HOME本身不能是符号链接目录（除非你明确知道它指向哪）。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
PATH顺序导致javac能用但java用错版本
很多教程让写export PATH=$JAVA_HOME/bin:$PATH，这没问题；但如果之前PATH里已有/usr/bin，而它里面也有java，那系统会优先用PATH前面的——也就是你刚加的$JAVA_HOME/bin。但反过来，如果写成export PATH=$PATH:$JAVA_HOME/bin，就彻底失效了。
实操建议：
- 永远把
$JAVA_HOME/bin放在PATH最前面：export PATH=$JAVA_HOME/bin:$PATH - 检查实际生效顺序：
echo $PATH | tr ':' '\n'，确认你的bin目录排第一 -
which java和which javac输出路径必须一致，且都属于$JAVA_HOME下
验证是否真的成功：三步缺一不可
只跑java -version不够。生产环境出问题往往卡在编译器或类路径：
- 运行
javac -version：确认javac可用，且版本与java一致（JDK 17对应javac 17） - 测试
CLASSPATH：写个最小HelloWorld.java，用javac HelloWorld.java && java HelloWorld跑通 - 检查
JAVA_HOME被其他工具识别：mvn -v或gradle -v输出里必须显示你设的JAVA_HOME路径
最容易被忽略的是CLASSPATH里的.（当前目录）——它必须存在，否则java HelloWorld会报ClassNotFoundException，哪怕.class文件就在当前目录。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
