企业官网建设流程全解析

简介：JDK11在Windows 64位平台上的压缩免安装版，面向Java开发者、运维人员以及需要在无管理员权限环境下快速搭建Java开发或运行环境的用户，省去传统安装流程，解压配置JAVA_HOME与PATH即可直接使用。资源共423个文件，压缩包约171.44MB，包含83个dll动态库、72个jmod模块文件、40个exe命令行工具、安全证书、策略配置、源码和release信息等，覆盖运行库、模块系统、工具链与安全策略，便于按需查看JDK内部组成。作为长期支持版本，JDK11带来了模块化系统、HTTP Client API、文本块、G1/ZGC垃圾收集器增强等特性，本包对这些特性所需的模块与配置文件均完整保留，适合桌面开发、学习新语法或临时环境调试。目前已有1825人学习下载，对于希望快速获得完整JDK11免安装环境并深入理解其目录结构的读者，是一份可直接部署落地的实用资源。 不知道还有没有人记得，JDK 11 是 Oracle 在 2018 年 9 月发布的长期支持版本，直到现在，很多中小公司、传统 IT 系统的生产环境依然跑在 JDK 8 或 JDK 11 上。之前在一个新项目上需要本地快速搭一套 JDK 11 环境，当时图省事用了 exe 安装包，点完一轮向导后以为万事大吉，结果过了两周因为要切多个 JDK 版本，折腾得脑壳疼。后来改成 JDK 11 window64 压缩免安装版，也就是 .zip 包，从解压到配好环境变量只要几分钟，而且换版本、拷贝到别的机器都很自由。今天这篇文章就把这套折腾过很多次的操作流程写透，涉及下载渠道、环境变量细节、命令行 still 1.8 的排查思路，以及多版本共存的一些实用经验。

这篇文章适合两类人看：一类是刚入门 Java，需要在本机配置第一套 JDK 环境的；另一类是身边有好几个 JDK 版本在来回切换、经常被环境变量坑到的老开发。放心，整个过程不复杂，只要跟着一步步来，基本不会再出现"配了但没生效"这种鬼问题。

1. 为什么推荐压缩免安装版：三个真实场景

先回答一个很多人会问的问题：官网明明有 exe 安装包，一键下一步不香吗？为什么要费劲去解压 zip？

1.1 zip版和exe安装版的本质区别

exe 安装版做的事情比较多：把 JDK 文件复制到指定目录、写注册表、往C:\Windows\System32塞java.exe/javaw.exe/javaws.exe、注册卸载信息、甚至可能帮你设置JAVA_HOME和PATH。听起来很省事，但它同时给你的系统留下了大量"看不见的状态"，一旦你后面想换版本、卸载重装、或者让两个版本共存，这些隐藏状态就会出来捣乱。

而压缩免安装版本质上就是一堆文件的集合，整个 JDK 的全部内容都打包在 zip 里。你把它当作一个普通压缩包解压到某目录，然后通过手动配置环境变量让系统知道它的位置。系统里没有任何隐藏的注册信息，想换版本就把解压目录删掉，干净利落。

1.2 压缩版在三个场景下的明显优势

第一个场景是多版本共存。开发老项目要用 JDK 8，新项目要用 JDK 11，偶尔又要试试 JDK 17。zip 版直接解压三个目录，切换时改一下环境变量就行；而 exe 版装三个版本在系统里，光注册表那堆项就够你喝一壶。

第二个场景是快速迁移环境。比如你换了一台新电脑，或者要帮同事搭一套一模一样的开发环境。zip 版直接拷贝目录过去，配置好环境变量，完成。不需要重新走一遍安装向导，更不需要重新下载安装包。

第三个场景是CI/CD 和服务器环境。我现在打包、跑自动化测试的机器基本都是 zip 版 JDK，因为这些机器不想有太多"安装痕迹"，出了问题也能快速回滚到之前的 JDK 目录版本。

补充一句，如果你在 Linux 环境遇到的是 rpm 包或者 yum 安装的场景，思路类似但不在本文范围内，本篇只说 Windows 64 位平台的 zip 破解方式。

