Windows多JDK版本切换：批处理脚本一键管理实战

在Windows下开发Java项目，遇到的最烦人的事之一就是JDK版本切换。项目A是老系统，必须用JDK8，项目B是微服务架构，要用JDK17，偶尔还要试试JDK21的新特性。每次切项目都要手动改环境变量、改JAVA_HOME、改PATH，改完还要重新打开终端验证，一天下来可能来回折腾好几次。我之前也是这么干的，直到有一次在JAVA_HOME里漏了个分号，把系统的PATH搞坏了，花了一个多小时才恢复，从那以后我就下定决心搞一套好用的JDK版本管理方案。

这篇文章就把我整理的一套基于批处理脚本的Windows多JDK管理方案完整分享出来。核心思路就一个：用几个简单的.bat脚本，在同一个终端窗口里随时切换当前要用的JDK版本，脚本会自动处理JAVA_HOME和PATH的更新，顺带还能记住你系统原本的JDK配置，需要的时候一键还原。整个方案不依赖第三方工具，不装额外软件，纯Windows自带功能，对开发环境没有侵入性，也方便在团队里直接分享。

这个方案适合谁用？很明确：日常工作离不开命令行、需要频繁在多个JDK版本之间切换的Java开发者，尤其是做老项目维护同时又在搞新框架的朋友。如果你只是固定用一个版本，那直接装好配好环境变量就行，没必要搞这套。但如果你跟我一样，终端里一天到晚要开好几个项目，这个方案能帮你省下大量重复劳动。

1. 核心思路拆解：为什么用批处理而不是其他方案

1.1 先看看市面上的替代方案

在动手写脚本之前，我其实把市面上主流的方案都过了一遍，有踩坑也有对比，这里直接说结论。

第一种是手动改环境变量，这种不用多说，费时费力还容易出错，唯一的“优点”是什么都不用装。

第二种是用IDE内部切换，比如IDEA和Eclipse都能在项目级别指定JDK版本。这个方案最大的问题是只对IDE内部生效，如果你在终端里跑Maven、Gradle、Jar包，或者用命令行手工编译，IDE的配置完全不起作用。而且IDEA内部切换JDK的前提是你已经把多个JDK都“登记”到IDE里了，说到底还是要先安装好多个版本。

第三种是用现成的工具，社区里有一些开源的JDK版本管理工具，原理上是改JAVA_HOME和PATH，再在shell层面切换。但这些工具很多是macOS和Linux生态的，Windows上要么需要额外装模拟环境，要么就是命令行工具本身的维护活跃度一般。另外，很多公司开发机是锁了权限的，装第三方工具需要审批，太麻烦。

第四种是绿化版JDK配合软链接。这个思路是把JDK解压到一个固定目录，然后通过改一个软链接指向不同版本。批处理脚本也能做这事，但软链接需要管理员权限，而且在部分Windows版本上对符号链接有额外限制，不够稳。

对比下来，批处理脚本方案的优势就很明显了：Windows自带，不用装任何东西，脚本代码完全透明可控，出了问题自己改代码就能排查，而且脚本运行在“当前终端进程”级别，不影响系统全局配置，切错了关掉终端就完事。

1.2 这版脚本的设计目标

动手写之前，我给自己定了几个硬性指标，写完后发现这些指标对使用体验影响非常大。

第一个指标是“切换必须即时生效”。我经常在同一个终端会话里连续切换版本，如果每次切换都要关掉终端重开，体验就废了。这就要求脚本不能用setx直接改系统环境变量，因为setx改完只对“未来”新开的进程生效，当前会话不会有任何变化。正确的做法是在当前cmd进程里用set命令临时修改进程级环境变量，同时也可以顺带用setx把默认版本写进系统变量，这样新窗口和当前窗口都不会出问题。

第二个指标是“不能把系统原有的PATH搞丢”。PATH变量里往往有大量其他软件加的路径，比如Python、Git、Node等，切换JDK时绝对不能一股脑覆盖。所以脚本里必须对PATH做“只替换JDK相关项，其余原样保留”的处理，而不是简单地用字符串拼接。

