企业官网建设流程全解析

搭过几次新机器之后你会发现，装 JDK 那五分钟从来不是问题，真正吃掉半天的是装完之后那堆看不见的活：环境变量写没写对、终端里java -version和javac -version为什么对不上、IDE 里报"找不到 JDK"、换个项目又要切回旧版本、同事照着你写的文档配了一遍结果怎么都跑不起来。这些事单独看都是小事，凑在一起就是典型的"配置税"。我后来干脆把这套流程做成一个 Java 环境配置自动化工具：给一个安装包路径，剩下的探测、落盘、写变量、验证、出错回滚全部交给程序，一条命令跑完，新机器从零到能编译不超过两分钟。下面就把这个东西的设计取舍、跨平台实现细节和实测踩过的坑完整拆一遍，适合手上有多台开发机、经常给团队新人做环境交接、或者单纯受够了手工配 PATH 的同学照着复现。

1. 手工配 Java 环境这件事，真正耗时的从来不是装 JDK

先把问题拆开看。很多人对"配 Java 环境"的理解就是下载安装包、下一步下一步、验证一下版本号。这个理解没错，但它只覆盖了整条链路的第一步。剩下几步才是返工的主要来源，而且这几步有个共同特征：它们不会立刻报错，而是延迟到某个不确定的时刻才炸，所以你很难把故障和当初那次配置动作联系起来。

1.1 让配置反复返工的五类隐性成本

我把过去几年遇到的返工场景归了个类，大概能覆盖八成以上：

这五类里面，前三类是"写错地方"，第四类是"写坏格式"，第五类是"选错包"。它们都不会在写入的那一刻给你任何提示，全部要靠后续验证才能暴露。所以自动化工具的价值不在于省掉"复制粘贴路径"这几秒钟，而在于把验证做成流程的一部分，让错误在当场暴露，而不是三天后在构建机上暴露。

1.2 一次典型的交接事故复盘

说个具体的。某团队要给新加入的几位开发者准备统一环境，负责人写了一份图文文档，步骤一共十一张截图。前两位照着做没问题，第三位卡在构建阶段，日志里是一行很普通的"找不到符号"。

排查链路是这样的：先看java -version，正常；再看javac -version，报"不是内部或外部命令"，也就是系统里只有运行环境没有编译器；确认安装包名称，发现文档里的链接指向的是运行环境版本，而前两位之所以没出问题，是因为他们电脑上原本就装着别的开发包，java命令实际找到的是那个旧版本，新装的运行环境根本没有被使用。整个事故里有两个独立的错误同时存在，而且互相掩盖——这正是手工配置最麻烦的地方，错误之间会互相遮蔽。

如果把这件事交给工具做，javac -version是必过的一项检查，第二个错误立刻就会被拦下；而"PATH 里到底哪个 java 会被优先命中"也会被显式打印出来，第一个错误也藏不住。这就是我在设计这个工具时坚持的第一条原则：所有的隐式状态都必须被显式打印出来。

2. 工具形态怎么选：脚本、安装器、还是常驻命令

确定要做，接下来第一件事是选形态。这个选择直接决定了后面所有实现细节，所以值得单独聊一章。

2.1 三种形态分别适合什么场景

我评估过三条路线：

纯脚本方案。写一份 shell 脚本加一份 PowerShell 脚本，用户按平台各跑一个。优点是零依赖、体积小、随便改；缺点是两个平台两份代码，逻辑容易分叉，而且脚本本身的可读性和错误处理能力有限，尤其是需要做"备份—写入—验证—回滚"这种带事务感的事情时，脚本会写得很勉强。

安装器方案。打成平台原生的安装包，双击下一步。优点是体验最好；缺点是打包成本高，改一行逻辑就要重新出包，而且安装器在写环境变量这件事上并没有比脚本强多少，反而多了一层黑盒。

常驻命令方案。用 Java 自己写一个命令行工具，分发成一个可执行的 jar 或者用包装脚本调用。优点是逻辑只写一遍，跨平台靠 Java 抹平；而且这个工具的用户本来就要装 Java，用它自己的生态解决它自己的问题，自洽。

2.2 为什么最终选了"以 Java 为主，脚本兜底"

我最终的结构是这样：核心逻辑全部用 Java 写，跨平台差异收拢到少数几个策略实现类里；分发时给 Windows 配一个.cmd启动器，给类 Unix 系统配一个.sh启动器，两个启动器只负责找到 java 并转发参数，不含任何业务逻辑。

