企业官网建设流程全解析

1. 先搞清楚：为什么现在还有人要装 JDK8

打开任何一个后端招聘帖，或者是老项目的部署文档，你会发现一个很奇怪的现象：2024 年了，新项目都在讨论 JDK17、JDK21，可偏偏有一大批系统还在 Windows 上用着 JDK8。这不是谁偷懒，而是现实决定的。JDK8 是 Java 历史上生命周期最长的一个版本，2014 年发布，到 2030 年前后都还有商业支持版本在跑，大量企业内部的中间件、老框架、定制化组件，都建立在 JDK8 的语言特性和运行机制之上。你把它换成高版本，轻则启动报错，重则字节码不兼容、反射被模块系统拦住，排查成本高得离谱。

所以我写这篇东西，不是教你"点下一步"就完事，而是把这件看起来简单的事讲透。Windows 安装 JDK8这件事，表面是下载一个安装包、配两个环境变量，真正容易翻车的点在于：选哪个发行版、装 32 位还是 64 位、JAVA_HOME 和 Path 到底谁管谁、机器上已经有别的 JDK 怎么办、命令行显示版本不对怎么查。这些问题在搜索引擎上答案零散而且互相矛盾，很多人配了半小时环境变量，最后卡在java -version打印出另一个版本上。

这篇文章适合三类人看：第一类是完全没接触过 Java 环境配置的新手，想一次装对不折腾；第二类是手上维护着老项目、需要在同一台 Windows 机器上让 JDK8 和 JDK17 和平共处的开发者；第三类是帮同事、帮客户远程装环境的技术支持人员，需要一套能复现、能抄作业的标准流程。全文基于 Windows 10 和 Windows 11 的实测，Windows Server 2016 及以上同样适用，涉及命令的地方我都会给出可直接粘贴的内容。

在动手之前，我建议你先在心里回答一个问题：这台机器上的 JDK8，是"唯一版本"还是"多个版本之一"？答案不同，后面的配置策略完全不一样。很多教程只讲单版本装法，等你后面要装第二个 JDK 时，环境变量一团乱，只能重装系统级别的折腾。所以下面的内容我会两套都讲，并且告诉你为什么。

1.1 JDK8 到底"老"在哪，又强在哪

先说清楚概念，避免新手把 JDK 和 JRE 混为一谈。JRE 是运行环境，只有java命令，能跑 class 文件但不能编译；JDK 是开发工具包，包含 JRE 外加javac、jar、javadoc、jps、jstack这些工具。你要做开发，必须装 JDK；如果只是运行别人打包好的程序，装 JRE 理论上够用，但实际工作中我建议一律装 JDK，因为排查问题时jps、jstack、jmap这些工具是你唯一的救命稻草，缺了它们线上问题只能靠猜。

JDK8 相对 JDK7 最大的变化，是引入了 Lambda 表达式和 Stream API，让 Java 第一次有了像样的函数式写法。还有接口默认方法、方法引用、Optional 类、全新的日期时间 API（java.time），以及把永久代 PermGen 换成了元空间 Metaspace。这最后一条尤其重要：以前 JDK7 跑久了报java.lang.OutOfMemoryError: PermGen space，是无数人的噩梦，JDK8 之后这个错误基本消失了，取而代之的是元空间溢出，排查思路完全不同。如果你在维护老系统，看到 PermGen 相关的报错，那说明机器上跑的其实不是 JDK8，或者是 JDK8 但参数里还留着-XX:MaxPermSize，这种情况下 JVM 会直接警告参数无效。

还有个细节很多人不知道：JDK8 的file.encoding在 Windows 上默认跟随系统区域设置，中文环境就是 GBK。而 JDK9 之后默认改成了 UTF-8。这就导致同一个项目，在 JDK8 上读文件正常，换到 JDK11 上中文全乱码。反过来也一样。所以当你在 Windows 上装 JDK8 时，编码问题一定要提前意识到，不要等程序跑出乱码才回头找原因。

