Mac JDK配置全指南：安装、环境变量与多版本管理

1. 为什么 Mac 上装 JDK 不是“点下一步”那么简单

很多人在 Windows 上装过 JDK，觉得无非就是下载 exe、双击安装、勾选路径、配个 JAVA_HOME 就完事了。但一到 Mac，尤其是 macOS Sonoma（14.x）或 Ventura（13.x）之后的系统，事情立刻变得微妙起来——你点开官网下载的 .dmg 文件，双击安装成功，终端里敲java -version也显示正常，可一打开 IntelliJ IDEA，它却报错：“No JDK specified”；或者你刚配好 Maven，执行mvn compile却提示JAVA_HOME points to wrong location；更常见的是，团队要求用 JDK 17 写新模块，但遗留系统必须跑在 JDK 8 上，你切来切去，不是javac: command not found，就是Unsupported class file major version 61—— 这些都不是配置错误，而是 Mac 系统底层对 Java 的调度逻辑和 Shell 环境加载机制，与 Windows 完全不同。

核心矛盾就在这里：Mac 不是“装完 JDK 就等于环境就绪”，而是“装完只是起点，配置才是真正的分水岭”。macOS 默认使用 zsh（自 Catalina 起），而 zsh 的启动文件（.zshrc/.zprofile）加载顺序、PATH 注入时机、Shell 子进程继承规则，都直接影响java、javac、mvn等命令能否被正确识别。更关键的是，Apple 自己早已弃用 Java（2017 年起不再预装），Oracle JDK 也不再提供 macOS ARM64（M1/M2/M3）原生安装包，OpenJDK 社区版本又分散在多个发行版（Adoptium/Temurin、Azul Zulu、Amazon Corretto、Red Hat Build of OpenJDK）之间，每个版本的安装路径、符号链接策略、甚至java_home命令的输出格式都不一致。

我亲身踩过的第一个坑，是在 M1 Mac 上用 Homebrew 装了openjdk@17，java -version显示 17.0.1，但运行 Spring Boot 启动类时抛出java.lang.UnsatisfiedLinkError: Native library (libjli.dylib) not found in resource path。查了三小时才发现，Homebrew 安装的 OpenJDK 默认不创建/usr/libexec/java_home可识别的标准路径结构，而 Spring Boot 的启动脚本硬编码依赖java_home -v 17的输出结果。这不是你代码的问题，是 Mac 上 JDK 的“存在形式”本身就不统一。

所以这篇文章不讲“如何下载 JDK”，而是直击本质：Mac 上 JDK 的安装行为，本质上是在做三件事——物理部署（把字节码放进磁盘）、逻辑注册（让系统知道它在哪）、环境绑定（让所有 Shell 和 GUI 应用都能一致调用它）。漏掉任何一环，你都会陷入“终端能跑，IDE 报错；命令行能编，Maven 失效”的诡异状态。接下来，我们一层层拆解这三件事怎么落地。

2. 安装环节：别只盯着 Oracle 官网，真正该用的是这三类 JDK 发行版

先明确一个事实：Oracle JDK 在 macOS 上已不具备生产推荐性。自 JDK 17 成为 LTS 版本后，Oracle 对免费商用的限制收紧（需订阅才能用于生产环境），且其官网提供的 macOS x64 安装包无法在 Apple Silicon（M 系列芯片）上原生运行（仅支持 Rosetta 2 模拟），性能损耗约 15–20%，GC 延迟波动明显。我实测过同一段 Kafka Producer 压测代码，在 Temurin 17 ARM64 下平均吞吐 42k msg/s，在 Oracle JDK 17 x64（Rosetta）下仅 33k msg/s，且 GC pause 时间多出 37%。

那么该装谁？答案很清晰：优先选 Adoptium/Temurin（Eclipse Foundation 主导），次选 Azul Zulu，慎用 Homebrew 默认源。下面这张表是我过去两年在 12 台 Mac（含 M1 Pro、M2 Max、Intel i9）上实测对比的结果：

提示：Temurin 是目前唯一在 macOS 上实现“安装即注册”的发行版。它安装时会自动向/usr/libexec/java_home注册条目，并创建标准符号链接/Library/Java/Home指向最新版 JDK，这是其他发行版做不到的。

安装实操步骤（以 Temurin 17 为例）：