第三个指标是“要有状态提示”。我不知道你怎么想，反正我切完版本之后第一件事一定是敲java -version看一眼。脚本里直接把当前生效的版本、JAVA_HOME路径、PATH里Java相关项打出来，一眼就能确认切没切对，省掉一次手动验证。

第四个指标是“支持临时切换和全局切换两种模式”。临时切换只对当前终端窗口生效，关掉就恢复；全局切换则写入系统级环境变量，新打开的终端都用新版本。这两种场景在开发中都会遇到，缺一个都不舒服。

1.3 为什么用“环境变量映射”而不是修改JAVA_HOME默认值

很多人的第一反应是，脚本里把JAVA_HOME改成JDK17的完整路径不就行了吗？确实可以，但有一个隐藏问题：JDK版本号经常有小版本更新，比如JDK17会有17.0.1、17.0.2、17.0.12……如果每个版本的小版本路径都写死在脚本里，升级小版本就得改脚本。

我采用的方案是“版本目录名归档”，每个JDK解压后的目录名统一改成jdk-8、jdk-17、jdk-21这种不带小版本号的名字，脚本里只维护“版本别名到目录路径”的映射关系。将来更新小版本，只要保证目录名不变，脚本一行都不用改。

这个方法其实借鉴了Linux的alternatives机制，只不过在Windows上用批处理脚本实现了最小可用版本。好处很明显：脚本代码更简洁，维护成本几乎为零，新加一个JDK版本只需要在脚本里加一行映射，再往固定目录里扔一个解压包。

2. 准备工作：JDK的安装与目录规划

2.1 JDK安装包的准备

这一步本身比较简单，主要是别踩坑。JDK建议从官方或可信镜像获取安装包。注意这里说的“安装”其实可以不依赖安装程序，JDK本质上就是一组目录和可执行文件，安装版和压缩版唯一的区别是安装版会注册服务、写注册表、设置系统变量，这些对我们来说非但没用，反而是负担。

所以我建议下载压缩版（.zip格式）。如果你只有安装版，装好之后也能用，只是路径可能会带空格或者带版本号，后面脚本处理起来要注意引号。我强烈推荐压缩版，下载完直接解压到规划好的目录就行。

2.2 目录规划：把JDK统一放一个地方

这一步很重要。我在D盘建了一个专门目录，比如D:\dev\java，下面再按版本建子目录：

code复制D:\dev\java\jdk-8
D:\dev\java\jdk-11
D:\dev\java\jdk-17
D:\dev\java\jdk-21

每个子目录里放对应版本的JDK解压内容，目录名统一去掉版本小号。这里有个技巧：解压后的目录名通常很长，比如jdk-17.0.12，我建议直接重命名成jdk-17，不然每次写路径都容易打错，脚本里维护起来也乱。

为什么要统一放在一个目录下？因为脚本里可以用一个“根目录变量”去拼接完整的JDK路径，将来整盘迁移或者换电脑，只需要改这一处，其他脚本不用动。

2.3 系统级环境变量的初始设置

你可能会问：“既然脚本要管理JAVA_HOME，那我系统里还要不要配JAVA_HOME和PATH？”

我的建议是：让系统级的JAVA_HOME指向你最常用的那个版本。比如你平时80%时间用JDK17，那就把系统JAVA_HOME指向D:\dev\java\jdk-17，PATH里加上%JAVA_HOME%\bin。这样新开任何终端，默认就是JDK17，日常用起来没有任何感知，只有在切到其他版本时才需要跑脚本。

这么做的另一个好处是“保险”。万一某个脚本半路出错，只要关掉当前终端，再打开一个新终端，就又回到系统默认的JDK17了。这个回退机制虽然简单，但关键时候能救命。

3. 核心脚本实现：一键切换的原理与完整代码

3.1 脚本一：管理JDK版本映射表（jdk-env.bat）

这是整个方案的核心配置文件，其他脚本都会调用它。它维护了两张“表”：一张是版本号到目录名的映射，另一张是记录系统原始环境变量备份。

