Windows下JDK 23解压版安装与环境变量配置全攻略-代码聚汇网

Windows下JDK 23解压版安装与环境变量配置全攻略

小丸子书单·2026-09-04·阅读 22 GEO检测（免费）

JDK 23Windows安装环境变量

|难度：普通|阅读约 35 分钟

最近有个朋友问我：JDK 23 解压版装完之后，java -version 能正常打印版本号，但一敲 javac 就提示“不是内部或外部命令”，这到底是 JDK 没装好，还是他漏了哪一步？我远程看了一下，问题不在安装，而在他对“解压、管理员运行、版本检查”这三件事的理解上——尤其是不清楚环境变量在 Windows 里的生效机制。这篇文章就围绕 Windows 上安装 JDK 23 的整个流程展开，重点讲清楚为什么有些步骤需要管理员权限、哪些地方其实不需要、以及版本检查结果该怎么解读。无论你是第一次接触 Java 的新手，还是以前一直用 exe 安装器、想换个更干净的解压版的老手，这篇教程都能直接拿来当操作手册用。

1. 从 exe 换成 zip：解压版 JDK 23 到底赢在哪里

很多人下载 JDK 时第一反应是找一个 .exe 安装包，双击、下一步、完成，一切交给安装向导。这个思路本身没有错，但如果你经常在本地维护多个 JDK 版本、或者需要把一套开发环境原样复制到别的电脑上，“zip 解压版”反而是更省心的选择。

1.1 exe 安装器和 zip 压缩包在 Windows 上的真实差异

Oracle 官网给 Windows 用户提供了两种 JDK 23 形态：一是传统的 jdk-23_windows-x64_bin.exe，二是 jdk-23_windows-x64_bin.zip。两种文件里的东西本质上是一样的，解压出来的 bin 目录、lib 目录、conf 目录都相同，唯一的区别在于系统层面的“集成方式”。

exe 安装器会帮你做几件额外的事：把 JDK 写到 C:\Program Files\Java\ 这类系统目录下，在“卸载或更改程序”里注册一条记录，同时写注册表键值，让你能通过系统的“添加或删除程序”来卸载。听起来很方便，但代价是它把 JDK 的安装路径写死了，版本切换时你需要在控制面板里卸载旧的、再装新的，或者忍受机器上同时躺着好几个版本，路径管理变得一团糟。

zip 解压版则是另一种哲学：它不碰注册表，不创建卸载记录，你把它解压到哪个目录，JDK 就存在于哪个目录。想装多个版本？没问题，D:\Java\jdk-17、D:\Java\jdk-21、D:\Java\jdk-23 各放各的，靠环境变量指向当前要用的那个。想迁移环境？直接把整个目录压缩打包，带到另一台机器上解压一遍，把环境变量改过来就能用。

用一张表来对比两者的差别会更直观：

对比维度	exe 安装器	zip 解压版
默认安装位置	`C:\Program Files\Java`	由你自己决定，常见于 `D:\Java` 等
注册表	会写入	不会写入
系统卸载列表	会出现	不会出现
多版本共存	不方便，需反复安装卸载	天然支持，目录隔离即可
环境迁移	需要重新安装	直接拷贝目录再配环境变量即可
卸载方式	控制面板卸载	删除目录并清理环境变量
管理员权限依赖	安装时通常需要 UAC 提权	只有改系统环境变量时才涉及提权

所以，如果你只是想在个人电脑上跑一跑 Java 程序，exe 和 zip 没有高下之分；但如果你想把 JDK 的安装过程变得“可复制、可回滚、可切换”，zip 版的优势会非常明显。

1.2 解压版适合谁来用，哪些情况建议绕开

先说不适合的场景。假如你是一个完全不懂命令行的用户，希望装完就自动能用、自动出现在开始菜单里，并且你只需要一个固定版本的 JDK，那老老实实用 exe 安装器会更舒服。zip 版给你最大的自由度，同时也把“环境变量配置、PATH 顺序、命令行工具检查”这些责任全交给了你。

适合用解压版的人，我认为主要有三类：

第一类是需要在多个 JDK 版本之间切换的开发者。比如公司老项目跑在 JDK 17 上，新项目想试试 JDK 23，两个版本都必须在同一台机器上随时可用。zip 版可以做到让 JAVA_HOME 只是一个可随时改写的变量，切版本时改一下指向再开新窗口即可。