2. 下载JDK 11的渠道与文件校验

2.1 下载渠道怎么选

JDK 11 的下载渠道主要有下面这几个，我实际下载对比过，直接说结论：

如果你从 Oracle 官网下载，在页面里要勾选Accept License Agreement，然后选择 Windows x64 的.zip体积版本，文件名大致是jdk-11.0.xx_windows-x64_bin.zip。注意别粗心选了.msi，那两个是完全不同的东西。

阿杜明（Adoptium）这个渠道在国内访问题速度比较快，它的下载链接直接指向 GitHub Release，可以选择OpenJDK11U-jdk_x64_windows_hotspot_11.0.xx_x.zip。我个人更推荐 Adoptium，因为它的版本更新节奏很稳，而且完全开源免费。

如果你在的机房或公司网络访问海外资源很慢，用清华 TUNA 镜像站或阿里云镜像也可以，那边通常有稳定的 JDK 版本归档。

2.2 解压后的目录结构变化

拿到 zip 包后，解压到某个目录，我一般放在D:\Java\下，解压出来的目录名类似jdk-11.0.21。这个时候你会发现，JDK 11 的目录结构和 JDK 8 相比有不小变化：

• bin：可执行文件，包括java.exe、javac.exe等
• conf：JDK 9 以后新增的配置目录，java.security、logging.properties都在这里
• include：本地方法开发用的 C 头文件
• jmods：JMOD 格式的模块文件，这个也是 JDK 9 引入模块系统后出现的
• legal：许可证和版权信息
• lib：类库和运行时所需文件

有一个明显的差异是，JDK 11 解压之后没有 JRE 目录。以前 JDK 8 会自带一个 jre 目录，你可以在没有 JDK 的机器上只拷贝 JRE 来跑 Java 程序。JDK 11 之后，官方不再提供独立的 JRE 安装包，如果你确实需要一个瘦身运行时环境，可以基于jlink命令自己裁剪，这个过程后续我找时间单独写一篇，这里就不展开了。

另一个需要留意的点是，解压路径不要带中文和空格。虽然大多数情况下带空格也能用，但很多脚本（Maven 的某些插件、批处理工具）在解析路径时会出幺蛾子。我之前见过有人把 JDK 解压到D:\Program Files (x86)\Java\jdk-11，结果 IDEA 里反编译插件直接失效，改成D:\Java\jdk-11.0.21之后就正常了。

解压工具方面，Windows 自带资源管理器就能解压 zip，但如果你解压的路径层级比较深或者目录名很长，建议用 7-Zip、Bandizip 或 NanaZip，遇到长路径问题会少一些。

3. 环境变量配置：JAVA_HOME与PATH的正确写法

解压完成之后，真正决定"命令行能不能找到java"的，就是环境变量了。很多教程一上来就让你配，却不解释为什么这么配，导致很多人只会照着敲，一出问题就不会排查。

3.1 配置的思路：设 JAVA_HOME，再用它去拼接 Path

在 Windows 上正确且通用的做法是配置两个环境变量：

1. 新建系统变量JAVA_HOME，值为 JDK 解压后的完整目录，比如：

   D:\Java\jdk-11.0.21

2. 在系统变量Path中新增一行：

   %JAVA_HOME%\bin

为什么要把JAVA_HOME单独拆出来，而不是直接把D:\Java\jdk-11.0.21\bin写进 Path？原因主要有两点：

• 切换方便：以后要换 JDK 版本，只需要把JAVA_HOME改成另一个目录，Path 里那个%JAVA_HOME%\bin不需要动。
• 第三方工具依赖：Maven、Tomcat、Gradle、IDEA 等大量中间件会去读JAVA_HOME这个环境变量来定位 JDK，即使你没把bin加进 Path，它们也能工作。

注意，JAVA_HOME的值末尾不要加反斜杠。如果你写成D:\Java\jdk-11.0.21\，某些工具拼接路径时会出现双反斜杠或工具解析错误。这个细节常年有人踩。

3.2 配系统变量还是用户变量