这里我给出一份可以直接用的完整代码：

bat复制@echo off
rem ============================================
rem JDK 版本映射表与基础环境配置
rem 所有脚本共享此配置文件
rem ============================================

set "JDK_ROOT=D:\dev\java"
set "JDK_CURRENT_VERSION=17"

rem 此文件会被其他脚本call，需要把变量传递回调用方
rem 用endlocal & set "xxx=%xxx%" 模式返回变量
endlocal & set "JDK_ROOT=%JDK_ROOT%" & set "JDK_CURRENT_VERSION=%JDK_CURRENT_VERSION%"

这里用了批处理里比较绕的一个技巧。因为整个脚本在运行时会被一个隐形的局部作用域包裹，直接在脚本里set变量，用完后变量就没了。为了让调用方拿到JDK_ROOT等变量，需要先用setlocal开启延迟定位，再在脚本结束时用endlocal配合set把指定变量“抛”回调用方作用域。

不过，在实际使用中我发现这个写法对新手太不友好，而且容易写错。我后来改用了更直白的方案：在每个需要JDK映射的脚本里直接维护一段“版本目录变量定义段”。虽然代码重复了一点，但可读性强很多，别人拿到脚本一看就懂。下面是修改后的版本：

bat复制@echo off
rem ============================================
rem JDK 版本管理脚本 - 公共配置
rem ============================================

set "JDK_ROOT=D:\dev\java"
set "JDK_8=%JDK_ROOT%\jdk-8"
set "JDK_11=%JDK_ROOT%\jdk-11"
set "JDK_17=%JDK_ROOT%\jdk-17"
set "JDK_21=%JDK_ROOT%\jdk-21"
set "DEFAULT_JDK=17"

rem 当前生效版本，会随着切换脚本更新
if not defined CURRENT_JDK set "CURRENT_JDK=%JDK_ROOT%\jdk-%DEFAULT_JDK%"

这里有个细节：我用if not defined来判断CURRENT_JDK是否已有值，这样同一个终端里多次call这个配置脚本时，不会每次重置CURRENT_JDK。这个判断是必须的，否则切换脚本刚切到JDK8，下一行调用配置脚本又把版本重置回17了。

3.2 脚本二：切换JDK版本（jdk-use.bat）

jdk-use.bat是高频使用的核心切换脚本，它接收一个参数，比如8、11、17、21，返回对应当前状态信息。

先看完整代码：

bat复制@echo off
setlocal enabledelayedexpansion

rem ============================================
rem 用法: jdk-use.bat 8|11|17|21
rem 示例: jdk-use.bat 17
rem ============================================

call "%~dp0jdk-env.bat"

if "%1"=="" (
    echo [错误] 请指定JDK版本号，例如: jdk-use.bat 17
    exit /b 1
)

set "TARGET_JDK="
if "%1"=="8" set "TARGET_JDK=%JDK_8%"
if "%1"=="11" set "TARGET_JDK=%JDK_11%"
if "%1"=="17" set "TARGET_JDK=%JDK_17%"
if "%1"=="21" set "TARGET_JDK=%JDK_21%"

if not defined TARGET_JDK (
    echo [错误] 不支持的JDK版本: %1
    echo 支持版本: 8, 11, 17, 21
    exit /b 1
)

if not exist "%TARGET_JDK%\bin\java.exe" (
    echo [错误] 在 %TARGET_JDK% 下未找到 java.exe
    echo 请检查JDK安装路径
    exit /b 1
)

rem ============================================
rem 处理JAVA_HOME和PATH
rem ============================================

set "JAVA_HOME=%TARGET_JDK%"
set "CURRENT_JDK=%TARGET_JDK%"

rem PATH的处理：去掉所有旧JDK相关的bin目录项，再追加当前JDK的bin
set "NEW_PATH="
set "OLD_PATH=%PATH%"

