1. 先搞清楚为什么现在还有人要装 JDK8打开任何一个后端招聘帖或者是老项目的部署文档你会发现一个很奇怪的现象2024 年了新项目都在讨论 JDK17、JDK21可偏偏有一大批系统还在 Windows 上用着 JDK8。这不是谁偷懒而是现实决定的。JDK8 是 Java 历史上生命周期最长的一个版本2014 年发布到 2030 年前后都还有商业支持版本在跑大量企业内部的中间件、老框架、定制化组件都建立在 JDK8 的语言特性和运行机制之上。你把它换成高版本轻则启动报错重则字节码不兼容、反射被模块系统拦住排查成本高得离谱。所以我写这篇东西不是教你点下一步就完事而是把这件看起来简单的事讲透。Windows 安装 JDK8这件事表面是下载一个安装包、配两个环境变量真正容易翻车的点在于选哪个发行版、装 32 位还是 64 位、JAVA_HOME 和 Path 到底谁管谁、机器上已经有别的 JDK 怎么办、命令行显示版本不对怎么查。这些问题在搜索引擎上答案零散而且互相矛盾很多人配了半小时环境变量最后卡在java -version打印出另一个版本上。这篇文章适合三类人看第一类是完全没接触过 Java 环境配置的新手想一次装对不折腾第二类是手上维护着老项目、需要在同一台 Windows 机器上让 JDK8 和 JDK17 和平共处的开发者第三类是帮同事、帮客户远程装环境的技术支持人员需要一套能复现、能抄作业的标准流程。全文基于 Windows 10 和 Windows 11 的实测Windows Server 2016 及以上同样适用涉及命令的地方我都会给出可直接粘贴的内容。在动手之前我建议你先在心里回答一个问题这台机器上的 JDK8是唯一版本还是多个版本之一答案不同后面的配置策略完全不一样。很多教程只讲单版本装法等你后面要装第二个 JDK 时环境变量一团乱只能重装系统级别的折腾。所以下面的内容我会两套都讲并且告诉你为什么。1.1 JDK8 到底老在哪又强在哪先说清楚概念避免新手把 JDK 和 JRE 混为一谈。JRE 是运行环境只有java命令能跑 class 文件但不能编译JDK 是开发工具包包含 JRE 外加javac、jar、javadoc、jps、jstack这些工具。你要做开发必须装 JDK如果只是运行别人打包好的程序装 JRE 理论上够用但实际工作中我建议一律装 JDK因为排查问题时jps、jstack、jmap这些工具是你唯一的救命稻草缺了它们线上问题只能靠猜。JDK8 相对 JDK7 最大的变化是引入了 Lambda 表达式和 Stream API让 Java 第一次有了像样的函数式写法。还有接口默认方法、方法引用、Optional 类、全新的日期时间 APIjava.time以及把永久代 PermGen 换成了元空间 Metaspace。这最后一条尤其重要以前 JDK7 跑久了报java.lang.OutOfMemoryError: PermGen space是无数人的噩梦JDK8 之后这个错误基本消失了取而代之的是元空间溢出排查思路完全不同。如果你在维护老系统看到 PermGen 相关的报错那说明机器上跑的其实不是 JDK8或者是 JDK8 但参数里还留着-XX:MaxPermSize这种情况下 JVM 会直接警告参数无效。还有个细节很多人不知道JDK8 的file.encoding在 Windows 上默认跟随系统区域设置中文环境就是 GBK。而 JDK9 之后默认改成了 UTF-8。这就导致同一个项目在 JDK8 上读文件正常换到 JDK11 上中文全乱码。反过来也一样。所以当你在 Windows 上装 JDK8 时编码问题一定要提前意识到不要等程序跑出乱码才回头找原因。1.2 哪些场景非 JDK8 不可我列几个实际遇到过的场景你对照看看自己是不是其中之一。第一公司内部的 ERP、OA、财务系统用的是十年前的框架比如 Struts2 加 Spring 3这些框架在高版本 JDK 上会直接抛异常。第二某些国产中间件、老版本的 Tomcat 7 或者 WebLogic官方支持的 JDK 上限就写死在 8。第三大数据生态里Hadoop、Hive、Spark 的早期版本对 JDK8 依赖很深虽然新版本已经支持 11 和 17但存量集群升级成本极高。第四教学和考试环境很多高校的 Java 课程、软考、认证考试仍然以 JDK8 为基准。第五也是最现实的一条你接手了一个没人敢动的项目能跑就行别的事以后再说。这种时候正确的做法不是顺便升级一下而是老老实实把 JDK8 装好先让系统稳定运行升级的事单独排期评估。我见过太多人抱着顺手升一升的心态把一个本来只是环境缺失的问题变成了两周的兼容性改造。注意如果这台机器是生产服务器装 JDK8 之前一定要确认应用当前的 JDK 版本和启动参数别想当然认为肯定是 8。用java -version和jps -lvm确认清楚再动手。2. 下载前的三个决定发行版、位数、安装包类型很多人一上来就搜jdk8下载点进第一个结果下载、装完然后发现装的是 JRE或者装完是 32 位版本内存上限被卡在 1.5G 左右跑什么都慢。这三个决定必须在下载之前想清楚否则后面全是返工。2.1 选哪个发行版别只盯着一个来源JDK8 的发行版有好几个来源各有各的适用场景。我整理成表格你按自己的情况对号入座。发行版典型包名适合场景需要注意的点Oracle JDK 8jdk-8uXXX-windows-x64.exe传统企业项目、老框架后期更新版本在授权条款上有变化商用前要确认合规Eclipse Temurin 8OpenJDK8U-jdk_x64_windows_hotspot_8uXXX.zip通用开发、开源项目只提供压缩包需要手动配环境变量Amazon Corretto 8amazon-corretto-8-x64-windows-jdk.msi长期免费支持、服务器安装器行为与 Oracle 略有差异Azul Zulu 8zulu8.XX.X-ca-jdk8.0.XXX-win_x64.msi需要长期稳定更新的场景版本号命名规则不同国内厂商发行版各家自有命名国内网络环境、企业采购需确认与目标项目的兼容性选哪个我的经验是**开发机优先选带 exe/msi 安装器的版本省心服务器和需要频繁切换版本的机器优先选 zip 压缩包版本可控。**压缩包版本不写注册表、不碰系统目录解压即用删掉就是卸载干净这对需要多版本共存的机器来说是最优解。至于从哪下载原则很简单认准发行方的官方站点或者其官方代码托管仓库的发布页。第三方下载站的安装包我强烈不建议用一是版本可能是被改过的二是很多下载站会捆绑东西三是你无法验证文件完整性。这一点在给客户装环境时尤其重要出问题你没法解释。2.2 32 位还是 64 位这个问题比你想象的严重2024 年了还有人装 32 位 JDK通常是因为看了一篇年代久远的教程。判断方法很简单在 Windows 上打开设置 - 系统 - 关于看系统类型这一行写的是基于 x64 的处理器就装 64 位写的是基于 x86或者32 位操作系统才装 32 位。现在还在跑 32 位 Windows 的机器基本都是十几年前的老设备或者某些工控机。为什么强调这个因为 32 位 JVM 的堆内存上限受地址空间限制实际上你能给的最大堆通常在 1.5G 到 2G 之间再大就启动不了。而 64 位 JVM 只要物理内存够几十 G 的堆都能给。如果你在一个 16G 内存的机器上误装了 32 位 JDK然后按教程配了-Xmx4g结果就是 JVM 直接起不来报Could not reserve enough space for object heap新手很容易以为是内存不够其实是位数错了。确认当前已装 JDK 位数的方法命令行执行java -version如果输出里有64-Bit Server VM就是 64 位只写Client VM没有 64-Bit 字样那多半是 32 位。这是最快的判断方式。2.3 校验文件完整性一个被忽略的好习惯从官网下载的文件如果网络不稳定有可能下载不完整装到一半报错或者装完了运行异常。养成校验的习惯能省很多时间。发行方一般会提供 SHA256 校验值Windows 上用 PowerShell 一条命令就能算出本地文件的哈希Get-FileHash -Algorithm SHA256 C:\Users\你的用户名\Downloads\jdk-8uXXX-windows-x64.exe把输出的哈希值和官网公布的值比对一致就放心装。不一致就重新下载。这一步大概花 10 秒但能挡掉一类莫名其妙的安装失败。提示如果官网只给了 MD5用Get-FileHash -Algorithm MD5也行。哈希值不区分大小写比对时不用纠结字母大小写。3. 安装实操从双击安装包到环境变量配好进入正题。下面按安装器版本这一条主线讲因为它涉及步骤最多坑也最集中讲完再补压缩包版本的做法。3.1 图形化安装每一步都在做什么双击安装包第一个界面是欢迎页直接下一步。第二个界面是安装路径默认是C:\Program Files\Java\jdk1.8.0_XXX后面还有一步问你 JRE 装哪里默认是C:\Program Files\Java\jre1.8.0_XXX。路径要不要改我的建议分两种情况。如果你这辈子只打算在这台机器上装这一个 JDK默认路径完全没问题别折腾。如果你确定以后会有多个 JDK 版本共存那从一开始就把安装目录规划好比如统一放在C:\Java\下面每个版本一个子目录C:\Java\jdk1.8.0_202 C:\Java\jdk-17.0.9 C:\Java\jdk-21.0.1这样做的好处是所有 JDK 在同一层级切换版本时只需要改一个环境变量值不用去翻Program Files里那一堆名字相似的目录。而且路径里没有空格写脚本的时候不用处理引号转义少一类奇怪的问题。安装过程中的两个小坑第一安装器会顺便装一个 JRE并且往系统 Path 里塞一个C:\ProgramData\Oracle\Java\javapath的条目。这个目录里放的是java.exe、javaw.exe、javac.exe的转发程序它总是指向最后安装的那个 JRE。这就是很多人装完 JDK8 又装了 JDK17 之后java -version显示的不是自己想要的那个版本的根源。记住这个条目后面排查要用。第二安装路径里绝对不要出现中文和空格之外的怪字符尤其不要放在桌面或者中文命名的文件夹下。JVM 在解析类路径时对非 ASCII 字符的处理在 JDK8 上并不完美有些场景会出问题没必要给自己找麻烦。安装完成后安装器会提示成功。但此时打开命令行执行java -version可能会成功javac -version却提示找不到命令因为安装器配了 Path 但没配 JAVA_HOME而且不同版本安装器的行为不一致。所以下一步的环境变量配置必须自己动手。3.2 JAVA_HOME、Path、CLASSPATH三个变量的分工这三个变量的关系用一个比喻就明白了。JAVA_HOME 是JDK 住在哪Path 是系统去哪儿找可执行文件CLASSPATH 是java 命令去哪儿找要加载的类。很多人配错是因为把 JAVA_HOME 和 Path 的职责搞混了。先说 JAVA_HOME。它的值是 JDK 的安装根目录不带\bin变量名JAVA_HOME 变量值C:\Java\jdk1.8.0_202为什么要设这个变量因为大量第三方工具依赖它Maven、Gradle、Tomcat 的启动脚本、各种 IDE 的项目配置都会去读 JAVA_HOME 来决定用哪个 JDK。你如果不设这些工具要么报错要么用系统里第一个找到的 java结果不可控。再说 Path。Path 里要加的是 JDK 的 bin 目录。这里有一个关键选择**写绝对路径C:\Java\jdk1.8.0_202\bin还是写%JAVA_HOME%\bin**我强烈建议后者。原因是切换 JDK 版本时你只需要改 JAVA_HOME 一个变量的值Path 不用动。如果你写的绝对路径以后每换一次版本就得改一次 Path改漏了就会出现JAVA_HOME 是 17java -version 显示 8这种诡异现象。Path 中新增%JAVA_HOME%\bin操作路径右键此电脑→ 属性 → 高级系统设置 → 环境变量。注意要区分用户变量和系统变量。对于个人开发机配在用户变量里就够了改动即时生效且不需要管理员权限如果是多人共用的服务器配在系统变量里这样所有账户都能用。切换版本的灵活性上用户变量更占优势因为你可以给不同用户配不同版本。最后说 CLASSPATH。**我的建议是不要设或者只设一个点号.。**网上大量老教程让你设.;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar这在 JDK8 上完全没必要因为这两个 jar 里放的是老式的 Java 类库现代 JDK 的类加载机制已经不需要显式指定。而如果你设错了 CLASSPATH比如丢了开头的点号会导致java HelloWorld找不到当前目录的类报Could not find or load main class新手排查这个错误能耗掉一下午。不设 CLASSPATH 时JVM 默认就是当前目录最省事。注意如果机器上已有 CLASSPATH 变量且里面还有别的内容不要在原有内容上乱加先备份一份值再改。删掉别人配的东西可能导致其他软件出问题。3.3 验证四条命令确认装对了环境变量改完必须重新打开一个新的命令行窗口因为已经打开的窗口继承的是旧的环境变量改了也不会生效。这是新手最常犯的错误改完发现没用以为是配置错了其实是窗口没重开。新开一个 cmd 或 PowerShell依次执行java -version javac -version echo %JAVA_HOME% where java逐条解释结果应该是什么样。java -version正常输出类似java version 1.8.0_202 Java(TM) SE Runtime Environment (build 1.8.0_202-b08) Java HotSpot(TM) 64-Bit Server VM (build 25.202-b08, mixed mode)注意这里显示的版本号是1.8.0_XXX而不是8.0.XXX这是 JDK 的历史遗留命名两者是同一个东西不要以为自己装错了。第二行如果出现64-Bit说明位数正确。javac -version应该输出javac 1.8.0_202。如果这条报不是内部或外部命令说明 Path 没配好或者配的是 JRE 的路径而不是 JDK 的路径。JDK 的 bin 目录里一定有javac.exe去目录里看一眼就能确认。echo %JAVA_HOME%应该原样打印你设的路径。如果打印出%JAVA_HOME%本身说明变量没设成功检查是不是把变量设到了另一个作用域用户变量和系统变量设混了。where java会列出系统里所有能找到的 java.exe按 Path 顺序排列。**这条命令是排查版本冲突的利器。**正常情况下应该优先列出你配的C:\Java\jdk1.8.0_202\bin\java.exe。如果第一行是C:\ProgramData\Oracle\Java\javapath\java.exe或者C:\Windows\System32\java.exe那就是被抢了需要把 Path 里%JAVA_HOME%\bin的条目上移到这些条目之前。3.4 压缩包版本的做法解压即用如果你下载的是 zip 包很多发行版只提供这种流程更简单但要更细心。解压到一个没有空格和中文的目录比如C:\Java\jdk8u202注意解压后的目录结构很多压缩包解压出来会多一层目录比如jdk8u202-b08\jdk8u202-b08\bin这种情况下 JAVA_HOME 要指向真正含 bin 的那一层。然后配环境变量的步骤和上面完全一样。区别在于压缩包版本不在系统里注册任何东西也不会有 javapath 这类干扰项所以where java通常非常干净只有你自己配的那一个。对需要精细控制版本的场景来说这是优点。卸载也很简单把环境变量里的相关条目删掉然后把目录删掉就完事了不留垃圾。相比之下安装器版本卸载后可能残留注册表和 javapath 目录还得手动清理。提示解压类 JDK 建议在目录名里保留完整的版本号比如jdk8u202、jdk8u392这样以后装了多个 8 的小版本时一眼能分清哪个是哪个不用去翻 release 文件。4. 多版本共存让 JDK8 和 JDK17 不打架这部分是很多人真正需要的。一台机器上同时有 JDK8 和 JDK17怎么做到想用哪个用哪个而不是改一次环境变量重启一次。4.1 不要直接改 Path改用切换策略最笨的办法是用 JDK8 时把 Path 改成 8 的 bin用 JDK17 时改成 17 的 bin每次改完重启命令行。能用但费劲而且容易忘。更好的做法是分层第一层把每个 JDK 的版本变量单独定义好互不干扰JAVA8_HOME C:\Java\jdk1.8.0_202 JAVA17_HOME C:\Java\jdk-17.0.9 JAVA21_HOME C:\Java\jdk-21.0.1第二层定义一个总的 JAVA_HOME它的值引用上面某一个JAVA_HOME %JAVA8_HOME%第三层Path 里只写%JAVA_HOME%\bin。这样切换版本时你只需要把 JAVA_HOME 的值从%JAVA8_HOME%改成%JAVA17_HOME%全局就是一致的。改完之后新开窗口验证即可。这种做法的好处是所有依赖 JAVA_HOME 的工具Maven、Gradle、IDE、Tomcat 脚本都会自动跟着切不会出现命令行是 8IDE 里是 17这种分裂状态。我见过太多项目因为 IDE 和命令行用了不同 JDK编译出来的 class 版本对不上报Unsupported major.minor version 52.0或者61.0这类错误只要版本统一就不会出现。4.2 用脚本做单次会话级切换上面改的是系统级变量影响所有新开的窗口。如果你只是临时想用另一个版本跑一下不想改全局配置可以在脚本里做会话级覆盖。写一个 bat 文件双击就直接进入使用 JDK8 的命令行echo off set JAVA_HOMEC:\Java\jdk1.8.0_202 set PATH%JAVA_HOME%\bin;%PATH% echo JAVA_HOME set to %JAVA_HOME% java -version cmd /k这段脚本的逻辑很直白把 JAVA_HOME 临时设置成 JDK8 的路径然后把它的 bin 目录拼到当前 Path 的最前面这样本次会话里java命令优先找到的就是 JDK8。最后一句cmd /k保持窗口不关闭方便你继续在里面敲命令。把这段保存成use-jdk8.bat放在桌面或者放一个专门的工具目录里同理再做一份use-jdk17.bat。需要哪个版本就双击哪个互不影响也不污染系统环境。这个技巧我在处理跨版本兼容性验证时用得特别多比如要确认这个 API 在 JDK8 上能不能编译通过直接开一个 JDK8 会话编译一遍再开一个 JDK17 会话编译一遍两分钟就能得出结论。PowerShell 用户可以用这段来做永久设置需要管理员权限[Environment]::SetEnvironmentVariable(JAVA_HOME, C:\Java\jdk1.8.0_202, Machine)第三个参数 Machine 表示系统变量换成 User 就是用户变量。设置完同样要新开窗口才生效。4.3 验证多版本切换是否成功切换之后不要只看java -version就完事把这三条都跑一遍命令期望结果说明echo %JAVA_HOME%指向当前目标版本目录确认变量本身生效where java第一行是目标版本的 bin 下的 java.exe确认没有被其他路径抢占javac -version与 java 版本一致确认编译器也是目标版本不是残留的旧版特别强调第三行。我遇到过一种情况java 命令已经是 JDK17 了但 javac 还是 JDK8 的原因是某次操作在 Path 里额外加了一个绝对的 bin 路径导致两个版本混在一起。这种状态下编译出来的 class 是 52.0用 JDK17 的 java 运行会直接报版本不支持的错。所以每次切换后三条一起验养成习惯。还有一个隐蔽的干扰源C:\Windows\System32\java.exe。某些软件会在安装时往这里放一个 java.exe。系统目录在 Path 里的优先级通常很高所以偶尔会出现明明配了 JAVA_HOMEwhere java第一行却是 System32 的情况。解决办法是把%JAVA_HOME%\bin移到 Path 列表的最上方或者干脆把系统目录里那个 java.exe 重命名备份前提是确认没有别的软件依赖它。5. 常见问题与排查技巧实录下面这些是我在实际操作中反复遇到过的按症状—原因—处理的结构整理你可以当速查表用。5.1 命令行提示不是内部或外部命令这是最高频的问题。先按顺序排除四个可能。第一命令行窗口没有重新打开用的是改环境变量之前的老窗口。第二Path 里写的是绝对路径但路径本身写错了比如把jdk1.8.0_202写成了jdk1.8.0_20。第三配置的是用户变量但当前命令行是以另一个用户身份运行的比如管理员权限的窗口对应的是管理员账户的环境变量。第四装的其实是 JREbin 目录里根本没有 javac.exe。排查顺序建议先去文件资源管理器里打开你配的路径确认java.exe和javac.exe都在。在的话再看环境变量里 Path 的条目是否完整。都不行就重开窗口再试。这三步能解决 95% 的此类问题。5.2 java 版本和预期的对不上where java输出多行第一行不是你配的那个就是被抢了。常见的抢占者有C:\ProgramData\Oracle\Java\javapath\Oracle 安装器写的、C:\Windows\System32\、其他软件自带的 JRE 目录。处理方法是打开环境变量里 Path 的编辑界面从上往下看找到%JAVA_HOME%\bin这一条把它上移到所有其他 java 相关条目的前面。Windows 的 Path 是按顺序查找的谁在前面用谁。如果 Path 太长看不到全貌可以点编辑文本按钮切换到文本模式看清楚顺序再调整。注意Path 编辑界面的编辑文本模式下每一行是一个路径不要给路径加引号也不要留空行。加引号会导致整个路径失效这是个非常隐蔽的坑。5.3 中文乱码怎么处理JDK8 在 Windows 上默认编码跟随系统区域中文系统就是 GBK。如果你的程序读写的文件是 UTF-8 编码就会乱码。临时解决办法是在命令行先执行chcp 65001把代码页切成 UTF-8再运行程序。但这个只对当前窗口有效而且某些老程序在 65001 代码页下会输出异常。更稳妥的做法是启动时显式指定编码java -Dfile.encodingUTF-8 -jar your-app.jar如果希望永久生效可以设一个环境变量JAVA_TOOL_OPTIONS值为-Dfile.encodingUTF-8。这个变量的好处是 JVM 启动时会自动读取不用每次改命令。缺点是它会在启动时打印一行Picked up JAVA_TOOL_OPTIONS提示看着有点烦但不影响使用。还有一个相关参数是-Dsun.jnu.encodingUTF-8它控制的是文件名的编码。这两个参数一起用时能覆盖绝大多数中文乱码场景。不过要注意JDK8 上改编码不如 JDK9 之后干净某些场景依然会跟随系统所以最根本的办法还是统一下项目里的文件编码和运行环境编码。5.4 安装包双击没反应或中途失败这种现象在 Windows 11 上比以前多。可能的原因有几个。一是安装包被安全软件拦截了去安全软件的拦截记录里找找看或者临时关闭实时防护再装。二是临时目录权限问题安装器需要往%TEMP%写文件如果那个目录权限异常就会卡住可以用管理员身份运行安装包试试。三是下载的文件不完整回到第 2.3 节的哈希校验步骤验证一下。四是系统里的某个残留服务占用了文件重启后重装通常能解决。另外还有一种情况安装到一半报错误 1723或类似的 MSI 错误多半是 Windows Installer 服务状态异常。这种时候重启电脑再装或者用msiexec /unregister和msiexec /regserver重新注册一下服务成功率很高。5.5 装完了但程序起不来几个方向如果java -version一切正常但你的 jar 或者 Tomcat 起不来问题通常不在 JDK 安装本身而在下面几个方向。检查启动脚本里有没有硬编码的 JAVA_HOME 路径指向一个不存在的目录这在迁移或者拷贝项目时极其常见。检查有没有-Xmx之类的内存参数超过了物理内存减去系统占用后的可用值。检查端口是否被占用Web 应用常见的 8080、8005 冲突会直接导致启动失败。还有一个容易被忽略的点JDK8 的 Metaspace 默认没有上限如果某个应用疯狂生成动态类比如大量使用反射、字节码增强的框架会出现元空间持续增长直到耗尽机器内存的情况。这类问题的表现是程序运行一段时间后响应变慢、机器内存吃紧日志里不一定有明显报错。处理方式是加参数限制-XX:MaxMetaspaceSize256m然后观察是否稳定。提示排查 JVM 层面的问题jps -lvm能列出当前机器上所有 Java 进程及其启动参数jstack pid能打印线程栈jmap -heap pid能看堆内存分布。这三个命令都在 JDK 的 bin 目录里前提是你装的是 JDK 而不是 JRE。6. 装完之后值得马上做的几件事环境装好只是起点下面这几件事做了能让你后面少走很多弯路。第一件写一个最小的 Hello World 跑通全流程。不要觉得多余这能一次性验证 javac 和 java 两个命令、编码、类路径三个环节。新建一个HelloJDK8.java内容如下public class HelloJDK8 { public static void main(String[] args) { System.out.println(JDK version: System.getProperty(java.version)); System.out.println(Java home: System.getProperty(java.home)); } }在文件所在目录执行javac HelloJDK8.java java HelloJDK8java.home输出的路径会告诉你当前实际用的是哪个 JDK 的运行环境。这个信息在多版本环境下特别有用比java -version更准确因为它打印的是 JVM 自己认定的主目录。第二件把常用的构建工具一并配好。如果项目用 Maven注意 Maven 自己也会读 JAVA_HOME所以只要 JDK 切对了Maven 通常不用额外配置。但如果你需要针对某个项目固定 JDK 版本可以在maven-compiler-plugin里显式声明 source 和 target 都为 1.8这样即使有人用 JDK17 跑构建编译出来的也是 8 的目标版本。当然这只解决编译层面运行时还是得用 8。第三件给环境留一份记录。在C:\Java\下面放一个README.txt写清楚每个目录对应哪个版本、什么时候装的、用在哪个项目上。这个习惯听起来有点多余但当你半年后接手一个没人维护的机器看到这份记录会非常庆幸。我自己维护的几台构建机上都放了这个文件同事接手时能省掉大量摸索时间。第四件考虑把 JAVA_HOME 和 Path 的配置导出备份。用setx命令可以或者直接截图存一份。Windows 的环境变量界面看起来能看全但实际上长 Path 会被折叠出问题时不容易发现。导出一份文本备份出问题能快速对照。最后再说个实际体会。JDK8 在 Windows 上的安装本身并不复杂复杂的是它经常出现在一个已经有其他 JDK 的机器上而大部分教程默认你是从零开始的。所以我在任何一台新机器上装 JDK 之前都会先花两分钟执行where java、java -version、echo %JAVA_HOME%三条命令摸清现状再动手。这个两分钟的投入比事后排查版本冲突省下的时间多得多。另外如果你是要给一台长期运行的服务器装环境尽量选压缩包版本放在统一的目录下别用安装器因为安装器版本在多用户、多版本场景下带来的隐性耦合太多卸载时还可能留下 javapath 那种干扰项后续维护的人会骂人。这些都是踩过坑之后才明白的写下来给后面的人省点事。