Windows 环境变量分系统变量和用户变量两类。同样是配置JAVA_HOME，放哪一层有讲究：

• 系统变量：对这台机器的所有用户生效，修改需要管理员权限。
• 用户变量：只对当前用户生效，修改不需要管理员权限。

我平时的习惯是配在系统变量里，这样无论是当前账号还是其他账号登录，JDK 都是可用的。如果你只是自己在普通权限下开发，配用户变量也不是不行，但有些 IDE 和命令行工具在检测 JDK 时只读系统变量，偶尔会遇到工具找不到 JDK 的情况，所以干脆统一配系统变量最省事。

另外注意，修改系统变量之后，已经打开的 cmd/PowerShell 窗口不会自动刷新，必须新开一个终端窗口才能让改动生效。这个坑排在最常见问题前三名。

3.3 CLASSPATH 到底要不要配

网上很多老教程会告诉你还要配一个CLASSPATH环境变量，内容是.;%JAVA_HOME%\lib;%JAVA_HOME%\lib\tools.jar。这个在 JDK 5、JDK 6 那会儿确实必要，因为那时候 JVM 不会自动加载当前目录的类，需要手动指定。

从 JDK 1.5 开始，classpath的默认值就已经包含了当前目录（.），JDK 9 引入模块系统之后，tools.jar也不在原来位置了。所以JDK 11 的压缩版配置，完全不需要设置 CLASSPATH。你配了反而可能干扰 IDE 和构建工具，让它们以为某些 jar 在固定路径，结果找不到。

4. 刚配完就翻车：命令行还是1.8的完整排查链路

配完了，环境变量也都填进去了，然后在 cmd 里输入java -version，结果屏幕上跳出来的还是java version "1.8.0_xx"，瞬间心态崩了。这个情况可以说是 JDK 11 配置里最经典的问题，也是搜索引擎里的高频问题。下面直接带你走一遍排查链路。

4.1 第一步：定位当前生效的 java.exe 到底来自哪里

在命令行里执行：

where java

这个命令会列出所有出现在PATH中的java.exe的位置，按照 Path 顺序从上到下排列。Windows 在执行命令时，就按照这个顺序找到第一个匹配的 exe 并运行。

所以如果你看到输出第一条是：

C:\Windows\System32\java.exe

那就说明你的java -version调用到的根本不是新配置的 JDK 11，而是 System32 目录里的这一个，跟JAVA_HOME没关系。

4.2 第二步：确认 Path 的优先级与 System32 的埋伏

Windows 里，修改环境变量实际上是把系统 Path 和用户 Path 拼接在一起，系统变量在上，用户变量在下。C:\Windows\System32通常在系统 Path 里而且位置很靠前。

问题就在这：如果你以前安装过 JDK 的 exe 版，安装程序会往C:\Windows\System32里放三个文件——java.exe、javaw.exe、javaws.exe。它们就像三颗钉子一样钉在那里，而由于 System32 的优先位置，无论你怎么改JAVA_HOME，命令行都会先命中它们。

遇到这种情况，有两条路：

• 如果旧版 JDK 是通过 exe 安装的，先到"控制面板-程序卸载"里把旧 JDK 卸载掉，通常这种情况下 System32 下的残留也会被清理。
• 如果卸载完了where java还列出 System32 路径，手动去C:\Windows\System32下检查并删除java.exe、javaw.exe、javaws.exe这三个文件。删除前建议备份一下，毕竟这是系统目录。

提示：System32 是管理员目录，删除操作需要以管理员身份的 cmd 或文件管理器执行。

4.3 第三步：检查注册表里的版本指向

除了文件，exe 安装版还会在系统里留下注册表项。打开regedit，定位到：

HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment

如果机器上曾经装过 32 位的 JDK，还需要检查：

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\JavaSoft\Java Runtime Environment

看CurrentVersion的值指向哪个版本。如果是1.8，而你在 System32 下的 java.exe 又不在了的话，部分依赖注册表查询的工具（比如某些旧版 IDE 和脚本）还是会认为系统当前 JDK 是 1.8。