rem 注意：Windows路径分隔符是;，使用for循环按分隔符切割
for %%p in ("%OLD_PATH:;=" "%") do (
    set "P=%%~p"
    if /i not "!P!"=="!P:jdk-=!" (
        rem 包含"jdk-"字样的路径项，跳过
    ) else (
        rem 不包含"jdk-"的路径项，保留
        if defined NEW_PATH (
            set "NEW_PATH=!NEW_PATH!;!P!"
        ) else (
            set "NEW_PATH=!P!"
        )
    )
)

rem 在PATH最前面加入当前JDK的bin目录
set "PATH=%JAVA_HOME%\bin;%NEW_PATH%"

rem 清除可能的无效目录引用（如双分号）
set "PATH=%PATH:;;=;%"

rem ============================================
rem 输出当前状态
rem ============================================

echo ============================================
echo JDK已切换到: %1
echo JAVA_HOME: %JAVA_HOME%
echo ============================================
echo java -version 验证结果:
java -version
echo ============================================

这段脚本里有很多值得讲清楚的细节，逐一说明下。

PATH的处理逻辑是整个脚本的灵魂。Windows的PATH是用分号分隔的一组路径，切换JDK的本质就是把JDK版本的bin目录从PATH里“摘”出来，替换成另一个版本的bin目录。但PATH里往往还混着其他和JDK无关的路径，比如Git的cmd目录、Python的Scripts目录，这些必须原样保留。我是用一个for循环按分号切分PATH，对每个路径项判断它是否包含“jdk-”字符串，包含的说明是JDK相关项，直接丢掉；不包含的通通保留。这样无论你原来PATH里有多少个JDK项，切一次就会清理干净。

排除规则是根据实际环境经验定的。实际开发机里，Path下跟JDK相关的项基本都有jdk字样，比如D:\dev\java\jdk-17\bin、C:\Program Files\Java\jdk1.8.0_202\bin。用jdk-作为关键字足够精准，不会误伤其他路径。但如果你机器上有某些软件路径碰巧包含jdk-，这个规则就需要调整。我之前的判断逻辑是“包含jdk即排除”，但这样太宽泛，可能会误杀一些无关路径，所以最后选定用“jdk-”这串含连字符的关键字。

注意一个Windows批处理的坑：for循环里处理路径时，默认空格和分号都是分隔符，而Windows路径可能含空格（比如C:\Program Files\java\jdk-17\bin），所以切割PATH时不能用默认的for方法。我用了"%OLD_PATH:;=" "%"这个技巧：先把分号替换成引号+空格+引号的形式，再让for按空格分割时又能正确分辨带引号的路径。简单说，每个路径项最终都会保留自己的完整内容，包括里面的空格。我刚开始写这段时也在这里翻了车，切出来的路径项全被空格劈成两半，后来才琢磨出这个带引号的切割法。

setlocal enabledelayedexpansion是必须的。批处理在if和for代码块内，%变量%会被一次性展开成进入代码块前的值，导致循环里取到的变量永远是初始值。开启延迟变量扩展后，用!变量!语法访问变量，才拿到循环过程中不断变化的最新值。

3.3 脚本三：查看当前JDK状态（jdk-status.bat）

这个脚本很简单，但很实用。加载配置后，把当前生效的JAVA_HOME、CURRENT_JDK、PATH里所有JDK相关项打印出来：

bat复制@echo off
call "%~dp0jdk-env.bat"

echo ============================================
echo 当前JDK状态
echo ============================================
echo JAVA_HOME: %JAVA_HOME%
echo CURRENT_JDK: %CURRENT_JDK%
echo 当前生效的java版本:
java -version 2>&1
echo ============================================
echo PATH中的JDK相关路径:
echo %PATH:;=&echo.%

PATH那一行的写法是批处理里常用的“把分号替换成换行”小技巧，输出时每个路径单独占一行，方便检查。跑一次这个脚本，你就能清楚地看到当前环境到底是什么状态。

3.4 脚本四：一键启动指定JDK版本下的程序

实际开发中，有时候我需要在特定JDK版本下执行一段命令，但不希望改动全局状态。比如我要用JDK8跑一个老项目的Jar包，但又懒得切换默认版本，这时可以用一个“临时环境启动器”：