这么选有三个理由。第一，这套东西的目标用户一定装了某个版本的 Java，否则他不需要这个工具，所以"用 Java 写"不构成额外的依赖负担。第二，环境变量的持久化写入本质上是一次系统 API 调用，Java 里可以用ProcessBuilder调set/export这类系统命令，也可以用平台原生命令，控制粒度比 shell 脚本更细，还方便统一做日志。第三，出错回滚需要序列化和状态管理，Java 里做起来比纯脚本舒服得多。

有一点需要提前说明：启动器里找 java 这一步本身就有坑。如果用户是第一次配环境，机器上可能压根没有 java，启动器就转不起来了。我的处理是给启动器加一条降级路径——先找JAVA_HOME，找不到就看 PATH，都没有就提示"请先用安装包手工装一个任意版本的开发包，再运行本工具"，并且明确告诉用户这一步只需要做一次。这是个产品层面的妥协，绕不开，但要说清楚。

3. 跨平台写环境变量：三套系统的三套脾气

这是整个工具里最容易翻车的一章。三个平台的持久化环境变量，机制完全不同，而且每一套都有各自的暗坑。

3.1 Windows：注册表、命令行工具与 PATH 长度

Windows 上持久化环境变量，市面上常见三种写法，差别很大：

• set：只影响当前命令行窗口，关闭即失效。绝对不能用它做持久化。
• setx：写注册表，持久化生效，但它有两个著名缺陷——单值超过 1024 字符会被截断，而且写 PATH 时会把原本的REG_EXPAND_SZ类型改成REG_SZ，导致里面原本的%SystemRoot%这类变量引用永久变成字面量，再也展开不了。这个坑一旦踩中，修复起来非常麻烦，因为原有内容已经丢失了。
• [Environment]::SetEnvironmentVariable(name, value, scope)：在 PowerShell 里调用底层 API，行为比 setx 稳妥，不会截断，也不会把类型改掉。

所以我在 Windows 分支里只用第三种，绝不碰 setx。核心代码大致是这样：

param( [Parameter(Mandatory = $true)][string]$JdkHome, [ValidateSet('Machine','User')][string]$Scope = 'Machine' ) $javaExe = Join-Path $JdkHome 'bin\java.exe' if (-not (Test-Path $javaExe)) { throw "目标目录不是有效的开发包根目录：$JdkHome" } # 1. 先备份现有 PATH，落到文件里 $stamp = Get-Date -Format 'yyyyMMddHHmmss' $backup = Join-Path $env:ProgramData "java-env-backup-$stamp.txt" $oldPath = [Environment]::GetEnvironmentVariable('Path', $Scope) $oldHome = [Environment]::GetEnvironmentVariable('JAVA_HOME', $Scope) "JAVA_HOME=$oldHome" | Out-File $backup -Encoding utf8 "PATH=$oldPath" | Out-File $backup -Append -Encoding utf8 # 2. 拆段、清掉旧 JAVA_HOME 相关段、再拼回来（保证幂等） $parts = $oldPath -split ';' | Where-Object { $_ -and ($_ -notmatch '(?i)jdk') -and ($_ -notmatch '%JAVA_HOME%') } $newPath = (@("%JAVA_HOME%\bin") + $parts) -join ';' # 3. 写入 [Environment]::SetEnvironmentVariable('JAVA_HOME', $JdkHome, $Scope) [Environment]::SetEnvironmentVariable('Path', $newPath, $Scope) Write-Host "已写入，备份文件：$backup" Write-Host "新的 PATH 前 200 字符：$($newPath.Substring(0, [Math]::Min(200, $newPath.Length)))"

几个细节值得单独点出来。第一，PATH 里优先写%JAVA_HOME%\bin这种变量引用形式，而不是绝对路径。这样以后换版本只要改JAVA_HOME一个地方，PATH 自动跟着走，不用再动长串。第二，清理旧段时用了宽松匹配，jdk和%JAVA_HOME%都当成待清理目标，因为用户历史配置里可能有各种写法。第三，备份一定要做，而且路径要打印出来，这是回滚的唯一依据。

另外还有一个容易被忽略的点：系统级变量和用户级变量会合并，合并顺序是系统级在前、用户级在后。也就是说如果历史遗留的用户级 PATH 里藏着一个旧 JDK 的 bin，它会排在系统级 PATH 后面，但如果你往系统级 PATH 前面插了新版本，反而会出现"新版优先"的假象——一旦用户换了登录账户，顺序可能又变。我的做法是两个作用域都检查一遍，发现残留就提示用户确认是否清理，不擅自删，但一定要让他知道。