1.2 哪些场景非 JDK8 不可

我列几个实际遇到过的场景，你对照看看自己是不是其中之一。第一，公司内部的 ERP、OA、财务系统，用的是十年前的框架，比如 Struts2 加 Spring 3，这些框架在高版本 JDK 上会直接抛异常。第二，某些国产中间件、老版本的 Tomcat 7 或者 WebLogic，官方支持的 JDK 上限就写死在 8。第三，大数据生态里，Hadoop、Hive、Spark 的早期版本对 JDK8 依赖很深，虽然新版本已经支持 11 和 17，但存量集群升级成本极高。第四，教学和考试环境，很多高校的 Java 课程、软考、认证考试仍然以 JDK8 为基准。

第五，也是最现实的一条：你接手了一个没人敢动的项目，能跑就行，别的事以后再说。这种时候，正确的做法不是"顺便升级一下"，而是老老实实把 JDK8 装好，先让系统稳定运行，升级的事单独排期评估。我见过太多人抱着"顺手升一升"的心态，把一个本来只是环境缺失的问题，变成了两周的兼容性改造。

注意：如果这台机器是生产服务器，装 JDK8 之前一定要确认应用当前的 JDK 版本和启动参数，别想当然认为"肯定是 8"。用java -version和jps -lvm确认清楚，再动手。

2. 下载前的三个决定：发行版、位数、安装包类型

很多人一上来就搜"jdk8下载"，点进第一个结果，下载、装完，然后发现装的是 JRE，或者装完是 32 位版本，内存上限被卡在 1.5G 左右，跑什么都慢。这三个决定必须在下载之前想清楚，否则后面全是返工。

2.1 选哪个发行版：别只盯着一个来源

JDK8 的发行版有好几个来源，各有各的适用场景。我整理成表格，你按自己的情况对号入座。

选哪个？我的经验是：**开发机优先选带 exe/msi 安装器的版本，省心；服务器和需要频繁切换版本的机器，优先选 zip 压缩包版本，可控。**压缩包版本不写注册表、不碰系统目录，解压即用，删掉就是卸载干净，这对需要多版本共存的机器来说是最优解。

至于从哪下载，原则很简单：认准发行方的官方站点或者其官方代码托管仓库的发布页。第三方下载站的安装包我强烈不建议用，一是版本可能是被改过的，二是很多下载站会捆绑东西，三是你无法验证文件完整性。这一点在给客户装环境时尤其重要，出问题你没法解释。

2.2 32 位还是 64 位：这个问题比你想象的严重

2024 年了还有人装 32 位 JDK，通常是因为看了一篇年代久远的教程。判断方法很简单：在 Windows 上打开"设置 - 系统 - 关于"，看"系统类型"这一行，写的是"基于 x64 的处理器"就装 64 位，写的是"基于 x86"或者"32 位操作系统"才装 32 位。现在还在跑 32 位 Windows 的机器，基本都是十几年前的老设备或者某些工控机。

为什么强调这个？因为 32 位 JVM 的堆内存上限受地址空间限制，实际上你能给的最大堆通常在 1.5G 到 2G 之间，再大就启动不了。而 64 位 JVM 只要物理内存够，几十 G 的堆都能给。如果你在一个 16G 内存的机器上误装了 32 位 JDK，然后按教程配了-Xmx4g，结果就是 JVM 直接起不来，报Could not reserve enough space for object heap，新手很容易以为是内存不够，其实是位数错了。

确认当前已装 JDK 位数的方法：命令行执行java -version，如果输出里有64-Bit Server VM，就是 64 位；只写Client VM没有 64-Bit 字样，那多半是 32 位。这是最快的判断方式。

2.3 校验文件完整性：一个被忽略的好习惯

从官网下载的文件，如果网络不稳定，有可能下载不完整，装到一半报错，或者装完了运行异常。养成校验的习惯能省很多时间。发行方一般会提供 SHA256 校验值，Windows 上用 PowerShell 一条命令就能算出本地文件的哈希：