第二类是经常搭测试环境、CI 构建镜像的人。这类场景往往希望以“拷贝目录 + 设置环境变量”的方式快速完成部署，而不是跑到每台机器上去点一遍安装向导。

第三类是轻微“洁癖”的开发者。我不太喜欢 JDK 安装器在注册表里留一堆东西，也不需要它在系统服务里注册什么自启动项。zip 版用完即走，删目录就完事，卸载后电脑几乎不留痕迹。

标题里提到的“解压”步骤，正是这个方案的第一步。先把这一步做对，后面管理员运行和版本检查才有意义。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 下载解压的正确姿势：目录规划、哈希校验与 0x80010135

解压听起来是整篇文章里技术含量最低的一步，但真正操作时，你会发现有一半的安装问题都出在“解压到哪”“系统用的哪个解压逻辑”“目录名是不是太长”这些细节上。

2.1 先从官网把正确的 zip 包拿下来

去 Oracle 官网的 Java Downloads 页面，能找到 JDK 23 的 Windows x64 安装包和压缩包。注意看文件名，我们需要的是 jdk-23_windows-x64_bin.zip，不要误下成 .exe。如果你用的是 Windows on ARM 设备，则需要选择对应的 aarch64 版本，文件名里会有明确标识。

下载完成后，建议先做一件事：校验 SHA-256，确认文件在传输过程中没有被损坏。具体操作是，打开文件资源管理器，进入下载目录，在地址栏输入 cmd 后回车，然后在命令行窗口里执行：

bat复制certutil -hashfile jdk-23_windows-x64_bin.zip SHA256

命令执行后，终端会打印一串 64 位的十六进制字符串。去官网页面找到对应的哈希值逐位比对，只要前几位和最后几位一致，基本可以放心解压。别看这步有点“强迫症”，实际工作中遇到过不少因为下载不完整导致解压到一半报错的情况，花 10 秒钟做一次校验能省掉后面一长串排查时间。

2.2 解压目录的规划：空格和中文是最大的隐形坑

然后就是标题里提到的“解压”。你在 Windows 上右键点击 zip 包，系统自带的文件资源管理器会直接解压，这当然能用。但如果你追求更稳定的体验，我建议不管用系统自带功能还是第三方工具，都要严格遵守一条目录规划原则：JDK 最终所在的路径，不要包含空格和中文。

比如这两种路径：

推荐：D:\Java\jdk-23
不推荐：C:\Program Files\Java\jdk-23

C:\Program Files 里有空格，很多脚本和命令行工具在拼接路径时如果忘记加引号，就会把路径拆成两段，导致找不到 java.exe。虽然现代 Java 工具链大部分能正确处理带空格的路径，但你没必要给自己埋这种雷。把 JDK 统一放在一个简洁的目录下，比如 D:\Java\ 或 C:\dev\java\，后续配置 JAVA_HOME 时会顺手很多。

具体解压操作也很简单。假设你下载的是 jdk-23_windows-x64_bin.zip，我想让 JDK 最终位于 D:\Java\jdk-23，可以分两步走：先在 D:\ 下创建 Java 文件夹，再把 zip 包里的内容解压到这个文件夹里。一定要留意解压后有没有出现双重目录，也就是解压完发现路径变成了 D:\Java\jdk-23\jdk-23。这种情况在国内下载的某些二次打包版本里尤其常见。如果是这样，你需要手动把内层目录的内容挪到外层，或者直接记住这个真实路径，后面配置时指向内层那一层。

2.3 解压时提示 0x80010135 该怎么处理

关于解压，有一个搜索热度很高的错误码值得单独说：错误代码 0x80010135。很多人在 Windows 上解压文件时碰到它，第一反应是压缩包坏了。其实这个错误更多和 Windows 文件资源管理器对“超长路径”的限制有关。当你把 zip 解压到一个本身层级已经很深的目录里，而压缩包内部又有非常深的目录结构时，Windows 自带的解压功能会因为路径总长度超过系统默认的 MAX_PATH 限制而中断，报出 0x80010135。

处理办法通常有三个方向：

