企业官网建设流程全解析

说实话，Windows 下做 Java 开发的人，迟早都会遇到这样一个场景：电脑上同时跑着公司老项目的 JDK 8，新项目要求的 JDK 17，再加上一个想尝鲜的 JDK 21，三个项目谁都不让谁。你打开搜索引擎找"Java 多版本管理工具"，出来的答案要么是让你改环境变量然后重启电脑，要么是推荐一个工具然后安装到一半就懵了。这篇东西想讲的，就是我在这件事上踩过的坑、试过的方案，以及现在一直在用的那套组合拳。

Java 多版本管理这件事，真正麻烦的点从来不是"装几个 JDK"，而是"让不同项目各自用对版本"。装 JDK 本身没有技术含量，下载解压、配一下环境变量，谁都会。难的是切换的成本、切换之后的一致性，以及 IDAE、Maven、Tomcat 这些周边工具到底听谁的。这篇文章面向两类人：一类是本地开发时需要频繁切换 JDK 版本的 Java 开发，另一类是刚开始接触 Java 环境配置、想弄清楚 JAVA_HOME 和 PATH 到底是什么关系的新手。看完之后，你至少能根据自己的使用习惯选出一套方案，而不是继续在"删环境变量、改环境变量、重启电脑"的循环里打转。

1. 为什么手动改环境变量，在多版本场景下必然翻车

1.1 你手头的项目早就不是一个 JDK 版本了

先说个真实工作场景。我之前在一家公司同时维护三个项目：第一个是 2016 年留下的老系统，Spring 4 + JDK 8，碰一下就可能出兼容问题；第二个是团队新起的微服务项目，JDK 17 + Spring Boot 3，代码里全是新语法；第三个是技术预研项目，想试试 JDK 21 的虚拟线程。

这三个项目在你电脑上共存的时候，问题就来了：你的 JAVA_HOME 指向 8，那 17 的项目编译不过；指向 17，老系统直接启动报错。于是大部分人开始手动切环境变量：右键"此电脑"→"属性"→"高级系统设置"→"环境变量"，把 JAVA_HOME 改成目标版本，再改 PATH，然后打开一个新的 cmd 窗口验证。一次两次还行，一周切十几次之后，你一定会崩溃。

1.2 手动切换的三个硬伤

第一个硬伤是改完不一定立即生效。Windows 下每个进程在启动时都会把当时的环境变量复制一份到自己的内存里，之后你无论怎么改系统设置，已经打开的终端、已经启动的 IDEA、已经跑着的服务都不会感知到变化。所以你会看到一个经典场景：改了环境变量，新开的 PowerShell 里java -version是新版本，但之前挂着没关的 cmd 里还是老版本。这时候你以为自己改错了，其实只是进程缓存的问题。

第二个硬伤是 PATH 里很容易残留多个 JDK 路径。我看过不少同事的 PATH，里面同时躺着C:\Program Files\Java\jdk1.8.0_202\bin、C:\Program Files\Eclipse Adoptium\jdk-17.0.10.7\bin、还有某个工具加上去的路径。where java找出来的是哪个，取决于 PATH 的搜索顺序和环境变量继承的时机，结果就是"时灵时不灵"。等你在 Terminal 里敲java -version输出 8，转头跑到 Maven 里又是 17 的时候，那种割裂感真的让人头皮发麻。

第三个硬伤是没有可追溯性。你永远记不住"当前到底用的哪个版本"。今天上午切到 17 排查问题，下午临时切回 8 给同事看老系统，结果晚上自己写代码时被UnsupportedClassVersionError教育了一顿。手动切换本质上是靠人的记忆去维持一个"本机唯一 Java 版本"的状态，这和多项目并存的现实完全不匹配。

1.3 先搞清楚 JAVA_HOME 和 PATH 到底谁在起作用

在继续往下聊之前，必须把两个概念对齐，否则后面所有方案都讲不清楚。

PATH 决定的是：你在命令行里输入java时，Windows 去哪里找 java.exe。系统会从左到右扫描 PATH 里列出的目录，找到第一个 java.exe 就执行。所以命令行里的 Java 版本，取决于 PATH 里到底谁排在前面。

JAVA_HOME 决定的是：Maven、Tomcat、Gradle 这些脚本工具认为你用的哪个 JDK。它们不直接扫 PATH，而是读取 JAVA_HOME 这个环境变量，然后在%JAVA_HOME%\bin下面找 java。很多人在命令行里看到java -version没问题，但mvn -version却提示另一个版本，原因就是 JAVA_HOME 和 PATH 指向了两个不同的 JDK。