Get-FileHash -Algorithm SHA256 "C:\Users\你的用户名\Downloads\jdk-8uXXX-windows-x64.exe"

把输出的哈希值和官网公布的值比对，一致就放心装。不一致就重新下载。这一步大概花 10 秒，但能挡掉一类莫名其妙的安装失败。

提示：如果官网只给了 MD5，用Get-FileHash -Algorithm MD5也行。哈希值不区分大小写，比对时不用纠结字母大小写。

3. 安装实操：从双击安装包到环境变量配好

进入正题。下面按"安装器版本"这一条主线讲，因为它涉及步骤最多，坑也最集中，讲完再补压缩包版本的做法。

3.1 图形化安装：每一步都在做什么

双击安装包，第一个界面是欢迎页，直接下一步。第二个界面是安装路径，默认是C:\Program Files\Java\jdk1.8.0_XXX，后面还有一步问你 JRE 装哪里，默认是C:\Program Files\Java\jre1.8.0_XXX。

路径要不要改？我的建议分两种情况。如果你这辈子只打算在这台机器上装这一个 JDK，默认路径完全没问题，别折腾。如果你确定以后会有多个 JDK 版本共存，那从一开始就把安装目录规划好，比如统一放在C:\Java\下面，每个版本一个子目录：

C:\Java\jdk1.8.0_202 C:\Java\jdk-17.0.9 C:\Java\jdk-21.0.1

这样做的好处是，所有 JDK 在同一层级，切换版本时只需要改一个环境变量值，不用去翻"Program Files"里那一堆名字相似的目录。而且路径里没有空格，写脚本的时候不用处理引号转义，少一类奇怪的问题。

安装过程中的两个小坑：

第一，安装器会顺便装一个 JRE，并且往系统 Path 里塞一个C:\ProgramData\Oracle\Java\javapath的条目。这个目录里放的是java.exe、javaw.exe、javac.exe的转发程序，它总是指向"最后安装的那个 JRE"。这就是很多人装完 JDK8 又装了 JDK17 之后，java -version显示的不是自己想要的那个版本的根源。记住这个条目，后面排查要用。

第二，安装路径里绝对不要出现中文和空格之外的怪字符，尤其不要放在桌面或者中文命名的文件夹下。JVM 在解析类路径时对非 ASCII 字符的处理在 JDK8 上并不完美，有些场景会出问题，没必要给自己找麻烦。

安装完成后，安装器会提示成功。但此时打开命令行执行java -version可能会成功，javac -version却提示找不到命令，因为安装器配了 Path 但没配 JAVA_HOME，而且不同版本安装器的行为不一致。所以下一步的环境变量配置必须自己动手。

3.2 JAVA_HOME、Path、CLASSPATH：三个变量的分工

这三个变量的关系，用一个比喻就明白了。JAVA_HOME 是"JDK 住在哪"，Path 是"系统去哪儿找可执行文件"，CLASSPATH 是"java 命令去哪儿找要加载的类"。很多人配错，是因为把 JAVA_HOME 和 Path 的职责搞混了。

先说 JAVA_HOME。它的值是 JDK 的安装根目录，不带\bin：

变量名：JAVA_HOME 变量值：C:\Java\jdk1.8.0_202

为什么要设这个变量？因为大量第三方工具依赖它：Maven、Gradle、Tomcat 的启动脚本、各种 IDE 的项目配置，都会去读 JAVA_HOME 来决定用哪个 JDK。你如果不设，这些工具要么报错，要么用系统里第一个找到的 java，结果不可控。

再说 Path。Path 里要加的是 JDK 的 bin 目录。这里有一个关键选择：**写绝对路径C:\Java\jdk1.8.0_202\bin，还是写%JAVA_HOME%\bin？**我强烈建议后者。原因是切换 JDK 版本时，你只需要改 JAVA_HOME 一个变量的值，Path 不用动。如果你写的绝对路径，以后每换一次版本就得改一次 Path，改漏了就会出现"JAVA_HOME 是 17，java -version 显示 8"这种诡异现象。

