Windows环境变量配置攻略：JDK安装、JAVA_HOME与多版本切换

1. 开始之前：先想明白 JDK 装在哪儿、环境变量又是什么

1.1 JDK、JRE、环境变量这三者的关系

很多人一上来就搜“Java 环境变量配置”，但根本不知道配的是谁。先花两分钟把这个底层逻辑捋清楚，后面不管你怎么装、怎么改都不会慌。

JDK 是 Java Development Kit，也就是 Java 开发工具包，里面包括了编译器 javac、运行工具 java、打包工具 jar、文档生成工具 javadoc 这一整套。日常写 Java 代码、编译代码、跑代码，全靠它。JRE 是 Java Runtime Environment，只负责运行已经编译好的 class 文件，不包含编译器。JDK 9 之后，官方把 JRE 直接合并到了 JDK 模块里，所以现在你去下载，基本只见到 JDK 安装包，不会再单独找“JRE 下载”了。如果你在一个教程里看到“先装 JDK，再单独装 JRE”这种操作，基本可以判断那是七八年前的存量内容。

那么环境变量到底是什么？我习惯用一个比喻：Windows 本身不是算命的，它并不知道你的 java.exe 被塞进了哪个文件夹。当你在命令行敲 java -version 时，系统会从一个叫 PATH 的列表里，从上往下挨个目录翻，看哪个目录里面有 java.exe，找到就执行。这个 PATH 列表就是 Windows 维护的“快捷搜索清单”，里面记录了各种常用程序的安装位置。

但光有 PATH 还不够，很多开发工具需要知道你整个 JDK 的根目录在哪里，比如 IDAE 要定位编译器、Maven 要调用 javac、Tomcat 要找到 Java 运行时，这时候就需要 JAVA_HOME。你可以把 JAVA_HOME 理解成一张“指向卡”，它告诉整个世界：“我的 JDK 放在 C:\Program Files\Java\jdk-25”。后面所有工具要 Java，就先来读这张卡，卡指向哪里，工具就用哪里的 Java。

所以 Windows 下配置 Java 环境变量的核心，其实就是做好两件事：建一个 JAVA_HOME 指向 JDK 根目录，再把 %JAVA_HOME%\bin 加进 PATH。就这么简单。

1.2 2026 年的版本节奏：别再闭眼装 Java 8 了

目前网上能搜到的环境变量教程，大量还停留在 Java 8 时代。那些教程写 CLASSPATH，教你配一堆 dt.jar、tools.jar，那已经是历史文件了。到了 2026 年，如果你是从零开始学 Java，装 Java 8 更像是在给自己挖坑。

这里简单梳理一下版本节点。Java 8 是 2014 年的版本，Java 11 是 2018 年，Java 17 是 2021 年，Java 21 是 2023 年，Java 25 是 2025 年 9 月发布的最新 LTS 版本。所谓 LTS 就是长期支持版，Oracle 会提供长达数年的稳定性更新，企业生产环境一般只认 LTS。注意，Java 的版本号并不是“三年一代”，如果你看到教程推荐 Java 22、Java 23、Java 24，那些都是非 LTS 的尝鲜版，半年就换一代，个人学习可以，生产环境没必要追。

给一个 2026 年很实际的选型建议：

如果你是在校学生或者准备找 Java 开发工作，安装 Java 17 或 21 是最稳妥的，教程和面试用的生态基本都覆盖了。如果你想体会一下最新的功能，Java 25 也完全可以装。真正的开发老手往往不会只装一个版本，而是用多版本共存方案，这部分后面专门讲。

1.3 OpenJDK 发行版怎么选

现在说的“JDK”，并不只有 Oracle 官方网站那一家。Java 语言本身是开源的，市面上有很多基于 OpenJDK 构建的发行版，它们功能几乎一样，区别主要在维护方、更新周期和商业支持上。

如果你是新手，我建议直接选 Eclipse Temurin，也就是 Adoptium 社区提供的版本。这个发行版完全免费、无门槛下载，不需要注册 Oracle 账号，更新也比较规律，是目前全球 Java 开发者用的最多的 OpenJDK 发行版之一。安装包是一个 MSI 文件，Windows 下双击就能装，还自带环境变量配置选项，对新手非常友好。