所以多版本管理工具的终极目标，就是让这两者始终指向同一个版本。记住这句话，后面所有方案都是在想办法实现它。

2. 现有的四类切换方案，我逐个试过之后的选型结论

2.1 四类方案的自我介绍

先说网上最常见的四类方案，每一类我都实际用过，优缺点会直接说。

第一类：手动改环境变量。零成本、零依赖，但刚才说了，切换次数一多必然出问题。只适合"一年切一次"的极低频场景。

第二类：SDKMAN。Java 圈子里名气最大，但这里有一个坑很多人没注意：SDKMAN 官方并不支持 Windows 原生环境。你想在 Windows 上用 SDKMAN，得先装 Git Bash 或者 WSL，然后在那个模拟出来的 Linux 环境里用它装 JDK。这等于多绕了一层，而且它管理的是 WSL/模拟环境里的 Java，跟你 Windows 原生的 IDEA、Maven 是两个世界。如果你本来就重度使用 WSL 开发，那可以用；如果你主要在 Windows 原生环境写代码，我的建议是别折腾。

第三类：jEnv for Windows。jEnv 在 macOS/Linux 上很好用，Windows 也有社区移植版和 Git Bash 兼容版，可以用jenv add、jenv local这类命令在目录级别指定 JDK 版本。这个工具的思路其实是对的，而且符合"项目维度隔离版本"的理念。但它的问题也很现实：社区维护的活跃度一般，新 JDK 版本发布后有时需要手动添加版本目录，老一点的版本在 Windows 终端里偶尔会有字符编码问题。我用过一段时间，体验不算差，但总觉得像一个"借宿"在 Windows 上的外来工具。

第四类：scoop。这是我现在的主力方案。scoop 本身是 Windows 下的包管理器，但它对 Java 多版本的支持有一个天然优势：它通过 shim 机制来切换版本，不直接改系统环境变量，切换速度极快，而且用户级安装不需要管理员权限。配合它社区维护的 java bucket，你可以一键安装 Temurin 8/11/17/21 多个版本，然后用一条scoop reset命令切换。

2.2 方案对比，直接摆数据

为了让大家看得更直观，我做了个对比表，都是基于我自己的使用感受：

我个人的选型结论很明确：日常 Windows 原生开发，首选 scoop。它解决的是"命令行里切换版本"这个最核心的诉求，而且安装、卸载、更新 JDK 都很干净。但 scoop 有一个先天短板——它默认不主动修改 JAVA_HOME，而 IDEA 的 Maven 导入、Tomcat、Elasticsearch 这些工具又偏偏要看 JAVA_HOME。所以真正的完整方案，是 scoop 加一个目录联接技巧，把 JAVA_HOME 也管起来。这个我们放到第 5 章细说。

2.3 顺带说一下 JDK 发行版怎么选

多版本管理的另一个前置问题：你装的到底是哪个"JDK"？Oracle JDK 有许可限制，个人开发还行，公司里大规模用就要小心。开源免费的主流选择是Eclipse Temurin（Adoptium 项目）、Amazon Corretto、Microsoft OpenJDK、Azul Zulu。功能上大同小异，我默认推荐 Temurin，因为它在 scoop 的 java bucket 里覆盖最全、更新最及时、社区活跃度最高。后面所有示例都基于 Temurin。

3. 用scoop一条命令装好JDK 8、17、21，随时切换

3.1 先装上 scoop 本体

scoop 是个用户级的 Windows 包管理器，理念和 Linux 下的包管理器类似：软件装在用户目录，不用管理员权限，不污染系统注册表，卸载时删目录就完事。这也是我选择它的重要原因——你不想因为切换个 JDK 还动不动弹 UAC。

安装之前先打开 PowerShell（不需要管理员模式），执行：

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser Invoke-RestMethod -Uri https://get.scoop.sh | Invoke-Expression

第一句是放宽当前用户的 PowerShell 脚本执行策略，第二句是拉取并执行安装脚本。装完验证一下：

scoop --version

网络如果慢，多试几次。scoop 会把默认安装目录放在%USERPROFILE%\scoop下，后续 JDK 也会装在这个目录内部，与系统盘 Program Files 完全隔离。

3.2 添加 java bucket

scoop 本身只内置了一个 main bucket，里面没有完整的 JDK 版本列表。Java 相关的构建包都在社区维护的 java bucket 里，用下面的命令添加：