1. 下载正确包型：访问 https://adoptium.net/zh-CN/temurin/releases/?version=17 → 找到macOS aarch64（M 系列芯片）或macOS x64（Intel 芯片）的.pkg文件（不是.tar.gz）。注意：.tar.gz是免安装版，需手动解压并配置，新手极易出错，务必选.pkg。

2. 双击安装，全程默认选项：安装器会自动将 JDK 放入/Library/Java/JavaVirtualMachines/temurin-17.jdk。这个路径是 macOS 官方约定路径，所有工具（包括java_home命令）都认它。

3. 验证注册是否成功：

   # 查看系统已注册的所有 JDK /usr/libexec/java_home -V # 正常输出应包含类似： # 17.0.1 (arm64) "/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home" # 获取 JDK 17 的绝对路径（供后续配置） /usr/libexec/java_home -v 17 # 输出：/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home

注意：如果你之前用 Homebrew 装过openjdk，请先卸载干净：

brew uninstall openjdk@17 openjdk@11 openjdk@8 sudo rm -rf /opt/homebrew/opt/openjdk*

否则java_home -V会混杂多个来源路径，导致后续配置混乱。

为什么不用.tar.gz手动解压？因为手动解压后，JDK 不会被java_home命令识别，你得自己写脚本去扫描/opt/java或~/Downloads/jdk-17这类路径，还要处理权限、符号链接、Info.plist 等一堆 macOS 特有文件。Temurin 的.pkg安装器内部做了这些事：它会写入/Library/Java/JavaVirtualMachines/标准目录、生成Contents/Info.plist（GUI 应用读取用）、设置正确的libexec权限、并触发java_home的数据库重建。省下的这 20 分钟，够你写三个单元测试。

3. 配置环节：PATH 和 JAVA_HOME 的生死时速，zsh 加载顺序决定成败

Mac 上 JDK 配置失败的 83% 案例，根源不在 JDK 本身，而在 Shell 环境变量的加载时机错乱。很多人照着网上教程，在.zshrc里加了：

export JAVA_HOME=$(/usr/libexec/java_home -v 17) export PATH=$JAVA_HOME/bin:$PATH

然后source ~/.zshrc，echo $JAVA_HOME显示正确，java -version也 OK，但一重启 Terminal，或者打开 VSCode，java -version就变回系统自带的 1.8（macOS 自带的过时 JDK）。这是为什么？

因为macOS 的 zsh 启动流程分三层，而.zshrc只在“交互式非登录 Shell”中加载。Terminal.app 新建窗口默认启动的是“登录 Shell”（login shell），它加载的是.zprofile，而不是.zshrc。VSCode 的集成终端、IntelliJ 的 Terminal、甚至某些 GUI 应用调用的 Shell，也默认走登录 Shell 流程。.zshrc在这里根本不会被执行。

我画了个真实加载链路图（文字版）：

Terminal 启动 → zsh 作为 login shell → 读取 ~/.zprofile ↓ （若 ~/.zprofile 未定义 JAVA_HOME） → 读取 ~/.zshenv（全局，但通常为空） ↓ （若未退出）→ 读取 ~/.zshrc（但此时 JAVA_HOME 已错过）

所以正确做法是：把 JDK 配置写进.zprofile，而不是.zshrc。.zprofile是登录 Shell 的专属配置文件，所有 GUI 应用启动的 Shell 都会加载它，且它在 Shell 初始化早期执行，确保JAVA_HOME在任何子进程启动前就已就位。

具体操作：

1. 编辑.zprofile（如果不存在就新建）：

   nano ~/.zprofile

2. 写入以下内容（关键！带注释说明每行作用）：

   # 【第1行】用 java_home 命令动态获取 JDK 17 路径，避免硬编码 export JAVA_HOME=$(/usr/libexec/java_home -v 17 2>/dev/null) # 【第2行】检查 JAVA_HOME 是否获取成功，失败则 fallback 到 Temurin 默认路径（防命令失效） if [ -z "$JAVA_HOME" ]; then export JAVA_HOME="/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home" fi # 【第3行】将 javac、java 等命令加入 PATH 最前面，确保优先调用 export PATH="$JAVA_HOME/bin:$PATH" # 【第4行】可选：为 Maven、Gradle 等工具显式声明，避免它们自行探测出错 export MAVEN_OPTS="-Xms512m -Xmx2g"

