答案是切断直接路径硬编码，统一由java_home驱动path并控制加载顺序和作用域。需清理path中所有显式jdk路径，只保留%java_home%\bin（windows）或$java_home/bin:$path（linux/macos），确保java_home指向jdk根目录且末尾不带\bin，同时排查\_java_home等隐形覆盖变量，并交叉验证echo、where/which、java/javac版本一致性。
Java 环境变量被覆盖，本质不是配置没写，而是多个来源的设置相互打架——后加载的路径压过了你想要的 JDK，或者脚本临时定义的 _JAVA_HOME 抢占了系统级 JAVA_HOME。修复核心就一条：**切断直接路径硬编码，统一由 JAVA_HOME 驱动 PATH，并控制加载顺序和作用域。**
Windows：清理 PATH 中所有显式 JDK 路径，只留 %JAVA_HOME%\bin
系统变量里的 PATH 很容易被旧安装、IDE 或游戏悄悄加进类似 C:\Program Files\Java\jdk-8\bin 的条目。这些路径会排在用户变量之前或之中，导致 java -version 总调用老版本。
- 打开“系统属性 → 高级 → 环境变量”，在“系统变量”和“用户变量”中都检查 PATH
- 逐条查找含
\java\、\jdk-、\jre-的路径，全部删掉 - 只保留一条：
%JAVA_HOME%\bin（注意是百分号包裹，不是实际路径） - 确认 JAVA_HOME 变量本身存在且值为 JDK 根目录（如
C:\Program Files\Java\jdk-17），末尾不带\bin
Linux/macOS：统一在 ~/.bashrc 或 ~/.zshrc 中声明，并确保 login shell 加载
终端行为不一致？很可能是因为 VS Code 内置终端只读 ~/.zshrc，而 SSH 登录走的是 ~/.zprofile。不同入口加载不同文件，变量自然时有时无。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 编辑
~/.zshrc（macOS Catalina 及以后默认 Zsh）或~/.bashrc - 写入两行（路径按你实际 JDK 位置调整）：
export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64export PATH=$JAVA_HOME/bin:$PATH - 若用 Bash 且有
~/.bash_profile，末尾加source ~/.bashrc；Zsh 同理可在~/.zprofile中source ~/.zshrc - 改完运行
source ~/.zshrc，再新开终端验证
警惕脚本内 _JAVA_HOME 的隐形覆盖
某些启动脚本（如 Tomcat、自研部署脚本）会写 export _JAVA_HOME=...。这个下划线开头的变量虽非标准，但部分 Java 工具链会优先读它，直接绕过你的系统 JAVA_HOME。
- 执行
env | grep -i "_java"查看当前是否已存在_JAVA_HOME - 搜索常用脚本目录：
grep -r "_JAVA_HOME" /opt/tomcat/ ~/bin/ 2>/dev/null - 若发现脚本中硬编码了该变量，可注释掉，或改为
export JAVA_HOME=$HOME/java/jdk-17并同步更新 PATH - 临时规避：在运行前手动清除，如
unset _JAVA_HOME && ./startup.sh
验证与兜底：别只信 java -version
一个命令不够，要交叉比对才能确认是否真修复：
-
echo $JAVA_HOME（Linux/macOS）或echo %JAVA_HOME%（Windows）→ 看输出是否为你设的根路径 -
which java（Linux/macOS）或where java（Windows）→ 确认路径指向$JAVA_HOME/bin/java或%JAVA_HOME%\bin\java.exe -
java -version和javac -version→ 两者版本号必须一致，且是你期望的 JDK 版本 - 重启终端或资源管理器（Windows）再测，避免缓存干扰
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