其他几个发行版我给你摆个对照表：

选择困难症的话，直接下拉页面选 Temurin 的 MSI 安装包就行。这个系列和后面我讲的安装器选项完全吻合。

2. 图形界面配置：最稳的手动操作流程

2.1 安装 JDK 时这几个勾选要认真看

很多人装 JDK 时一路点“Next”，从来没看过安装界面上的选项，这是后续各种配置问题的源头。以 Temurin 的 MSI 安装器为例，安装过程会有一个界面让你选择功能，还会出现两个很关键的复选框：一个叫“Set JAVA_HOME variable”，另一个叫“Add to PATH”。翻译过来就是“设置 JAVA_HOME 变量”和“把 Java 加入 PATH”。

如果你勾选了这两项，安装器实际会帮你完成大部分环境变量配置，装完就能直接跑 java -version。很多人不知道这点，装完后又手动去配，结果 PATH 里同一个版本的 bin 目录被写了两次，或者旧版本的路径排在前面，反而把新版本盖掉了。所以我的建议是：安装时看清楚这两个勾选，如果你打算完全手动掌控，就把它们取消；如果你懒得折腾，就让它们保持勾选，装完先验证，不行再手动改。

另外注意安装路径。我建议把 JDK 装到一个不含中文、不含空格的简单路径下，比如默认的 C:\Program Files\Java\ 就可以。虽然 Windows 现在对空格路径的支持已经很成熟，但实际工作中很多脚本、工具在解析路径时容易出现莫名其妙的问题，干脆从一开始就避免这种麻烦。

2.2 打开环境变量面板的三条最快路线

Windows 打开环境变量面板的入口一直在变，很多人还在教“右键我的电脑 -> 属性 -> 高级系统设置”，其实到了新版系统里，右键“此电脑”后不一定直接有“属性”入口了。这里给你三条实测有效的路径，任选一条都能到：

1. 按 Win + R，输入 sysdm.cpl，回车，弹出“系统属性”，切到“高级”选项卡，点“环境变量”。这是最快的。
2. 打开“设置”，进入“系统” -> “系统信息” -> “高级系统设置”，也能弹到同一个窗口。
3. 在文件资源管理器地址栏输入 控制面板\所有控制面板项\系统，然后点击左侧“高级系统设置”。

进入环境变量窗口后，你会看到上下两个列表：上面是用户变量，下面是系统变量。这里有一个实际工程经验：配置 JDK 时，建议把 JAVA_HOME 和 PATH 都写在“系统变量”里，而不是“用户变量”里。原因很简单，很多后台服务比如 Tomcat、Jenkins、Elasticsearch 在 Windows 上是以服务形式运行的，服务进程不一定读取你的用户变量，但一定会继承系统变量。只配用户变量的话，你在自己终端里可能一切正常，服务一启动就告诉你找不到 Java。

2.3 手动配置 JAVA_HOME 和 PATH

如果你很享受“自己掌控一切”的感觉，或者安装器没有帮你设置成功，那就按下面的步骤手动配置。

先打开环境变量窗口，在“系统变量”区域点击“新建”，变量名填写 JAVA_HOME，变量值填写你的 JDK 实际安装目录。注意，这里填的是 JDK 的“根目录”，不是“bin 目录”。比如你的 JDK 装在：

code复制C:\Program Files\Java\jdk-21

那么 JAVA_HOME 的值就是 C:\Program Files\Java\jdk-21，不要写成 C:\Program Files\Java，更不要写成 C:\Program Files\Java\jdk-21\bin。写成 bin 目录是新手常见的错误，因为 JAVA_HOME 的用途是让工具寻找整个 JDK，后面拼接 \bin 是固定动作，你如果提前把 bin 写进去，人家反而找不到编译器和运行时了。

然后找到系统变量里的 Path，双击编辑。在弹窗里点“新建”，输入 %JAVA_HOME%\bin。这里的 %JAVA_HOME% 会被系统自动替换成刚才设置的路径。新添加的这一行，最好用右侧“上移”按钮把它移到列表靠前的位置。Windows 在 PATH 里是“从上往下查找”，如果前面已经存在其他 Java 相关路径，比如旧版本的 javapath，系统可能会先命中旧版本，导致你配的新 JDK 不生效。