Path 中新增：%JAVA_HOME%\bin

操作路径：右键"此电脑"→ 属性 → 高级系统设置 → 环境变量。注意要区分"用户变量"和"系统变量"。对于个人开发机，配在用户变量里就够了，改动即时生效且不需要管理员权限；如果是多人共用的服务器，配在系统变量里，这样所有账户都能用。切换版本的灵活性上，用户变量更占优势，因为你可以给不同用户配不同版本。

最后说 CLASSPATH。**我的建议是：不要设，或者只设一个点号.。**网上大量老教程让你设.;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar，这在 JDK8 上完全没必要，因为这两个 jar 里放的是老式的 Java 类库，现代 JDK 的类加载机制已经不需要显式指定。而如果你设错了 CLASSPATH，比如丢了开头的点号，会导致java HelloWorld找不到当前目录的类，报Could not find or load main class，新手排查这个错误能耗掉一下午。不设 CLASSPATH 时，JVM 默认就是当前目录，最省事。

注意：如果机器上已有 CLASSPATH 变量且里面还有别的内容，不要在原有内容上乱加，先备份一份值再改。删掉别人配的东西可能导致其他软件出问题。

3.3 验证：四条命令确认装对了

环境变量改完，必须重新打开一个新的命令行窗口，因为已经打开的窗口继承的是旧的环境变量，改了也不会生效。这是新手最常犯的错误，改完发现没用，以为是配置错了，其实是窗口没重开。

新开一个 cmd 或 PowerShell，依次执行：

java -version javac -version echo %JAVA_HOME% where java

逐条解释结果应该是什么样。java -version正常输出类似：

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)

注意这里显示的版本号是1.8.0_XXX，而不是8.0.XXX，这是 JDK 的历史遗留命名，两者是同一个东西，不要以为自己装错了。第二行如果出现64-Bit，说明位数正确。

javac -version应该输出javac 1.8.0_202。如果这条报"不是内部或外部命令"，说明 Path 没配好，或者配的是 JRE 的路径而不是 JDK 的路径。JDK 的 bin 目录里一定有javac.exe，去目录里看一眼就能确认。

echo %JAVA_HOME%应该原样打印你设的路径。如果打印出%JAVA_HOME%本身，说明变量没设成功，检查是不是把变量设到了另一个作用域（用户变量和系统变量设混了）。

where java会列出系统里所有能找到的 java.exe，按 Path 顺序排列。**这条命令是排查版本冲突的利器。**正常情况下应该优先列出你配的C:\Java\jdk1.8.0_202\bin\java.exe。如果第一行是C:\ProgramData\Oracle\Java\javapath\java.exe或者C:\Windows\System32\java.exe，那就是被抢了，需要把 Path 里%JAVA_HOME%\bin的条目上移到这些条目之前。

3.4 压缩包版本的做法：解压即用

如果你下载的是 zip 包（很多发行版只提供这种），流程更简单但要更细心。解压到一个没有空格和中文的目录，比如C:\Java\jdk8u202，注意解压后的目录结构，很多压缩包解压出来会多一层目录，比如jdk8u202-b08\jdk8u202-b08\bin，这种情况下 JAVA_HOME 要指向真正含 bin 的那一层。

然后配环境变量的步骤和上面完全一样。区别在于：压缩包版本不在系统里注册任何东西，也不会有 javapath 这类干扰项，所以where java通常非常干净，只有你自己配的那一个。对需要精细控制版本的场景来说，这是优点。

卸载也很简单：把环境变量里的相关条目删掉，然后把目录删掉就完事了，不留垃圾。相比之下，安装器版本卸载后可能残留注册表和 javapath 目录，还得手动清理。

提示：解压类 JDK 建议在目录名里保留完整的版本号，比如jdk8u202、jdk8u392，这样以后装了多个 8 的小版本时，一眼能分清哪个是哪个，不用去翻 release 文件。