bat复制@echo off
setlocal enabledelayedexpansion
call "%~dp0jdk-env.bat"

if "%1"=="" (
    echo [用法] jdk-run.bat ^<版本^> ^<命令^>
    echo [示例] jdk-run.bat 8 java -version
    exit /b 1
)

set "VER=%1"
shift
set "TARGET_JDK="
if "%VER%"=="8" set "TARGET_JDK=%JDK_8%"
if "%VER%"=="11" set "TARGET_JDK=%JDK_11%"
if "%VER%"=="17" set "TARGET_JDK=%JDK_17%"
if "%VER%"=="21" set "TARGET_JDK=%JDK_21%"

if not defined TARGET_JDK (
    echo [错误] 不支持的JDK版本: %VER%
    exit /b 1
)

rem 临时设置环境变量，仅对本脚本及其子进程生效
set "JAVA_HOME=%TARGET_JDK%"
set "PATH=%TARGET_JDK%\bin;%PATH%"

rem 执行剩余的命令
%*

这个脚本用了shift来逐个处理参数，很好理解：第一个参数是版本号，剩下的所有内容拼起来当命令执行。实际用起来的感觉很像Linux里的env JAVA_HOME=xxx java -version，只是Windows版。比如我想用JDK8快速验证某个Jar包是否兼容：

code复制jdk-run.bat 8 java -jar old-project.jar

跑完不影响当前终端的JDK配置，下一条命令还是原来的版本。

4. 实操过程：从配置到日常使用的完整演示

4.1 首次配置：把脚本放到固定目录并加入PATH

上面几个脚本你可以放在同一个目录，比如D:\dev\scripts\jdk-tools，然后把这个目录加到系统PATH里。具体操作是：右键“此电脑”->“属性”->“高级系统设置”->“环境变量”，在“系统变量”里找到Path，编辑并新建一行，把路径填进去。

加分到PATH后，新开的终端里就能直接使用jdk-use.bat等命令了。这里有个前提：脚本文件名建议不带.bat后缀也能被识别？Windows默认对.bat和.cmd文件可以在命令行里省略扩展名直接执行，所以jdk-use.bat在命令行里敲jdk-use就会执行。

我用的是.bat后缀，设置好之后打开任意终端，输入jdk-use就能看到用法提示。如果你已经开着终端，需要新开一个窗口才能让新增的PATH生效。

4.2 日常切换演示：从JDK17切换到JDK8

假设当前系统默认是JDK17，现在要切到JDK8跑一个老项目：

code复制C:\> jdk-use 8

脚本执行后，我预期输出如下内容：

code复制============================================
JDK已切换到: 8
JAVA_HOME: D:\dev\java\jdk-8
============================================
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)
============================================

注意看这里有个“版本命名”历史包袱：JDK8内部版本号是1.8.0_202，不是8.0.2之类的，这是Java官方从JDK5开始就玩的命名游戏。如果你看到java -version输出1.8.0_xxx，别怀疑自己切错了，这确实是JDK8。

切换完我再去跑Maven项目，因为Maven启动脚本会读取JAVA_HOME，自然会用JDK8的编译器和运行时。

4.3 常见使用场景：IDE命令行和CI本地验证

在实际开发中，这个方案最常用的场景有三个。

第一个场景：IDEA里配置多个JDK。把JDK_ROOT目录下的每个版本路径都添加进去，IDEA项目设置里就可以按项目切换。但注意，IDEA里切换JDK只影响IDE内部；在IDEA的Terminal面板里跑Maven时，用的还是系统PATH里的JDK。所以，我养成了一个习惯：在IDEA的Terminal里跑Maven前，先敲一下jdk-use查看当前版本，确保和我想要的版本一致。

第二个场景：本地验证CI构建。流水线里经常用JDK17构建，但我本地默认是JDK8（某些老项目需要），这时在项目根目录执行：

code复制jdk-use 17
mvn clean package

这样本地看到的构建日志和平时的CI日志基本一致，排查问题方便很多。