配置完成后，需要关闭当前终端、重新打开一个新终端来测试。运行：

bash复制java -version
javac -version

如果你看到了版本号，并且和你安装的 JDK 版本一致，那环境变量就配好了。如果提示“不是内部或外部命令”，说明 PATH 这一步没生效，回到上一步检查变量的拼写。

2.4 2026 年了，真的别再手动配 CLASSPATH

如果你在网上搜 Java 环境变量配置，一定会看到好多教程让你在系统变量里新建一个 CLASSPATH，值写 .;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar。这套配置在 Java 8 及以前的老版本里有它的历史背景，但从 Java 9 开始，JDK 采用了模块化系统，dt.jar 和 tools.jar 这两个文件已经被彻底移除，你即使配了 CLASSPATH，里面指向的 jar 文件都不存在了，自然也没有意义。

更关键的是，现代 Java 开发完全不需要手工配置 CLASSPATH。无论是用 javac 编译还是用 java 运行，JDK 都会自动把自身的核心库加载好，项目里的依赖则交给 Maven、Gradle 这类构建工具去管理。你手动写一个 CLASSPATH，不但没有帮助，反而可能干扰项目的类加载，比如你指定了某个不存在的 jar 路径，运行时报一堆 ClassNotFoundException，排查半天才发现是环境变量里遗留的老配置。

如果你发现自己电脑里已经存在一个 CLASSPATH 变量，并且你用的是 JDK 9 以上版本，建议直接把它删掉。放心，删了不会出问题，只会让你后续少很多麻烦。真正需要指定类路径的场景，用 java -cp 把参数写到命令里就够了，而不是塞进全局环境变量。

3. 更新式的玩法：winget 安装与命令行的快速配置

3.1 一条命令装好 JDK

2026 年，Windows 上的软件安装已经越来越习惯用 winget 了。winget 是微软官方的包管理器，它最大的价值是：不用去浏览器找下载链接、不用分辨哪个按钮是广告，直接在终端里搜包、装包、升级包。

安装 Temurin 之前，先搜索一下包里确切的名称。打开 PowerShell 或者 Windows Terminal，运行：

bash复制winget search Temurin

输出结果里会有一串 Id，类似 EclipseAdoptium.Temurin.21.JDK。每个版本的 JDK 是一个独立的包，比如你要装 JDK 21，就执行：

bash复制winget install --id EclipseAdoptium.Temurin.21.JDK -e

-e 参数表示精确匹配，避免误装到同名包的其他版本。安装过程中，winget 会调用 Temurin 的 MSI 安装器，所以前面提到的“设置 JAVA_HOME”和“添加到 PATH”选项依然有效，安装器默认会帮你写好环境变量。

装完后，重点来了：立刻关掉当前终端并重新打开一个窗口，再运行：

bash复制java -version

如果你能看到版本信息，说明 winget 帮你完成了所有环节。一条命令解决安装加配置，这是现代 Windows 下最快的 Java 环境搭建方式之一。

3.2 学会用命令查看当前 Java 环境状态

不管你是用什么方式装的，装完之后一定要会用命令来诊断环境。很多自称“配置好了”的人，其实连当前系统到底在跑哪个 Java 都不清楚。下面这三个命令几乎能回答 90% 的问题。

第一个是查看 JAVA_HOME：

powershell复制echo $env:JAVA_HOME

在 CMD 下则用：

bat复制echo %JAVA_HOME%

如果输出的值不是你期望的 JDK 根目录，后续一切讨论都无从谈起。第二个是查看当前生效的 java 到底从哪个路径来的：

bash复制where.exe java

这个命令会把 PATH 列表里能找到的所有 java.exe 完整路径列出来，排在最上面的就是正在生效的那一个。如果你发现自己明明配了 JDK 21，但 java -version 显示的却是 17，就执行这个命令看第一个路径到底指向哪里，基本可以定位问题。第三个才是版本查看：

bash复制java -version
javac -version

要注意，有些机器上 java -version 能正常显示，javac -version 却提示找不到。这种情况多半是系统里只装了 JRE 或者你不小心把 JDK 的路径写成了运行目录，而 bin 目录里的 javac 没有被 PATH 覆盖到。

3.3 在终端临时设置变量，不影响全局环境

