JDK8 这个版本挺有意思，明明官方早就停止免费商用支持了，但你去翻翻各类招聘要求、老项目依赖清单、还有一堆企业内训课件，它出现的频率依然高得离谱。原因不复杂：大量存量系统跑在它上面，很多中间件和构建工具对它的兼容性经过了十年以上的验证，加上语法稳定、坑位明确，团队交接成本低。所以对刚入行的朋友来说，把 JDK8 在 Windows 上装明白、配清楚，依然是一项绕不过去的基本功。
这篇内容面向的是第一次在 Windows 上手动配置 Java 环境的人，也适合那些装过但没搞懂环境变量到底在干什么、换台机器就抓瞎的朋友。我会把下载、安装、环境变量、验证、多版本共存、常见报错这几件事从头到尾讲一遍，每一步都说明白"为什么要这么做"，而不是让你照着截图点下一步。文中涉及的命令和配置都可以直接复制使用，装完之后我会给一段可运行的代码让你确认环境真的通了。
需要提前说明一点：网上很多教程只告诉你"把路径粘进 JAVA_HOME 就行"，但没告诉你路径里带空格会出什么问题、Path 里旧条目不清会怎样互相覆盖、以及为什么命令行里 java 能跑而 javac 报错。这些才是实际动手时真正卡人的地方，我会在对应章节里逐个拆开讲。
1. 装之前先想清楚：为什么是 JDK8，以及装哪个包
1.1 JDK8 在当下的真实定位
先把预期摆正。JDK8 不是一个"最新最好"的选择，而是一个"兼容性最广、存量最多"的选择。它的 Lambda 表达式和 Stream API 在当时是里程碑式的改动，至今仍是大量业务代码的主力写法；而它之后的版本在模块化、GC 策略、许可证策略上都有较大变化，老项目贸然升级往往牵一发动全身。
所以你在 Windows 上装 JDK8，通常对应三种场景：一是学习 Java 基础语法，教材和课程大多基于 8；二是接手一个已经跑了多年的存量项目，依赖锁定在 8；三是本地需要同时保留多个 JDK 版本做兼容性验证。这三种场景对安装方式的要求略有不同，后面讲多版本共存时会展开。
有一点必须提醒：JDK8 的官方免费商用支持早已结束，个人学习和内部开发一般不受影响，但如果涉及对外交付的商业项目，许可证合规需要由团队自行评估，这不是技术问题，我不在这里展开，你心里有数即可。
1.2 JRE 和 JDK 到底差在哪，别装错
这是新手第一个容易踩的坑。JRE 是运行时环境，只能"跑"Java 程序；JDK 是开发工具包，除了运行时还带编译器 javac、打包工具 jar、诊断工具 jps/jstack 等。你要写代码、要编译，就必须装 JDK，装 JRE 是不够的。
判断方法很简单：装完之后在命令行敲javac -version，能出版本号说明是 JDK；提示"不是内部或外部命令"，那多半装成了 JRE，或者环境变量没配对。这个验证动作我建议你装完立刻做，别等到写代码时才发现编译不了。
另外，现在很多发行方提供的是"JDK 包含 JRE"的整合包，安装目录下既有 bin 也有 jre 子目录，这是正常的。你只需要认准下载页面上写的是 JDK 而不是 JRE 就行。
1.3 选哪个发行版：原版与常见衍生版的取舍
JDK8 的发行来源不止一家。原版由官方提供，衍生版则是在 OpenJDK 基础上做了构建和长期维护的版本，常见的有几类：有的主打长期免费更新，有的主打性能优化，有的主打容器场景。对 Windows 本地开发来说，它们的差别其实很小，因为核心的 javac 和运行时行为是一致的。
我的建议是：如果你只是本地学习或跑存量项目，选一个你能稳定下载到、安装包完整的发行版即可，不必纠结。真正需要在意发行版差异的是生产环境的服务器部署，那涉及补丁策略和支持周期，和本地开发不是一回事。
下载时注意两点：一是认准 Windows 的 x64 安装包（现在基本没有 32 位机器了，但老设备要确认）；二是优先选.exe安装包而不是压缩包，安装包会自动处理注册表和部分系统集成，省事。压缩包版本适合不想动系统、想绿色便携的场景，后面多版本共存会提到。
2. 安装过程里那些没人明说但很关键的选项
2.1 安装路径：为什么我强烈建议不要带空格和中文
安装向导默认会往C:\Program Files\Java\...这类路径装，这个路径本身没问题，但"Program Files"中间有个空格。绝大多数现代工具能正确处理带空格的路径，但总有一些老脚本、老构建插件、以及某些命令行拼接场景会在空格处断掉，表现为莫名其妙的"找不到文件"。
我的习惯是统一装到一个短路径下，比如C:\Java\jdk1.8.0_xxx或者D:\dev\jdk8。这样做有三个好处：路径短，命令行里好敲；无空格无中文，杜绝一类低级错误；多个版本可以并列放在同一个父目录下，管理清晰。
安装时向导会让你选两次路径：第一次是 JDK 本体，第二次是 JRE（如果这个安装包带独立 JRE 的话）。两次都改到你规划好的目录下，别一个改一个不改，否则后面找起来很乱。
2.2 安装向导里那两个"可选功能"要不要装
安装过程中通常会弹出两个可选项：一个是"公共 JRE"，一个是"Java 相关浏览器插件/更新检查"之类的东西。我的处理方式是：公共 JRE 可以不装（因为 JDK 自带运行时，开发场景用不到系统级公共 JRE），浏览器插件和自动更新检查一律不装。
理由很实际：自动更新检查会在后台起服务、弹提示，干扰开发；浏览器插件在如今的环境里基本没有使用场景，装了纯属占地方。少装一个组件，就少一个将来出问题时需要排查的变量。
2.3 装完先别急着配环境变量，先确认目录结构
安装完成后，打开你选定的安装目录看一眼，正常的 JDK8 目录下应该有这些关键内容：bin目录（里面有 java.exe、javac.exe）、jre子目录（运行时）、lib目录（类库）、还有include、db等。看到bin里有javac.exe，就说明装的是完整 JDK。
这一步很多人跳过，结果后面环境变量配了半天，其实是安装包本身不完整或者装错了类型。花三十秒确认目录结构，能省掉后面半小时的排查。
3. 环境变量：三个变量各管什么，配错会怎样
3.1 JAVA_HOME：不是给系统看的，是给工具看的
JAVA_HOME指向 JDK 的根目录（注意是根目录，不是 bin 目录）。它的作用不是让命令行能敲 java，而是给各种工具提供一个"JDK 在哪"的统一入口。Maven、Gradle、Tomcat、IDEA 这些工具在启动时都会去读JAVA_HOME，然后据此定位编译器和运行时。
这就是为什么很多人遇到"命令行 java 能跑，但某个构建工具说找不到 JDK"——因为那个工具读的是JAVA_HOME，而你可能只把 bin 加进了 Path，没设JAVA_HOME。所以这个变量必须设，且值必须是 JDK 根目录。
配置路径：右键"此电脑"→属性→高级系统设置→环境变量，在"系统变量"里新建，变量名JAVA_HOME，变量值填你的 JDK 根目录，比如C:\Java\jdk1.8.0_xxx。填完不要带结尾的反斜杠，虽然多数情况能容错，但带上容易在某些拼接场景出双斜杠问题。
3.2 Path：顺序决定优先级，这是多版本冲突的根源
Path变量决定命令行敲一个命令时，系统按什么顺序去哪些目录找可执行文件。我们要把%JAVA_HOME%\bin加进去，这样 java、javac 才能被找到。
关键点在"顺序"。Path 是一个按顺序查找的列表，系统找到第一个匹配就停。如果你机器上装过别的 JDK，或者某些软件自带了一份 java.exe 并把它加进了 Path，那么谁排在前面谁生效。这就是"我明明配了新 JDK，命令行却还是老版本"的根本原因。
我的做法是：把%JAVA_HOME%\bin放在 Path 列表靠前的位置（不用非得第一个，但要排在其它 Java 相关条目之前）。同时，把 Path 里那些指向旧 JDK 的 bin 目录条目清理掉，避免它们在某些情况下抢先命中。
注意：编辑 Path 时用列表式的编辑界面逐条添加，不要手动在一长串文本里插分号，很容易多一个少一个分号导致整段失效。这是 Windows 上配环境变量最常见的翻车点之一。
3.3 CLASSPATH：现代开发基本不用配，但要知道它是什么
老教程里会让你配CLASSPATH，值写.;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar之类。这个做法在 JDK8 时代其实已经不太必要了，因为现代构建工具和 IDE 都会自己管理类路径，命令行直接跑单个类也不需要它。
我的建议是：不配CLASSPATH。如果某些老教材的示例要求你配，配的时候务必保留开头那个点号（代表当前目录），否则会出现"当前目录下的类找不到"的怪问题。但更推荐的做法是理解它、然后不配，把类路径交给工具管理。
三个变量的职责可以用一张表说清楚：
| 变量名 | 作用对象 | 典型值 | 是否必配 |
|---|---|---|---|
| JAVA_HOME | 各类开发工具、构建工具 | JDK 根目录 | 必配 |
| Path | 命令行查找可执行文件 | %JAVA_HOME%\bin | 必配 |
| CLASSPATH | Java 类加载查找路径 | 一般留空或含当前目录 | 通常不配 |
3.4 用户变量还是系统变量，选哪个
环境变量分"用户变量"和"系统变量"两层。用户变量只对当前登录账户生效，系统变量对所有账户生效。个人开发机装在自己账户下，配用户变量就够了，改坏了影响面小；如果是多人共用的机器或者需要给服务账户用，配系统变量更合适。
有一个细节：如果用户变量和系统变量里有同名变量（比如都叫JAVA_HOME），用户变量优先。所以有时候你改了系统变量没生效，是因为用户变量里还留着一个旧值把它盖住了。排查"配了不生效"时，两层都要看。
4. 验证：从命令行到一段能跑起来的代码
4.1 三个命令确认环境真的通了
配完环境变量，必须新开一个命令行窗口（已经开着的窗口读的是旧环境，改了也不生效，这是另一个高频困惑点）。然后依次执行：
java -version javac -version echo %JAVA_HOME%第一条输出运行时版本，第二条输出编译器版本，两条的版本号应该一致，且都是 1.8.x。第三条输出你设的 JDK 根目录。三条都对，环境基本就通了。
如果java -version能出结果但javac -version报"不是内部或外部命令"，说明 Path 里只有运行时没有编译器，通常是装成了 JRE，或者 Path 指向了错误的 bin。如果两条版本号不一致，说明 Path 里有多个 Java 条目，靠前的那个不是你想要的，回去清理顺序。
4.2 写一个最小可运行程序做端到端验证
命令行验证通过只说明工具能找到，不代表编译运行链路完整。我习惯再跑一个最小程序做端到端确认。新建一个文件叫HelloCheck.java，内容如下：
public class HelloCheck { public static void main(String[] args) { String javaVersion = System.getProperty("java.version"); String javaHome = System.getProperty("java.home"); System.out.println("运行时版本: " + javaVersion); System.out.println("运行时目录: " + javaHome); System.out.println("环境验证通过"); } }注意文件名必须和类名完全一致（包括大小写），这是 Java 的硬性规定，新手经常在这里栽跟头。然后在文件所在目录打开命令行，执行：
javac HelloCheck.java java HelloCheck第一条命令生成HelloCheck.class，第二条运行它。看到三行输出，说明从编译到运行整条链路都通了。这里有个细节：运行的时候写的是java HelloCheck，不带.class后缀，带上反而会报错，这也是常见困惑点。
4.3 为什么我坚持用命令行验证而不是直接开 IDE
有人会问，我都用 IDE 了，还折腾命令行干嘛。原因在于 IDE 往往会自己捆绑或配置一份 JDK，你即使系统环境没配好，IDE 里也能跑。这就导致一个假象：你以为环境配好了，换台机器或者用命令行工具时立刻露馅。
先用命令行把系统级环境验证通过，再让 IDE 去用这个环境，链路才是清晰的。将来出问题时，你也能快速判断是系统环境的问题还是 IDE 配置的问题。这个习惯值得养成。
5. 多版本共存：一台机器上同时留 JDK8 和更高版本
5.1 为什么不能靠"装两个安装包"解决
很多人以为装两个 JDK 就是装两遍，然后系统会自动处理。实际上 Windows 上多个 JDK 共存的核心矛盾就在JAVA_HOME和Path这两个变量上——它们各自只能有一个值。你装了两个版本，但环境变量只能指向其中一个，切换就得手动改，很麻烦。
正确的思路是：安装层面让多个版本各自独立存放（比如C:\Java\jdk8、C:\Java\jdk17），切换层面通过改JAVA_HOME的值来实现。因为Path里写的是%JAVA_HOME%\bin这种引用形式，只要改了JAVA_HOME，Path 自动跟着指向新版本，不用动 Path。
5.2 手动切换与脚本切换两种做法
手动切换就是每次去环境变量界面改JAVA_HOME的值，改完新开命令行生效。简单直接，适合切换不频繁的场景。
切换频繁的话，可以写两个批处理脚本，一个切到 8，一个切到 17，用setx命令改用户级变量：
:: switch-to-jdk8.bat setx JAVA_HOME "C:\Java\jdk8" echo 已切换到 JDK8，请新开命令行窗口生效:: switch-to-jdk17.bat setx JAVA_HOME "C:\Java\jdk17" echo 已切换到 JDK17，请新开命令行窗口生效setx写的是用户级变量，改完对之后新开的窗口生效，当前窗口不受影响。所以脚本执行完必须新开窗口验证，这一点要记住。另外setx有长度限制，值太长会被截断，JDK 路径一般不会触发，但心里有数。
5.3 绿色压缩包版本在多版本场景下的优势
如果你不想让安装程序往系统里写注册表、写各种集成项，可以直接用压缩包版本：解压到某个目录，然后手动设JAVA_HOME指向它即可。这种方式对系统零侵入，删掉目录就等于卸载，特别适合多版本并存和临时验证。
代价是没有自动的系统集成，所有配置都得手动来。但对已经理解了JAVA_HOME和Path原理的人来说，这反而是优点——环境完全可控，出问题好定位。
6. 那些年踩过的坑：典型报错与排查链路
6.1 "不是内部或外部命令"的三种成因
这个报错几乎是配置 JDK 时出现频率最高的。它的本质是：系统在 Path 列出的所有目录里都没找到你敲的那个可执行文件。成因通常有三种：一是 Path 里根本没加%JAVA_HOME%\bin；二是加了但JAVA_HOME本身没设或设错，导致引用展开后是个无效路径；三是加了但拼写有误，比如把 bin 写成了 bind。
排查顺序建议从内到外：先echo %JAVA_HOME%看变量值对不对，再去看那个目录下到底有没有javac.exe，最后检查 Path 里那条引用写得对不对。三步下来基本能定位。
6.2 版本对不上：Path 顺序与残留条目的排查
现象是：你明明把JAVA_HOME指向了新版本，java -version却还是老版本。原因几乎总是 Path 里存在多个 Java 相关条目，且靠前的那个指向旧版本。
排查方法：把 Path 的值完整打印出来看顺序。命令行里可以这样看：
echo %Path%输出是一长串用分号分隔的路径，从头往后找，第一个包含 java 或 jdk 的目录是谁，谁就是实际生效的那个。找到后回到环境变量界面，把多余的旧条目删掉，或者把%JAVA_HOME%\bin上移到它前面。
还有一种隐蔽情况：某些软件安装时往 Path 里塞了自己的 java 目录，名字看起来和 JDK 无关，但里面确实有 java.exe。这种只能靠逐个目录去看有没有 java.exe 来识别，比较费时，但值得做一次彻底清理。
6.3 中文乱码与编码相关的连带问题
命令行里跑 Java 程序输出中文乱码，是 Windows 上另一个高频问题。根源在于命令行窗口的默认编码和 Java 源文件的编码不一致。JDK8 的javac默认按平台编码读取源文件，而 Windows 中文环境的命令行编码和文件实际编码可能对不上。
解决办法有两个层面：一是编译时显式指定编码，javac -encoding UTF-8 HelloCheck.java；二是运行时如果输出仍乱码，可以在启动时指定-Dfile.encoding=UTF-8。更彻底的做法是把命令行窗口的代码页切到 UTF-8（chcp 65001），但这会影响该窗口内所有程序的输出，按需使用。
我的习惯是：源文件统一存成 UTF-8，编译时显式带-encoding UTF-8，这样跨机器跨环境都稳定，不依赖平台默认值。
6.4 权限与路径相关的隐性失败
有时候环境变量明明配对了，但某些程序就是读不到，或者安装时提示写入失败。这类问题多半和权限有关：改系统变量需要管理员权限，普通账户改不了；装到C:\Program Files下某些操作也需要提权。
排查思路：确认你改的是用户变量还是系统变量，改系统变量时用管理员身份打开环境变量界面；确认安装目录当前账户有读写权限。这类问题不常见，但一旦遇到很容易被误判成"配置错了"，白白浪费时间。
7. 收尾前再聊几句实操体会
装 JDK 这件事，技术含量其实不高，但它是一个典型的"细节决定成败"的场景。我见过太多人卡在环境变量上半天，最后发现只是 Path 里多了一条旧记录，或者改完没新开窗口。所以我的建议始终是：每一步都验证，别攒着一起验。装完看目录结构，配完看echo，配完 Path 看java -version和javac -version，最后跑一段代码做端到端确认。每步都确认过，出问题时你就能立刻知道是哪一步引入的。
另外分享一个小习惯：我会把自己机器的环境变量配置截图或者导出成文本存一份，换机器或者重装系统时直接对照着配，比凭记忆快得多，也不会漏。环境变量界面没有导出功能，但你可以用set命令把当前所有变量打印出来重定向到文件，作为备份参考。
最后说一句关于版本选择的话：JDK8 够用、稳定、资料多，适合打基础和跑存量项目；但如果你是在做全新项目，且团队没有历史包袱，也没必要死守 8，更高版本在语法和工具链上的改进是实打实的。工具是为人服务的，搞清楚自己为什么选它，比盲目跟风装最新版或者死守老版本都重要。