3. 立即生效配置：

   source ~/.zprofile

4. 验证是否全局生效：

   # 检查当前 Shell echo $SHELL # 应为 /bin/zsh # 检查 JAVA_HOME echo $JAVA_HOME # 应输出 /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home # 检查 PATH 中 java 是否在最前 echo $PATH | tr ':' '\n' | head -5 # 第一行应为 $JAVA_HOME/bin # 终极验证：新开一个 Terminal 窗口，执行 java -version # 必须显示 17.x.x javac -version # 必须显示 17.x.x

注意：如果你同时用了 Oh My Zsh 或其他框架，确认它没有在.zshrc里覆盖JAVA_HOME。Oh My Zsh 默认不碰 JAVA_HOME，但某些主题插件会。执行grep -r "JAVA_HOME" ~/.oh-my-zsh/可排查。

为什么不能把export JAVA_HOME=...写死成绝对路径？因为 Temurin 升级后，路径会从temurin-17.0.1.jdk变成temurin-17.0.2.jdk，硬编码路径会失效。而/usr/libexec/java_home -v 17命令会自动指向最新版 17.x，这是 macOS 原生支持的智能路由机制。

还有一个隐藏雷区：不要在.zshrc里重复写export JAVA_HOME。如果.zshrc和.zprofile都写了，且.zshrc在.zprofile之后加载（取决于你的框架），就会覆盖掉正确的值。我的经验是：.zprofile专管环境变量（JAVA_HOME、PATH、EDITOR），.zshrc专管交互行为（alias、prompt、fzf 配置），职责分离，永不冲突。

4. 多版本管理：jEnv 不是银弹，原生命令 + 符号链接才是 Mac 的正统解法

很多教程一上来就推jEnv：“一行命令切换 JDK！” 但我在 8 个项目中实测发现，jEnv在 macOS 上有三大硬伤：
① 它通过修改PATH前缀来“欺骗”系统，但 GUI 应用（如 IDEA、VSCode）启动时并不读取jEnv的 shell 函数，仍用.zprofile里的原始JAVA_HOME；
②jEnv的rehash命令在 Temurin 更新后经常失效，需手动jenv add，而jenv add又要求你精确知道新 JDK 的完整路径（/Library/Java/JavaVirtualMachines/temurin-17.0.2.jdk/Contents/Home），比直接改.zprofile还麻烦；
③ 当项目需要 JDK 11 + JDK 17 + JDK 21 并存时，jEnv的shell模式（当前终端生效）和local模式（当前目录生效）会互相干扰，java -version和mvn -v显示的版本可能不一致。

真正的 Mac 原生多版本管理方案，是/usr/libexec/java_home+ 符号链接 + IDE 项目级配置三位一体。

4.1 用java_home命令精准定位任意版本

java_home是 macOS 内置命令，无需安装，它读取/Library/Java/JavaVirtualMachines/下所有 JDK 的Contents/Info.plist，按版本号智能排序。这才是 Apple 认证的“官方路由”。

常用命令：

# 列出所有已注册 JDK（含架构信息） /usr/libexec/java_home -V # 获取 JDK 8 的路径（即使你装了 11/17/21，也能精准抓取） /usr/libexec/java_home -v 1.8 # 获取 JDK 11 的路径（注意：11 不写 1.11，写 11） /usr/libexec/java_home -v 11 # 获取最新版 JDK 17（自动匹配 17.0.2、17.0.3） /usr/libexec/java_home -v 17 # 获取最新版 JDK（不管几号） /usr/libexec/java_home -v 21

提示：java_home -v后面的版本号格式必须严格。JDK 8 是1.8，JDK 11+ 是11、17、21，不能写1.11或17.0，否则返回空。

4.2 创建/Library/Java/Home符号链接，实现系统级软切换

macOS 系统本身预留了一个“快捷入口”：/Library/Java/Home。这是一个符号链接，指向当前“系统默认 JDK”。很多老工具（如旧版 Ant、某些 Shell 脚本）会直接读取这个路径，而不是JAVA_HOME。

我们可以利用它做轻量级切换：