3.2 macOS：版本探测与 shell 启动文件的分裂

macOS 上有两件事要处理。一是找到一个可用的 JDK 根目录，二是把变量写进正确的启动文件。

第一件事相对简单，系统自带一个版本探测器：

/usr/libexec/java_home -V

它会列出所有已安装的运行时及其版本，用它返回的路径作为 JAVA_HOME 是最稳的，不要自己拼/Library/Java/JavaVirtualMachines/...这种路径，因为不同分发版的目录结构并不统一。

第二件事才是麻烦。macOS 从某个版本之后默认 shell 换了，用户的启动文件可能是~/.zshrc、~/.zprofile、~/.bash_profile、~/.bashrc中的任意一个，写错文件的表现是"当前窗口能用，新开窗口就没了"。我的策略是：

1. 通过$SHELL判断当前 shell；
2. 找到该 shell 实际会加载的那个文件——交互式非登录 shell 读~/.zshrc或~/.bashrc，登录 shell 读~/.zprofile或~/.bash_profile；
3. 两个都写，用带标记的段落包裹，方便以后精确替换。

带标记这件事很关键。我在文件里插入的是这样一段：

# >>> java-env-managed begin >>> export JAVA_HOME="$(/usr/libexec/java_home -v 17 2>/dev/null || echo /path/to/jdk)" export PATH="$JAVA_HOME/bin:$PATH" # <<< java-env-managed end <<<

有了这对标记，重跑工具时就可以按正则把旧段落整段替换掉，而不是每次都往后追加一堆重复的 export。这是保证幂等的核心手段，比"检查 PATH 里有没有包含某字符串"可靠得多。

3.3 Linux：profile.d 与 alternatives 的分工

Linux 的服务端场景多，需要区分"给当前用户配"和"给整机配"。

给当前用户配，写~/.bashrc或者~/.profile，思路和 macOS 一致，用标记段落。给整机配，我倾向于写到/etc/profile.d/下单独建一个文件：

#!/usr/bin/env bash # /etc/profile.d/java_env.sh export JAVA_HOME="/opt/jdk/current" export PATH="$JAVA_HOME/bin:$PATH"

用独立文件而不是往/etc/profile里塞，好处是卸载时直接删文件就行，干净利落,不会把系统文件改花。注意这个文件需要可读，部分发行版还要求644权限才会被加载。

至于update-alternatives，很多教程推荐用它管理 java 命令。它确实能处理/usr/bin/java这个符号链接指向哪个版本，但它只管命令链接，不管 JAVA_HOME。而大量构建工具和框架是靠读JAVA_HOME来确定用哪个 JDK 的。所以我的做法是两者一起用：alternatives 负责让java、javac这些命令正确，profile.d负责JAVA_HOME正确。只做前者会出现"命令行版本对、构建工具版本不对"的诡异现象。

4. 一键流程的骨架：探测、落盘、写入、验证、回滚

工具的主流程我定成五段，顺序不能换，每一段都有存在理由。

4.1 探测：先确认"装进来的到底是什么"

第一步不是急着装，而是把你给的路径验明正身。判断依据不是目录名，而是实际执行一次：