有时候你只是在当前窗口里想快速试一下某个版本，不想永久修改系统变量，这时可以用临时设置的方式。这种方式非常适合日常调试，因为它只影响当前这个终端会话，关掉窗口就恢复原样，不会污染全局配置。

CMD 下这样写：

bat复制set JAVA_HOME=C:\Program Files\Java\jdk-17
set Path=%JAVA_HOME%\bin;%Path%
java -version

PowerShell 下这样写：

powershell复制$env:JAVA_HOME = "C:\Program Files\Java\jdk-17"
$env:Path = "$env:JAVA_HOME\bin;$env:Path"
java -version

注意第二行把 %JAVA_HOME%\bin 放在了 PATH 最前面，这是有意为之，目的是让当前终端优先解析到刚设置的 JDK 版本。你在实际切换版本时，只要保证 JDK 根目录路径是正确的，这个技巧基本百试百灵。

4. 多版本共存：同时管理 Java 8、Java 17、Java 21 和 Java 25

4.1 为什么需要装很多个 JDK

很多人以为“装了一个最新版就万事大吉”，现实中完全不是这么回事。我见过太多开发者的电脑里，同时装着 Java 8、Java 11、Java 17，可能还有 Java 21。原因很简单：公司里的老系统用 Java 8，这是历史包袱，不是说换就能换的；平时自己跟教程学新特性，又需要 Java 21 甚至 Java 25；再赶上某个中间件框架对 JDK 版本有硬性要求，你就必须在不同版本之间来回切换。

除了 JDK，还有一些中间件也很看重 JAVA_HOME。比如 Elasticsearch，它启动时会去读 JAVA_HOME，如果指向了不支持的版本，可能直接拒绝启动。所以多版本管理不是“极客炫技”，而是 Java 开发者的基本生存技能。

4.2 稳妥的目录管理方案

多版本共存的核心思路是：不同版本的 JDK 各自待在自己独立的目录里，然后通过修改 JAVA_HOME 这个“指针”来切换默认版本。

实际安装时，我会把每个版本的安装目录都保持清晰。比如你用的是手动解压版或安装器，最后可能形成这样的目录结构：

code复制C:\Program Files\Java\jdk-1.8.0_202
C:\Program Files\Java\jdk-17.0.12
C:\Program Files\Java\jdk-21.0.5
C:\Program Files\Java\jdk-25

每个文件夹里面应该直接能看到 bin、lib、conf 这些子目录。JAVA_HOME 的值就指向这些带版本号的目录。

这里提醒一下，如果你之前装了多个 Temurin 发行版，它的默认安装路径可能是 C:\Program Files\Eclipse Adoptium\jdk-21.0.5-hotspot 这种带后缀的目录，不影响使用，但看起来比较长。为了管理方便，一些人会手动把 JDK 目录整理到统一的 C:\Program Files\Java\ 下，前提是你修改了安装路径或在安装后移动目录。移动之后，安装器原本写入注册表的一些信息可能不准，但只要你确保 JAVA_HOME 和 PATH 都指向新位置，实际开发影响不大，只是 Windows 的“已安装程序”列表里可能还保留着旧记录，介意的话最好还是安装时就直接指定好目录。

4.3 切换版本的正确姿势

多版本安装完成以后，你不需要反复修改 PATH，只需要修改 JAVA_HOME。逻辑很简单：PATH 里始终保持着 %JAVA_HOME%\bin 这一行，不管 JAVA_HOME 指向哪个 JDK，PATH 都会自动跟着生效。

假设你现在要把默认 Java 切换到 17，用管理员身份打开 CMD，执行：

bat复制setx JAVA_HOME "C:\Program Files\Java\jdk-17.0.12" /M

setx 是 Windows 自带的持久化设置环境变量的命令，/M 表示修改系统级变量，必须用管理员权限运行。执行完以后，关掉当前所有终端窗口，重新打开一个新窗口，然后运行 java -version 验证。注意，setx 不能用来修改 PATH，因为 Windows 的 PATH 值格式比较复杂，容易被 setx 截断，一旦写坏，系统里很多命令都会失效。改 PATH 请坚持用图形界面，或者用 PowerShell 里的 [Environment]::SetEnvironmentVariable 方法。

如果你想在 PowerShell 里持久化切换版本，可以这样写：