4. 多版本共存：让 JDK8 和 JDK17 不打架

这部分是很多人真正需要的。一台机器上同时有 JDK8 和 JDK17，怎么做到想用哪个用哪个，而不是改一次环境变量重启一次。

4.1 不要直接改 Path，改用切换策略

最笨的办法是：用 JDK8 时把 Path 改成 8 的 bin，用 JDK17 时改成 17 的 bin，每次改完重启命令行。能用，但费劲，而且容易忘。更好的做法是分层：

第一层，把每个 JDK 的版本变量单独定义好，互不干扰：

JAVA8_HOME = C:\Java\jdk1.8.0_202 JAVA17_HOME = C:\Java\jdk-17.0.9 JAVA21_HOME = C:\Java\jdk-21.0.1

第二层，定义一个总的 JAVA_HOME，它的值引用上面某一个：

JAVA_HOME = %JAVA8_HOME%

第三层，Path 里只写%JAVA_HOME%\bin。这样切换版本时，你只需要把 JAVA_HOME 的值从%JAVA8_HOME%改成%JAVA17_HOME%，全局就是一致的。改完之后新开窗口验证即可。

这种做法的好处是，所有依赖 JAVA_HOME 的工具（Maven、Gradle、IDE、Tomcat 脚本）都会自动跟着切，不会出现"命令行是 8，IDE 里是 17"这种分裂状态。我见过太多项目因为 IDE 和命令行用了不同 JDK，编译出来的 class 版本对不上，报Unsupported major.minor version 52.0或者61.0，这类错误只要版本统一就不会出现。

4.2 用脚本做单次会话级切换

上面改的是系统级变量，影响所有新开的窗口。如果你只是临时想用另一个版本跑一下，不想改全局配置，可以在脚本里做会话级覆盖。写一个 bat 文件，双击就直接进入使用 JDK8 的命令行：

@echo off set "JAVA_HOME=C:\Java\jdk1.8.0_202" set "PATH=%JAVA_HOME%\bin;%PATH%" echo JAVA_HOME set to %JAVA_HOME% java -version cmd /k

这段脚本的逻辑很直白：把 JAVA_HOME 临时设置成 JDK8 的路径，然后把它的 bin 目录拼到当前 Path 的最前面，这样本次会话里java命令优先找到的就是 JDK8。最后一句cmd /k保持窗口不关闭，方便你继续在里面敲命令。

把这段保存成use-jdk8.bat放在桌面或者放一个专门的工具目录里，同理再做一份use-jdk17.bat。需要哪个版本就双击哪个，互不影响，也不污染系统环境。这个技巧我在处理跨版本兼容性验证时用得特别多，比如要确认"这个 API 在 JDK8 上能不能编译通过"，直接开一个 JDK8 会话编译一遍，再开一个 JDK17 会话编译一遍，两分钟就能得出结论。

PowerShell 用户可以用这段来做永久设置（需要管理员权限）：

[Environment]::SetEnvironmentVariable("JAVA_HOME", "C:\Java\jdk1.8.0_202", "Machine")

第三个参数 "Machine" 表示系统变量，换成 "User" 就是用户变量。设置完同样要新开窗口才生效。

4.3 验证多版本切换是否成功

切换之后不要只看java -version就完事，把这三条都跑一遍：

特别强调第三行。我遇到过一种情况：java 命令已经是 JDK17 了，但 javac 还是 JDK8 的，原因是某次操作在 Path 里额外加了一个绝对的 bin 路径，导致两个版本混在一起。这种状态下编译出来的 class 是 52.0，用 JDK17 的 java 运行会直接报版本不支持的错。所以每次切换后三条一起验，养成习惯。

