前两天帮一个刚转行的朋友收拾他那台笔记本系统是 win10要跑一个几年前的老项目第一步就卡在 jdk8 安装与环境变量配置上。他跟我说照着网上的教程点了七八遍cmd 里敲java -version还是那句不是内部或外部命令。我远程看了一眼他的环境变量JAVA_HOME 写成了C:\Program Files\Java\jdk1.8.0_202\binPath 里又拼了一次%JAVA_HOME%\bin等于最后变成了...\bin\bin。这种错我第一次见的时候也折腾了半小时才反应过来。所以这篇就把 win10 下 jdk8 的下载、安装、环境变量配置整条链路拆开讲。不只是告诉你点哪里还要讲清楚每一步在干什么、为什么非得这么写、配完之后用什么命令验证、配错了从哪几个方向去查。适合刚学 Java 的新人、需要给老项目搭环境的运维、以及经常帮别人重装系统的朋友。整套流程走下来大概十五分钟但把原理弄明白以后遇到 jdk 版本切换、多版本共存、Maven 找不到 JDK 这些事你都能自己判断。1. 装之前先想清楚win10 上为什么还在用 jdk8很多人第一次装 jdk 的时候会疑惑现在 JDK 都出到 20 多个版本了为什么教程和公司项目还在用 8。这个问题不搞清楚你后面遇到到底装哪个版本的时候就会反复横跳。1.1 为什么企业项目依然锁死 JDK8JDK8 是 2014 年发布的到现在十几年了按说早该淘汰。但现实是大量生产环境的项目还跑在 8 上面原因很实际语法和 API 已经够用。JDK8 引入了 Lambda 表达式、Stream 流、Optional、方法引用、接口默认方法还有全新的 java.time 日期时间 API。这几样东西基本覆盖了日常业务开发的绝大部分需求。很多人面试被问jdk8 新特性说的就是这些。后面的 11、17、21 更多是在性能、GC、模块化、虚拟线程上做文章对写业务代码的人来说体感没那么强。依赖生态的历史包袱。老项目依赖的框架版本、中间件客户端、公司内部的私有 SDK很多是编译在 Java 8 字节码上的你贸然换高版本可能编译不过也可能编译过了运行时抛UnsupportedClassVersionError。升级成本远大于收益。一个新版本的语言特性带来的开发效率提升抵不过一次全量回归测试、一套 CI 流水线改造、一轮生产环境灰度的成本。所以很多团队的做法是新项目用 17 或 21老项目继续锁 8。理解这一点很重要因为它决定了你本机经常需要多个 JDK 共存而不是装一个就完事。这就直接影响后面环境变量怎么设计。1.2 Oracle JDK 与 OpenJDK 发行版怎么选含商用授权那道坎Windows 上能拿到的 JDK8主要分几类来源特点适用场景Oracle JDK 8u202 及更早最后一批可免费商用的版本需要 Oracle 官方构建、又不想碰授权问题的场景Oracle JDK 8u211 及以后采用新的许可协议商用需付费个人学习、开发测试可以生产要慎重Eclipse Temurin 8社区维护的 OpenJDK 构建长期更新目前最主流的选择个人和公司都合适Amazon Corretto 8亚马逊维护带有长期支持承诺部署在云上的项目常用Azul Zulu 8老牌 OpenJDK 发行版平台覆盖全需要多平台一致性时用各类 zip 免安装包解压即用不写注册表多版本共存、便携环境、CI 机器这里的关键分界线是 8u202。Oracle 从 8u211 开始改了许可条款免费使用范围收窄到开发和测试。很多公司内部规范会直接写明生产环境禁止使用 Oracle JDK 8u211 以上这不是技术问题是合规问题你如果在企业里做环境规划这条得先跟团队对齐。提示如果你只是自己学习、写练手项目用哪个都行。但如果是给公司机器配环境优先选择 Temurin 或 Corretto 这类 OpenJDK 发行版省掉后面被合规部门追着问的麻烦。另外要强调一点JDK 和 JRE 不是一回事。JRE 只有运行环境包含java命令但没有javac。你如果装成了 JRE写代码的时候编译器都找不到。所以下载的时候看清楚要的是 JDK。1.3 装之前的三项检查位数、磁盘路径、旧版本残留动手之前花两分钟做三件事能省掉后面一大堆莫名其妙的报错。第一确认系统位数和架构。win10 绝大多数是 64 位但也不排除有些老机器是 32 位或者你用的是 ARM 架构的笔记本比如某些骁龙处理器的轻薄本。查看方式很简单WinR 输入sysdm.cpl回车在系统标签页能看到系统类型。64 位系统就下 x64 的包ARM 设备要下 aarch64 的包。装错位数的表现是安装程序直接提示不兼容或者装上了但跑起来各种诡异问题。第二规划安装路径。默认路径是C:\Program Files\Java\jdk1.8.0_XXX里面有空格。绝大多数情况下没问题命令行的引号处理已经足够健壮。但如果你后面要接一些老掉牙的构建脚本、自己写的 C 程序通过路径拼接去调 JVM空格就可能成为隐患。我的习惯是统一装到D:\dev\jdk\下面路径短、没空格、没中文。第三清理旧版本残留。这一步最容易被忽略。如果你之前装过 JDK 或者装过某个自带 Java 的软件系统里可能已经存在别的 java.exe而且它可能被写进了 PATH 的最前面。最典型的两个位置C:\Windows\System32\下面如果有java.exe那几乎必然抢在你自己配的路径前面。C:\ProgramData\Oracle\Java\javapath\这个目录是 Oracle JDK 安装程序自动创建的里面放的是java.exe、javac.exe、javaw.exe的快捷方式实际是符号链接安装程序会把它加到系统 PATH 的最前面。先打开 cmd 敲一句where java看看现在能搜到几个 java分别在哪个目录。把结果记下来后面排查的时候对照着看一目了然。2. jdk8 的下载与安装向导里每个选项都在做什么准备工作做完了接下来是下载和安装。这一章我分成三种方式来写图形化 exe 安装、向导里的选项取舍、以及 zip 免安装方式。你在不同场景下会用不同的方式。2.1 exe 安装包下载时的版本细节下载的时候要盯住三件事架构、包类型、版本号。文件名一般长这样jdk-8u202-windows-x64.exe。拆开看8u202是版本号u 代表 update。8u202 就是 JDK8 的第 202 次更新。windows是平台。x64是架构对应 64 位。32 位是i586或者不带后缀。.exe是安装程序对应的还有.zip免安装包。如果你要的是 Oracle 的包官方网站上现在只放最新的几个版本老版本要去 Java Archive 归档页面找。Temurin 和 Corretto 则是直接列出所有可用版本找 8 那一条拉下来就行页面上会写好是 JDK 还是 JRE别点错。注意网上有些第三方站点提供的绿色版精简版JDK号称体积小安装快实际可能被改过东西。JDK 是编译和运行的核心工具链一旦被篡改编译产物和运行时行为都可能出问题。老老实实从官方渠道拿。下载速度慢是很常见的事几百兆的包有时候要等十几分钟。这个阶段可以去准备别的事别急着下完就装。2.2 安装向导逐项说明与公共 JRE的取舍双击 exe 之后向导大概有这么几步。每一步的默认值我都不建议无脑下一步说一下理由。第一步是安装路径。点更改改成你规划好的目录比如D:\dev\jdk\jdk1.8.0_202。注意这里改的是整个 JDK 的根目录不是 bin 目录。很多人这里手滑点到 bin 里去了后面配 JAVA_HOME 的时候就会带着 bin 一起配直接埋雷。第二步是组件选择。这一步是重点JDK8 的安装程序会问你要装哪些组件开发工具Development Tools包含 JDK 本体里面有javac、jar、javadoc、jdb等等还有一份内嵌的 JRE。公共 JREPublic JRE单独装一份到C:\Program Files\Java\jre1.8.0_XXX并且会写注册表、创建 javapath 目录、加到系统 PATH。源代码Source CodeJDK 的源码包压缩文件一般不用装想看源码的话现在 IDE 都能自动反编译。Java DB一个内嵌数据库几乎没人用取消。我的建议是只勾开发工具公共 JRE 取消勾选。理由有两个一是内嵌 JRE 已经够用JDK 目录下的jre文件夹就是二是公共 JRE 会偷偷修改系统 PATH创建 javapath 目录还会往注册表里写东西等你以后装第二个 Java 版本的时候两个版本互相打架排查起来非常烦人。只有一种情况需要装公共 JRE你有非 Java 的程序比如某些桌面工具、某些老版本的 Office 插件依赖系统级的 JRE 运行。这种场景现在很少见了。第三步就是等待进度条走完。装完会提示成功点关闭即可。这时候可以去安装目录看一眼确认结构长这样D:\dev\jdk\jdk1.8.0_202\ ├── bin\ │ ├── java.exe │ ├── javac.exe │ ├── jar.exe │ ├── javadoc.exe │ └── ... ├── jre\ │ ├── bin\ │ └── lib\ ├── lib\ │ ├── tools.jar │ └── dt.jar ├── include\ └── src.zip如果bin目录下没有javac.exe说明你装的是 JRE 不是 JDK回去重新下载。这是新手最容易犯的错没有之一。2.3 用 zip 包手动部署把 JDK 当成绿色软件用如果你本机要同时维护 JDK8、JDK11、JDK17 三个版本或者你的机器上不允许随便装软件有些公司的开发机是这么管的那 zip 免安装包就是更好的选择。做法非常简单把jdk-8uXXX-windows-x64.zip解压到D:\dev\jdk\下面目录名改成好记的比如jdk8。后面所有环境变量里写的路径就统一指向D:\dev\jdk\jdk8。想装第二个版本再解压一个到D:\dev\jdk\jdk17互不干扰。这种方式的最大好处是可逆。不想要了整个目录删掉环境变量改一下干干净净不留注册表垃圾、不留 javapath、不留公共 JRE。我在自己的机器上一直用这种方式装过多少次系统都是这么搞的从没出过残留问题。代价是没有自动更新、没有开始菜单快捷方式但对开发机来说这两个本来也不重要。3. 环境变量配置JAVA_HOME、Path、CLASSPATH 各自干什么到了核心环节。网上教程一搜一大把但大部分只告诉你新建一个叫 JAVA_HOME 的变量值写你的 JDK 路径不解释为什么。不理解原理一旦出问题就只能瞎试。3.1 三个变量的职责拆解我用寄快递来类比一下。假设你要给朋友寄东西快递系统需要知道三件事东西从哪发、地址怎么写、按什么路线送。变量名类比实际作用是否必配JAVA_HOME发货仓库地址告诉其他程序Maven、Gradle、Tomcat、IDE你的 JDK 装在哪强烈建议配Path快递线路告诉系统去哪些目录里找可执行文件必须配CLASSPATH附带的说明书告诉 JVM 去哪找 class 文件和 jar 包现代开发基本不用配JAVA_HOME本身不参与命令查找它是个给别的程序看的约定。你敲java命令能不能跑起来跟 JAVA_HOME 没有直接关系靠的是 Path。但 Maven 的mvn.cmd脚本第一件事就是读 JAVA_HOME找不到就报错退出。IDEA 创建 Maven 项目时也会读它。所以这个变量是给整个工具链用的必须配。Path才是真正让java命令全局可用的那个。它的作用机制是你在 cmd 里敲一个命令系统会按 Path 里列出的目录顺序一个一个去找同名的 exe。找到第一个就用它后面的不管。CLASSPATH是 JVM 找类的搜索路径。JDK 8 及以前确实有不少教程要求配成.;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar。但现在dt.jar和tools.jar这两个文件在运行时根本用不到tools.jar 是给编译器用的而且现代构建工具都是显式传 classpath。不配 CLASSPATH 时JVM 默认就是当前目录行为符合直觉。配错了反而麻烦比如忘了写开头的.导致你自己写的类都找不到。结论除非你明确知道自己在干什么否则 CLASSPATH 一个都不要配。这是很多老教程留下的历史包袱。3.2 新建 JAVA_HOME 的完整点击路径Windows 上打开环境变量设置有好几个入口我推荐最快的那个WinR 打开运行框输入sysdm.cpl回车。切到高级标签页点右下角的环境变量按钮。弹出的窗口分上下两半上半部分是用户变量下半部分是系统变量。用户变量和系统变量的区别这里必须说清楚用户变量只对当前登录的账号生效系统变量对所有账号生效。一般个人机器上用哪边都行但如果你要给多个账号共用或者有的服务是以系统账号跑的就必须配到系统变量里。我个人的习惯是统一配到系统变量跟大多数教程一致避免出现我这个账号能用换个账号就不行的诡异现象。接下来在下半部分系统变量里点新建。变量名填JAVA_HOME注意全大写中间是下划线。别写成JAVA-HOME或者JavaHome虽然 Windows 环境变量不区分大小写但很多构建脚本是按JAVA_HOME这个大写的字符串去读的写错了照样读不到。变量值填 JDK 的根目录D:\dev\jdk\jdk1.8.0_202。不要带 bin不要在末尾加反斜杠。末尾加反斜杠的话某些脚本拼接时会出现\\bin这种双斜杠大部分情况能容错但个别老工具不行。判断值写得对不对有个土办法把这段路径复制到资源管理器的地址栏回车。如果能直接打开并看到 bin、jre、lib 这几个文件夹就对了。3.3 编辑 Path 的两种方式与各自的坑Path 的编辑是整件事里最容易出错的地方。win10 的 Path 编辑界面跟 win7 完全不同这里单独讲。正确做法在系统变量列表里找到Path选中点编辑。弹出的窗口是一个列表每行一个路径。这是 win10 才有的界面比 win7 那种一大坨文本友好太多。点右侧新建输入%JAVA_HOME%\bin注意是百分号包住变量名中间没有空格。一路点确定保存。用%JAVA_HOME%\bin而不是写死完整路径好处是以后换 JDK 版本只要改 JAVA_HOME 一个地方就行Path 不用动。这是很多人重复劳动的原因。位置很重要。列表里可以用上移按钮调整顺序。建议把%JAVA_HOME%\bin移到靠前的位置最好是第一行。原因在 1.3 里提过如果系统里已经有别的 java.exe比如 System32 或者 javapath 目录里的而它们在 Path 里排在你前面那么你敲java用的就是旧的那个java -version出来的版本号跟你装的完全对不上你会以为环境变量没生效。用编辑文本按钮时的坑界面右下角还有个编辑文本按钮点开就是传统的一行超长字符串用分号分隔。我不建议用它因为字符串很长的时候眼睛根本对不上位置容易误删。如果你的 Path 末尾原本没有分号你在后面直接粘贴会把新路径和前一个路径粘成一串系统当成一个不存在的目录。万一粘贴时把整段覆盖了系统自带的那些路径C:\Windows\system32、C:\Windows全没了后果很严重——很多基础命令都会失效。如果你非要用文本模式操作前先全选复制粘贴到记事本里备份一份出事了好还原。这个习惯我保持了十几年救过我不止一次。3.4 多版本共存与切换方案前面说过实际开发中经常要在 JDK8 和更高版本之间切换。有了 JAVA_HOME 之后切换就变得很简单有三种方式。方式一改 JAVA_HOME 的值。直接去环境变量界面把 JAVA_HOME 改成另一个 JDK 的路径。缺点是每次都要点好几层窗口而且要重开终端才生效。方式二写批处理脚本临时切换。在当前 cmd 窗口里执行set JAVA_HOMED:\dev\jdk\jdk17 set PATH%JAVA_HOME%\bin;%PATH% java -version这里用的是set临时只影响当前窗口不是setx永久写进注册表。临时切换的好处是不污染全局配置关掉窗口就恢复原样。配合一个jdk8.bat和jdk17.bat想用哪个双击哪个。方式三用工具管理。有一些版本管理工具可以一行命令切换 JDK比如 Windows 上的 Scoop、Chocolatey 都支持管理多个 Java 版本。团队规模大的话可以考虑个人用前面两种足够了。极其重要的警告永远不要用setx去修改 PATH。setx有个 1024 字符的截断限制如果你的 Path 很长装了开发环境之后基本都很长执行setx PATH %PATH%;xxx会把超出部分直接砍掉导致一堆系统命令失效严重的时候资源管理器都打不开。这个坑每年都有人踩修复起来要手写完整 Path非常痛苦。4. 验证与排查敲完命令不生效的九成原因都在这配完了不代表就能用。必须验证而且要用多条命令交叉验证。4.1 三重验证法java、javac、where 一套打穿关闭所有已经打开的 cmd 窗口这一步必须做环境变量只对新的进程生效这是新手最常忽略的一点重新打开一个依次执行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就说明java命令通了。注意这里如果显示的是别的版本号说明 Path 顺序有问题有别的 java 抢在前面。接着javac -version应该输出javac 1.8.0_202。如果提示不是内部或外部命令但java -version是好的那只有两种可能要么你装的是 JRE 没有 javac要么 bin 目录没进 Path。这是判断 JDK 和 JRE 的快速方法。再看echo %JAVA_HOME% where java where javacecho %JAVA_HOME%输出了正确路径说明变量本身没问题。where java会列出系统能找到的所有java.exe 及其路径按搜索顺序排列第一条就是实际生效的那个。如果第一条不是D:\dev\jdk\...\bin\java.exe那就找到问题根源了。这三条命令下来能覆盖 95% 的环境变量问题。我还习惯把它们打包成一个自检脚本echo off echo JAVA_HOME echo %JAVA_HOME% echo. echo java -version java -version 21 echo. echo javac -version javac -version 21 echo. echo where java where java echo. echo where javac where javac pause存成check-jdk.bat放在桌面上以后每换一次环境跑一遍三十秒就能确认状态。注意java -version是往标准错误流输出的所以脚本里加了21才能正常显示这一点很多人不知道直接重定向到文件会发现文件是空的。最后做个真实的编译测试确认不只是命令能跑编译链路也通public class Hello { public static void main(String[] args) { System.out.println(version System.getProperty(java.version)); System.out.println(java.home System.getProperty(java.home)); System.out.println(sun.arch.data.model System.getProperty(sun.arch.data.model)); } }javac Hello.java java Hello这个程序会打印出实际运行时用的 JDK 版本、安装目录和位数。java.home的输出特别有用它能告诉你 JVM 到底从哪个目录启动的。如果这里指向的是...\jre而不是...\jdk不用慌JDK8 的 JVM 本来就是在 jre 目录里跑的只要版本号对就没问题这个细节容易被误判。4.2 环境变量配置失败速查表下面这张表是我这些年攒下来的按出现频率排序。遇到问题从上往下对基本能定位到。现象可能原因排查方法解决方式java 不是内部或外部命令Path 没配或没保存echo %PATH%看有没有 bin 目录重新编辑 Path确保点了所有确定命令能跑但版本号不对Path 顺序问题旧版本抢位where java看第一条路径把%JAVA_HOME%\bin上移到 Path 最前javac 找不到但 java 能用装的是 JRE看安装目录有没有 bin\javac.exe重新安装 JDK只勾开发工具改了变量但没生效cmd 窗口是旧的无关掉所有 cmd重新打开JAVA_HOME 显示成%JAVA_HOME%变量没建立或写在了用户变量但读的是系统上下文检查用户变量和系统变量挪到系统变量或在同一个作用域里配Maven 报 JAVA_HOME 无效JAVA_HOME 指向了 bin 或 jreecho %JAVA_HOME%改成 JDK 根目录不带 bin编译报 UnsupportedClassVersionError编译和运行用的 JDK 版本不一致对比javac -version和java -version统一 Path 和 JAVA_HOME 指向系统命令大面积失效误用 setx 截断了 PATHecho %PATH%看是否只剩一小段手动补回系统默认路径装完两个版本互相干扰javapath 目录或公共 JRE 残留where java看是否有 javapath卸载公共 JRE清理 javapath 目录4.3 五个真实踩坑记录第一个坑javapath 目录悄悄抢位。这是我遇到最多的情况。你明明把 JAVA_HOME 改成了新版本Path 也改了但java -version死活不变。用where java一看第一条是C:\ProgramData\Oracle\Java\javapath\java.exe。这个目录是 Oracle 安装程序创建的并且它会把自己插到系统 PATH 的最前面。解决办法是去系统变量里找到 PATH把这项删掉或者手动把它移到后面。如果你用的是 zip 免安装方式根本不会有这个问题。第二个坑Path 里写了引号。有些人看到路径有空格习惯性地写成D:\Program Files\Java\jdk1.8.0_202\bin。Windows 的环境变量里不需要引号加了引号反而会被当成路径名的一部分导致目录根本不存在。这个问题很隐蔽因为echo %PATH%的输出里带引号看起来很正常。第三个坑装了 32 位的 JDK。表现是编译大项目时莫名报内存不足或者某些依赖原生库的组件加载失败。检查方法就是跑上面那个sun.arch.data.model输出应该是64。如果输出32说明装错了卸载重装。第四个坑目录名带中文或特殊符号。把 JDK 解压到D:\我的软件\java\这种目录下。大部分情况下能跑但一些老版本的构建工具在处理非 ASCII 路径时会出问题日志里的路径显示成乱码。稳妥起见JDK 路径里只用英文、数字和下划线。第五个坑系统变量和用户变量里都配了一份 Path。用户 Path 会被追加到系统 Path 后面如果你两边都写了 Java 相关的路径实际生效的可能是系统那一份导致你以为改了用户变量却不生效。排查的时候两个都要看。我的一般原则是同类变量只在一个地方配要么全系统要么全用户别混着来。5. 从能跑 java 到能跑项目把 jdk8 接进实际开发链路java -version能输出正确的版本号只是第一步。真正跑项目的时候会有一堆工具来读你的环境变量任何一个环节对不上都会报错。这一章讲怎么把这些环节串起来。5.1 用 Maven 验证 JAVA_HOME 是否真的对Maven 是 Java 项目里最常见的构建工具它的启动脚本mvn.cmd在 Windows 上做的第一件事就是检查 JAVA_HOME。所以用 Maven 来验证环境变量比单纯敲java -version更严格。配置好 Maven 的环境变量之后这一步是另一个话题简单说就是把解压目录配成MAVEN_HOME再把%MAVEN_HOME%\bin加到 Path执行mvn -v正常输出里会有一行Java version: 1.8.0_202, vendor: Oracle Corporation还会打印Java home: D:\dev\jdk\jdk1.8.0_202\jre。看到这两行对上了说明 JAVA_HOME 是真的配对了Maven 能正常读到你指定的 JDK。如果报这个错The JAVA_HOME environment variable is not defined correctly This environment variable is needed to run this program九成是下面三种情况之一JAVA_HOME 没配或者配在了用户变量里但 Maven 是以其他身份启动的。JAVA_HOME 的值末尾带了反斜杠或者带了引号。JAVA_HOME 指向了不存在的目录比如 JDK 被删了但变量还在。注意 Maven 输出的Java home是jre目录这是正常的不用去改 JAVA_HOME 指向 jre。原因在 4.1 里说过。顺带一提如果你的项目是 Gradle 构建的也可以用gradle -v做同样的验证它也会打印当前用的 JVM 版本和路径。5.2 IDE 里指定 JDK 与语言级别命令行环境配好了IDE 里还得单独配一遍。这两套是独立的IDE 通常会读系统的 JAVA_HOME 作为默认值但项目级别的配置是它自己存的。IntelliJ IDEA 里要关注三处File → Project Structure → Project这里设置Project SDK和Project language level。跑 JDK8 项目SDK 选 1.8language level 选 8。language level 决定编译器允许你用哪些语法特性设高了在低版本 JDK 上编译不过报错设低了则用不了 Lambda 表达式。File → Project Structure → SDKs这里可以添加多个 JDK起别名区分。多版本共存的时候特别有用。Settings → Build, Execution, Deployment → Build Tools → Maven → Runner这里有个JRE选项控制 Maven 用哪个 JDK 跑。如果你系统 JAVA_HOME 是 17 但项目要 8这里必须单独指定否则 Maven 编译会用错版本。Eclipse 里则是Window → Preferences → Java → Installed JREs添加你的 JDK 目录。项目右键 →Properties → Java Build Path → Libraries确认 JRE System Library 是 1.8。项目右键 →Properties → Java Compiler把Compiler compliance level设成 1.8。我在实际项目里见过最常见的问题是IDEA 里项目 SDK 设的是 1.8但 Maven Runner 用的还是系统的 17结果编译出来的 class 文件是 17 的字节码部署到 8 的服务器上直接抛UnsupportedClassVersionError。日志里的报错信息会写class file version 61.0对应 17和this version of the Java Runtime only recognizes class file versions up to 52.0对应 8看到这组数字就能立刻反应过来是版本错配。5.3 一份新机器初始化清单与批处理自检脚本把上面的东西整理成一份清单以后换机器、重装系统、给同事搭环境照着走一遍就行。初始化清单确认系统架构下载对应位数的 JDK8 包优先 OpenJDK 发行版。解压或安装到无空格无中文的路径比如D:\dev\jdk\jdk8。确认bin目录下有javac.exe排除装成 JRE 的可能。新建系统变量JAVA_HOME值为 JDK 根目录。编辑系统变量Path新建%JAVA_HOME%\bin并上移到靠前位置。不配 CLASSPATH。关掉所有终端重新打开跑自检脚本。用where java确认第一条是预期路径。写一个 Hello.java 编译运行确认编译链路通畅。配置 Maven 并用mvn -v交叉验证。在 IDE 里单独指定 SDK 和 language level。再补一个更完整的自检脚本比 4.1 里那个多了 Path 检测和常见问题提示echo off chcp 65001 nul echo JDK 环境自检 echo. echo [1] JAVA_HOME 变量 if %JAVA_HOME% ( echo [失败] JAVA_HOME 未设置 ) else ( echo %JAVA_HOME% if exist %JAVA_HOME%\bin\javac.exe ( echo [通过] 找到 javac.exe ) else ( echo [失败] 未找到 javac.exe可能装的是 JRE 或路径有误 ) ) echo. echo [2] java 命令版本 java -version 21 echo. echo [3] javac 命令版本 javac -version 21 echo. echo [4] java.exe 搜索顺序 where java echo. echo [5] PATH 中的 Java 相关项 echo %PATH% | findstr /i java jdk echo. echo 自检结束 pause把这个脚本存成 UTF-8 编码的文件开头加了chcp 65001切换代码页避免中文乱码放在桌面随时可用。提醒一句写批处理脚本的时候if语句块里的括号和变量展开顺序有讲究。上面这个脚本里用的是if ... ( ... ) else ( ... )的写法如果变量值里含有特殊字符可能会出问题。稳妥一点的做法是用setlocal enabledelayedexpansion配合!VAR!语法或者干脆拆成多个独立的if判断不用 else。这个细节在写自动化脚本的时候会经常遇到。最后分享一个我自己用了几年的小习惯每次环境配置完成后把echo %JAVA_HOME%、where java、java -version三条命令的输出复制到一个文本文件里用日期命名丢进一个专门的文件夹。下次环境出问题的时候翻出上一次的记录一对比哪个环节变了立刻就看出来了。比从头排查快得多尤其是在同时维护好几台机器的时候。