第一，把 zip 包挪到短路径下去解压。比如直接放在 C:\ 或 D:\ 根目录，不要放在 C:\Users\你的用户名\Downloads\若干层子目录 里，这个操作最简单，大多数情况下立刻就能解决。

第二，换用第三方解压工具，比如 7-Zip。它对长路径的处理比 Windows 文件资源管理器宽容得多，很多资源管理器解压失败的文件，7-Zip 都能顺利解出来。

第三，如果非要用资源管理器解压，且文件在很深的目标目录中，可以尝试开启 Windows 的“长路径支持”。这个需要在系统设置或本地组策略里开启，对普通用户来说操作成本略高，一般不建议为了安装 JDK 去动系统级设置。

解压完成后，进入 JDK 根目录，确认能看到 bin、conf、include、legal、lib、man 等几个子目录，并且 bin 目录下有 java.exe、javac.exe，说明解压这一步就通过了。否则就回头检查包是否下载完整，或者是不是解压到了错误位置。

3. “管理员身份运行”不是每次都要，但要分清哪一步真正需要

标题里的第二个关键词是“管理员运行”。很多教程喜欢在任何操作前都加一句“请以管理员身份运行 cmd”，但这个说法把不少人带偏了。实际上，安装 JDK 23 解压版的过程中，不是每一步都需要管理员权限。你需要先搞清楚：普通权限和管理员权限之间有什么界限？哪些操作真的需要管理员令牌？

3.1 普通权限和提升权限的边界在哪里

Windows 里有一层用户账户控制机制，也就是常说的 UAC。它把程序分成了两类：一类以普通用户权限运行，另一类被“提升”为管理员权限运行。普通权限能读写你个人目录下的文件、能修改当前用户的配置；但当你试图写入 C:\Program Files、修改系统级环境变量、操作系统服务时，Windows 会要求你提供管理员权限。

这个设计本质上是为了防止恶意程序在用户无感知的情况下修改系统核心设置。所以你看安装教程里频繁提到“管理员身份运行”，不是因为它每一步都需要，而是因为很多环境配置操作确实卡在系统级写入这个坎上。

对于 JDK 23 解压版安装，你可以把操作分成两类：

把 JDK 解压到 D:\Java\：普通用户权限完全够用，不需要管理员。
编辑“系统变量”里的 JAVA_HOME 和 PATH：因为系统环境变量存储在 Windows 注册表的全局区域，需要管理员权限才能写入。

问题在于，很多人在配置环境变量之前，已经打开了一个普通权限的命令行窗口，然后敲 setx /M 或尝试往系统 PATH 里追加路径，结果被系统拒绝。最稳妥的顺序是：在开始配置系统环境变量前，主动启动一个“以管理员身份运行”的命令行窗口，后面的操作都在这个窗口里完成。

3.2 真正需要管理员身份运行的三个典型时刻

基于 JDK 23 解压版安装场景，我把需要管理员权限的典型操作总结成三个：

第一个是手动修改系统级环境变量。你打开“环境变量”窗口后，上方是当前用户的变量，下方是系统变量。如果打算把 JAVA_HOME 配置成系统变量，并让所有用户都能使用，就必须保证当前进程具备管理员权限；否则编辑按钮是灰色或无法保存。

第二个是用命令行向系统变量追加 PATH。Windows 的 setx /M 命令明确会写入系统级配置，它要求命令行窗口必须是提升了权限的。在普通权限的命令行里执行 setx /M，大概率会得到一个“拒绝访问”的错误。

第三个是希望所有用户账户都能访问同一个 JAVA_HOME。如果电脑有多个人共用，这个需求就需要管理员处理。若你只想让当前登录账户用 JDK，把 JAVA_HOME 配置到“用户变量”里就够了，这种情况下管理员权限不是必需的。

顺带一提，网上也有“如何取消以管理员身份运行”这类问题。它通常指的是某个快捷方式被设置了“以管理员身份运行此程序”选项，每次双击都要弹 UAC，有点烦。JDK 本身不会强制你这么做，你只是需要理解什么时候该提权、什么时候不该提权。

3.3 如何正确启动管理员命令行并完成环境变量配置

