1. 为什么 Mac 上装 JDK 不是“点下一步”那么简单很多人在 Windows 上装过 JDK觉得无非就是下载 exe、双击安装、勾选路径、配个 JAVA_HOME 就完事了。但一到 Mac尤其是 macOS Sonoma14.x或 Ventura13.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 自己早已弃用 Java2017 年起不再预装Oracle JDK 也不再提供 macOS ARM64M1/M2/M3原生安装包OpenJDK 社区版本又分散在多个发行版Adoptium/Temurin、Azul Zulu、Amazon Corretto、Red Hat Build of OpenJDK之间每个版本的安装路径、符号链接策略、甚至java_home命令的输出格式都不一致。我亲身踩过的第一个坑是在 M1 Mac 上用 Homebrew 装了openjdk17java -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 SiliconM 系列芯片上原生运行仅支持 Rosetta 2 模拟性能损耗约 15–20%GC 延迟波动明显。我实测过同一段 Kafka Producer 压测代码在 Temurin 17 ARM64 下平均吞吐 42k msg/s在 Oracle JDK 17 x64Rosetta下仅 33k msg/s且 GC pause 时间多出 37%。那么该装谁答案很清晰优先选 Adoptium/TemurinEclipse Foundation 主导次选 Azul Zulu慎用 Homebrew 默认源。下面这张表是我过去两年在 12 台 Mac含 M1 Pro、M2 Max、Intel i9上实测对比的结果发行版官网地址ARM64 原生支持java_home -v兼容性GUI 应用识别率IDEA/VSCode更新频率备注Eclipse Temurinhttps://adoptium.net✅ 完整支持AArch64✅ 完美兼容路径标准100%自动检测每月安全更新首选社区最活跃路径规范/Library/Java/JavaVirtualMachines/temurin-17.jdkAzul Zuluhttps://www.azul.com/downloads✅ 完整支持✅ 兼容路径略长98%偶需手动指定每月更新商业友好免费用于生产M1 编译优化极佳Amazon Correttohttps://corretto.aws✅ 支持但 ARM64 包命名混乱⚠️ 部分版本java_home不识别85%常需重装每季度AWS 生态适配好但 Mac 端维护较弱Homebrew openjdk17brew install openjdk17✅ARM64❌ 默认不注册到/usr/libexec/java_home40%IDEA 常找不到随 Brew 更新便捷但不可靠仅适合临时 CLI 工具链不建议用于开发主环境Oracle JDKhttps://www.oracle.com/java/technologies/downloads❌仅 x64需 Rosetta✅95%不定期LTS 版本免费仅限开发测试商用需付费提示Temurin 是目前唯一在 macOS 上实现“安装即注册”的发行版。它安装时会自动向/usr/libexec/java_home注册条目并创建标准符号链接/Library/Java/Home指向最新版 JDK这是其他发行版做不到的。安装实操步骤以 Temurin 17 为例下载正确包型访问 https://adoptium.net/zh-CN/temurin/releases/?version17 → 找到macOS aarch64M 系列芯片或macOS x64Intel 芯片的.pkg文件不是.tar.gz。注意.tar.gz是免安装版需手动解压并配置新手极易出错务必选.pkg。双击安装全程默认选项安装器会自动将 JDK 放入/Library/Java/JavaVirtualMachines/temurin-17.jdk。这个路径是 macOS 官方约定路径所有工具包括java_home命令都认它。验证注册是否成功# 查看系统已注册的所有 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 openjdk17 openjdk11 openjdk8 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.plistGUI 应用读取用、设置正确的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 ~/.zshrcecho $JAVA_HOME显示正确java -version也 OK但一重启 Terminal或者打开 VSCodejava -version就变回系统自带的 1.8macOS 自带的过时 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在任何子进程启动前就已就位。具体操作编辑.zprofile如果不存在就新建nano ~/.zprofile写入以下内容关键带注释说明每行作用# 【第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立即生效配置source ~/.zprofile验证是否全局生效# 检查当前 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.8JDK 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 17Temurin sudo rm -f /Library/Java/Home sudo ln -s /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home /Library/Java/Home # 切换到 JDK 11Temurin 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 IDEAFile → Project Structure → Project→ 设置Project SDK为你需要的 JDK如 Temurin-17File → Project Structure → SDKs→ 点添加多个 JDKTemurin-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.source17/maven.compiler.source maven.compiler.target17/maven.compiler.target maven.compiler.release17/maven.compiler.release /properties这样即使JAVA_HOME指向 JDK 11Maven 也会用内置的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 61JDK 17 的 class 版本号。根因分析Maven 启动脚本/usr/local/Cellar/maven/3.9.6/libexec/bin/mvn内部硬编码了JAVA_HOME探测逻辑它会优先读取环境变量但如果没设就 fallback 到/usr下的系统 JDKmacOS 自带的 1.8。而你的.zprofile虽设了JAVA_HOME但 Maven 脚本在子 Shell 中执行时可能因 PATH 顺序问题调用了/usr/bin/java而非$JAVA_HOME/bin/java。完整排查链路which java→ 看是否指向$JAVA_HOME/bin/java应为/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/javaecho $JAVA_HOME→ 确认是否正确cat $(which mvn) | grep JAVA_HOME→ 查看 Maven 脚本里如何探测 JAVA_HOMEmvn -X | head -20→ 开启 debug 模式看 Maven 实际用了哪个 javaps 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.15.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_HOMEIDEA 也看不到。完整排查链路终端中执行launchctl getenv JAVA_HOME→ 查看 GUI 进程能否读取该变量通常为空open -a IntelliJ IDEA→ 用命令行启动 IDEA观察是否仍有此提示命令行启动会继承当前 Shell 环境ps aux | grep idea→ 查看 IDEA 进程的父进程确认是否由 Dock 启动Dock 启动 GUI 环境修复方案永久方案在~/.zshenv中设置JAVA_HOMEzshenv是所有 zsh 进程包括 GUI都会加载的最早配置文件echo export JAVA_HOME$(/usr/libexec/java_home -v 17) ~/.zshenv echo export PATH$JAVA_HOME/bin:$PATH ~/.zshenv然后重启 Mac或登出重登让 GUI 环境重新加载。快速方案在 IDEA 中手动添加 JDKFile → Project Structure → SDKs → → Add JDK→ 导航到/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home。验证方法重启 IDEAFile → Project Structure → Project SDK应显示 Temurin-17且新建项目可正常创建。5.3 故障javac命令不存在但java命令正常现象java -version正常但javac -version报错command not found。根因分析java命令是 JRE 的一部分而javac是 JDK 的编译器。你可能误装了 JREJava Runtime Environment而非 JDKJava Development Kit。macOS 自带的/usr/bin/java就是 JRE它没有javac。完整排查链路which java→ 如果输出/usr/bin/java说明你在用系统自带 JREls $JAVA_HOME/bin/→ 查看是否有javac文件/usr/libexec/java_home -V→ 确认是否真的装了 JDK输出中应有JDK字样而非JRE修复方案卸载所有非 JDK 发行版重新从 Temurin 官网下载.pkgJDK 安装包安装。验证方法javac -version # 应输出 17.0.15.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.dylibJVM 启动库。Temurin 的 ARM64 包名含aarch64x64 包名含x64极易选错。完整排查链路uname -m→ 输出arm64M 系列或x86_64Intelfile /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/lib/jli/libjli.dylib→ 查看 dylib 架构/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文件无警告且CtrlClick可跳转到 JDK 源码。5.7 故障java_home -V不显示刚安装的 JDK现象双击安装了 Temurin 17.pkg但/usr/libexec/java_home -V输出中没有它。根因分析安装未完成或权限问题。.pkg安装器需写入/Library/Java/JavaVirtualMachines/若磁盘空间不足、权限被锁、或安装中途取消会导致目录不完整。完整排查链路ls -la /Library/Java/JavaVirtualMachines/→ 看是否有temurin-17.jdk目录ls -la /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Info.plist→ 看关键文件是否存在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 21 | head -1 | grep -q 17.0 \ javac -version 21 | 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 21 \ echo ✅ java_home 命令可用 || echo ❌ java_home 命令失效6.2 GUI 应用层验证IDEA / VSCodeIDEAFile → Project Structure → Project SDK→ 应显示 Temurin-17新建一个HelloWorld.javapublic static void main方法内写System.out.println(OK);CtrlShiftF10运行 → 输出OK。VSCode打开.java文件右下角状态栏应显示 Java