powershell复制[Environment]::SetEnvironmentVariable('JAVA_HOME', 'C:\Program Files\Java\jdk-17.0.12', 'Machine')

这条命令同样需要管理员权限，效果和 setx ... /M 一致。这里也提醒一句：修改机器级环境变量后，已经打开的 Windows Terminal、CMD、IntelliJ IDEA 都不会自动感知，必须完整退出并重新打开。有些开发者发现改了 JAVA_HOME 但 java -version 还是旧版本，八成是因为没重开窗口，或者只是在旧窗口里开了新标签页。

如果你只是想临时在当前终端切一下版本，用上一节讲的临时变量方法就够了，不需要动用 setx。

5. 验证与排雷：配置完为什么还是不生效

5.1 判断配置是否成功的标准动作

不管你是新装还是改版本，配置完建议按这个顺序验证三遍：

1. 先看 echo %JAVA_HOME%，确认系统变量是否指到你期望的目录。
2. 再看 where java，确认 PATH 里第一个 java.exe 来源于哪个目录。
3. 最后跑 java -version，确认运行结果是目标版本。

这三条命令是从“源头”到“结果”的完整链路。如果 JAVA_HOME 是对的，但 where java 出现的是别的位置，说明你的 PATH 里存在更靠前的干扰项，最常见的元凶是 Oracle 安装器留下的 C:\Program Files\Common Files\Oracle\Java\javapath。这个路径排在系统 PATH 的较前位置时，会抢走 java 命令的解析权，你再怎么改 JAVA_HOME 也没用。

解决办法是在 PATH 编辑界面找到这个 javapath 条目，直接删除，或者用右侧的“下移”把它移到最后。如果确定机器上没有任何 Oracle 老组件，直接删除是最干净的。

5.2 常见问题速查表

我整理了一张排查表，覆盖网上被问烂的场景，每一个都是实际踩过坑的：

这条表中最后一种情况要特别小心。环境变量里最怕动的就是 PATH，因为它前面那些系统目录一旦没了，Windows 连基本的 notepad、ping 都找不到。修改 PATH 时永远在原有值基础之上“添加”或“编辑”，不要整个删除重写。如果你不小心改坏了，可以参考系统的默认值从备份里恢复，或者借助注册表编辑器把 HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment 里的 Path 改回来。

5.3 为什么改了环境变量不是立刻生效

很多新手会疑惑：明明控制面板里已经确定保存了，为什么命令行里还是老样子？

这要从 Windows 的进程模型说起。每个进程启动时都会从父进程继承一份环境变量快照，在它运行期间，你去修改系统级别的环境变量，它也不会收到更新。你打开 CMD，它继承的是 Windows 资源管理器 explorer.exe 的环境快照；你在 explorer 弹出的控制面板里改了环境变量，但 explorer 并不会实时更新自己那份快照，于是从 explorer 启动的新 CMD 可能依然带着旧值。

所以实战中有两个经验：一是配置完系统环境变量后，尽量把已经开着的终端、IDE 全部关掉，再从开始菜单启动一个全新的终端，不要只是关掉标签页再开新标签；二是如果发现怎么重开都是旧值，最快的办法是注销并重新登录 Windows，或者重启 explorer.exe 进程。生产环境装 Java 时，干脆配置完直接重启一次系统，省得各种后台服务带着旧环境变量运行。

6. 和 IDEA、Maven、Tomcat 正确联动

6.1 IDEA 的 Project SDK 不一定跟着系统走

很多人配好了系统环境变量，结果打开 IntelliJ IDEA 后发现项目还是无法使用刚装好的 JDK，心里会咯噔一下。其实 IDEA 对 JDK 的管理是独立的，它默认有自己的运行时配置，不一定完全跟随 JAVA_HOME。

IDEA 里新建项目时，会让你选择 Project SDK。如果下拉列表里没有你要的版本，点击“Add SDK -> JDK”，手动浏览到 JDK 安装目录，选中真正的根目录就行。这里有一个细节：IDEA 对 JDK 目录的识别比较严格，它会检查目录结构是否完整，也就是必须有 bin、lib、release 这几个东西。如果你把 JAVA_HOME 指向了错误的目录，IDEA 会觉得这不是合法 JDK，直接拒绝添加