还有一个隐蔽的干扰源：C:\Windows\System32\java.exe。某些软件会在安装时往这里放一个 java.exe。系统目录在 Path 里的优先级通常很高，所以偶尔会出现明明配了 JAVA_HOME，where java第一行却是 System32 的情况。解决办法是把%JAVA_HOME%\bin移到 Path 列表的最上方，或者干脆把系统目录里那个 java.exe 重命名备份（前提是确认没有别的软件依赖它）。

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

下面这些是我在实际操作中反复遇到过的，按"症状—原因—处理"的结构整理，你可以当速查表用。

5.1 命令行提示"不是内部或外部命令"

这是最高频的问题。先按顺序排除四个可能。第一，命令行窗口没有重新打开，用的是改环境变量之前的老窗口。第二，Path 里写的是绝对路径但路径本身写错了，比如把jdk1.8.0_202写成了jdk1.8.0_20。第三，配置的是用户变量，但当前命令行是以另一个用户身份运行的（比如管理员权限的窗口对应的是管理员账户的环境变量）。第四，装的其实是 JRE，bin 目录里根本没有 javac.exe。

排查顺序建议：先去文件资源管理器里打开你配的路径，确认java.exe和javac.exe都在。在的话，再看环境变量里 Path 的条目是否完整。都不行就重开窗口再试。这三步能解决 95% 的此类问题。

5.2 java 版本和预期的对不上

where java输出多行，第一行不是你配的那个，就是被抢了。常见的抢占者有：C:\ProgramData\Oracle\Java\javapath\（Oracle 安装器写的）、C:\Windows\System32\、其他软件自带的 JRE 目录。

处理方法是打开环境变量里 Path 的编辑界面，从上往下看，找到%JAVA_HOME%\bin这一条，把它上移到所有其他 java 相关条目的前面。Windows 的 Path 是按顺序查找的，谁在前面用谁。如果 Path 太长看不到全貌，可以点"编辑文本"按钮切换到文本模式，看清楚顺序再调整。

注意：Path 编辑界面的"编辑文本"模式下，每一行是一个路径，不要给路径加引号，也不要留空行。加引号会导致整个路径失效，这是个非常隐蔽的坑。

5.3 中文乱码怎么处理

JDK8 在 Windows 上默认编码跟随系统区域，中文系统就是 GBK。如果你的程序读写的文件是 UTF-8 编码，就会乱码。临时解决办法是在命令行先执行chcp 65001把代码页切成 UTF-8，再运行程序。但这个只对当前窗口有效，而且某些老程序在 65001 代码页下会输出异常。

更稳妥的做法是启动时显式指定编码：

java -Dfile.encoding=UTF-8 -jar your-app.jar

如果希望永久生效，可以设一个环境变量JAVA_TOOL_OPTIONS，值为-Dfile.encoding=UTF-8。这个变量的好处是 JVM 启动时会自动读取，不用每次改命令。缺点是它会在启动时打印一行"Picked up JAVA_TOOL_OPTIONS"提示，看着有点烦，但不影响使用。

还有一个相关参数是-Dsun.jnu.encoding=UTF-8，它控制的是文件名的编码。这两个参数一起用时，能覆盖绝大多数中文乱码场景。不过要注意，JDK8 上改编码不如 JDK9 之后干净，某些场景依然会跟随系统，所以最根本的办法还是统一下项目里的文件编码和运行环境编码。

5.4 安装包双击没反应或中途失败

这种现象在 Windows 11 上比以前多。可能的原因有几个。一是安装包被安全软件拦截了，去安全软件的拦截记录里找找看，或者临时关闭实时防护再装。二是临时目录权限问题，安装器需要往%TEMP%写文件，如果那个目录权限异常就会卡住，可以用管理员身份运行安装包试试。三是下载的文件不完整，回到第 2.3 节的哈希校验步骤验证一下。四是系统里的某个残留服务占用了文件，重启后重装通常能解决。

另外还有一种情况：安装到一半报"错误 1723"或类似的 MSI 错误，多半是 Windows Installer 服务状态异常。这种时候重启电脑再装，或者用msiexec /unregister和msiexec /regserver重新注册一下服务，成功率很高。