第三个场景：多项目并行开发。同时打开两个终端窗口，一个切到JDK8跑老服务，一个切到JDK21跑新服务，互不干扰，因为环境变量是进程级的。这一点是setx改系统变量的方案完全做不到的。

4.4 进阶技巧：给脚本加“默认版本”记忆功能

用了一段时间后，我发现一个痛点：每次打开新终端，默认是系统的JDK版本，如果那天主要用JDK11，每次都要手动敲jdk-use 11。于是我改造了jdk-env.bat，加了一个“当前默认版本记忆”文件。

原理很简单：把每次切换的版本写到固定配置文件里，下次打开新终端时自动读取。在jdk-use.bat的末尾加一行：

bat复制echo %1 > "%~dp0.last-version"

然后在jdk-env.bat里，初始化CURRENT_JDK时先看这个文件内容：

bat复制if exist "%~dp0.last-version" (
    set /p SAVED_VER="%~dp0.last-version"
    if "!SAVED_VER!"=="8" set "CURRENT_JDK=%JDK_8%"
    if "!SAVED_VER!"=="11" set "CURRENT_JDK=%JDK_11%"
    if "!SAVED_VER!"=="17" set "CURRENT_JDK=%JDK_17%"
    if "!SAVED_VER!"=="21" set "CURRENT_JDK=%JDK_21%"
)

当然，这个记忆功能有个副作用：新打开的终端会自动使用上次切换的版本，而不是系统默认版本。如果你更希望新终端永远是系统版本，就不要加这一段，保持原状就行。这是个人习惯问题，没有对错。

5. 常见问题与排查技巧实录

5.1 切换完成后java -version还是原版本

这个问题的出现频率最高，原因十有八九是当前终端是“以管理员身份运行”的。Windows下以管理员身份运行的终端和使用者普通权限的终端，系统环境变量和用户环境变量的读取优先级不一样，而且管理员终端的某些系统级PATH项和用户级PATH项合并规则也和普通终端不同。如果你在管理员终端跑脚本，脚本里改的是当前进程的PATH，但由于管理员模式下系统环境变量本来就比用户变量有更高的“权重”，某些老的JDK路径项可能在PATH中更靠前。

我的处理方法是：切完版本后不只看java -version，还要用where java看一下实际调用的java.exe在哪个路径，确认到底是不是你切换的那个版本下的可执行文件。如果where java输出的路径是旧的，说明PATH里还有其他JDK项排在前面。可以把脚本里“在PATH最前面加入当前JDK的bin目录”这行调整逻辑，改成先把当前JDK的bin目录放到第一位，再把过滤后的旧PATH接在后面。

另外，如果你开了多个终端窗口，切版本前就要想清楚：脚本只影响执行它的那个终端进程，其他已经打开的终端还保持着旧的环境变量。这不是脚本逻辑有bug，而是Windows进程环境变量的基本工作机制。要验证这一点，可以在另一个终端敲jdk-status，看看JAVA_HOME是不是还指向旧版本。

5.2 脚本运行后中文乱码

如果你用的系统是中文Windows，而脚本文件保存时用了UTF-8编码，那么执行时输出中文会变成乱码。这是因为默认的cmd控制台代码页是GBK（代码页936），显示UTF-8编码的字符就会乱码。

最稳妥的解决办法：用系统自带的记事本打开.bat文件，另存为时选择“ANSI”编码。用ANSI编码保存的批处理文件在中文Windows上最保险，不会出现乱码。如果你喜欢用VS Code编辑批处理文件，记得在右下角把编码切换成GBK，或者干脆在文件开头加上chcp 65001切换代码页到UTF-8，但chcp切换可能会影响某些中文软件的路径显示，所以我个人推荐直接用ANSI编码保存，省事。

5.3 脚本报“系统找不到指定的路径”

这类错误通常是因为JDK目录路径写错了。比如你解压JDK后目录名带了小版本号，我脚本里写的是jdk-17，但实际目录是jdk-17.0.12，那脚本在检查bin\java.exe时自然找不到。

