在MacOS上安装JDK说简单是真的很简单——装完打开终端敲一个java -version就能看到版本号说麻烦也确实是麻烦版本怎么选、官网下载页从哪进、装完JAVA_HOME配了半天不生效、项目里一个要JDK 8另一个要JDK 17一台电脑根本不够折腾。这些情况我基本都遇到过尤其是帮同事排查环境问题时十个有八个都卡在环境变量和版本选择上。这篇文章我就从安装前选版本讲起把.dmg安装、Homebrew安装、环境变量配置、多版本切换和常见报错全部过一遍适合刚开始接触Java的初学者也适合被MacOS上JDK环境搞到头大的老手。1. 安装前先搞清楚Mac芯片架构和JDK版本1.1 先看你的Mac是Apple Silicon还是Intel芯片很多人在下载JDK时根本没注意芯片架构拿到一个安装包就往回装结果装完要么提示无法打开要么跑起来明显卡顿。MacOS从2020年开始慢慢切换到Apple SiliconM1、M2、M3、M4系列但Intel芯片的Mac依旧有不少存量。这两类机器对JDK安装包的要求不太一样。查看方法很简单点击屏幕左上角的苹果图标选择“关于本机”如果看到“芯片”一栏写着Apple M1/M2/M3等就是Apple Silicon如果写的是Intel那就是Intel芯片。也可以在终端运行uname -m输出arm64表示Apple Silicon架构输出x86_64表示Intel架构。这个命令在下载JDK时非常有用因为很多下载页面会同时提供macOS AArch64和macOS x64两种包选错虽然也能装上但可能在加载本地库或做底层操作时出问题。尤其是搞Native Image、JNI这类东西架构不匹配会让你怀疑人生。有一点需要说明在Apple Silicon上装上x64版JDK天不会塌macOS会用Rosetta 2转译运行但属于“能跑和跑得好”之间的差距。如果你只是写普通业务代码可能感知不强但如果涉及性能测试、本地编译或者CPU密集运算建议还是老老实实选arm64版本。1.2 JDK 8、11、17、21怎么选什么时候用最新版JDK的版本问题比芯片架构更容易让人迷糊。目前市面上最常见的几个版本是JDK 8、JDK 11、JDK 17和JDK 21这几个都属于LTS长期支持版本Oracle会提供好几年的安全更新。中间那些版本比如JDK 9、10、12到16、18到20大多是过渡版本不会长期维护生产环境基本没人用。选择逻辑我一般建议这样场景推荐版本原因老项目维护Spring Boot 2.xJDK 8 或 11很多旧框架在JDK 17下会反射报错新项目Spring Boot 3.xJDK 17Spring Boot 3要求Java 17起步新项目且追求长期稳定JDK 21最新LTSSpring Framework 6.1支持学习最新语法和特性JDK 21或更新版虚拟线程、模式匹配等新特性体验更好搜索热词里频繁出现“jdk 8”“jdk 17”“jdk降级到17”“jdk 21”说明很多人的真实处境是项目代码是老的开发机上的JDK却是新的跑起来全是错误。其实JDK降级这件事并不复杂核心就是“一台机器可以同时装多个JDK版本切换JAVA_HOME指向即可”后面我会专门讲。另外还是要提醒一句不是最新版本就一定好。JDK的版本发布节奏是半年一个最新的非LTS版本虽然能体验新功能但很多依赖库、构建插件未必及时适配踩坑成本挺高。我自己在工作机上通常长期保留JDK 8和JDK 21两个版本偶尔用JDK 17做兼容性验证很少碰非LTS版本。1.3 发行版怎么选Oracle JDK、Temurin、OpenJDKJDK不只有一个“官方版本”它有很多发行版这一点经常把人绕晕。Oracle JDK是最多人认知里的“官方JDK”但它的许可协议经历了几次调整。以前Java 8时期Oracle JDK商用要收费后来Oracle推出了NFTC协议很多场景下可以免费使用但条款需要仔细看。对于个人开发和绝大多数企业内部开发场景问题不大但如果要部署到生产环境卖软件还是建议仔细核对授权。如果你不想纠结授权问题我建议优先考虑Temurin。Temurin是Eclipse基金会旗下的Adoptium项目出品的OpenJDK发行版开源免费社区活跃而且下载页面很清爽直接提供macOS的.pkg和.tar.gz包。很多CI镜像、Docker镜像用的也是Temurin开发环境和部署环境保持一致能少踩不少版本不一致的坑。其他发行版也有各自的定位Azul Zulu在嵌入式和高性能场景下有积累Amazon Corretto和阿里Dragonwell在云厂商生态里比较常见。选型时其实不用太纠结核心原则是“跟着你实际部署环境走”。比如公司生产环境用的Docker镜像是eclipse-temurin:17-jdk那开发机就装Temurin 17如果生产用的是某个云厂商的JDK开发环境也保持一致。这样至少能保证本地编译和线上运行用的是同一套运行时。2. JDK安装实操下载、安装、验证全流程2.1 从官网下载JDK别被“镜像站”坑了下载JDK的路径通常分两类。一类是Oracle官网地址是https://www.oracle.com/java/technologies/downloads/进去以后能看到各个版本的下载入口。Oracle下载页会要求你勾选接受许可协议有时候还需要登录Oracle账号。另一类是Adoptium官网https://adoptium.net/页面更简洁直接选版本、选操作系统、选架构就能下载。搜索热词里频繁出现“jdk官网”“jdk下载官网”“oracle官网jdk下载”说明这个问题确实是高频需求。我个人的偏好是需要Oracle JDK时就老老实实从Oracle官网下需要Temurin时从Adoptium官方渠道下。至于那些来路不明的“jdk镜像网站”或第三方下载站我强烈建议绕开——JDK安装包是需要管理员权限安装的系统级组件一旦被塞了额外的东西风险比普通应用大得多而且很难察觉。下载时还要注意文件后缀。macOS下常见的JDK安装文件有三种.dmg、.pkg和.tar.gz。.dmg和.pkg都是图形化安装包双击后一路下一步就能装好.tar.gz是压缩包解压后手动放到指定目录后面我会讲到这种方式它其实更适合多版本管理。2.2 .dmg/.pkg安装装完有哪些隐藏变化用.dmg安装JDK的流程大家应该不陌生双击.dmg挂载磁盘镜像然后运行里面的.pkg安装器输入管理员密码等进度条走完就完成了。安装完成后JDK会被放到/Library/Java/JavaVirtualMachines/目录下目录名类似jdk-17.jdk或jdk-21.jdk。这里有一个macOS特有的隐藏变化安装器会自动把/usr/bin/java这个符号链接指到已安装JDK的bin/java所以你会发现装完以后不用配任何环境变量直接在终端敲java -version就能看到输出。这也导致很多人误以为“装完就能用不用配环境变量”结果到了Maven、Gradle、Tomcat这些工具面前又傻眼了因为它们找的是JAVA_HOME。安装过程中有两个小细节值得注意。第一如果Mac上已经装过其他版本的JDK再装新版本时不会覆盖旧版本而是并存在/Library/Java/JavaVirtualMachines/下面系统会有一个默认的优先级机制后面可以手动切换。第二安装包报错的时候不要反复重试同一个文件先检查一下下载是否完整有时候重新下载一遍就好了。2.3 另一种干净方式用Homebrew装JDK如果你不想去网页上点下载也不喜欢图形化安装向导Homebrew是个很舒服的选择。Homebrew是macOS上最常见的包管理器安装JDK只需要一行命令brew install --cask temurin17如果要用Oracle JDK也可以brew install --cask oracle-jdk用Homebrew安装的最大好处是升级、卸载都很方便而且它会自动处理一些乱七八糟的依赖。但这里有个坑Homebrew里通过brew install openjdk17这种方式安装的OpenJDK属于keg-only意思是它不会主动把自己放进/usr/bin或默认的Java路径里。安装完成后终端会提示你执行一些额外的命令来配置链接很多人没注意这行提示装完发现java -version仍然报错还以为安装失败了。另外Apple Silicon上的Homebrew默认装在/opt/homebrew目录Intel芯片的Mac装在/usr/local目录。如果你同时用了Rosetta 2转译的Homebrew和原生Homebrew两个包管理器的JDK是互相隔离的这也可能是环境变量反复出问题的一个隐藏原因。2.4 安装后的验证三连java、javac、java_home无论用哪种方式安装装完之后建议依次运行三个命令确认JDK真的安装成功了java -version javac -version /usr/libexec/java_home -Vjava -version和javac -version分别验证运行时和编译器是否可用。第三个/usr/libexec/java_home -V是macOS自带的一个工具它会列出系统里所有已经安装的JDK版本输出类似这样Matching Java Virtual Machines (4): 21.0.5 (arm64) Eclipse Temurin - Java SE 21.0.5 /Library/Java/JavaVirtualMachines/temurin-21.jdk/Contents/Home 17.0.13 (arm64) Eclipse Temurin - Java SE 17.0.13 /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home 1.8.0_392 (x86_64) Eclipse Temurin - Java SE 8 /Library/Java/JavaVirtualMachines/temurin-8.jdk/Contents/Home这个命令在排查问题的时候特别有用。比如有同事跟我说“IDEA里看不到JDK”我第一反应就是让他跑一下/usr/libexec/java_home -V看系统到底认不认识这个JDK。如果系统列表里根本没有说明JDK没装好如果系统列表里有但工具里找不到那问题多半出在工具配置上不是JDK本身。3. JAVA_HOME环境变量配置配置对了才稳3.1 先理解苹果的java_home机制再动手配置很多人一上来就照抄Windows的配置习惯在/etc/profile或~/.bash_profile里写死一个JDK路径结果macOS默认shell是zsh配置根本没被加载。为了不瞎折腾先搞清楚macOS定位JDK的机制比直接抄命令更重要。macOS系统自带/usr/libexec/java_home这个工具它负责在/Library/Java/JavaVirtualMachines和~/Library/Java/JavaVirtualMachines这两个目录里查找已安装的JDK并根据版本、架构、厂商信息返回最合适的一个路径。安装JDK时自动创建的/usr/bin/java链接本质上也是调用java_home来找到实际执行文件。所以macOS的java命令本身不需要JAVA_HOME也能工作。但问题出在其他工具上。Maven、Gradle、Tomcat、IDEA、Eclipse等工具在启动时并不会调用/usr/bin/java它们会直接读取JAVA_HOME环境变量。如果JAVA_HOME没配好就会出现一种令人抓狂的现象终端里java -version显示的是17但mvn -version显示的却是8甚至干脆报错找不到JDK。3.2 手把手配置~/.zshrc含代码和验证步骤macOS从Catalina开始默认shell变成了zsh所以环境变量配置应该写在用户目录下的.zshrc文件里。配置方法很简单# 编辑 ~/.zshrc vi ~/.zshrc在文件末尾加上export JAVA_HOME$(/usr/libexec/java_home -v 17) export PATH$JAVA_HOME/bin:$PATH然后执行source ~/.zshrc这里最推荐的方式是用/usr/libexec/java_home -v 17动态获取路径而不是写死/Library/Java/JavaVirtualMachines/jdk-17.jdk/Contents/Home。两者的区别在于动态获取方式在JDK升级后依然有效而写死路径一旦JDK小版本更新路径里的版本号可能就变了配置就失效了。如果你只想配JDK 8就把参数改成-v 1.8。例如老项目里需要JDK 8时可以临时在终端执行export JAVA_HOME$(/usr/libexec/java_home -v 1.8) export PATH$JAVA_HOME/bin:$PATH验证配置是否生效可以依次执行echo $JAVA_HOME java -version which java如果输出路径指向你想要的JDK版本目录就说明配置成功了。一个小细节是修改.zshrc后新开的终端窗口才会自动加载最新配置已经打开的终端窗口里要么执行source ~/.zshrc要么直接新开一个窗口否则会误以为配置没生效。3.3 多版本切换和“JDK降级”的实现“JDK降级”其实是很多人的真实需求尤其是项目从新版本Java切回老版本时。理解前面提到的机制后你会发现降级根本不是卸载新版JDK而是让JAVA_HOME指向旧版本而已。最朴素的做法是每次都手动写export命令但这样效率太低。我自己的方案是在.zshrc里定义几个快捷命令alias jdk8export JAVA_HOME$(/usr/libexec/java_home -v 1.8); export PATH$JAVA_HOME/bin:$PATH; java -version alias jdk17export JAVA_HOME$(/usr/libexec/java_home -v 17); export PATH$JAVA_HOME/bin:$PATH; java -version alias jdk21export JAVA_HOME$(/usr/libexec/java_home -v 21); export PATH$JAVA_HOME/bin:$PATH; java -version这样在终端里输入jdk17当前窗口就会立刻切到JDK 17。每次切换后建议先确认一下java -version输出再继续干活。需要注意切换只对当前终端窗口和从当前窗口启动的进程生效新开的终端窗口会回到.zshrc里的默认设置。还有一个观点我必须强调不要因为项目要用JDK 8就把系统里唯一的JDK卸载了再装8。多个版本并存是常态也是最好的方案。你在同一台机器上开三个终端窗口分别用JDK 8、17、21跑不同项目完全可行。4. 多版本JDK管理与卸载4.1 用SDKMAN管理JDK适合频繁切换的人如果你需要在多个JDK版本之间频繁切换手动改.zshrc还是有点笨拙。这时候可以试试SDKMAN它是一个命令行工具专门用来管理JDK、Maven、Gradle这类Java生态的开发工具。安装SDKMAN很简单在终端执行curl -s https://get.sdkman.io | bash安装完成后新开一个终端窗口输入sdk list java就能看到所有可用的Java发行版和版本号。然后安装指定版本sdk install java 17.0.13-tem切换到某个版本sdk use java 17.0.13-tem设置为默认版本sdk default java 17.0.13-temSDKMAN的实现原理并不神秘它本质上也是在管理JAVA_HOME环境变量只不过把环境管理、版本切换、多发行版选择这些操作统统包成了命令。好处是命令统一、容易记忆坏处是对于只用一两个版本的人来说引入一个额外工具反而多了一层复杂度。我的建议是如果你需要同时维护三个以上JDK版本可以认真考虑SDKMAN如果只是偶尔用一下老版本手动配置完全够用。4.2 手动放JDK到指定目录干净且直观还有一种多版本管理方式对我个人来说其实最顺手直接下载.tar.gz压缩包解压后放到合适的目录完全绕开图形安装器。macOS的java_home工具会识别两个目录一个是系统级的/Library/Java/JavaVirtualMachines另一个是用户级的~/Library/Java/JavaVirtualMachines。操作步骤大致是# 下载 temurin-17.tar.gz 后解压到目标目录 mkdir -p ~/Library/Java/JavaVirtualMachines tar -xzf temurin-17.tar.gz -C ~/Library/Java/JavaVirtualMachines/ # 验证是否被系统识别 /usr/libexec/java_home -V用这种方式安装的JDK不经过系统的安装向导不会创建/usr/bin/java符号链接也不会写入一些系统级配置但java_home依然能正确识别它IDEA这类工具也能正常发现。想卸载某个版本时直接删除对应的.jdk文件夹即可不存在卸载残留问题。这种方式也有一个小缺点因为.tar.gz版JDK没有注册到系统安装器所以以后想用pkgutil命令查看安装记录时看不到它。但说实话对于开发环境来说这个缺点可以忽略不计。4.3 卸载JDK与清理残留JDK卸载也是一个被搜索很多次的问题因为很多人在安装新版JDK后没意识到旧版还在导致java -version输出的始终不是自己想要的版本。如果你是用.dmg/.pkg安装的JDK最简单的卸载方式是直接删除目录sudo rm -rf /Library/Java/JavaVirtualMachines/jdk-17.jdk如果你是用Homebrew安装的卸载命令是brew uninstall --cask temurin17卸载完成后建议执行一次/usr/libexec/java_home -V确认版本已经不在列表里。如果你发现/usr/bin/java这个链接还指向已删除的JDK不用太担心它会在系统重新定位时自动找下一个可用的JDK。少数情况下可能需要重启终端或重启系统才能真正干净。很多人提到的“macOS系统数据占用过大”往往也和残留的旧JDK有关。一个JDK安装目录动辄几百MB如果每年装一个新版本三四年下来系统里可能躺着七八个JDK占掉好几个G。建议定期检查/Library/Java/JavaVirtualMachines目录把不再使用的版本删掉。这比清理各种缓存要安全得多效果也直接得多。5. 常见问题与排查技巧实录5.1 “找不到JDK”“java: command not found”怎么办新装的Mac或者刚重装完系统打开终端敲java -version最常见的报错就是zsh: command not found: java这时候第一步不是去配环境变量而是先确认JDK到底装没装。运行ls /Library/Java/JavaVirtualMachines/ /usr/libexec/java_home -V如果目录为空说明JDK根本没装上回到第2章的安装流程重新装一遍。如果目录里有.jdk文件夹但java命令依然找不到那问题多半出在PATH上。macOS的/usr/bin/java实际上是一个符号链接它依赖java_home机制来定位真实JDK。如果连/usr/bin/java都不存在说明系统安装器没有正确建立链接。这种情况多发生在用.tar.gz手动安装JDK后因为没有执行系统安装器/usr/bin/java自然不会指向任何地方。解决办法就是手动配置环境变量export JAVA_HOME并把它加入PATH这样就可以不依赖/usr/bin/java直接使用JDK。5.2 环境变量配置了却不生效这个问题的出现频率极高我几乎每周都能遇到一次。症状是明明打开了~/.zshrc明明加了export语句为什么新开终端还是看不到JAVA_HOME先按顺序排查三件事。第一确认你改的是不是当前shell对应的配置文件。macOS默认shell是zsh对应的是~/.zshrc如果你手动切换过shell的bash对应的是~/.bash_profile或~/.bashrc。改错文件必然不生效。第二确认语法没有被破坏。export JAVA_HOME$(...)这种写法中括号前后不要有多余空格引号不要用中文引号。第三确认配置加载顺序是否有其他文件覆盖了你的设置。.zprofile、.zshrc、.zshenv的执行顺序不一样如果你在多个文件里都写了JAVA_HOME后加载的文件会覆盖先加载的。最直接的验证方法是新开一个终端窗口依次执行echo $JAVA_HOME cat ~/.zshrc | grep JAVA_HOME如果echo $JAVA_HOME有输出说明配置生效了如果输出为空但grep能看到配置说明配置文件没有被加载。这时候大概率是shell类型不对或者加载顺序有问题。一个比较彻底的排查手段是zsh -x这会启动一个带调试输出的zsh它会清楚显示加载了哪些配置文件以及每一步发生了什么。虽然不是特别美观但排查加载问题时非常高效。5.3 pkg安装包报错“准备安装时发生错误”搜索热词里的“macos准备安装时发生错误请尝试重新运行此程序”是一个很典型的macOS安装器报错。这个报错出现在双击.pkg安装包后安装器可能还没进入正式界面就弹出红色警告。我遇到过的原因大致有几种。最常见的是下载的安装包不完整或者磁盘镜像挂载过程中出了点问题文件校验没通过。这种情况最简单的办法是重新下载安装包下载完成后先对比一下文件大小是否和官网一致再双击运行。第二个常见原因是安装包格式和当前macOS版本不兼容新版JDK的安装包可能要求macOS 12以上你还在跑macOS 10.14或10.15这时候换一个支持旧系统的JDK版本就能解决。第三个原因比较隐蔽系统里已经存在同名或相同版本的JDK安装器和旧版本的残留记录冲突了。可以先到/Library/Java/JavaVirtualMachines目录看看有没有同版本文件夹有的话先备份后删除再重新安装。如果以上方法都不奏效可以试试重启Mac再安装。macOS安装器的临时状态偶尔会卡住重启能清理掉大部分临时问题。这个过程其实和系统级安全日志有关但普通用户没必要深究重启、重新下载、更换安装包版本这三个动作能覆盖绝大多数场景。5.4 IDEA、JMeter等开发工具识别不到JDK很多工具自己在启动时会扫描系统里的JDK但它们扫描的方式和java_home并不完全一致。比如IntelliJ IDEA发现不了JDK通常需要在File Project Structure SDKs里手动添加JDK路径路径应该是.jdk文件夹的Contents/Home子目录例如/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home。JMeter的情况更典型。JMeter本身是个Java应用启动时会去找JAVA_HOME环境变量如果JAVA_HOME没配置它要么启动失败要么用系统默认的Java版本跑两种都可能带来诡异问题。不仅仅是JMeterEclipse MAT、各种命令行工具都遵循类似的逻辑。所以排查工具识别不到JDK时优先检查这两件事工具自带的JDK设置页面里有没有正确指向JDK路径以及启动工具的那个终端窗口里的JAVA_HOME是不是你期望的版本。如果是在图形化界面里启动的工具还要注意图形应用不一定会读取终端里的环境变量可能需要单独配置LaunchAgent或者在.zshrc里设置全局环境。6. 不同项目场景下的JDK版本适配6.1 Spring Boot / Spring Authorization Server需要哪个JDKJava开发最常遇到的版本适配问题就是Spring Boot项目。Spring Boot 2.x基于Java 8构建在JDK 8到JDK 17之间都能正常跑但Spring Boot 3.x强制要求Java 17以上。如果你在Spring Boot 3.0的项目里用JDK 8编译Maven会直接报错提示class file版本不对或java.version配置不兼容。Spring Authorization Server也是如此。它的1.x版本基于Spring Security 6要求JDK 17起步。搜索热词里提到“spring authorization server自定义过滤器”这类定制开发场景建议直接使用JDK 17或JDK 21避免老版本JDK在某些新API上出现不兼容。实际项目里最常见的坑不是代码问题而是IDE、Maven和系统三者的Java版本不一致。比如系统默认JDK是8但项目用Maven编译时指定了java.version17/java.version构建工具就会抛错。排查这类问题我习惯先用mvn -version看Maven使用的是哪个Java版本再用java -version看系统Java版本最后检查项目的pom.xml里maven.compiler.source/target或java.version配置三者对齐了问题基本就消失了。6.2 JMeter、Eclipse MAT这类工具的JDK配置细节做性能测试或内存分析时很多人会临时装JMeter、Eclipse MAT这些小工具结果工具打不开第一时间怀疑是JDK没装好。其实这类工具的JDK配置思路高度一致。JMeter在启动时会读取JAVA_HOME环境变量如果找不到会退而求其次使用PATH里能找到的java命令。如果系统里有多个JDK而JAVA_HOME指向的是JDK 8JMeter也会用JDK 8跑即使你后来在终端里切换了JAVA_HOME也没用——因为JMeter进程是从某个特定终端或图形环境启动的继承的是那个环境里的变量。所以启动JMeter之前先确认当前终端窗口里的JAVA_HOME是否正确再用命令行启动这是一种更稳妥的做法。Eclipse MAT的情况稍有不同它基于Eclipse RCP启动时优先读取安装目录下的MemoryAnalyzer.ini配置文件里指定的JVM参数。老版本MAT对JDK版本敏感如果遇到闪退可以在MemoryAnalyzer.ini里显式指定-vm参数指向某个JDK的bin/java可执行文件。这招对很多基于Eclipse的工具都有效包括老版STS之类的插件化工具。6.3 升级macOS或磁盘空间告急时JDK怎么处理升级macOS大版本后偶尔会出现JDK环境异常的情况。大多数情况下系统更新不会主动删除/Library/Java/JavaVirtualMachines下的JDK但可能会改变默认shell的配置文件优先级或者把一些符号链接重置。如果你更新系统后发现java -version和更新前不一样先检查/usr/libexec/java_home -V看系统还认识多少个JDK。如果JDK还在列表里说明问题出在shell配置上重新检查.zshrc即可。磁盘空间告急是另一个高频话题。搜索热词里的“macos系统数据占用过大”很多人都会遇到。JDK本身不算特别大但多个版本的JDK叠加起来再加上各种开发工具缓存空间消耗就很可观。使用.pkg安装的JDK都会出现在/Library/Java/JavaVirtualMachines目录你可以按大小排个序把长期不用的老版本直接删掉。Homebrew用户还可以定期运行brew cleanup清理下载缓存能释放不少空间。这比盲目删除系统里的其他文件安全得多。有一点必须特别提醒不要为了清理磁盘空间去删除/usr/bin/java也尽量不要乱动/Library/Java/JavaVirtualMachines之外的系统Java相关目录。稳妥的做法永远是把不用的JDK目录删掉而不是去动系统的路径配置。最后再分享一个个人习惯。我以前也喜欢“哪个版本最新就装哪个”后来被生产环境狠狠教育过几次现在所有开发机都固定采用“一个默认LTS版本 一个备用LTS版本”的方案。工作机上默认JDK 21遇到老项目时再切到JDK 8这套组合让我在绝大部分场景下都游刃有余。装JDK最关键的一点不是背命令而是理解版本和路径的机制以及养成先确认当前环境是什么再动手的习惯。把这个习惯养成了以后换电脑、重装系统、加入新项目你都不会再被JDK环境卡住。