我推荐的方式是：在 Windows 开始菜单附近搜索 cmd，搜索结果里出现“命令提示符”后，右键并选择“以管理员身份运行”。或者按 Win + R，在运行框里输入 cmd，然后同时按 Ctrl + Shift + Enter，同样能触发管理员权限请求。如果当前登录账户本身是管理员，UAC 弹窗出来直接点是；如果是标准用户，则需要输入一台电脑上管理员账户的密码。

打开后的命令行窗口，标题栏一般会带上“管理员”字样。你可以先确认自己确实具备管理员权限：

bat复制net session

如果命令执行成功，没有提示“拒绝访问”，就说明当前窗口已具备管理员权限。如果提示拒绝访问，说明权限还不够，请重新按上面的方式打开。

接下来建议先不急着写环境变量，先创建好目录并确认 JDK 根目录无误。假设 JDK 在 D:\Java\jdk-23，那么配置应围绕这个路径展开。需要提醒的是：不要在学习阶段就想着“我能不能把管理员权限彻底关掉”，那是和系统安全机制作对，属于给自己挖坑。保持界面对话框弹出，每一个提权操作都明确是你自己主动发起的，这个习惯更健康。

4. 版本检查背后的“生效机制”：为什么 java -version 能用，javac 却找不到

标题里的第三个关键词是“版本检查”。如果只是简单执行一条 java -version，那这篇教程可以缩减一半。但实际问题是，版本检查的反馈往往不是直白的“成功”或“失败”，它更多是在告诉你环境变量生效到哪一步了。开头提到的那个朋友就卡在这里。

4.1 PATH 和 JAVA_HOME 到底在干什么

要把版本检查结果看懂，必须理解两个概念：一个是 PATH，一个是 JAVA_HOME。

PATH 是 Windows 用来“按图索骥”找命令的目录清单。你在命令行里输入 java，系统会按 PATH 中配置的目录顺序去找有没有 java.exe。如果 PATH 里配置了 D:\Java\jdk-23\bin，系统就会去这个目录里找；找不到才会看下一个目录。所以 PATH 更像是一张通讯录，记录的是“到哪儿能找到工具”。

JAVA_HOME 则是一个约定俗成的环境变量名。Java 生态里的构建工具比如 Maven、Gradle，以及运行 Java 服务的脚本，通常都会读取 JAVA_HOME 来确定 JDK 的安装根目录，然后在这个目录下找 bin/java.exe。所以它更像“家庭住址”，告诉工具你的 JDK 住在哪。

听起来 JAVA_HOME 好像不是必需的，只要 PATH 里能访问到 java.exe 就行了。但实际运行 Maven 或一些应用服务器时，它们不一定通过 PATH 找 Java，而是直接读 JAVA_HOME。如果只配了 PATH 没配 JAVA_HOME，你平时编译运行可能没感觉，但一跑 Spring Boot 项目或 Maven 打包就会碰壁。

标准做法是：先把 JAVA_HOME 配好，再让 PATH 通过 %JAVA_HOME%\bin 引用它。这样以后升级 JDK 时，只需要把 JAVA_HOME 指向新的解压目录即可，PATH 本身不用改。

4.2 配置 JAVA_HOME 和 PATH 的完整操作顺序

既然要用管理员权限，现在开始操作：

第一步，右键“此电脑”，选择“属性”，在左侧找到“高级系统设置”，点击后弹出的“系统属性”窗口里，注意右下角的“环境变量”按钮。由于我们要写系统变量，这里建议保持整个流程在已提升权限的上下文里操作，如果窗口要求确认，就确认。

第二步，在“系统变量”一栏点击“新建”。变量名统一写成 JAVA_HOME，变量值填 JDK 解压后的根目录，比如 D:\Java\jdk-23。注意，这里填的是 JDK 的根目录，不是根目录下的 bin 目录，这个非常关键。

第三步，在“系统变量”里找到名称为 Path 的条目，双击它，在弹出的“编辑环境变量”窗口里点击“新建”，添加一行：

bat复制%JAVA_HOME%\bin

如果你编辑的是 Windows 10 或 Windows 11 的 Path 环境变量，它通常以列表形式展示，不容易操作错；如果弹窗显示的是老式单行文本框，则需要在内容末尾先加分号再粘贴，但新版 Windows 一般已经不存在这个问题。