scoop bucket add java

添加完成后，可以先搜索一下有哪些可用的 JDK 包：

scoop search temurin

不同时间点搜索结果可能会有细微差异，但一般能看到这样的包名：

temurin8-jdk temurin11-jdk temurin17-jdk temurin21-jdk

包名细节注意：具体名字以scoop search的结果为准，因为 java bucket 的维护者偶尔会调整命名规则。你只要认准temurin这个前缀和后面的版本号就行。

3.3 安装多个 JDK 版本

多版本共存的精髓就是：一次性把所有需要的版本都装好。比如我现在装的是 8、17、21：

scoop install temurin8-jdk temurin17-jdk temurin21-jdk

scoop 会按顺序下载、解压、注册 shim。装完以后，你可以在%USERPROFILE%\scoop\apps下面看到每个 JDK 的独立目录，目录里还有一个current链接，指向当前激活的具体版本。

3.4 切换版本：一条 scoop reset 命令

切换版本是这张王牌的核心用法。想用 17 就执行：

scoop reset temurin17-jdk

想用 21 就执行：

scoop reset temurin21-jdk

执行完直接验证：

java -version

输出应该是你刚切换到的版本。这里有一个源自 shim 机制的特性：切换后新开的终端立刻生效，不需要改环境变量，不需要重启电脑，也不需要担心 PATH 里有其他 JDK 路径干扰。看到这里你可能觉得问题解决了，但真正的工作场景还差一步——JAVA_HOME 还没被管起来。

3.5 查看、升级、卸载

日常遇到的需求无非是这几种，写法也很固定：

# 查看当前已安装的所有 JDK 及激活状态 scoop list # 升级某个版本的 JDK 到最新补丁版 scoop update temurin17-jdk # 删除某个不再需要的 JDK scoop uninstall temurin8-jdk

卸载也很有意思：它会把整目录删掉，不留注册表残留。相比以前手动卸载 Oracle JDK 还得跑卸载程序、删环境变量、清理注册表，体验完全不在一个量级。

4. 切换工具背后真正起作用的三件事：PATH顺序、JAVA_HOME、进程缓存

4.1 一条命令找到你实际用的是谁家的 java

很多人在 Windows 上被多版本问题折磨，其实是没有掌握一个诊断命令：

where.exe java

它会按 PATH 的搜索顺序列出所有能被找到的 java.exe 路径。正常情况下，你希望第一条就是当前要用的 JDK。但现实往往很残酷：第一次运行你可能发现输出里有C:\Windows\System32\java.exe——这是 Windows 自带的一个"占位"启动器。如果你曾经装过带系统级配置的 Oracle JDK，它还可能把 java.exe 放在 System32 里，这个路径在 PATH 里的优先级极高，结果就是你怎么切版本都不生效。

排查一切 Java 版本问题的第一步，永远是先确认where java的第一条路径到底指向哪里。这个习惯能帮你省下后面八成的问题排查时间。

4.2 为什么新终端变了，旧终端却还是老版本

这部分是理解 Windows 多版本管理的核心：环境变量是进程启动时的快照。你启动 cmd、PowerShell、IDEA 或任何一个程序时，Windows 会把当前用户环境变量和系统环境变量合并成一份副本，交给这个进程。之后无论你通过"系统属性"改了多少次环境变量，已经跑着的进程和它派生的子进程都不会重新读取。

所以"改完环境变量要不要重启？"这个问题的准确答案是：你要重启的不是电脑，而是你依赖旧环境变量的那个进程及其父进程链。如果你从任务栏固定图标里点开 IDEA，它继承的是 Explorer 进程的环境变量快照——很多时候你改了环境变量但 IDEA 还是旧版本，就是因为 Explorer 还没刷新。传统解决办法是重启资源管理器，或者干脆注销重登。而 scoop 的方案之所以感受"即时生效"，是因为它操作的不是环境变量而是 shim 链接，新终端启动时按照 PATH 去找 shim，shim 再指向目标版本，中间没有环境变量缓存这层阻碍。

4.3 scoop reset 到底做了什么

在 scoop 的目录结构里，有一个叫shims的目录（默认在%USERPROFILE%\scoop\shims）。初次安装时，scoop 会把这个目录加进你的用户 PATH。每个通过 scoop 安装的程序，都会在这个 shims 目录里生成一个同名的小启动器 exe。