# 查看当前链接指向 ls -la /Library/Java/Home # 切换到 JDK 17（Temurin） sudo rm -f /Library/Java/Home sudo ln -s "/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home" /Library/Java/Home # 切换到 JDK 11（Temurin） sudo rm -f /Library/Java/Home sudo ln -s "/Library/Java/JavaVirtualMachines/temurin-11.jdk/Contents/Home" /Library/Java/Home

注意：必须用sudo，因为/Library/Java/是系统目录。执行后，所有未显式设置JAVA_HOME的进程（如双击运行的 Jar 包、某些 GUI 工具）都会自动使用新链接指向的 JDK。

4.3 IDE 级别配置：让每个项目用对 JDK，互不干扰

这才是多版本管理的终点——不要指望全局切换解决一切，而要让每个项目在自己的上下文中绑定 JDK。

• IntelliJ IDEA：
  File → Project Structure → Project→ 设置Project SDK为你需要的 JDK（如 Temurin-17）；
  File → Project Structure → SDKs→ 点+添加多个 JDK（Temurin-8、Temurin-11、Temurin-17），路径填/usr/libexec/java_home -v 8等命令的输出结果。

  关键技巧：IDEA 的Project SDK设置会覆盖系统JAVA_HOME，且对 Maven/Gradle 控制台生效。这是最可靠的方案。

• VSCode + Extension Pack for Java：
  打开项目根目录的.vscode/settings.json，添加：

  { "java.configuration.runtimes": [ { "name": "JavaSE-17", "path": "/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home" }, { "name": "JavaSE-11", "path": "/Library/Java/JavaVirtualMachines/temurin-11.jdk/Contents/Home" } ] }

  然后在 Java 文件中右键 →Java: Configure Java Runtime，选择对应版本。VSCode 的 Java 插件会据此启动 Language Server，确保语法检查、补全、调试全部基于目标 JDK。

• Maven 项目：在pom.xml中强制指定编译版本（防 IDE 配置遗漏）：

  <properties> <maven.compiler.source>17</maven.compiler.source> <maven.compiler.target>17</maven.compiler.target> <maven.compiler.release>17</maven.compiler.release> </properties>

  这样即使JAVA_HOME指向 JDK 11，Maven 也会用内置的javac（由maven-compiler-plugin下载）编译为 JDK 17 字节码。

总结多版本管理心法：
✅系统层：用/Library/Java/Home符号链接设默认 JDK（影响双击 Jar、老脚本）；
✅Shell 层：用.zprofile设JAVA_HOME（影响 Terminal、CLI 工具）；
✅IDE 层：在项目设置中显式绑定（影响开发、调试、构建）；
❌拒绝 jEnv 全局切换：它增加复杂度，却不解决 GUI 应用问题，得不偿失。

5. 排查实战：从 “java -version 正确但 Maven 报错” 到 “IDEA 找不到 JDK” 的完整链路

理论讲完，现在进入最硬核的部分：真实故障排查。我整理了过去三年在 Mac 上遇到的 7 类高频 JDK 相关故障，每类都给出现象 → 根因分析 → 完整排查链路 → 修复方案 → 验证方法，你可以当手册直接查阅。

5.1 故障：java -version显示 17，但mvn -v显示 Java version: 1.8

现象：
Terminal 中java -version输出openjdk version "17.0.1"，但执行mvn -v却显示Java version: 1.8.0_362，且mvn compile报错Unsupported class file major version 61（JDK 17 的 class 版本号）。

根因分析：
Maven 启动脚本（/usr/local/Cellar/maven/3.9.6/libexec/bin/mvn）内部硬编码了JAVA_HOME探测逻辑，它会优先读取环境变量，但如果没设，就 fallback 到/usr下的系统 JDK（macOS 自带的 1.8）。而你的.zprofile虽设了JAVA_HOME，但 Maven 脚本在子 Shell 中执行时，可能因 PATH 顺序问题，调用了/usr/bin/java而非$JAVA_HOME/bin/java。

完整排查链路：

1. which java→ 看是否指向$JAVA_HOME/bin/java（应为/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/java）
2. echo $JAVA_HOME→ 确认是否正确
3. cat $(which mvn) | grep "JAVA_HOME"→ 查看 Maven 脚本里如何探测 JAVA_HOME
4. mvn -X | head -20→ 开启 debug 模式，看 Maven 实际用了哪个 java
5. ps aux | grep mvn→ 看 Maven 进程的环境变量（JAVA_HOME是否被继承）

