JDK 和 Maven 在 Windows 下的安装和配置算是 Java 开发里最基础但也最容易出幺蛾子的一环。不少新手甚至工作一两年的同事都可能在环境变量、版本兼容这些地方卡过壳。这篇文章就把我多年来在 Windows 上折腾 JDK 和 Maven 的经验完整梳理一遍从下载到配置从原理到踩坑一步步讲清楚争取让你看完就能一次搞定。1. 环境准备与版本选型思路1.1 先搞清楚 JDK 和 Maven 各自扮演什么角色在动手下载之前先把这两个东西的角色理清楚后面配置起来思路会顺畅很多。JDK 是 Java 开发工具包它不光包含 Java 运行时环境还带了编译器、调试工具、打包工具等一系列开发必需品。你可以把 JDK 理解为生产 Java 程序的整套工厂而 Maven 则是工厂里的自动化流水线管理员。Maven 本身也是用 Java 写的所以它的运行依赖 JDK必须先装 JDK 再装 Maven这个顺序不能反。Maven 解决的核心痛点有两个。第一个是依赖管理以前做 Java 项目要把各种 jar 包手动下载、复制到 lib 目录版本冲突更是噩梦Maven 通过仓库机制你只需要在配置文件里声明依赖它自动帮你下载和管理。第二个是标准化构建编译、测试、打包、部署这一整套流程Maven 用约定的生命周期统一搞定。搞清楚这两层关系你就明白为什么网上教程都要求先配好 JAVA_HOME再配置 MAVEN_HOME因为 Maven 启动时会去找 Java 环境找不到就直接报错退出。1.2 如何选择合适的 JDK 版本Windows 下选 JDK 版本我见过太多人在这里踩坑。选版本不能只看最新更要看你的项目需求。目前市面上主流的有 Java 8、Java 11、Java 17 这几个 LTS 长期支持版本Java 21 也已经发布。如果你的项目是维护老系统Java 8 是绝对主流很多传统企业的遗留系统还停在 JDK 8 上如果是新项目建议至少 Java 11 起步能上 Java 17 就直接上因为 Java 17 在性能、语法、垃圾回收器方面都有明显提升。还有一个容易被忽略的问题Oracle JDK 和 OpenJDK 的抉择。Oracle JDK 从 Java 8u211 版本开始个人使用免费但企业商用需要付费授权OpenJDK 则完全开源免费。对绝大多数开发者来说选 OpenJDK 或者基于 OpenJDK 的发行版比如一些社区维护的版本完全够用没必要为了心理安慰去冒险用 Oracle JDK 商用。我个人的建议是去 OpenJDK 官网或者靠谱的镜像站下载选 LTS 版本对应 Windows x64 的 .zip 或 .msi 安装包都可以。zip 版更灵活卸载时直接删文件夹msi 版会自动配好注册表和环境变量省事但不够透明。我自己习惯用 zip 包因为配置过程完全可控也方便多版本切换。1.3 Maven 版本搭配的原则Maven 版本的选择相对简单核心原则是Maven 3.6.x 以上版本兼容 JDK 8 到 JDK 17Maven 3.9.x 对 JDK 17 和 JDK 21 支持更完善。如果你用的是 JDK 8 环境也不要刻意用老版本 Maven3.6.3 以上都没问题。Maven 官网提供 Binary zip archive 和 Binary tar.gz archive 两种格式Windows 下直接下 Binary zip archive。下载页面看准 .zip 后缀的包别下成 Source 包那个是源码不能直接运行。这里有个很多人不知道的小细节Maven 不需要安装程序解压即用。整个 Maven 就是一个文件夹只要把路径配好它就能跑起来。这种绿色软件的好处是你可以同时保留多个 Maven 版本随时切换。1.4 目录规划与多版本共存思路强烈建议你在 C 盘以外的盘符建一个统一的开发工具目录比如D:\devtools\然后分别创建D:\devtools\jdk和D:\devtools\maven目录把解压后的文件放进去。为什么特意强调目录规划因为 Windows 下最容易出的问题就是路径里有空格或中文。比如你把 JDK 装到C:\Program Files\Java\jdk-17这个路径虽然能用但在某些老旧脚本、批处理文件里空格就会引发奇怪的问题。更别用中文目录名少数框架和插件在解析路径时遇到中文会直接乱码。多版本共存的做法也很简单用不同的文件夹名区分版本比如D:\devtools\jdk8和D:\devtools\jdk17需要切换时只需修改 JAVA_HOME 环境变量指向目标目录。这个思路同样适用于 Maven如果你有老项目必须用 Maven 3.5完全可以保留两个 Maven 目录。2. JDK 安装与核心配置详解2.1 JDK 解压安装的正确姿势以 zip 包为例说明安装流程。下载完成后用解压工具解压到D:\devtools\jdk目录。解压完成后你会看到一个类似jdk-17.0.8的文件夹里面是 bin、conf、include、jmods、legal、lib 这些子目录。如果你是下载的 .msi 安装包双击安装时会自动解压到系统目录并配置环境变量。但这里我要多说一句msi 安装方式虽然省事但它生成的环境变量配置比较隐蔽后期如果你想改路径或者换版本反而要多几步操作。zip 包完全手动控制出问题也好排查。解压完成后先验证一下目录结构是否正确。打开文件夹找到bin目录里面应该能看到java.exe和javac.exe这两个最关键的可执行文件。千万注意如果你在 bin 里找不到javac.exe说明你下载的不是 JDK而是 JRE那样没法编译 Java 代码。2.2 环境变量配置的底层逻辑真正让无数人困惑的是环境变量配置。这里我把原理讲透你就不会再被各种教程绕晕。Windows 环境变量分用户变量和系统变量两种。系统变量对所有用户生效修改它需要管理员权限用户变量只对当前用户生效不需要额外权限。开发工具的环境变量配置在用户变量里就够用没必要动系统变量这样更安全。需要配置的核心是三个变量JAVA_HOME指向 JDK 安装目录Path在原有值的基础上追加 JDK 的 bin 目录CLASS_PATH早期教程会配置这个现在其实不需要了打开环境变量编辑器的方法右键此电脑→属性→高级系统设置→环境变量。在用户变量区域点击新建变量名填JAVA_HOME变量值填你的 JDK 目录路径比如D:\devtools\jdk\jdk-17.0.8。注意JAVA_HOME 一定要指到 JDK 的具体版本目录而不是只到 jdk 这一层。很多工具包括 Maven、Tomcat、Gradle依赖这个变量来定位 Java 环境如果你指错了层级后面全都会报错。然后找到 Path 变量点击编辑。Win10 和 Win11 的环境变量编辑器是列表形式的直接点新建添加%JAVA_HOME%\bin即可。这里特意用%JAVA_HOME%来引用而不是写完整路径这样以后切换 JDK 版本时只需要修改 JAVA_HOMEPath 不用动。至于CLASS_PATH我明确建议你不需要配置。这个东西是 JDK 1.4 时代的遗留产物。现代 JDK 和构建工具会自动处理类路径配置了反而可能干扰项目运行。网上有些老教程还在教人配 CLASS_PATH直接跳过就行。2.3 验证 JDK 是否配置成功配置完环境变量最关键的一步是验证。先关掉所有已经打开的命令行窗口重新打开一个新的 cmd 窗口依次执行两个命令java -version javac -version如果输出类似这样的结果说明 JDK 配置成功java version 17.0.8 2023-07-18 LTS Java(TM) SE Runtime Environment (build 17.0.89-LTS-211) Java HotSpot(TM) 64-Bit Server VM (build 17.0.89-LTS-211, mixed mode, sharing)如果提示不是内部或外部命令一般有两种可能一是 Path 变量没配置正确二是修改完环境变量后没有重开 cmd 窗口。老版本的 cmd 窗口在启动时读取环境变量之后修改的变量不会自动生效必须新开窗口才能加载最新的环境变量。还有一种情况是 java -version 能显示但 javac 提示找不到。这种情况通常是你的 Path 里同时存在多个 Java 的路径系统优先找到了 JRE 而不是 JDK 的 bin。排查方法很简单执行where java命令它会列出所有被找到的 java.exe 路径看看排第一个的是不是你刚才配置的那个。2.4 实战小测试写一个 Hello World 确认编译链完整环境变量配好不等于万事大吉最好再实际编译运行一次程序确认整条链路通畅。在任意目录新建一个Hello.java文件内容如下public class Hello { public static void main(String[] args) { System.out.println(JDK 配置成功可以正常编译运行); } }在命令行中进入该目录依次执行javac Hello.java java Hello看到输出JDK 配置成功可以正常编译运行就说明 JDK 的编译链全部正常。这一步看起来多余但它能帮你提前暴露问题。我就遇到过明明 java -version 正常但 javac 实际是坏的情况就是因为系统里装了多个 JDK版本混乱。实际编译测试是最可靠的检验方式。3. Maven 安装与仓库配置实战3.1 解压与基础配置Maven 的安装同样采用绿色解压方式。下载好的 zip 包解压到D:\devtools\maven\目录你会得到一个类似apache-maven-3.9.6的文件夹。和 JDK 一样需要配置两个环境变量MAVEN_HOME指向 Maven 目录然后在 Path 中追加%MAVEN_HOME%\bin。变量值建议写成D:\devtools\maven\apache-maven-3.9.6。配置完成后重开 cmd执行mvn -v验证Apache Maven 3.9.6 (bc2360e076d871d84e09e0a1f3b7e1f) Maven home: D:\devtools\maven\apache-maven-3.9.6 Java version: 17.0.8, vendor: Oracle Corporation, runtime: D:\devtools\jdk\jdk-17.0.8注意看最后一行Maven 会显示它当前使用的 Java 版本。如果你发现这里显示的 Java 版本和实际不符说明 JAVA_HOME 配置有偏差或者系统 Path 里有其他 Java 抢先被找到了。Maven 只看 JAVA_HOME 和 Path 里的 java 指令不看系统里装了多少个 JDK。3.2 配置本地仓库路径Maven 默认会把依赖 jar 包下载到用户目录下的.m2\repository文件夹。这个默认路径在 C 盘依赖下载多了以后会占用好几个 GB 空间而且万一 C 盘空间紧张或者系统重装这些缓存就全没了。更合理的做法是在 Maven 安装目录外单独建一个仓库目录比如D:\devtools\maven-repository。这个目录最好和 Maven 安装目录分开因为后期升级 Maven 时如果仓库在安装目录里升级时容易被一并清理。修改settings.xml文件它在 Maven 安装目录下的conf文件夹里。找到localRepository标签默认是被注释掉的取消注释并修改为localRepositoryD:\devtools\maven-repository/localRepository修改后保存再次执行mvn help:effective-settings命令在输出的内容里搜索 localRepository就能看到你的配置是否生效。这个命令是验证配置的利器比瞎猜强多了。3.3 配置阿里云镜像加速下载这个步骤在咱们这基本属于必需品因为 Maven 中央仓库服务器在国外直接下载依赖的速度经常让人崩溃尤其是拉取大体积 jar 包时卡个十几分钟是常事。在settings.xml的mirrors标签内添加镜像配置mirror idaliyunmaven/id name阿里云公共仓库/name urlhttps://maven.aliyun.com/repository/public/url mirrorOfcentral/mirrorOf /mirror这里解释一下配置里各标签的含义mirrorOf写 central表示只对中央仓库生效镜像其他自定义仓库不受影响url指向阿里云的公共仓库它聚合了中央仓库和常用的公共仓库覆盖面广且更新及时。配置完以后新建一个普通项目执行一次mvn clean compile观察下载速度。正常情况下你会在日志里看到依赖 jar 包快速下载完成的记录而不是之前那样长时间卡在 Downloading... 的状态。记住阿里云公共仓库是 https 协议如果项目里有特殊的私服仓库镜像配置要调整成针对性的规则不能盲目 mirrorOf 设为*。3.4 JDK 版本与编译参数设置Maven 默认使用 JAVA_HOME 对应的 JDK 版本进行编译但这不代表项目构建总会用你期望的版本。如果你的系统环境是 JDK 17但项目要求以 Java 8 语法编译就必须在项目的pom.xml中显式指定编译版本。在pom.xml中加入properties maven.compiler.source8/maven.compiler.source maven.compiler.target8/maven.compiler.target project.build.sourceEncodingUTF-8/project.build.sourceEncoding /properties这里有一个常见误区maven.compiler.source和target只控制编译时的源码语法级别和目标字节码版本它并不等于运行时用的 JDK。如果你用 JDK 17 编译 target 为 8 的代码运行时仍需要 JRE 8 或更高版本。而且 JDK 17 编译 target 8 时会提示源选项 8 已过时这是正常的不影响使用。如果你的电脑上同时装了 JDK 8 和 JDK 17而 Maven 仍用 JDK 17 来编译可以通过设置JAVA_HOME临时切换也可以直接在 Maven 的mvn.cmd前设置环境变量。但最推荐的方式还是用 IDE 的 Project Structure 指定项目 SDK这是后话这里不展开。4. 实操中高频踩坑与排查方案速查4.1 命令找不到的经典场景与解法不是内部或外部命令错误多半是 Path 配置错误。先执行echo %JAVA_HOME%看变量是否输出正确路径再执行echo %Path%看%JAVA_HOME%\bin是否在里面。有个小提示在 cmd 里用echo %Path%时系统会显示展开后的完整路径你直接找 JDK 的 bin 目录路径是否存在就行。还有一类隐蔽情况电脑上装了某些软件会自己往 Path 里加 Java 的路径比如某些 IDE 自带 JRE。这样即使你配置了 JAVA_HOME命令行执行java时系统按 Path 顺序找到的却是其他版本的 java。排查方式就是执行where java把所有位置列出来确认排在最前面的是不是你想要的那个。mvn 不是内部或外部命令排查思路同上先确认MAVEN_HOME配置正确再看 Path 里有没有%MAVEN_HOME%\bin。另外注意MAVEN_HOME 和 M2_HOME 是历史遗留的两种命名新版本 Maven 用 MAVEN_HOME 即可不要同时配置两个避免冲突。4.2 JAVA_HOME 与 Path 互相影响问题JAVA_HOME 理论上应该和 Path 中的 java 指令来源一致。如果出现java -version显示一个版本而 Maven 构建时又用另一个版本大多是因为 Path 里的某个 java.exe 和 JAVA_HOME 不一致。解决办法打开 Path 编辑把所有指向 java.exe 的条目都检查一遍。比如有些软件会自动添加C:\Program Files\Common Files\Oracle\Java\javapath到 Path这个路径指向系统安装的公共 JRE和你的 JAVA_HOME 无关。如果它排在前面就会优先被执行。最稳妥的做法是把%JAVA_HOME%\bin移到 Path 列表最顶部。在 Windows 环境变量编辑器里选中条目后可以上移。这样能确保命令行执行 java 时优先使用 JAVA_HOME 指定的版本。4.3 Maven 下载依赖失败的排查路径依赖下载失败是最让人抓狂的问题之一。常见报错有Could not transfer artifact、PKIX path building failed、Connection reset等。首先判断是不是网络问题。直接访问中央仓库地址看能否打开。如果打不开那你的镜像配置就非常重要了。把 settings.xml 里的镜像换成阿里云后重试。如果镜像配置了对依然报 SSL 证书错误那就是 JDK 版本自带的 CA 证书库和镜像站的证书不匹配。这种情况常见于 JDK 8 低版本访问某些新版 HTTPS 镜像站解决办法有两个升级 JDK 版本或者用 HTTP 协议的镜像地址不推荐。还有一种隐性坑settings.xml文件编码问题。如果你用记事本编辑过 settings.xml 并保存成了 UTF-8 with BOM 格式Maven 解析时可能直接报错。强烈建议用 VS Code 或 Notepad 编辑编码选 UTF-8 无 BOM 格式。4.4 环境变量修改后不生效的处理技巧这是老生常谈但从来不过时的问题。Windows 的资源管理器、命令行窗口、IDE特别是已经打开的在启动时就会把当时的环境变量读入内存。你修改了环境变量它们不会自动刷新必须关掉重新打开。但如果你重开了 cmd 还是不行还有一个隐藏技能执行refreshenv命令。这个命令来自 Chocolatey 包管理器如果你没装 Chocolatey可以使用 PowerShell 的方式在 PowerShell 中执行$env:Path [System.Environment]::GetEnvironmentVariable(Path,Machine) ; [System.Environment]::GetEnvironmentVariable(Path,User)手动刷新当前会话的 Path。其实最简单粗暴的办法永远有效重启电脑。虽然听起来愚笨但对于环境变量死活不生效的情况重启后所有进程都会拿到最新的环境变量。4.5 常见问题速查表症状可能原因排查/解决java -version 正常javac 找不到Path 中 JRE 优先于 JDK检查 where java调整 Path 顺序mvn -v 提示找不到MAVEN_HOME 或 Path 配置错误验证变量值确认 bin 路径存在依赖下载极慢未配置国内镜像settings.xml 添加镜像源依赖下载失败 SSL 报错镜像 HTTPS 证书不匹配换 JDK 版本或换镜像地址Maven 编译报不支持发行版本pom.xml 未指定 compiler 版本显式设置 source/target中文路径导致项目编译异常项目路径含中文目录项目放在英文路径下settings.xml 修改后不生效编辑格式问题或修改错文件检查用户级 vs 全局级 settings5. 进阶配置与多版本切换技巧5.1 利用 Maven settings.xml 提升日常效率Maven 的 settings.xml 其实分为两种级别全局配置在 Maven 安装目录的 conf 文件夹下用户配置在%USERPROFILE%\.m2\settings.xml。用户配置优先级高于全局配置意味着你可以不改安装目录只维护用户级配置升级 Maven 时配置也不会丢。日常开发中我会在用户级 settings.xml 里额外配置一项offlinefalse/offline明确允许在线下载同时设置interactiveModetrue/interactiveMode。还有自定义属性properties配合 profile 使用比如针对不同 JDK 版本定义不同的maven.compiler.source值。需要多提一嘴的是profiles标签。你可以在里面定义一个 activeByDefault 的 profile统一设置 jdk 版本检查和编码方式。比如profiles profile idjdk-17/id activation activeByDefaulttrue/activeByDefault /activation properties maven.compiler.source17/maven.compiler.source maven.compiler.target17/maven.compiler.target /properties /profile /profiles这样一来几乎所有项目都会默认用 JDK 17 的编译参数省去每个项目都在 pom.xml 里重复配置的麻烦。5.2 IDEA 与命令行环境的环境变量差异用集成开发环境比如常见的 Java IDE时要注意IDE 内部运行 Maven 时可能不会完全继承你在命令行配置的环境变量。有些 IDE 有自己独立的Maven 设置面板它会优先使用面板里指定的 Maven home path、用户设置文件和本地仓库路径。所以我建议无论命令行还是 IDE都保证指向同一个 Maven 目录和同一个 settings.xml。这样你在命令行执行mvn clean package和 IDE 里的构建行为完全一致不会出现命令行能编译、IDE 里报错或者反过来这种精神分裂的情况。在 IDE 里配置 Maven 时有一个小技巧把本地仓库路径、镜像配置都设置好以后先打开 Maven 面板刷新一次确保 IDE 成功加载了新的 settings.xml。如果配置写错了IDE 通常会提示Settings file is invalid之类的错误这时候排查语法问题就行。5.3 Windows 下多 JDK 版本切换的封装脚本假设你电脑上同时装了 JDK 8 和 JDK 17不想每次切换都手动改环境变量可以写一个简单的批处理脚本放在桌面或任意目录下调用。新建switch-jdk.bat文件内容如下echo off echo 请选择要切换的 JDK 版本 echo 1. JDK 8 echo 2. JDK 17 set /p choice请输入序号 if %choice%1 ( setx JAVA_HOME D:\devtools\jdk\jdk-8u392 echo 已设置 JAVA_HOME 为 JDK 8 ) else if %choice%2 ( setx JAVA_HOME D:\devtools\jdk\jdk-17.0.8 echo 已设置 JAVA_HOME 为 JDK 17 ) else ( echo 输入无效 ) pause注意setx命令设置的是永久环境变量但当前命令行窗口不会立即生效需要新开窗口才能使用。如果你想当前窗口也生效需要用set JAVA_HOME...临时设置。这个脚本只是简化操作原理还是改环境变量。5.4 让 Maven 同时服务于多 JDK 项目的构建策略一个项目如果需要用 JDK 8 编译而另一个项目需要 JDK 17除了手动切换 JAVA_HOME 之外更优雅的方式是使用 Maven Toolchains 插件。简单来说它允许你在同一台机器上让 Maven 自动选择匹配的 JDK 来执行编译。在用户级 settings.xml 中加入pluginGroups pluginGrouporg.apache.maven.plugins/pluginGroup /pluginGroups然后在项目 pom.xml 中配置build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-toolchains-plugin/artifactId version3.1.0/version executions execution goals goaltoolchain/goal /goals /execution /executions configuration toolchains jdk version17/version /jdk /toolchains /configuration /plugin /plugins /build同时在toolchains.xml中指明 JDK 路径。这种方式适合团队协作时有统一构建要求但对单机个人开发来说手动切换 JAVA_HOME 其实已经够用不必为了炫技增加复杂度。6. 写在最后的个人实操体会说句实在话JDK 和 Maven 的安装配置看起来是初级内容可我在带新人或者帮同事排查环境问题时发现大量问题都出在最基础的环节。有人在 Path 里堆了好几个 Java 路径有人用记事本改 settings.xml 导致乱码还有人根本不看 Maven 输出的错误日志全靠猜。我个人的习惯是所有开发工具一律用绿色解压版所有路径放到 F 盘或 D 盘的一个固定目录环境变量统一配置在用户变量并且坚持每次配置文件改动后用命令行验证。这套习惯帮我省去了无数重复排查的时间。最后再分享一个容易被忽视的小技巧配置完环境变量后不只是重开 cmd最好把后台运行的资源管理器窗口也重启一下。因为如果你是通过资源管理器启动 IDE 或者某些工具它们继承的可能是旧的环境变量。按Ctrl Shift Esc打开任务管理器重启资源管理器进程或者干脆注销一次再登录环境变量才会非常彻底地刷新干净。
JDK 和 Maven 在 Windows 下的安装和配置算是 Java 开发里最基础但也最容易出幺蛾子的一环。不少新手甚至工作一两年的同事都可能在环境变量、版本兼容这些地方卡过壳。这篇文章就把我多年来在 Windows 上折腾 JDK 和 Maven 的经验完整梳理一遍从下载到配置从原理到踩坑一步步讲清楚争取让你看完就能一次搞定。1. 环境准备与版本选型思路1.1 先搞清楚 JDK 和 Maven 各自扮演什么角色在动手下载之前先把这两个东西的角色理清楚后面配置起来思路会顺畅很多。JDK 是 Java 开发工具包它不光包含 Java 运行时环境还带了编译器、调试工具、打包工具等一系列开发必需品。你可以把 JDK 理解为生产 Java 程序的整套工厂而 Maven 则是工厂里的自动化流水线管理员。Maven 本身也是用 Java 写的所以它的运行依赖 JDK必须先装 JDK 再装 Maven这个顺序不能反。Maven 解决的核心痛点有两个。第一个是依赖管理以前做 Java 项目要把各种 jar 包手动下载、复制到 lib 目录版本冲突更是噩梦Maven 通过仓库机制你只需要在配置文件里声明依赖它自动帮你下载和管理。第二个是标准化构建编译、测试、打包、部署这一整套流程Maven 用约定的生命周期统一搞定。搞清楚这两层关系你就明白为什么网上教程都要求先配好 JAVA_HOME再配置 MAVEN_HOME因为 Maven 启动时会去找 Java 环境找不到就直接报错退出。1.2 如何选择合适的 JDK 版本Windows 下选 JDK 版本我见过太多人在这里踩坑。选版本不能只看最新更要看你的项目需求。目前市面上主流的有 Java 8、Java 11、Java 17 这几个 LTS 长期支持版本Java 21 也已经发布。如果你的项目是维护老系统Java 8 是绝对主流很多传统企业的遗留系统还停在 JDK 8 上如果是新项目建议至少 Java 11 起步能上 Java 17 就直接上因为 Java 17 在性能、语法、垃圾回收器方面都有明显提升。还有一个容易被忽略的问题Oracle JDK 和 OpenJDK 的抉择。Oracle JDK 从 Java 8u211 版本开始个人使用免费但企业商用需要付费授权OpenJDK 则完全开源免费。对绝大多数开发者来说选 OpenJDK 或者基于 OpenJDK 的发行版比如一些社区维护的版本完全够用没必要为了心理安慰去冒险用 Oracle JDK 商用。我个人的建议是去 OpenJDK 官网或者靠谱的镜像站下载选 LTS 版本对应 Windows x64 的 .zip 或 .msi 安装包都可以。zip 版更灵活卸载时直接删文件夹msi 版会自动配好注册表和环境变量省事但不够透明。我自己习惯用 zip 包因为配置过程完全可控也方便多版本切换。1.3 Maven 版本搭配的原则Maven 版本的选择相对简单核心原则是Maven 3.6.x 以上版本兼容 JDK 8 到 JDK 17Maven 3.9.x 对 JDK 17 和 JDK 21 支持更完善。如果你用的是 JDK 8 环境也不要刻意用老版本 Maven3.6.3 以上都没问题。Maven 官网提供 Binary zip archive 和 Binary tar.gz archive 两种格式Windows 下直接下 Binary zip archive。下载页面看准 .zip 后缀的包别下成 Source 包那个是源码不能直接运行。这里有个很多人不知道的小细节Maven 不需要安装程序解压即用。整个 Maven 就是一个文件夹只要把路径配好它就能跑起来。这种绿色软件的好处是你可以同时保留多个 Maven 版本随时切换。1.4 目录规划与多版本共存思路强烈建议你在 C 盘以外的盘符建一个统一的开发工具目录比如D:\devtools\然后分别创建D:\devtools\jdk和D:\devtools\maven目录把解压后的文件放进去。为什么特意强调目录规划因为 Windows 下最容易出的问题就是路径里有空格或中文。比如你把 JDK 装到C:\Program Files\Java\jdk-17这个路径虽然能用但在某些老旧脚本、批处理文件里空格就会引发奇怪的问题。更别用中文目录名少数框架和插件在解析路径时遇到中文会直接乱码。多版本共存的做法也很简单用不同的文件夹名区分版本比如D:\devtools\jdk8和D:\devtools\jdk17需要切换时只需修改 JAVA_HOME 环境变量指向目标目录。这个思路同样适用于 Maven如果你有老项目必须用 Maven 3.5完全可以保留两个 Maven 目录。2. JDK 安装与核心配置详解2.1 JDK 解压安装的正确姿势以 zip 包为例说明安装流程。下载完成后用解压工具解压到D:\devtools\jdk目录。解压完成后你会看到一个类似jdk-17.0.8的文件夹里面是 bin、conf、include、jmods、legal、lib 这些子目录。如果你是下载的 .msi 安装包双击安装时会自动解压到系统目录并配置环境变量。但这里我要多说一句msi 安装方式虽然省事但它生成的环境变量配置比较隐蔽后期如果你想改路径或者换版本反而要多几步操作。zip 包完全手动控制出问题也好排查。解压完成后先验证一下目录结构是否正确。打开文件夹找到bin目录里面应该能看到java.exe和javac.exe这两个最关键的可执行文件。千万注意如果你在 bin 里找不到javac.exe说明你下载的不是 JDK而是 JRE那样没法编译 Java 代码。2.2 环境变量配置的底层逻辑真正让无数人困惑的是环境变量配置。这里我把原理讲透你就不会再被各种教程绕晕。Windows 环境变量分用户变量和系统变量两种。系统变量对所有用户生效修改它需要管理员权限用户变量只对当前用户生效不需要额外权限。开发工具的环境变量配置在用户变量里就够用没必要动系统变量这样更安全。需要配置的核心是三个变量JAVA_HOME指向 JDK 安装目录Path在原有值的基础上追加 JDK 的 bin 目录CLASS_PATH早期教程会配置这个现在其实不需要了打开环境变量编辑器的方法右键此电脑→属性→高级系统设置→环境变量。在用户变量区域点击新建变量名填JAVA_HOME变量值填你的 JDK 目录路径比如D:\devtools\jdk\jdk-17.0.8。注意JAVA_HOME 一定要指到 JDK 的具体版本目录而不是只到 jdk 这一层。很多工具包括 Maven、Tomcat、Gradle依赖这个变量来定位 Java 环境如果你指错了层级后面全都会报错。然后找到 Path 变量点击编辑。Win10 和 Win11 的环境变量编辑器是列表形式的直接点新建添加%JAVA_HOME%\bin即可。这里特意用%JAVA_HOME%来引用而不是写完整路径这样以后切换 JDK 版本时只需要修改 JAVA_HOMEPath 不用动。至于CLASS_PATH我明确建议你不需要配置。这个东西是 JDK 1.4 时代的遗留产物。现代 JDK 和构建工具会自动处理类路径配置了反而可能干扰项目运行。网上有些老教程还在教人配 CLASS_PATH直接跳过就行。2.3 验证 JDK 是否配置成功配置完环境变量最关键的一步是验证。先关掉所有已经打开的命令行窗口重新打开一个新的 cmd 窗口依次执行两个命令java -version javac -version如果输出类似这样的结果说明 JDK 配置成功java version 17.0.8 2023-07-18 LTS Java(TM) SE Runtime Environment (build 17.0.89-LTS-211) Java HotSpot(TM) 64-Bit Server VM (build 17.0.89-LTS-211, mixed mode, sharing)如果提示不是内部或外部命令一般有两种可能一是 Path 变量没配置正确二是修改完环境变量后没有重开 cmd 窗口。老版本的 cmd 窗口在启动时读取环境变量之后修改的变量不会自动生效必须新开窗口才能加载最新的环境变量。还有一种情况是 java -version 能显示但 javac 提示找不到。这种情况通常是你的 Path 里同时存在多个 Java 的路径系统优先找到了 JRE 而不是 JDK 的 bin。排查方法很简单执行where java命令它会列出所有被找到的 java.exe 路径看看排第一个的是不是你刚才配置的那个。2.4 实战小测试写一个 Hello World 确认编译链完整环境变量配好不等于万事大吉最好再实际编译运行一次程序确认整条链路通畅。在任意目录新建一个Hello.java文件内容如下public class Hello { public static void main(String[] args) { System.out.println(JDK 配置成功可以正常编译运行); } }在命令行中进入该目录依次执行javac Hello.java java Hello看到输出JDK 配置成功可以正常编译运行就说明 JDK 的编译链全部正常。这一步看起来多余但它能帮你提前暴露问题。我就遇到过明明 java -version 正常但 javac 实际是坏的情况就是因为系统里装了多个 JDK版本混乱。实际编译测试是最可靠的检验方式。3. Maven 安装与仓库配置实战3.1 解压与基础配置Maven 的安装同样采用绿色解压方式。下载好的 zip 包解压到D:\devtools\maven\目录你会得到一个类似apache-maven-3.9.6的文件夹。和 JDK 一样需要配置两个环境变量MAVEN_HOME指向 Maven 目录然后在 Path 中追加%MAVEN_HOME%\bin。变量值建议写成D:\devtools\maven\apache-maven-3.9.6。配置完成后重开 cmd执行mvn -v验证Apache Maven 3.9.6 (bc2360e076d871d84e09e0a1f3b7e1f) Maven home: D:\devtools\maven\apache-maven-3.9.6 Java version: 17.0.8, vendor: Oracle Corporation, runtime: D:\devtools\jdk\jdk-17.0.8注意看最后一行Maven 会显示它当前使用的 Java 版本。如果你发现这里显示的 Java 版本和实际不符说明 JAVA_HOME 配置有偏差或者系统 Path 里有其他 Java 抢先被找到了。Maven 只看 JAVA_HOME 和 Path 里的 java 指令不看系统里装了多少个 JDK。3.2 配置本地仓库路径Maven 默认会把依赖 jar 包下载到用户目录下的.m2\repository文件夹。这个默认路径在 C 盘依赖下载多了以后会占用好几个 GB 空间而且万一 C 盘空间紧张或者系统重装这些缓存就全没了。更合理的做法是在 Maven 安装目录外单独建一个仓库目录比如D:\devtools\maven-repository。这个目录最好和 Maven 安装目录分开因为后期升级 Maven 时如果仓库在安装目录里升级时容易被一并清理。修改settings.xml文件它在 Maven 安装目录下的conf文件夹里。找到localRepository标签默认是被注释掉的取消注释并修改为localRepositoryD:\devtools\maven-repository/localRepository修改后保存再次执行mvn help:effective-settings命令在输出的内容里搜索 localRepository就能看到你的配置是否生效。这个命令是验证配置的利器比瞎猜强多了。3.3 配置阿里云镜像加速下载这个步骤在咱们这基本属于必需品因为 Maven 中央仓库服务器在国外直接下载依赖的速度经常让人崩溃尤其是拉取大体积 jar 包时卡个十几分钟是常事。在settings.xml的mirrors标签内添加镜像配置mirror idaliyunmaven/id name阿里云公共仓库/name urlhttps://maven.aliyun.com/repository/public/url mirrorOfcentral/mirrorOf /mirror这里解释一下配置里各标签的含义mirrorOf写 central表示只对中央仓库生效镜像其他自定义仓库不受影响url指向阿里云的公共仓库它聚合了中央仓库和常用的公共仓库覆盖面广且更新及时。配置完以后新建一个普通项目执行一次mvn clean compile观察下载速度。正常情况下你会在日志里看到依赖 jar 包快速下载完成的记录而不是之前那样长时间卡在 Downloading... 的状态。记住阿里云公共仓库是 https 协议如果项目里有特殊的私服仓库镜像配置要调整成针对性的规则不能盲目 mirrorOf 设为*。3.4 JDK 版本与编译参数设置Maven 默认使用 JAVA_HOME 对应的 JDK 版本进行编译但这不代表项目构建总会用你期望的版本。如果你的系统环境是 JDK 17但项目要求以 Java 8 语法编译就必须在项目的pom.xml中显式指定编译版本。在pom.xml中加入properties maven.compiler.source8/maven.compiler.source maven.compiler.target8/maven.compiler.target project.build.sourceEncodingUTF-8/project.build.sourceEncoding /properties这里有一个常见误区maven.compiler.source和target只控制编译时的源码语法级别和目标字节码版本它并不等于运行时用的 JDK。如果你用 JDK 17 编译 target 为 8 的代码运行时仍需要 JRE 8 或更高版本。而且 JDK 17 编译 target 8 时会提示源选项 8 已过时这是正常的不影响使用。如果你的电脑上同时装了 JDK 8 和 JDK 17而 Maven 仍用 JDK 17 来编译可以通过设置JAVA_HOME临时切换也可以直接在 Maven 的mvn.cmd前设置环境变量。但最推荐的方式还是用 IDE 的 Project Structure 指定项目 SDK这是后话这里不展开。4. 实操中高频踩坑与排查方案速查4.1 命令找不到的经典场景与解法不是内部或外部命令错误多半是 Path 配置错误。先执行echo %JAVA_HOME%看变量是否输出正确路径再执行echo %Path%看%JAVA_HOME%\bin是否在里面。有个小提示在 cmd 里用echo %Path%时系统会显示展开后的完整路径你直接找 JDK 的 bin 目录路径是否存在就行。还有一类隐蔽情况电脑上装了某些软件会自己往 Path 里加 Java 的路径比如某些 IDE 自带 JRE。这样即使你配置了 JAVA_HOME命令行执行java时系统按 Path 顺序找到的却是其他版本的 java。排查方式就是执行where java把所有位置列出来确认排在最前面的是不是你想要的那个。mvn 不是内部或外部命令排查思路同上先确认MAVEN_HOME配置正确再看 Path 里有没有%MAVEN_HOME%\bin。另外注意MAVEN_HOME 和 M2_HOME 是历史遗留的两种命名新版本 Maven 用 MAVEN_HOME 即可不要同时配置两个避免冲突。4.2 JAVA_HOME 与 Path 互相影响问题JAVA_HOME 理论上应该和 Path 中的 java 指令来源一致。如果出现java -version显示一个版本而 Maven 构建时又用另一个版本大多是因为 Path 里的某个 java.exe 和 JAVA_HOME 不一致。解决办法打开 Path 编辑把所有指向 java.exe 的条目都检查一遍。比如有些软件会自动添加C:\Program Files\Common Files\Oracle\Java\javapath到 Path这个路径指向系统安装的公共 JRE和你的 JAVA_HOME 无关。如果它排在前面就会优先被执行。最稳妥的做法是把%JAVA_HOME%\bin移到 Path 列表最顶部。在 Windows 环境变量编辑器里选中条目后可以上移。这样能确保命令行执行 java 时优先使用 JAVA_HOME 指定的版本。4.3 Maven 下载依赖失败的排查路径依赖下载失败是最让人抓狂的问题之一。常见报错有Could not transfer artifact、PKIX path building failed、Connection reset等。首先判断是不是网络问题。直接访问中央仓库地址看能否打开。如果打不开那你的镜像配置就非常重要了。把 settings.xml 里的镜像换成阿里云后重试。如果镜像配置了对依然报 SSL 证书错误那就是 JDK 版本自带的 CA 证书库和镜像站的证书不匹配。这种情况常见于 JDK 8 低版本访问某些新版 HTTPS 镜像站解决办法有两个升级 JDK 版本或者用 HTTP 协议的镜像地址不推荐。还有一种隐性坑settings.xml文件编码问题。如果你用记事本编辑过 settings.xml 并保存成了 UTF-8 with BOM 格式Maven 解析时可能直接报错。强烈建议用 VS Code 或 Notepad 编辑编码选 UTF-8 无 BOM 格式。4.4 环境变量修改后不生效的处理技巧这是老生常谈但从来不过时的问题。Windows 的资源管理器、命令行窗口、IDE特别是已经打开的在启动时就会把当时的环境变量读入内存。你修改了环境变量它们不会自动刷新必须关掉重新打开。但如果你重开了 cmd 还是不行还有一个隐藏技能执行refreshenv命令。这个命令来自 Chocolatey 包管理器如果你没装 Chocolatey可以使用 PowerShell 的方式在 PowerShell 中执行$env:Path [System.Environment]::GetEnvironmentVariable(Path,Machine) ; [System.Environment]::GetEnvironmentVariable(Path,User)手动刷新当前会话的 Path。其实最简单粗暴的办法永远有效重启电脑。虽然听起来愚笨但对于环境变量死活不生效的情况重启后所有进程都会拿到最新的环境变量。4.5 常见问题速查表症状可能原因排查/解决java -version 正常javac 找不到Path 中 JRE 优先于 JDK检查 where java调整 Path 顺序mvn -v 提示找不到MAVEN_HOME 或 Path 配置错误验证变量值确认 bin 路径存在依赖下载极慢未配置国内镜像settings.xml 添加镜像源依赖下载失败 SSL 报错镜像 HTTPS 证书不匹配换 JDK 版本或换镜像地址Maven 编译报不支持发行版本pom.xml 未指定 compiler 版本显式设置 source/target中文路径导致项目编译异常项目路径含中文目录项目放在英文路径下settings.xml 修改后不生效编辑格式问题或修改错文件检查用户级 vs 全局级 settings5. 进阶配置与多版本切换技巧5.1 利用 Maven settings.xml 提升日常效率Maven 的 settings.xml 其实分为两种级别全局配置在 Maven 安装目录的 conf 文件夹下用户配置在%USERPROFILE%\.m2\settings.xml。用户配置优先级高于全局配置意味着你可以不改安装目录只维护用户级配置升级 Maven 时配置也不会丢。日常开发中我会在用户级 settings.xml 里额外配置一项offlinefalse/offline明确允许在线下载同时设置interactiveModetrue/interactiveMode。还有自定义属性properties配合 profile 使用比如针对不同 JDK 版本定义不同的maven.compiler.source值。需要多提一嘴的是profiles标签。你可以在里面定义一个 activeByDefault 的 profile统一设置 jdk 版本检查和编码方式。比如profiles profile idjdk-17/id activation activeByDefaulttrue/activeByDefault /activation properties maven.compiler.source17/maven.compiler.source maven.compiler.target17/maven.compiler.target /properties /profile /profiles这样一来几乎所有项目都会默认用 JDK 17 的编译参数省去每个项目都在 pom.xml 里重复配置的麻烦。5.2 IDEA 与命令行环境的环境变量差异用集成开发环境比如常见的 Java IDE时要注意IDE 内部运行 Maven 时可能不会完全继承你在命令行配置的环境变量。有些 IDE 有自己独立的Maven 设置面板它会优先使用面板里指定的 Maven home path、用户设置文件和本地仓库路径。所以我建议无论命令行还是 IDE都保证指向同一个 Maven 目录和同一个 settings.xml。这样你在命令行执行mvn clean package和 IDE 里的构建行为完全一致不会出现命令行能编译、IDE 里报错或者反过来这种精神分裂的情况。在 IDE 里配置 Maven 时有一个小技巧把本地仓库路径、镜像配置都设置好以后先打开 Maven 面板刷新一次确保 IDE 成功加载了新的 settings.xml。如果配置写错了IDE 通常会提示Settings file is invalid之类的错误这时候排查语法问题就行。5.3 Windows 下多 JDK 版本切换的封装脚本假设你电脑上同时装了 JDK 8 和 JDK 17不想每次切换都手动改环境变量可以写一个简单的批处理脚本放在桌面或任意目录下调用。新建switch-jdk.bat文件内容如下echo off echo 请选择要切换的 JDK 版本 echo 1. JDK 8 echo 2. JDK 17 set /p choice请输入序号 if %choice%1 ( setx JAVA_HOME D:\devtools\jdk\jdk-8u392 echo 已设置 JAVA_HOME 为 JDK 8 ) else if %choice%2 ( setx JAVA_HOME D:\devtools\jdk\jdk-17.0.8 echo 已设置 JAVA_HOME 为 JDK 17 ) else ( echo 输入无效 ) pause注意setx命令设置的是永久环境变量但当前命令行窗口不会立即生效需要新开窗口才能使用。如果你想当前窗口也生效需要用set JAVA_HOME...临时设置。这个脚本只是简化操作原理还是改环境变量。5.4 让 Maven 同时服务于多 JDK 项目的构建策略一个项目如果需要用 JDK 8 编译而另一个项目需要 JDK 17除了手动切换 JAVA_HOME 之外更优雅的方式是使用 Maven Toolchains 插件。简单来说它允许你在同一台机器上让 Maven 自动选择匹配的 JDK 来执行编译。在用户级 settings.xml 中加入pluginGroups pluginGrouporg.apache.maven.plugins/pluginGroup /pluginGroups然后在项目 pom.xml 中配置build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-toolchains-plugin/artifactId version3.1.0/version executions execution goals goaltoolchain/goal /goals /execution /executions configuration toolchains jdk version17/version /jdk /toolchains /configuration /plugin /plugins /build同时在toolchains.xml中指明 JDK 路径。这种方式适合团队协作时有统一构建要求但对单机个人开发来说手动切换 JAVA_HOME 其实已经够用不必为了炫技增加复杂度。6. 写在最后的个人实操体会说句实在话JDK 和 Maven 的安装配置看起来是初级内容可我在带新人或者帮同事排查环境问题时发现大量问题都出在最基础的环节。有人在 Path 里堆了好几个 Java 路径有人用记事本改 settings.xml 导致乱码还有人根本不看 Maven 输出的错误日志全靠猜。我个人的习惯是所有开发工具一律用绿色解压版所有路径放到 F 盘或 D 盘的一个固定目录环境变量统一配置在用户变量并且坚持每次配置文件改动后用命令行验证。这套习惯帮我省去了无数重复排查的时间。最后再分享一个容易被忽视的小技巧配置完环境变量后不只是重开 cmd最好把后台运行的资源管理器窗口也重启一下。因为如果你是通过资源管理器启动 IDE 或者某些工具它们继承的可能是旧的环境变量。按Ctrl Shift Esc打开任务管理器重启资源管理器进程或者干脆注销一次再登录环境变量才会非常彻底地刷新干净。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