你执行scoop reset temurin17-jdk时，scoop 做的事情就是：更新shims\java.exe这个启动器的内部指向，让它去apps\temurin17-jdk\current\bin\java.exe找真正的程序。整个过程不碰 PATH、不改注册表、不产生进程环境变量缓存问题，这也是它为什么能够在多个 JDK 之间"秒切"。

4.4 双轨不一致的隐患：Maven 认 JAVA_HOME，不认 shim

看到这里你会意识到一个关键缺口：scoop 管理的只是命令行里的java，但Maven 的 mvn.cmd 脚本启动时会优先读取 JAVA_HOME 环境变量，Tomcat 的 catalina.bat 同样如此。如果 JAVA_HOME 还指向系统里某个旧 JDK，而命令行里java -version已经切到新版本，那 mvn、Tomcat 就会用旧 JDK 启动，造成一种"分裂"状态。

这就是为什么很多人在用 scoop 之后仍然遇到"感觉切换了，但项目里还是旧版本"的原因。单纯靠 scoop，解决不了 GUI 程序、构建工具对 JAVA_HOME 的依赖。那就得引入下一个技巧：用目录联接把 JAVA_HOME 变成一个"可切换的固定入口"。

5. 我的组合拳：用目录联接固定JAVA_HOME，让所有程序都认对版本

5.1 设计思路：让 JAVA_HOME 永远指向同一个路径

这个方案的思路很朴素：既然 Maven、Tomcat、IDEA 的 Maven 导入都读 JAVA_HOME，那我就让 JAVA_HOME 永远指向同一个路径——比如C:\Users\你的用户名\.java\current。这个路径本身不是一个具体的 JDK 目录，而是一个目录联接（Junction），它指向你当前想用的那个 JDK 的实际目录。

切换版本时，不需要修改 JAVA_HOME 环境变量本身，只需要把这个 Junction 删除、再重新指向另一个 JDK。这是把"多版本切换"收敛为一个"切换一个固定入口"的操作。

这个思路和很多"环境管理工具"（包括前面提到的 jEnv for Windows）的原理本质上是相同的，只是我们用 Windows 原生的目录联接来完成，不依赖额外运行时的适配层。

5.2 具体步骤：创建目录联接并配置统一环境变量

先创建目录联接的载体：

# 1. 在用户目录下建一个 .java 文件夹 mkdir "$env:USERPROFILE\.java" # 2. 创建 Junction，指向当前想用的 JDK（先切到 17 来演示） mklink /J "$env:USERPROFILE\.java\current" "$env:USERPROFILE\scoop\apps\temurin17-jdk\current"

注意，这里我用的是mklink /J，它创建的是目录联接（Junction），在 Windows 上不需要管理员权限。不要用mklink /D创建符号链接（Symbolic Link），那个通常需要管理员权限或开发者模式。

接下来修改用户环境变量：

JAVA_HOME = C:\Users\你的用户名\.java\current

同时在 PATH 的最前面加上：

%JAVA_HOME%\bin

这样设置之后，命令行里的java会优先从 JAVA_HOME 里找，Maven 的 mvn.cmd 也会直接用 JAVA_HOME，两边永远一致。以后切换版本，只需要改 Junction 指向。

5.3 一键切换脚本：一条命令重定向

为了方便，我把切换操作封装成一个 PowerShell 函数，放在 $PROFILE 里：