修复方案：
在.zprofile中，把$JAVA_HOME/bin放到PATH最前面（已写在第3节），并确保 Maven 是通过brew install maven安装（而非官网 zip 解压），因为 Homebrew 安装的 Maven 会正确继承 Shell 环境。

验证方法：

# 重启 Terminal，执行 mvn -v | grep "Java version" # 必须输出 Java version: 17.0.1

5.2 故障：IntelliJ IDEA 提示 “No JDK specified”，但 Terminal 一切正常

现象：
IDEA 启动后，新建项目时提示 “No JDK specified”，File → Project Structure → Project SDK下拉框为空，或只显示 “No SDK”。

根因分析：
IDEA 是 GUI 应用，它启动时的 Shell 环境不加载.zprofile，而是加载~/.zshenv（如果存在）或直接使用系统默认环境。因此，即使.zprofile里设了JAVA_HOME，IDEA 也看不到。

完整排查链路：

1. 终端中执行launchctl getenv JAVA_HOME→ 查看 GUI 进程能否读取该变量（通常为空）
2. open -a "IntelliJ IDEA"→ 用命令行启动 IDEA，观察是否仍有此提示（命令行启动会继承当前 Shell 环境）
3. ps aux | grep idea→ 查看 IDEA 进程的父进程，确认是否由 Dock 启动（Dock 启动 = GUI 环境）

修复方案：
永久方案：在~/.zshenv中设置JAVA_HOME（zshenv是所有 zsh 进程（包括 GUI）都会加载的最早配置文件）：

echo 'export JAVA_HOME=$(/usr/libexec/java_home -v 17)' >> ~/.zshenv echo 'export PATH="$JAVA_HOME/bin:$PATH"' >> ~/.zshenv

然后重启 Mac（或登出重登），让 GUI 环境重新加载。

快速方案：在 IDEA 中手动添加 JDK：
File → Project Structure → SDKs → + → Add JDK→ 导航到/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home。

验证方法：
重启 IDEA，File → Project Structure → Project SDK应显示 Temurin-17，且新建项目可正常创建。

5.3 故障：javac命令不存在，但java命令正常

现象：
java -version正常，但javac -version报错command not found。

根因分析：
java命令是 JRE 的一部分，而javac是 JDK 的编译器。你可能误装了 JRE（Java Runtime Environment）而非 JDK（Java Development Kit）。macOS 自带的/usr/bin/java就是 JRE，它没有javac。

完整排查链路：

1. which java→ 如果输出/usr/bin/java，说明你在用系统自带 JRE
2. ls $JAVA_HOME/bin/→ 查看是否有javac文件
3. /usr/libexec/java_home -V→ 确认是否真的装了 JDK（输出中应有JDK字样，而非JRE）

修复方案：
卸载所有非 JDK 发行版，重新从 Temurin 官网下载.pkgJDK 安装包安装。

验证方法：

javac -version # 应输出 17.0.1

5.4 故障：M1 Mac 上运行 Java 应用报UnsatisfiedLinkError: libjli.dylib not found

现象：
M1 Mac 上，java -jar app.jar启动失败，报错java.lang.UnsatisfiedLinkError: /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/lib/jli/libjli.dylib: dlopen(...): no suitable image found。

根因分析：
这是典型的架构不匹配。你装的是 Intel x64 版 JDK，但在 M1 上运行，Rosetta 2 无法正确加载libjli.dylib（JVM 启动库）。Temurin 的 ARM64 包名含aarch64，x64 包名含x64，极易选错。

完整排查链路：

1. uname -m→ 输出arm64（M 系列）或x86_64（Intel）
2. file /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/lib/jli/libjli.dylib→ 查看 dylib 架构
3. /usr/libexec/java_home -V→ 看输出中是否标注(arm64)或(x86_64)

修复方案：
卸载当前 JDK，从 Temurin 官网下载macOS aarch64版本重新安装。

验证方法：
java -jar app.jar正常启动，无 dylib 错误。

5.5 故障：JAVA_HOME设置正确，但 Gradle 报Could not determine java version from '17.0.1'

现象：
Gradle 7.6+ 报错Could not determine java version from '17.0.1'，尽管java -version显示正常。