第四步，点击所有窗口的“确定”，让配置写入。然后重新打开一个全新的命令行窗口，千万不要在旧窗口里继续检查，因为旧窗口启动时就已经读取了旧环境变量，新的配置不会自动同步进去。

4.3 java -version、javac -version 的输出应该长什么样

新打开的命令行窗口里，输入：

bat复制java -version

正常会看到类似下面的输出，具体 build 号取决于你下载的是哪个补丁版本：

text复制java version "23.0.1"
Java(TM) SE Runtime Environment (build 23.0.1+11-39)
Java HotSpot(TM) 64-Bit Server VM (build 23.0.1+11-39, mixed mode, sharing)

看到这五行，基本说明 JVM 能正常加载，运行时环境没问题。它使用的是 HotSpot 虚拟机，而且是 64 位版本。如果这里输出的不是 23，而是 java version "1.8.0_..." 或 java version "17..."，则说明 PATH 里旧的 Java 条目排到了新条目前面，系统优先找到了其他版本的 java.exe。

接着输入：

bat复制javac -version

正常输出：

text复制javac 23.0.1

javac 是 Java 编译器。很多安装问题恰恰表现为：java -version 正常，javac 提示找不到命令。这种情况说明当前执行环境中存在一个只包含运行时 java.exe、却不包含编译器 javac.exe 的旧路径。老的 JRE 版本目录里通常只有 java.exe，没有 javac.exe，而新 JDK 的 bin 目录里两者都有。如果你 PATH 中旧 JRE 的路径排在新 JDK 前面，java 命令会被旧 JRE 响应，javac 则完全找不到。这就解释了开头的现象。

你还可以用下面的命令查看实际执行的是哪个路径下的 java.exe：

bat复制where java
where javac

这两条命令会列出 PATH 中搜索到的所有 java.exe 和 javac.exe 的位置，排在最上面的就是真正被执行的。如果 where java 显示的路径指向了其他目录，就该回到 PATH 里调整顺序了。

4.4 一行 HelloWorld 做编译和运行的双重验证

版本号能打印出来，只能说明命令解析成功，还不足以证明整个编译链路已经打通。更可靠的验证方法是写一个最小的 Java 程序，用 javac 编译，再用 java 运行。

在某个临时目录下新建一个文本文件，改成 Hello.java，内容如下：

java复制public class Hello {
    public static void main(String[] args) {
        System.out.println("JDK 23 works!");
    }
}

然后在命令行中切换到该目录：

bat复制cd /d D:\tmp
javac Hello.java
java Hello

如果终端输出了 JDK 23 works!，说明从编译到运行整条链路正常，JDK 23 的安装与验证才算真正完成。

这里有个新手容易踩的坑：文件名必须和类名一致，也就是 Hello.java 对应 public class Hello。另外运行时输入的是 java Hello，不是 java Hello.class，也不是 java Hello.java。很多人第一次写 Java 时都会在这两个地方反复出错，看到错误别慌，对照检查即可。

5. 配置完成后最容易翻车的几种场景排查思路

到这里，JDK 23 应该已经能正常使用了。但总有一些“玄学”问题会在配置完后出现，我把自己遇到过的几种典型翻车场景放在这里，如果读者中招，可以按图索骥地查。

5.1 明明配置了 JAVA_HOME，新开的窗口却还是找不到 java

这个问题的关键往往在于“窗口的开启方式”。假设你先打开了一个普通 cmd，然后再在这个 cmd 里输入 start cmd 打开新窗口，那这个子窗口会继承父窗口的环境变量，而父窗口又是在配置生效前启动的，所以新窗口里依然读不到新的 JAVA_HOME 和 PATH。

正确做法是：配置完环境变量后，不要从任何已开着的命令行窗口里启动新窗口，而是彻底关闭所有 cmd 窗口，重新通过“开始菜单”或 Win + R 启动一个新的命令行。如果之前打开过 PowerShell，同理，也要完全关闭再开。

另一个类似的问题是“Windows 资源管理器还在用旧环境变量”。资源管理器进程负责启动你双击的很多程序，某些情况下系统配置已经改了，但桌面外壳没有刷新。这种概率比较低，如果你怎么开新窗口都不生效，重启一下资源管理器或注销重新登录通常能解决。

