Mac M1 用户应该都体会过那种感觉：系统升级一时爽，开发环境火葬场。尤其是 Java 开发，最典型的版本就是升级完 macOS 之后，满怀期待地打开终端，敲下一行java -version，结果等来的不是版本号，而是一句冰冷的command not found。再点开日常使用的 IDE，项目里原本好好的 JDK 路径全部变红，Maven 启动直接报编译失败，那一刻的心情真的很难平静。
这篇文章就是针对这个场景做的一次完整复盘：Mac M1 以及整个 Apple Silicon 系列芯片，在系统大版本升级后，Java 命令消失、JDK 版本不匹配、环境变量失效、构建工具异常这类问题，到底是怎么发生的，应该按什么顺序排查，又怎么一次性修复到位。适合刚升级完系统、Java 环境突然崩掉的开发者，也适合那些准备升级但不想事后被动“接锅”的朋友提前避雷。整体思路先说清楚：先理解根源，再动手排查，最后用一套足够规范的配置让环境真正稳住。
1. 升级后到底动到了什么：先搞懂问题的根源
1.1 Apple Silicon 的“两个世界”
很多人拿到 M1 之后，想当然地以为它就是一台“速度快一点的 Mac”，开发环境跟以前的 Intel Mac 一样随便跑。但 macOS 的底层在这里分成了完全不同的两个世界：Apple Silicon 芯片走的是 arm64（也叫 aarch64）指令集，Intel 时代走的是 x86_64。你的 Java 工具链，到底是给哪个世界准备的，升级前和升级后的命运完全不同。
系统的做法很现实：能原生支持 arm64 的软件，直接跑；不能支持的旧 x86_64 软件，通过 Rosetta 2 翻译层来模拟。但是模拟毕竟不是原生的，尤其在 Java 这个对运行时环境极其敏感的工具链上，模拟层的表现会随着系统升级变得非常不稳定。如果你以前装的是 x86_64 版 JDK，升级前也许还能靠 Rosetta 撑着跑，升级后只要 Rosetta 2 没有被正确安装，或者系统升级过程把某些旧组件标记为不兼容，java 命令就会直接消失。
还有一个特别容易把人带偏的隐藏细节：升级后你打开的终端，本身可能是通过 Rosetta 2 启动的。这时候你执行uname -m，返回的居然是x86_64，哪怕这台机器明明就是 M1。你以为是自己在跑原生 arm64 环境，其实整个 shell 都活在那个翻译层里，排查问题的时候很容易被这个信息误导，白白绕一大圈。
1.2 PATH 与 JAVA_HOME 为什么说丢就丢
第二个关键点，是环境变量的加载机制。macOS 的 shell 加载顺序大致是这样：系统级的/etc/paths和/etc/paths.d，然后是登录 shell 的~/.zprofile、~/.zshrc，最后才轮到你在终端里手动输入的命令。系统升级一般不会主动清空你的~/.zshrc，但有几个很常见的“暗箱操作”会让 Java 环境悄悄失效。
最常见的是默认 shell 切换。很多从 Intel Mac 时代走过来的开发者，习惯把环境变量写在~/.bash_profile里，而新系统默认 shell 是 zsh，新开的终端根本不读 bash 的配置文件。再有就是 Homebrew 的路径迁移，Apple Silicon 机器上 Homebrew 默认装在/opt/homebrew，如果旧配置里写的是/usr/local的路径，升级后那些链接自然全部失效。还有时候是系统更新过程中，顺手把/usr/bin/java这个符号链接清理掉了，结果命令直接找不到可执行文件。
JAVA_HOME这个变量特别容易栽在“写死路径”上。我见过太多配置是export JAVA_HOME=/Library/Java/JavaVirtualMachines/某个旧版本.jdk/Contents/Home这种写法。升级后那个旧 JDK 目录如果还在，也许还能勉强用；如果系统更新把它删掉了，或者你被迫换成了新版本，那这个变量就彻底指向一堆不存在的文件。与其说是“环境变量丢了”，不如说是“你给环境变量指定的目标已经不存在了”。
1.3 “看起来正常”但实际已损坏的关键点
除了命令直接找不到，还有一类更隐蔽的问题：java 命令能执行，但实际指向的却是错误版本或错误架构。这种情况比“不能用”更难受，因为表面上看啥都正常，一编译就出错。
举例来说，Homebrew 的 openjdk 默认是 keg-only，意思是不主动链接到系统标准目录，需要手动链接才让系统识别。升级后 brew 的符号链接动不动就断开，java 还在，但根本不是你想用的那个。再比如 IDE 的项目 SDK 记录的是升级前的绝对路径，JDK 明明已经重装了，IDE 却还盯着那个早就被系统清理掉的旧目录。还有一种常见场景：/usr/libexec/java_home返回的默认 JDK 变成了系统自带的某一个版本，而不是你项目里指定的那个，于是 Maven 在编译时莫名其妙抛出UnsupportedClassVersionError。这种“能用，但不对”的问题，往往比直接不能用来得更阴险。
2. 系统级排查：一步步定位 Java 环境卡在哪
2.1 先跑一遍体检清单
遇到 Java 环境异常，第一步千万不要急着重装系统或者重装 JDK。先做一组快速检查，把问题精确锁定到具体环节。我最常用的命令和期望结果整理成了一张表，方便你照着操作：
| 检查项 | 命令 | 期望结果 | 异常典型表现 |
|---|---|---|---|
| 芯片架构 | uname -m | arm64 | x86_64说明当前 shell 处于 Rosetta 模拟 |
| Java 版本 | java -version | 输出版本号和运行时信息 | command not found或版本低于预期 |
| Java 命令来源 | which -a java | 指向某个 JDK 的 bin/java | 无输出或指向/usr/bin/java |
| JAVA_HOME | echo $JAVA_HOME | 一个真实存在的路径 | 为空、指向不存在路径 |
| 系统可见 JDK | /usr/libexec/java_home -V | 列出所有已安装 JDK | 列表为空或缺少期望版本 |
| 物理目录 | ls /Library/Java/JavaVirtualMachines/ | 至少有一个.jdk目录 | 目录空或不存在 |
| Homebrew 版本 | brew list --versions | grep -i jdk | 输出对应版本 | 无输出 |
这组命令的核心价值，是快速区分三种情况：第一，Java 到底有没有装；第二，系统能不能发现它；第三，shell 是不是真的在用你期望的那个它。三者缺一不可。
很多朋友一看到echo $JAVA_HOME返回空，就以为 JDK 丢了。其实 JDK 可能一直好好躺在/Library/Java/JavaVirtualMachines/下面，只是环境变量没配置好而已。反过来也有一种情况很滑稽：JDK 确实被系统清理了，但java -version还能输出一个莫名其妙的版本号，那多半是 shell 配置里写死了某个路径，文件早就没了，命令来自一个残留的缓存或者假的 alias。
2.2 JAVA_HOME 到底该指向哪
macOS 自带一个非常好用的工具：/usr/libexec/java_home。它会扫描系统标准目录，把所有可见 JDK 汇总起来，再根据你给的参数返回一个正确的路径。基础用法有下面几种：
- 直接执行
java_home，返回默认 JDK 的根目录； - 执行
java_home -V，列出所有可见 JDK 的详细信息； - 执行
java_home -v 17，查找主版本号为 17 的 JDK，有多个时返回优先级最高的那个； - 执行
java_home --arch arm64，限定只看 arm64 架构的 JDK。
既然系统提供了这个工具，那最好的做法就是别把 JAVA_HOME 写死，而是让它动态计算。推荐在~/.zshrc写入这样一段：
export JAVA_HOME=$(/usr/libexec/java_home -v 17 --arch arm64 2>/dev/null || /usr/libexec/java_home)这段配置的含义很朴素：优先拿到 arm64 架构的 Java 17 路径；如果系统里恰好没有满足条件的 JDK，就回退到默认 JDK。好处在于每次打开终端都会重新解析一次，升级系统后 JDK 安装路径如果发生变化，JAVA_HOME 也会跟着自动更新，从根源上避免了“写死路径失效”的坑。
不过要注意，多版本共存时，java_home的默认返回值不一定是你要的版本。比如同时装了 Java 17 和 Java 21，到底返回哪个，取决于系统注册时的优先级。所以正式环境里，最好显式写明-v参数，宁可多打几个字，也不要赌它能猜中你的心思。
2.3 如何判断现有 JDK 是否匹配 Apple Silicon
光有 JAVA_HOME 还不够，还得确认 JDK 的二进制架构是不是 arm64。最直接的办法是看可执行文件的架构信息：
file /Library/Java/JavaVirtualMachines/某个JDK目录/Contents/Home/bin/java输出里如果包含arm64，说明这是原生 Apple Silicon 版本；如果只有x86_64，说明它原本是为 Intel Mac 准备的。对于这种旧架构 JDK，你倒不一定要立马卸载，尤其在跑一些老项目的时候，它可能还是必需品。但我的观点很明确：开发环境尽量换成原生 arm64，把源源不断的潜在冲突从源头掐掉。
还可以用arch命令强制在指定架构下执行 java，用来验证兼容性：
arch -arm64 java -version如果这条命令报错，说明当前 JDK 没有 arm64 版本。同理，arch -x86_64 java -version会强制走 Rosetta 模拟。当你想确认“到底是不是架构差异引起的异常”时，这两条命令对比一下，答案基本就出来了。
Rosetta 2 这个翻译层也不是一直存在的。系统升级后它可能被移除，如果你确实需要跑旧 x86_64 软件，可以到系统设置的“软件更新”里触发安装，也可以直接用命令安装。装好之后，x86_64 的 JDK 才有机会在模拟层跑起来。但我还是那句话，新项目别在兼容层上耗精力，真没必要。
3. 修复方案：从快捷修复到规范管理
3.1 最直接的修复：重装 ARM64 版 JDK
如果不想研究太多原理，升级后 Java 环境已经摆明了不干活，那最快的修复路径就是：删掉旧 JDK，装一个新的 ARM64 版 JDK。
具体操作并不复杂。从 OpenJDK 的官方页面找到 macOS 的 ARM64 安装包，dmg 或 tar.gz 都可以。dmg 版双击按提示安装，安装结束 JDK 会被放到/Library/Java/JavaVirtualMachines/下，并且自动出现在/usr/libexec/java_home -V的列表里，基本不需要手动干预。
tar.gz 版会稍微麻烦一点，需要解压之后手动移动到系统标准目录：
sudo mkdir -p /Library/Java/JavaVirtualMachines sudo mv /path/to/jdk-17.jdk /Library/Java/JavaVirtualMachines/移动完目录结构必须保持完整，最终应该是/Library/Java/JavaVirtualMachines/jdk-17.jdk/Contents/Home，这个路径下面有bin/java、lib/这些标准内容。如果结构不对，java_home工具可能连影都找不到。
装完先验证：
/usr/libexec/java_home -V java -version如果java -version还是找不到命令，别急，接着看 3.2 节配置环境变量。
3.2 让 JAVA_HOME 和 PATH 不再“过几天就失效”
重装 JDK 只是第一步，环境变量的配置才是决定这个环境能稳多久的关键。推荐把配置写进~/.zshrc，毕竟 macOS 默认 shell 就是 zsh：
export JAVA_HOME=$(/usr/libexec/java_home -v 17 --arch arm64 2>/dev/null || /usr/libexec/java_home) export PATH="$JAVA_HOME/bin:$PATH"修改完保存，然后执行：
source ~/.zshrc重新打开终端验证一次。
为什么 PATH 里要把$JAVA_HOME/bin放在最前面？因为 macOS 的 PATH 默认会有/usr/bin、/usr/local/bin、/opt/homebrew/bin好几个入口，这些目录下面也可能存在名为java的可执行文件，PATH 的顺序决定了系统先找到谁。如果你不管顺序，很可能出现这种状况：JAVA_HOME 明明存的是 Java 17，java -version执行出来的却是 Homebrew 的旧版 openjdk。要查这个问题，就用：
type -a java这条命令会把所有可达的 java 路径按查找顺序列出来。发现顺序不对的话，就回头检查 PATH 配置。
另外必须提一个隐蔽又高频的坑：shell 对命令路径是有缓存的。改了 PATH 之后如果java -version还是旧结果，先别怀疑人生，执行一声：
hash -r清掉缓存再试。“我明明改了啊”这种乌龙，一半以上都是被缓存骗了。
3.3 多版本 Java 并存：用 jenv 还是不用 jenv
现实项目里，很少有人只需要一个 JDK。老项目可能锁死在 Java 8，新项目已经按 Java 17 全面展开，中间偶尔还会冒出个 Java 11 的遗留系统。这种情况下，我推荐用 jenv 做版本管理。
jenv 的工作方式很有意思，它自己不装 JDK，而是把你已经装到系统里的各个 JDK 注册进来，然后通过一个前置 shim 在 PATH 里做切换。好处是系统层面的 JDK 管理还是统一走标准目录，jenv 只在入口处帮你选路。安装配置大致是：
brew install jenv echo 'export PATH="$HOME/.jenv/bin:$PATH"' >> ~/.zshrc echo 'eval "$(jenv init -)"' >> ~/.zshrc source ~/.zshrc然后把已有的 JDK 添加进来：
jenv add /Library/Java/JavaVirtualMachines/jdk-17.jdk/Contents/Home jenv add /Library/Java/JavaVirtualMachines/jdk-8.jdk/Contents/Home jenv versions在某个项目目录下想固定版本时，就执行：
jenv local 17从此以后这个目录里的 java 就固定为 Java 17，其它目录不受影响。这里藏着一个非常关键的细节：jenv 默认不会同步修改 JAVA_HOME，Maven 这类工具可是直接读 JAVA_HOME 的。你必须先启用 export 插件：
jenv enable-plugin export这一步漏掉的话，你会遇到一种非常分裂的症状：终端里 java 版本已经切到 17 了，但 JAVA_HOME 还是 8，Maven 也照样按 8 的逻辑在跑。把这个插件开了，jenv 才会在切换 java 版本时同步更新 JAVA_HOME。
如果你不想引入额外工具，靠 shell 函数也能实现类似切换，但这种自维护方案对 shell 编程水平要求比较高，日常折腾成本不低，我在这里就不展开细讲了。
3.4 配套工具链：Maven、Gradle、IDE 的 SDK 路径
Java 开发环境从来不只是 java 命令本身，Maven、Gradle、IDE 这些配套工具，个个都有自己的 JDK 逻辑，而且谁也不听谁的。
先说 Maven。执行mvn -version，输出里不仅显示 Maven 版本，还会显示它正在使用哪个 Java 环境。如果项目要求 Java 17，输出却指向一个老版本路径，说明 Maven 的 JAVA_HOME 来源有问题。常见的“元凶”是~/.mavenrc文件，有些开发者喜欢在里面单独指定一份 JAVA_HOME，这个文件的优先级很高。系统升级后如果它还是写死的旧路径，那你在~/.zshrc里改破天也没用，因为 Maven 只认它自己的那一份。
Gradle 的坑通常出在守护进程上。升级系统后，老的 Gradle daemon 可能还保留着旧 JVM 的运行参数。就算你现在把环境变量修好了，daemon 没重启的话，构建时用的依然是旧 JVM。遇到这种情况，先停掉 daemon 再重新编译：
./gradlew --stop大多数时候问题会自动消失。如果项目的gradle.properties里显式配置了org.gradle.java.home，那这个配置的优先级更高，记得同步更新成新 JDK 路径。
IDE 这边，比较常见的问题是项目 SDK 记录的绝对路径失效了。升级系统后即使 JDK 已经重装，IDE 的项目配置文件里可能还指着旧路径。处理方式就是进入项目结构设置，找到 SDK 或 Java 相关的设置项，重新添加新 JDK 路径；如果 IDE 自己已经检测到新 JDK，优先选自动检测的那个。这里多说一句，如果你之前是用自定义目录安装的 JDK，IDE 死活检测不到很正常，统一放进系统 JavaVirtualMachines 目录能省掉非常多的麻烦。
Homebrew 安装的 openjdk 还有一套特殊的逻辑。前面说过它是 keg-only，升级后链接经常掉。需要重新手动建立链接：
brew link openjdk@17 --force如果系统提示文件已经存在，就先 unlink 再 link：
brew unlink openjdk@17 brew link openjdk@17 --force链接完成后再用/usr/libexec/java_home -V确认可见。个人习惯上，我并不会死磕 brew 的链接机制，而是直接把 Homebrew 安装的 openjdk 目录软链到 JavaVirtualMachines 下。这样系统标准目录和 brew 装的两条线就能统一管理，java_home也能识别到，后续维护思路会清晰很多。
4. 实操记录：一次典型的“升级后 Java 消失”全流程
4.1 现场症状与初步判断
这里记录一次我处理过的典型情况，可以当成标准样本来参考。用户机器是 M1，升级完系统之后打开终端，执行java -version，屏幕上只有一句command not found。执行echo $JAVA_HOME，返回的是空行。再查看/Library/Java/JavaVirtualMachines/，里面明明还有一个旧 JDK 目录，但执行/usr/libexec/java_home -V，列表居然是空的。
这组现象说三件事：JDK 物理文件还在，但系统已经看不见它；JAVA_HOME 没有配置或者配置失效；shell 里找不到 java 命令，处于完全“无人接客”的状态。很多人的第一反应是把系统整个重装，但冷静下来按步骤走，发现真正的原因就两条：一个是旧 JDK 是 x86_64 版本，升级后系统不认；另一个是 shell 配置里根本没有动态查找逻辑，写死的旧路径早就失效。
4.2 逐步修复与验证记录
整套修复拆成六步，每走一步都验证一下，宁可慢一点，也不要引入新问题。
第一步，确认当前 shell 和芯片架构。执行：
uname -m返回arm64，说明终端是原生 Apple Silicon 模式，不是 Rosetta。这一步很关键，如果返回的是x86_64，后面所有判断都有可能会被带偏。
第二步，查看物理目录里的 JDK 到底是什么架构：
file /Library/Java/JavaVirtualMachines/旧目录/Contents/Home/bin/java输出显示x86_64，确认这是 Intel 版本 JDK，升级后的系统识别不到它就顺理成章了。
第三步，下载 arm64 版 JDK，安装到/Library/Java/JavaVirtualMachines/。装完后执行/usr/libexec/java_home -V，列表里能看到新版本目录了。
第四步，修改 shell 配置，写入动态 JAVA_HOME 和 PATH，用前面 3.2 节那套命令。
第五步，执行source ~/.zshrc重新加载配置，然后验证：
java -version which -a java这一步成功的话，版本号正常输出，which -a java也会指向新 JDK 的 bin 目录。
第六步，检查配套工具链。先跑mvn -version确认 Maven 使用新的 JAVA_HOME，然后打开 IDE，重新添加 JDK 路径。到这里，整个升级后的 Java 环境恢复流程就闭环了。
4.3 为什么这么改：每一步背后的参数选择逻辑
这套流程看起来简单，但每一步的选择背后都有原因，不是随手拍的。
选 JDK 版本时，优先选 LTS 版本。JDK 17 和 JDK 21 是目前比较主流的长期支持版本，大部分框架和插件都已经完成适配。不建议在突发环境故障后去装一个最新预览版碰运气，那种版本可能让你陷进“代码没有错，就是编译不过”的奇怪漩涡。
使用/usr/libexec/java_home动态获取路径，是为了把路径漂移的风险交给系统自己管理。macOS 升级时如果调整了 JDK 的注册信息，这个工具能自动反映最新结果。写死路径的配置短期可用，但每次升级都在赌运。
PATH 顺序放在$JAVA_HOME/bin之前，是为了保证java命令来源的唯一性。前面说了，/usr/bin、/opt/homebrew/bin 这些位置都可能存在 java 入口，PATH 顺序决定生效者是谁。既然是专项排查，那就得保证终端里敲下的每一个 Java 命令，都来自你刚配好的那个 JDK，而不是某个野路子的链接。
IDE 重新添加 SDK 这一步，很多人觉得麻烦就跳过。但 IDE 的编译逻辑和命令行并不是同一套，它可能直接读取项目配置里的绝对路径，不会跟着 JAVA_HOME 自动变化。命令行修复完，IDE 仍然报错是很正常的结果，这一步真的省不得。
5. 常见问题速查与避坑经验
5.1 明明装了 JDK，终端却提示 command not found
先别急着怀疑系统，多数时候问题出在“你改的配置文件和终端读的配置文件不是同一个”。macOS 默认 shell 是 zsh，配置文件是~/.zshrc。如果你把 JAVA_HOME 写进了~/.bash_profile，那新开的终端压根不会加载它。这是我在实际环境里看见过最多的一类问题，没有之一。
处理方法分两步。第一，在终端里执行echo $SHELL，确认当前 shell 到底是 zsh 还是 bash，把配置写对地方；第二，用type -a java和hash -r排查缓存。shell 缓存这个细节太容易被忽略了，很多开发者确实改了 PATH，但命令结果一成不变，于是立刻怀疑人生，其实只是旧路径被缓存了而已。
5.2 版本号对不上：编译时报 UnsupportedClassVersionError
这个错误在升级后相当常见。它说的意思是：class 文件是用较新的 JDK 编译出来的，当前 JVM 版本太旧，读不懂面前这份文件。好比一个用最新版软件保存的文档，拿旧版本去打开，打开失败几乎是必然结果。
升级系统后，IDE 或构建工具可能自动选择了系统可见的默认 JDK，而这个默认 JDK 往往不是项目要求的那一个。解决方案是把三个入口统一到同一个 JDK：IDE 的 Project SDK、Maven 的 JDK for importer、Gradle 的 Gradle JVM。只改 IDE 里显示的版本是不够的，Maven 和 Gradle 各自维护着独立的 JDK 设置，三个入口只要有一个没对齐，命令行编译结果和 IDE 编译结果就永远对不上号。
5.3 构建工具下载依赖时报 HTTPS 证书错误
升级系统后，Maven 或 Gradle 下载依赖时突然报 SSL 证书相关错误，这种情况要先忍住，别急着归咎于 Java。macOS 的系统证书存储和网络代理设置很可能在升级后发生了变动。
建议按顺序排查：系统时间对不对；系统代理是不是残留了旧的代理地址；目标仓库地址是不是真的可达。如果是公司内网仓库，证书链可能受到系统更新影响，要把新证书导入到 JDK 的cacerts信任库。这里要重点提醒：修改cacerts属于底层操作，操作前一定把原文件备份好。比起直接改信任库，更轻松的第一步是确认这条下载路径用浏览器能不能正常访问。浏览器能访问，问题基本就不在网络层，可以放心往下追。
5.4 Homebrew 更新后 openjdk 频繁失效
如果你习惯用 Homebrew 来装 JDK，升级系统后再执行一遍brew upgrade，openjdk 可能就是最先断联的那一批。原因一方面在于 keg-only 设计，另一方面是 brew 更新时会顺手清理旧版本的符号链接。
处理办法还是那两个命令，unlink 再 link：
brew unlink openjdk@17 brew link openjdk@17 --force如果执行时提示权限不足，确认一下你对目标目录是否拥有写权限。在用户目录之外操作系统目录，通常需要管理员权限，请谨慎处理。个人建议是：能不用 brew 管理 JDK 就不用。系统级的 JDK 安装还是走官方 dmg 或 tar.gz，放进标准目录最稳，brew 适合用来装构建工具和其它依赖。少一个中间环节，升级后的不确定性就少一分。
5.5 常用问题速查表
| 现象 | 核心原因 | 快捷处理 |
|---|---|---|
| java 命令找不到 | PATH 或符号链接失效 | 配置 JAVA_HOME 并重载 shell |
| java 能运行但版本不对 | PATH 顺序或缓存问题 | 用type -a java确认来源，hash -r清缓存 |
| java_home -V 列不出已装 JDK | JDK 架构不符或目录结构损坏 | 重装 arm64 版并放回标准目录 |
| IDE 项目 JDK 变红 | 项目配置写死旧路径 | 重新添加 SDK 路径 |
| Maven/Gradle 编译报版本错误 | 编译入口与 JDK 版本不一致 | 统一 IDE、Maven、Gradle 三处 JDK |
| Homebrew openjdk 链接丢失 | keg-only 链接失效 | unlink 后重新 link |
5.6 升级前的一个预防习惯
最后说点预防性的经验。每次大版本升级系统前，强烈建议先把环境变量和已安装的 JDK 清单导出一份存档。JDK 列表用/usr/libexec/java_home -V就能拿到，环境变量用env | grep -E 'JAVA|PATH'导出。这个动作不复杂，但升级后能帮你快速做对比，一眼看出到底是环境变量丢了，还是 JDK 真的被系统带走了，不用从头开始猜。
把上面这套排查流程完整走完一遍，你会发现大多数 Mac M1 升级系统后的 Java 环境异常，根源就那么几类：架构不匹配、环境变量写死、各个构建工具各自维护着独立的 JDK 路径。我个人这几年踩坑踩得最多的其实是 shell 缓存，改完配置之后，第一件事永远是重新加载配置然后清缓存，这一招能省掉大半冤枉路。
最后的经验之谈：系统升级后如果 Java 环境出了问题，千万别急着格式化重装。从uname -m和java -version这两条命令开始，一步一步确认“组件在不在、系统认不认、shell 用没用”，九成的问题在半小时内都能解决。等这套流程熟练了，你也能在别人升级完系统一脸懵的时候，淡定地敲下那两条命令，然后告诉他们：先看架构，再看路径，最后清缓存。