根因分析：
Gradle 的 Java 版本探测逻辑过于严格，它期望java -version输出中version字段是纯数字（如"17.0.1"），但某些 JDK 发行版（如早期 Zulu）会在引号内加额外空格或字符，导致正则匹配失败。

修复方案：
升级 Gradle 到 8.0+（已修复此问题），或在项目根目录gradle.properties中强制指定：

org.gradle.java.home=/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home

验证方法：
./gradlew --version输出中JVM行显示正确版本。

5.6 故障：VSCode Java 插件提示 “The java.home variable is not set”

现象：
VSCode 右下角弹出警告 “The java.home variable is not set. Please configure java.home in the settings”，Java 语法检查失效。

根因分析：
VSCode 的 Java 插件不读取 Shell 环境变量，它只认settings.json中的java.home配置，或系统级JAVA_HOME（但 GUI 启动时不继承）。

修复方案：
在工作区.vscode/settings.json中设置：

{ "java.home": "/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home" }

或全局设置（Cmd+,→ Settings → searchjava.home→ Edit in settings.json）。

验证方法：
重启 VSCode，打开.java文件，无警告，且Ctrl+Click可跳转到 JDK 源码。

5.7 故障：java_home -V不显示刚安装的 JDK

现象：
双击安装了 Temurin 17.pkg，但/usr/libexec/java_home -V输出中没有它。

根因分析：
安装未完成或权限问题。.pkg安装器需写入/Library/Java/JavaVirtualMachines/，若磁盘空间不足、权限被锁、或安装中途取消，会导致目录不完整。

完整排查链路：

1. ls -la /Library/Java/JavaVirtualMachines/→ 看是否有temurin-17.jdk目录
2. ls -la /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Info.plist→ 看关键文件是否存在
3. cat /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Info.plist | grep -A5 "JVMVersion"→ 看版本信息是否正确

修复方案：
删除残留目录，重新安装：

sudo rm -rf /Library/Java/JavaVirtualMachines/temurin-17.jdk # 然后双击 .pkg 重装

验证方法：
/usr/libexec/java_home -V输出中出现17.0.1 (arm64)。

以上七类故障，覆盖了 Mac 上 95% 的 JDK 配置问题。你会发现，所有问题的根因都指向同一个底层逻辑：Mac 的环境变量加载机制、GUI 与 CLI 的隔离性、以及 JDK 在 macOS 上的“注册”而非“放置”本质。理解了这一点，你就不再需要背诵各种命令，而是能根据现象，快速定位到 Shell 层、系统层、还是应用层的问题。

6. 终极验证清单：5 分钟确认你的 Mac JDK 环境是否真正健康

装完、配完、切完，怎么才算“真正搞定”？我给自己定了一套 5 分钟验证清单，每次重装 JDK 或升级系统后必跑一遍。它不追求花哨，只检验最核心的连通性。

6.1 Shell 层验证（Terminal）

在全新 Terminal 窗口中执行（不要 source，要全新会话）：

# 1. 检查 JAVA_HOME 是否存在且路径正确 echo $JAVA_HOME | grep -q "temurin-17" && echo "✅ JAVA_HOME 正确" || echo "❌ JAVA_HOME 错误" # 2. 检查 java 和 javac 是否可用且版本一致 java -version 2>&1 | head -1 | grep -q "17.0" && \ javac -version 2>&1 | grep -q "17.0" && \ echo "✅ java & javac 版本一致" || echo "❌ java/javac 版本不一致" # 3. 检查 PATH 中 $JAVA_HOME/bin 是否在最前 echo $PATH | cut -d':' -f1 | grep -q "$JAVA_HOME/bin" && \ echo "✅ PATH 顺序正确" || echo "❌ PATH 顺序错误" # 4. 检查 java_home 命令能否识别 /usr/libexec/java_home -v 17 >/dev/null 2>&1 && \ echo "✅ java_home 命令可用" || echo "❌ java_home 命令失效"

6.2 GUI 应用层验证（IDEA / VSCode）

• IDEA：
  File → Project Structure → Project SDK→ 应显示 Temurin-17；
  新建一个HelloWorld.java，public static void main方法内写System.out.println("OK");，Ctrl+Shift+F10运行 → 输出OK。

• VSCode：
  打开.java文件，右下角状态栏应显示 `Java