public record JdkInfo(Path home, String version, String vendor, boolean hasCompiler) {} public static JdkInfo probe(Path candidate) throws IOException { Path javaExe = candidate.resolve("bin") .resolve(System.getProperty("os.name").toLowerCase().contains("win") ? "java.exe" : "java"); Path javacExe = candidate.resolve("bin") .resolve(System.getProperty("os.name").toLowerCase().contains("win") ? "javac.exe" : "javac"); if (!Files.isExecutable(javaExe)) { throw new IllegalStateException("目录下没有可执行的 java：" + candidate); } String out = runAndCapture(javaExe.toString(), "-version"); String version = parseVersion(out); // 从输出里抓版本号 boolean hasCompiler = Files.isExecutable(javacExe); return new JdkInfo(candidate, version, parseVendor(out), hasCompiler); }

这里有两点经验。第一，版本号必须从实际执行的输出里解析，不能信目录名。我见过太多目录叫jdk-17实际里面是 11 的情况，也见过解压不完整、只有空壳目录的情况。第二，hasCompiler必须单独检查。前面那个交接事故就是栽在这上面。如果检测到没有编译器，工具应该直接拒绝并给出明确提示，而不是"先配上再说"。

顺便说一句，解析java -version的输出要小心，它写到标准错误流而不是标准输出流，很多实现里只读 stdout 会拿到空字符串。这个细节我踩过一次，调了半小时。

4.2 写入与验证：验证不是可选项

写入按平台分发，前面几节已经讲透。重点说验证。

我的验证分成四层，任何一层失败都触发回滚：

第四层看起来有点重，但它是最有价值的一层。我做过统计，前三层全过但第四层失败的场景大概占百分之几，原因往往是磁盘上残留了某个tools.jar或者CLASSPATH里有一条失效路径。多花三秒，省掉一次"配完了还是跑不起来"的扯皮，非常划算。

验证必须在新的子进程里做，不能在本进程里做。因为本进程的环境变量在启动时就固定了，你在 Java 里改了系统环境变量，当前 JVM 是看不到的。必须新起一个进程，它才会继承最新的环境。这个细节如果没处理好，会出现"工具说配好了，用户开新终端却不行"的经典割裂。

4.3 回滚：备份文件就是生命线

回滚逻辑很简单，但在设计上有个细节要拿捏：粒度。

按变量粒度回滚——只恢复 JAVA_HOME 和 PATH——比整文件恢复更合理。因为 PATH 是共享资源，用户在你这段时间里可能还装了别的东西，整文件覆盖会把他刚装的工具一起干掉。

我的做法是写入前把两个变量的原始值序列化到备份文件，回滚时读出来逐个恢复：

public void rollback(Path backupFile) throws IOException { Properties p = new Properties(); try (var in = Files.newInputStream(backupFile)) { p.load(in); } envWriter.set("JAVA_HOME", p.getProperty("JAVA_HOME", "")); envWriter.set("PATH", p.getProperty("PATH")); log.info("已回滚到备份状态：{}", backupFile); }

备份文件我建议落在固定位置而不是临时目录，因为临时目录会被系统清理，等到用户想回滚的时候文件已经没了。Windows 上放程序数据目录，类 Unix 系统上放用户目录下的隐藏子目录，文件名带时间戳，只保留最近五份，多了自动删。这套规矩看着啰嗦，但真出事的时候能救命。

5. 幂等性和多版本共存，才是工具能不能长期用的分水岭

这两个特性决定了工具是"用一次就扔"还是"能长期待在你机器上"。

5.1 幂等：跑一次和跑十次结果必须一样

非幂等的工具是灾难。用户重跑一次，PATH 后面多一段重复的 bin；跑五次，PATH 长得溢出屏幕，还得手工去删。

实现幂等的关键不是"检查有没有"，而是"先清理再写入"。具体到 PATH，就是把它按分隔符拆成数组，过滤掉所有指向 JDK 的段和所有包含变量引用的 JAVA_HOME 段，再把新段插到最前面，最后拼回去。这个过程跑多少次，结果都一样。

标记段落是另一个层面的幂等。凡是我往用户配置文件里写的块，都用成对标记包起来，重写时用正则精确替换：

private static final Pattern MANAGED = Pattern.compile( "# >>> java-env-managed begin >>>[\\s\\S]*?# <<< java-env-managed end <<<", Pattern.MULTILINE); public String upsert(String content, String block) { if (MANAGED.matcher(content).find()) { return MANAGED.matcher(content).replaceFirst( java.util.regex.Matcher.quoteReplacement(block)); } return content.endsWith("\n") ? content + block + "\n" : content + "\n" + block + "\n"; }

有个容易忽略的幂等盲区：大小写和路径分隔符。Windows 上同一个路径可能有C:\Java\jdk17、C:\JAVA\JDK17、C:/Java/jdk17好几种写法，单纯做字符串匹配会漏掉。所以比较前要先Path.toRealPath()归一化，再在 Windows 上做忽略大小写的比较。这一步不做，用户重跑十次就会得到十段重复内容，因为每次都"没找到"。

5.2 多版本：符号链接比写死路径优雅太多

开发中同时存在多个 JDK 版本是常态。两种模型我都试过。

写死模型：每次切版本就重写 JAVA_HOME 为某个具体路径。简单直接，但缺点是你永远无法从环境变量看出"当前用的是哪个版本"，只能靠java -version现查，而且构建脚本里如果引用了具体路径，切完就断。

符号链接模型：所有版本解压到jdk/17、jdk/21、jdk/8之类固定目录，然后维护一个jdk/current指向其中一个，JAVA_HOME 永远写jdk/current。切版本只改一条链接，环境变量一个字节都不用动。

# 类 Unix ln -sfn /opt/jdk/jdk-21 /opt/jdk/current

# Windows，需要管理员或开发者模式 New-Item -ItemType SymbolicLink -Path 'C:\jdk\current' ` -Target 'C:\jdk\jdk-21' -Force

符号链接模型的好处是切版本变成原子操作，失败也不会留下中间状态。缺点是 Windows 上创建符号链接需要额外权限，普通账户可能会失败。所以工具里要做降级：检测到权限不足就退回写死模型，但要明确告诉用户"本次使用的是直接路径模式，切换版本需要重新运行工具"。这种降级策略是我认为对一个工具是否成熟的判断标准之一——不假设用户环境十全十美。

另外还有一个细节：切完版本之后，已经在运行的进程不会自动更新环境。IDE、终端、构建守护进程，全部需要重启。我一般在切换完成后直接打一段提示，列出"需要重启的常见程序类型"，虽然啰嗦，但能省掉大量"为什么切了还是旧版本"的追问。

6. 实测踩坑与排查链路

这一章都是真金白银换来的。

6.1 环境变量写对了，IDE 却坚称没有 JDK

现象：命令行里java -version正常，工具验证也全绿，但打开 IDE 新建项目，提示找不到开发包。

排查链路：

1. 先在终端确认java -version——正常。说明系统层面没问题。
2. 用工具自带的诊断功能打印当前 JAVA_HOME——正常。
3. 关键一步：查这个 IDE 进程到底继承了什么环境。Windows 上看进程环境需要点手段，最土但最有效的办法是任务管理器里结束该 IDE 进程，重开，问题消失。

根因：IDE 是从它启动时那一刻的父进程环境继承变量的。如果 IDE 在配环境之前就已经开着，它拿到的是旧快照，之后无论你怎么改系统变量它都不会刷新。更隐蔽的情况是：Windows 上资源管理器本身也有环境快照，某些从资源管理器启动的程序会继承这份旧快照，导致"重开 IDE 都不好使"，必须重启资源管理器进程甚至重新登录。

解决方案写进工具里：写入环境变量成功后，工具主动检测当前有没有正在运行的常见开发程序进程，有就提示"建议重启以下进程：xxx"。这个提示我原本觉得多余，实际用下来是反馈最好的功能之一。

6.2 PATH 里有个更早的版本在抢

现象：工具说配好了，java -version却显示另一个版本。

排查链路：这条链路要看全量命中，而不是只看第一条。Windows 上where java，类 Unix 系统上which -a java，把全部命中项和顺序打出来，问题一目了然。

我遇到过的真实原因包括：某个工具安装时往系统 PATH 头部插了自己的 bin；用户手动加过一条绝对路径的旧版本；还有一个比较隐蔽的——PATH 里有两条相同的段，前面的那条指向已删除目录，系统跳过它继续往后找，导致实际命中的是第三条。

工具里的处理：诊断功能输出所有命中项并标注每一项的来源（系统级还是用户级）。同时在写入阶段，只要发现任何指向 JDK 的段残留在 PATH 中，不管位置在哪，一律清理掉，只保留工具自己插入的那一条。这个策略比较强硬，所以我加了确认提示，让用户知道要删什么。

6.3 中文路径与字符集带来的连锁反应

现象：路径里有中文字符时，某些构建工具报错，或者工具自身的脚本执行失败。

根因有两层。第一层是脚本文件本身的编码。Windows 的批处理默认按系统编码解析，如果文件存成不带 BOM 的 UTF-8，里面的中文注释会让解析错位。第二层是子进程输出的编码，Java 在 Windows 上默认按系统编码读子进程输出流，遇到非 ASCII 会乱码，导致版本号解析失败。

处理方式：一是把工具的所有脚本文件统一存成带 BOM 的 UTF-8，或者干脆在脚本里只用 ASCII 字符写注释——我选了后者，最省事。二是在 Java 里读子进程输出时显式指定编码，不要用平台默认值：

ProcessBuilder pb = new ProcessBuilder(javaExe.toString(), "-version"); pb.redirectErrorStream(true); Process p = pb.start(); String out = new String(p.getInputStream().readAllBytes(), StandardCharsets.UTF_8);

三是尽量劝用户把 JDK 装到纯英文路径下，工具里做一次简单检查，发现路径含非 ASCII 字符就警告。这条不是硬性拦截，但提示的价值很大。

6.4 权限不足与安全软件拦截

现象：写入系统级变量时报"拒绝访问"，或者执行到一半进程被杀。

根因：写系统级环境变量需要管理员权限，这一点在 Windows 上尤其明显。而某些安全软件对"批量修改环境变量"这种行为比较敏感，会拦截或者延迟放行。

处理方式：工具启动时先做一次权限探测——尝试往目标作用域写一个同值的变量，捕获异常就能判断有没有权限。没权限就明确提示"请以管理员身份重新运行，或者改用当前用户作用域"。绝不静默降级，因为用户级变量和系统级变量的作用范围完全不同，静默降级会造成"我配了但别的账户用不了"的困惑。

至于安全软件拦截，我的经验是：把工具的执行过程做成有日志的，每一步都输出到日志文件。一旦被拦截，用户拿着日志能看出停在哪一步，而不是面对一个没有任何输出的黑窗口反复重试。

7. 交付前的自检清单

工具写完不算完，还得能被别人正确使用。

7.1 一份可以抄走的验收脚本

每次配完，我会跑这么一段做最终确认。它同时覆盖了环境变量的持久值和实际解析结果：

#!/usr/bin/env bash set -u fail=0 check() { local label="$1"; shift if "$@" >/dev/null 2>&1; then echo "[OK] $label" else echo "[FAIL] $label" fail=1 fi } echo "JAVA_HOME = ${JAVA_HOME:-<未设置>}" check "java 可执行" java -version check "javac 可执行" javac -version echo "--- java 的全部命中项 ---" which -a java 2>/dev/null || where java 2>/dev/null echo "--- 版本一致性 ---" jv=$(java -version 2>&1 | head -n1) cv=$(javac -version 2>&1 | head -n1) echo "java : $jv" echo "javac: $cv" if [ -n "${JAVA_HOME:-}" ] && [ -x "$JAVA_HOME/bin/javac" ]; then real=$(readlink -f "$JAVA_HOME/bin/java" 2>/dev/null || echo "") found=$(command -v java) real_found=$(readlink -f "$found" 2>/dev/null || echo "$found") if [ -n "$real" ] && [ "$real" != "$real_found" ]; then echo "[WARN] java 命令实际指向 $real_found，与 JAVA_HOME 不一致" fail=1 fi fi [ $fail -eq 0 ] && echo "=== 全部通过 ===" || echo "=== 存在失败项，请查看上方输出 ===" exit $fail

最后那段一致性检查是我后来加的，之前吃过亏：java命令和JAVA_HOME指向不同版本，平时无感，但构建工具读 JAVA_HOME、命令行读 PATH，两边行为不一致，排查起来极其痛苦。把这项做成硬性检查之后，同类问题再没出现过。

7.2 一些只有自己上手才会知道的体会

第一，诊断信息的价值远大于自动化本身。我现在回头看，这个工具真正帮我省下的时间，大部分不是来自"自动写变量"，而是来自"出问题时能一眼看到全貌"。所以如果你只做一个功能，我建议做诊断而不是自动写入。

第二，日志要写给两种人看。一种是用户，他要看到"现在在干什么、成功了没有"；一种是你自己，出问题时你需要看到子进程的完整输出、变量的前后差异、每一步的耗时。这两种需求不要合并成一个输出流，分成两个文件或者两种级别更清楚。

第三，永远不要信任已存在的状态。工具每次运行都应该把当前状态完整读一遍再决策，而不是基于"上次运行留下的记录"做增量。用户在这中间可能手工改过文件、装过别的工具、换过 shell，任何缓存都可能过期。

第四，CLASSPATH 能不设就别设。我一开始把CLASSPATH也纳入了自动配置范围，设成.;%JAVA_HOME%\lib之类。后来发现这个做法在只写.的场景下会覆盖构建工具自己的类路径计算逻辑，引发莫名其妙的问题。现在我默认不碰 CLASSPATH，只在用户显式要求时才写，并且在文档里注明风险。

第五，给回滚留一条不用命令行的路。工具出问题时用户可能连终端都打不开，所以我在备份文件旁边同时放一份纯文本的"手工恢复说明"，里面就三行：打开哪个设置界面、把哪个变量改回什么值、删掉哪个段落。这份说明救过我自己一次。

最后说个可以继续往下做的方向。现在这个工具的版本探测是基于本地已有安装包的，如果再加上"检查某个版本是否已下载、没有就按需获取并校验完整性"的能力，就能覆盖从裸机到可开发的完整链路。不过这会引入网络依赖和校验逻辑，复杂度上一个台阶，我暂时没做，等到手工确认版本来源的环节真的成为瓶颈了再说。