5.5 装完了但程序起不来：几个方向

如果java -version一切正常，但你的 jar 或者 Tomcat 起不来，问题通常不在 JDK 安装本身，而在下面几个方向。检查启动脚本里有没有硬编码的 JAVA_HOME 路径指向一个不存在的目录，这在迁移或者拷贝项目时极其常见。检查有没有-Xmx之类的内存参数超过了物理内存减去系统占用后的可用值。检查端口是否被占用，Web 应用常见的 8080、8005 冲突会直接导致启动失败。

还有一个容易被忽略的点：JDK8 的 Metaspace 默认没有上限，如果某个应用疯狂生成动态类（比如大量使用反射、字节码增强的框架），会出现元空间持续增长直到耗尽机器内存的情况。这类问题的表现是程序运行一段时间后响应变慢、机器内存吃紧，日志里不一定有明显报错。处理方式是加参数限制：-XX:MaxMetaspaceSize=256m，然后观察是否稳定。

提示：排查 JVM 层面的问题，jps -lvm能列出当前机器上所有 Java 进程及其启动参数，jstack <pid>能打印线程栈，jmap -heap <pid>能看堆内存分布。这三个命令都在 JDK 的 bin 目录里，前提是你装的是 JDK 而不是 JRE。

6. 装完之后，值得马上做的几件事

环境装好只是起点，下面这几件事做了，能让你后面少走很多弯路。

第一件，写一个最小的 Hello World 跑通全流程。不要觉得多余，这能一次性验证 javac 和 java 两个命令、编码、类路径三个环节。新建一个HelloJDK8.java，内容如下：

public class HelloJDK8 { public static void main(String[] args) { System.out.println("JDK version: " + System.getProperty("java.version")); System.out.println("Java home: " + System.getProperty("java.home")); } }

在文件所在目录执行：

javac HelloJDK8.java java HelloJDK8

java.home输出的路径会告诉你当前实际用的是哪个 JDK 的运行环境。这个信息在多版本环境下特别有用，比java -version更准确，因为它打印的是 JVM 自己认定的主目录。

第二件，把常用的构建工具一并配好。如果项目用 Maven，注意 Maven 自己也会读 JAVA_HOME，所以只要 JDK 切对了，Maven 通常不用额外配置。但如果你需要针对某个项目固定 JDK 版本，可以在maven-compiler-plugin里显式声明 source 和 target 都为 1.8，这样即使有人用 JDK17 跑构建，编译出来的也是 8 的目标版本。当然这只解决编译层面，运行时还是得用 8。

第三件，给环境留一份记录。在C:\Java\下面放一个README.txt，写清楚每个目录对应哪个版本、什么时候装的、用在哪个项目上。这个习惯听起来有点多余，但当你半年后接手一个没人维护的机器，看到这份记录，会非常庆幸。我自己维护的几台构建机上都放了这个文件，同事接手时能省掉大量摸索时间。

第四件，考虑把 JAVA_HOME 和 Path 的配置导出备份。用setx命令可以，或者直接截图存一份。Windows 的环境变量界面看起来能看全，但实际上长 Path 会被折叠，出问题时不容易发现。导出一份文本备份，出问题能快速对照。

最后再说个实际体会。JDK8 在 Windows 上的安装本身并不复杂，复杂的是它经常出现在一个已经有其他 JDK 的机器上，而大部分教程默认你是从零开始的。所以我在任何一台新机器上装 JDK 之前，都会先花两分钟执行where java、java -version、echo %JAVA_HOME%三条命令，摸清现状再动手。这个两分钟的投入，比事后排查版本冲突省下的时间多得多。另外，如果你是要给一台长期运行的服务器装环境，尽量选压缩包版本放在统一的目录下，别用安装器，因为安装器版本在多用户、多版本场景下带来的隐性耦合太多，卸载时还可能留下 javapath 那种干扰项，后续维护的人会骂人。这些都是踩过坑之后才明白的，写下来给后面的人省点事。