function java-use { param([string]$Version) # 1. 用 scoop 重置命令行 shim（可选，但能保证 PATH 里其他工具也统一） scoop reset "temurin${Version}-jdk" # 2. 删除旧的目录联接 $link = "$env:USERPROFILE\.java\current" if (Test-Path $link) { cmd /c rmdir "$link" } # 3. 创建新的目录联接 $target = "$env:USERPROFILE\scoop\apps\temurin${Version}-jdk\current" if (-not (Test-Path $target)) { Write-Error "JDK $Version 未安装，请先执行 scoop install temurin${Version}-jdk" return } cmd /c mklink /J "$link" "$target" # 4. 当前会话立即生效（同时刷新 JAVA_HOME 和 PATH） $env:JAVA_HOME = $link $env:Path = "$link\bin;" + $env:Path # 5. 验证输出 java -version Write-Host "JAVA_HOME: $env:JAVA_HOME" }

以后切换就变成这样：

java-use 8 java-use 17 java-use 21

脚本里故意在删除 Junction 时用了cmd /c rmdir，这里有一个实际的坑要提醒你：在 PowerShell 里对 Junction 使用Remove-Item -Recurse有风险，某些版本下可能会递归删除目标目录里的真实文件。所以删除目录联接时，最稳妥的方式就是用cmd /c rmdir，它只会移除 Junction 这个链接本身，不会动目标文件夹。

5.4 这套方案解决了什么、还有什么需要注意

这套方案最大的价值，是把"命令行版本"和"JAVA_HOME 版本"彻底统一了。IDEA 导入 Maven 项目时读到的 JAVA_HOME 是对的，Tomcat 启动时找的 JDK 是对的，你随手打开一个 PowerShell 敲java -version也是对的。一切都是因为大家都在同一个入口%JAVA_HOME%上"汇合"。

它也有边界：IDE 里已经打开的项目不会因为你切换 Junction 而自动换 SDK。IDEA 项目 JDK 是记在项目配置里的，从.idea目录到workspace.xml，都有各自的 SDK 引用。所以切换到新版本后，老项目可能需要重新打开或者在 Project Structure 里手动指向新 SDK。好在 IDEA 提供了多 SDK 管理，这个下一章讲。

6. 配合IDEA、Maven和中间件，多版本管理才能算完整方案

6.1 IDEA 里的多 SDK 管理

IDEA 本身不依赖系统的 JAVA_HOME 来运行，它自带一个 JetBrains Runtime。所以哪怕你电脑上 Java 环境一团糟，IDEA 也能正常启动。真正受影响的是项目编译、Maven 导入、Gradle 同步这些环节。

正确做法是在 IDEA 里显式维护一份 SDK 列表，然后让每个项目选自己要的版本：

1. 打开File→Project Structure（快捷键Ctrl+Alt+Shift+S）。
2. 在左侧选择Project，右侧可以设置当前项目的SDK和Language level。
3. 选择SDKs，点+→Add JDK，把C:\Users\你的用户名\.java\current或具体 JDK 目录添加进去。

你可以把 8、17、21 全部加进去，IDEA 会记住每个 SDK 的路径和版本号。这样老项目用 SDK 8，新项目用 SDK 17，互不干扰。即使命令行里已经全局切到 17，IDEA 里的老项目依然可以用 8 编译，不会出现"切了版本整个 IDAE 都乱套"的情况。

另一个容易踩的坑在 Maven 设置里：Settings→Build Tools→Maven→Runner，这里有一个JRE选项，用于确定 Maven 运行时的 JDK。如果你导入一个老项目，它默认选了项目 JDK，那没问题；但如果选的是"Use Project JDK"且项目 SDK 是 17，而项目本身是老 Spring 4 代码，编译时就会报错。建议把这里的 JRE 设置成你希望 Maven 实际使用的 JDK，并且和项目 SDK 保持一致。

6.2 Maven 场景下的版本匹配

Maven 项目本身在 pom.xml 里也会声明编译版本。常见的是：

<properties> <maven.compiler.source>1.8</maven.compiler.source> <maven.compiler.target>1.8</maven.compiler.target> </properties>

这种写法只影响 javac 的 source/target，但如果你用高版本 JDK 编译老代码，还是会出现各种 API 兼容问题。更现代的做法是用<release>：

<properties> <maven.compiler.release>17</maven.compiler.release> </properties>

release参数会同时约束 source、target 和 API 版本，避免出现"用 Java 17 编译出来的字节码带着 Java 8 没有的 API 调用"。

如果你的一个项目里确实需要同时用到多个 JDK，比如编译产物要在 JDK 8 上运行、但某些构建插件需要 JDK 17，那就要配置 Maven Toolchains。在~/.m2/toolchains.xml里把 JDK 都列出来，然后在 pom 里通过maven-toolchains-plugin指定。这是相对进阶的场景，大多数人用不到，但知道有这个东西，等遇到时就不会慌。

6.3 中间件和脚本工具对 JAVA_HOME 的依赖

Tomcat 的catalina.bat启动时会去找JAVA_HOME或JRE_HOME，找不到就在 PATH 里找java。Gradle 启动时也会优先认JAVA_HOME，之后才看你项目里的org.gradle.java.home。

我在实际使用中发现，只要你把 JAVA_HOME 用第 5 章的 Junction 方案管理好，Tomcat、Gradle 基本不需要额外配置，因为它们都会顺着 JAVA_HOME 找到正确的 JDK。只有少数自带独立 JVM 的工具，比如 Elasticsearch，它启动时优先用ES_JAVA_HOME（如果有的话）或者内置的 JDK，再退回 JAVA_HOME。如果 Elasticsearch 报"Java version mismatch"这种错误，检查一下这几个变量的顺序，基本就能定位原因。

6.4 Git Bash 和 Windows Terminal 的表现差异

Windows Terminal 本身不缓存环境变量，新开标签就会读到最新的用户环境变量，所以配合 Junction 方案体验很好。Git Bash 里使用的java也来自 PATH，但注意它读取的是 Windows 的环境变量，所以不会有"Unix 和 Windows 两套 Java"的问题。唯一要注意的是，在 Git Bash 里写路径要用/c/Users/xxx/.java/current这种格式，是 IDAE 和 Windows 程序之间路径风格差异的老生常谈，跟多版本管理本身关系不大，不展开。

7. 我踩过的几个环境版本坑，以及现在的固定切换流程

7.1 故障一：Maven 用的 JDK 和 java -version 对不上

有段时间我执行scoop reset temurin17-jdk，命令行里java -version明确输出 17.0.10，但mvn -version里显示的却是 Java 8。排查过程很顺利——我直接看了 JAVA_HOME，发现它还指向系统里手动装的 JDK 8。这就是"命令行版本"和"JAVA_HOME 版本"双轨不一致的典型症状。解决办法就两条：要么把所有依赖 JAVA_HOME 的工具都改成读取where java的结果（不现实），要么让 JAVA_HOME 跟着一起切（就是第 5 章的方案）。这事也让我彻底放弃了"只靠 scoop 不设 JAVA_HOME"的偷懒做法。

7.2 故障二：IDEA 报 invalid source release 17

很经典的一个问题。项目 SDK 明明选了 17，IDEA 编译时却报invalid source release 17。我在网上翻了一圈，答案五花八门，但真正原因通常是IDEA 里 Maven Runner 的 JRE 设置和项目 SDK 不一致。具体来说，如果你在 IDEA 的 Maven 设置里把 Runner JRE 固定成某个低版本 JDK，那么即使项目 SDK 是 17，Maven 编译时依然用那个低版本 JRE 启动，结果自然匹配不上。排查思路：先看Settings → Build Tools → Maven → Runner → JRE，再看项目 SDK，两个版本要一致，问题一般就没了。

7.3 故障三：一切正常，但 Elasticsearch 启动就报版本不符

遇到过 Elasticsearch 7 要求 JDK 8，但我全局切到 17 后启动报错的情况。原因是 ES 启动脚本会优先检查ES_JAVA_HOME，然后才是JAVA_HOME。我之前手动配置过ES_JAVA_HOME指向一个 JDK 8 目录，后来那个目录卸载了，但环境变量还在，导致它读取了一个不存在的路径，然后回退失败。处理方式很直接：把ES_JAVA_HOME删掉，或者让它明确指向已安装的 JDK 8 目录。这以后我的原则就是：不轻易设置各个工具专用的独立 JAVA_HOME 变体，都让它统一走全局的 JAVA_HOME，否则变量多了必然出乱子。

7.4 我现在固定的换机、开发和切换流程

现在在一台全新 Windows 上配 Java 开发环境，我的操作顺序基本固定了：

1. 装 scoop，添加 java bucket。
2. 一次性安装所有可能用到的 JDK 版本：scoop install temurin8-jdk temurin17-jdk temurin21-jdk。
3. 创建.java\currentJunction，指向当前的默认版本。
4. 设置 JAVA_HOME 指向这个 fixed 路径，PATH 最前面加上%JAVA_HOME%\bin。
5. 把java-use函数写进 PowerShell $PROFILE。
6. IDEA 里把各项目需要的 SDK 都添加一遍，Maven Runner 的 JRE 跟项目 SDK 对齐。
7. 每个项目的 README 里注明"本项目要求 JDK 版本"，需要切换时执行java-use 对应的版本号。

这套流程走一遍大概二十分钟，之后基本不会再被环境问题打断。

7.5 一点个人体会

Windows 下做 Java 多版本管理，纠结"哪个工具最强"其实不是核心，核心是理解PATH、JAVA_HOME、进程环境变量缓存这三者之间的关系。你理解了它们，任何工具在你手里都只是表达这种理解的载体；不理解，换再多工具也是同一个坑换着花样踩。scoop 加目录联接这套组合，我用了两年多，稳定性是经过验证的。如果你现在还在被"切换 Java 版本要重启电脑"折腾，不妨照着第 3 章和第 5 章先搭一套，跑通之后，你会回来谢我的。