修起来也简单：打开jdk-env.bat，把JDK_17变量的值改成你机器上真实的路径。或者你把目录重命名成脚本里预期的名字。我个人强烈建议后者，因为目录名统一会让脚本的维护成本大幅降低。注意，如果改成脚本里预期的路径，必须保证目录名完全一致，包括大小写和不含多余空格。

5.4 切换后Maven或Gradle报“Unsupported major.minor version”

这个报错说明当前Maven或Gradle使用的JDK版本与项目要求的字节码版本不匹配。比如用JDK21编译的class文件，在JDK8环境跑就会报这个错。排查方向很明确：先jdk-use切换到项目要求的老版本JDK，再看Maven或Gradle是否正常。

有些时候Maven本身会读取JAVA_HOME环境变量来定位JDK，如果你在脚本里只改了PATH而没改JAVA_HOME，Maven可能还是按旧的JAVA_HOME找JDK。所以脚本里切版本时一定要同时更新JAVA_HOME和PATH，缺一不可。我的脚本里这两处都有对应处理。

另外提醒一个“Maven的坑”：Maven启动脚本通常在bin\mvn.cmd里用JAVA_HOME拼接路径，如果你新装的JDK是小版本号命名的目录，那JAVA_HOME的值就必须精确指向真实存在的目录，不能多一层或少一层。

5.5 想彻底删除某个JDK版本怎么办

操作不复杂，但要先把“使用该版本的窗口”全部关掉，然后在配置里做两处调整：一是从jdk-env.bat里删掉对应版本的映射变量，二是把该版本文件目录从JDK_ROOT下移除（或者改名备份）。如果该版本是系统默认版本，还要先去系统环境变量里把JAVA_HOME改到其他版本，再开新终端验证。

有一点务必注意：如果你运行过“用setx写全局版本”的脚本（这类脚本会把JAVA_HOME写入系统变量），在删除版本前先检查系统环境变量里是否还残留旧路径。我见过有人删除了JDK目录，但系统JAVA_HOME还指向旧路径，导致任何新终端都报找不到Java。处理的办法是把系统JAVA_HOME改成剩余版本路径即可。

5.6 常见问题速查表

6. 扩展思路：如何把这套脚本玩出更多花样

这套脚本本质上是一个“环境变量切换器”，只是正好用在JDK上。我后来还真把它扩展到了其他需要切换的环境变量场景，几个思路供参考。

第一个是切换不同版本的Maven。我的机器上有Maven 3.6.3和Maven 3.9.2，老项目用旧版Maven时有些插件会报错。用类似的思路写一个mvn-use.bat，无非就是把MAVEN_HOME和PATH里的maven相关项换掉。整个逻辑和JDK切换几乎一模一样，改改字符串就行。

第二个是切换不同架构的JDK。比如有些项目必须用32位JDK，有些用64位。我就在脚本里维护了x86和x64两个目录，用jdk-use -32或者jdk-use -64来切换。

第三个是给脚本加“日志”。每次切换都把时间、旧版本、新版本写进一个日志文件，方便回顾当天到底切了多少次、切到哪个版本。这对分析某些“这个版本能编译、那个版本不能编译”的诡异问题很有帮助。

第四个是结合Windows计划任务。比如每天上班前自动把JDK切到默认开发版本，省得每天第一件事就是敲命令。

这些扩展都不难，核心还是那套“环境变量切片与重组”的思路。一旦你把脚本模板写熟了，以后遇到任何需要切换的环境变量场景，基本都能十分钟之内改造出自己的一套工具。

最后还是想强调开头那句话：这个方案的真正价值不在脚本本身有多高级，而在于让你把重复、易错的手工操作变成了一个可复现、可分享的命令，换来的是几分钟的冗余操作时间，省下的是每次切错版本后排查环境变量的那种烦躁。我自己用这套方案已经一年多，再也没因为JDK环境问题耽误过正经开发。如果你也在Windows下被多JDK版本折磨，希望这篇分享能帮你少走一些弯路。