5.2 多版本 JDK 共存时，系统总是选中老版本

很多开发者电脑上不止一个 JDK，比如用户变量里配过 JDK 8 的 PATH，系统变量里又配了 JDK 23，两个版本同时存在，系统执行 java 时按 PATH 列表从上到下查找。谁排在前面，谁就“赢得”命令解析权。

排查步骤是：先执行 where java，看第一行输出指向谁。如果确实是老版本，就回到环境变量编辑器，把 JDK 23 对应的 %JAVA_HOME%\bin 条目上移到旧版本条目之前。

如果 where java 输出的第一个路径并没有对应的实际文件，但 java -version 仍有结果，就需要考虑另一个可能：是不是有 Windows Apps 别名在执行？有些系统在 PATH 里加入了指向 C:\Users\你的用户名\AppData\Local\Microsoft\WindowsApps 的条目，而这个目录下有时会存在 java.exe 的“执行别名”。这通常是为没有安装 Java 的用户准备的提示占位。解决办法是在“设置 -> 应用 -> 高级应用设置 -> 应用执行别名”里找到 java 相关项并关闭。

5.3 版本号正确了，但 javac 编译始终报“无法将类 Hello 识别为公共类”

这个问题常见于文件名、类名大小写不一致，或者源码文件本身有隐藏扩展名。Windows 默认隐藏已知文件的扩展名，你新建文本文件后手动改成 Hello.java，实际上文件可能叫 Hello.java.txt。在命令行里执行 javac Hello.java 时它还能找到文件吗？一般会提示找不到，但如果你通过地址栏到了那个目录，看起来一切合理，却依然报错，就要怀疑是不是扩展名变成了 .java.txt。

在文件资源管理器里勾选“文件扩展名”，确认真实文件名是 Hello.java 而不是 Hello.java.txt。这个方法能解决九成以上“文件名写对但编译器找不到公共类”的问题。

5.4 编译运行中文输出时出现乱码怎么办

Windows 命令行默认代码页和 Java 源码文件的编码如果不一致，可能出现乱码。JDK 18 之后默认字符集已经是 UTF-8，但 Windows 控制台如果不配合，依然可能显示乱码。最简单的方法是在源码文件里避免中文字符，或者编译时显式指定编码：

bat复制javac -encoding UTF-8 Hello.java
java -Dfile.encoding=UTF-8 Hello

如果你的程序输出包含中文，并且不想每次手动加参数，也可以在系统环境变量里新增 JAVA_TOOL_OPTIONS 为 -Dfile.encoding=UTF-8。不过这个办法会影响该机器上所有 Java 程序，算是“重武器”，需要谨慎使用，毕竟有些老程序可能依赖默认编码处理外部文件，改动之后可能引发别的问题。

5.5 终端窗口里的“管理员权限”和 JDK 本身是两回事

最后再强调一个容易搞混的概念：网上很多教程说要以管理员身份运行 cmd，但这绝不意味着“用管理员权限运行 java 就更好”。Java 程序本身的跨平台特性使其大部分运行场景都不需要管理员权限，普通用户权限足以完成编译和运行。管理员权限只是环境变量配置阶段的一把钥匙，不属于日常 Java 开发的一部分。

如果你在管理员命令行下执行 java -version 时一切正常，但切回普通命令行后却频繁提示找不到命令，多半不是权限问题，而是你在管理员模式下配置的系统 PATH 只对“系统变量”有效，而当前普通用户的环境变量或 PATH 中可能也有旧配置，两者发生了冲突。回看第 5.2 节的排查方法，检查用户变量和系统变量各自的 PATH 顺序即可。

我个人的习惯是，每次配置完 JDK 后，都会顺手把 JAVA_HOME、PATH 中与 Java 相关的条目全部截图保存一份。下次升级版本或者需要清理环境时，不需要靠回忆去猜当初改了什么。Windows 上的 JDK 安装没有太多神秘之处，核心就三条：正确的解压目录、清晰的环境变量、准确的验证命令。把这三点真正吃透，不管以后装 JDK 21、JDK 23 还是再往后的版本，你都能举一反三，没有必要每次遇到新版本就重新翻一遍教程从头踩坑。