处理方法：可以把不需要的旧版本注册表项删掉，或者把CurrentVersion改成 JDK 11 对应的值。当然，如果你就是想让某些工具识别到其他版本，保持旧值也不是不行，关键是要清楚这一点。

4.4 修复后的完整验证流程

排查完之后，怎么确认这次真的换过来了？我最常用的验证命令是这三条：

echo %JAVA_HOME% java -version javac -version

如果输出分别指向你的 JDK 11 解压路径、11.0.xx和javac 11.0.xx，一般就稳了。再用where java看一下路径列表，第一条应该变成你的%JAVA_HOME%\bin\java.exe。

最后，务必开一个新的 cmd 窗口再验证，因为已经开的终端不会重新加载环境变量。如果你需要在当前窗口立刻生效，可以执行：

set JAVA_HOME=D:\Java\jdk-11.0.21 set Path=%JAVA_HOME%\bin;%Path%

这两条只对当前窗口临时生效，适合快速测试，关掉窗口就没了。

5. 多版本JDK共存的日常使用经验

搞定了 JDK 11，很多人下一个问题就是：我机器上还有 JDK 8，真的要全局只留 JDK 11 吗？当然不需要。zip 免安装版给了你更灵活的多版本共存方案。

5.1 用切换脚本管理多个 JDK

我自己在D:\Java目录下放了多个版本的 JDK 目录：

D:\Java\jdk-8u202 D:\Java\jdk-11.0.21 D:\Java\jdk-17.0.9

然后在同一个目录写几个切换脚本，比如切换到 JDK 11 的脚本setjdk11.bat：

@echo off set "JAVA_HOME=D:\Java\jdk-11.0.21" set "PATH=%JAVA_HOME%\bin;%PATH%" echo 已切换到 JDK 11 java -version

切换到其他版本就是把JAVA_HOME改成对应目录。注意这个脚本改的是当前 cmd 会话的环境变量，不会影响系统全局，非常适合在同一个终端里快速切换测试。如果你希望永久切换，就需要去"系统属性"里改全局JAVA_HOME。

这里有个常见的坑：用setx命令在命令行里设置环境变量，比如setx Path "%Path%;%JAVA_HOME%\bin"，如果Path里的内容本身很长（一般超过 1024 字符），setx写入注册表的时候会截断，导致部分 Path 配置丢失。所以优先级最高的还是图形界面的环境变量编辑器，它没有长度限制，或者用setx时只设置一个中间变量再引用。

5.2 与 IDEA、Maven 的配合细节

IDEA 这个 IDE 有点特殊：它启动时会读取系统JAVA_HOME来决定自己的 JVM，但每个项目也可以单独指定 Project SDK。这意味着你在 IDEA 里既可以跑 JDK 11 的项目，也可以跑 JDK 8 的项目，互不干扰。哪怕系统JAVA_HOME指到了 JDK 11，某个项目依然可以选择jdk-8u202目录作为 SDK，完全不需要改动全局配置。

Maven 也有自己的脾气：mvn -v会优先读取JAVA_HOME环境变量，如果找不到，再回去用java命令。如果你在 Maven 里构建 JDK 11 项目时出现奇怪的编译错误，可以先用mvn -v看一下当前 Maven 使用的是哪个 JVM 版本，很多时候就是因为JAVA_HOME指到了旧版本而 Maven 自己没报错。

注意：切换 JDK 版本后，Maven 的maven-compiler-plugin还受项目pom.xml里的<source>和<target>控制。也就是说，哪怕你系统JAVA_HOME已经切到 JDK 11，如果 pom 里还写着1.8，编译结果依然会按 JDK 8 语言级别生成字节码，这不冲突，但要注意区分。

最后再分享一个小技巧：如果你经常要在一个 cmd 窗口里反复切换 JDK 版本，可以把上面那个切换脚本放到系统 Path 的某个目录里，比如D:\Tools\Scripts，这样你在任意路径都能直接输入setjdk11或setjdk8来切换，省去每次 cd 到D:\Java的步骤，实测下来这类小批处理在 Windows 开发机上非常实用。

本文还有配套的精品资源，点击获取