简介：这是一份面向 Java 开发者的 Apache Maven 3.6.2 构建工具完整安装包，可解决项目依赖管理、标准化构建、打包部署等日常流程问题，也可作为离线环境快速部署 Maven 的备选方案。压缩包共 68 个文件，大小约 8.77 MB，核心内容以 42 个 jar 包为主，涵盖 Maven 核心引擎、插件与第三方依赖；另有 bin 目录下的 mvn 可执行脚本、conf 目录下的 settings.xml 配置模板、若干 license 与 README 文档，以及适配多平台的 dll/so/jnilib 原生运行库。整体结构清晰，解压后即可配置本地仓库与镜像源。已有 321 人浏览学习。通过该包，开发者可获得完整 Maven 3.6.2 运行环境，无需逐一下载缺失组件；同时可参考文件清单了解各目录与库的作用，为后续升级 Maven、排查依赖冲突、编写简化构建脚本奠定基础。对于希望离线安装构建工具或系统学习 Maven 目录结构的开发者来说，是一份直接可用的资源。 想必不少Java开发者的硬盘里都躺着一个名为apache-maven-3.6.2.zip的压缩包，它可能来自公司文档、培训视频，或是某个技术交流群里的分享。这个版本在Maven的发布历史中确实比较特殊：它足够稳定，又是很多旧项目和新项目都能接受的“安全牌”。之所以单独把apache-maven-3.6.2.zip拿出来写一篇，是因为在日常答疑中，围绕它的下载、安装、换源、IDEA集成、报错排查，出现的频率实在太高，而且很多问题其实都是重复的。这篇文章，我想把这些分散的细节系统性地梳理一遍，重点放在“为什么这么做”和“出了问题怎么自己定位”上，而不是单纯复制官方文档。无论你是刚接触Maven的新手，还是被依赖问题折腾得头疼的老手，应该都能在这里找到一些可用的东西。
1. 为什么是3.6.2：版本选择背后的兼容性逻辑
1.1 这个版本卡在JDK生态的关键节点上
Maven 3.6.2发布于2019年，它其实正好卡在Java生态的一个重要过渡期。那会儿Java 8还是绝对的主流，Java 11已经开始被Spring Boot等框架支持，但许多老项目的编译目标依然锁定在JDK 8上。Maven 3.6.2在这两者之间表现得非常从容，它基于Java 7构建，运行时兼容Java 8到Java 12左右的版本，这意味着在那段时间里，你几乎不需要为了Maven去额外调整本机的JDK环境。
我见过不少团队的编译环境是这样的：操作系统Windows Server 2016，JDK版本8u202，Maven版本3.6.2，Nexus私服存了一堆内部构件。这套组合服役了好几年，没出过大问题。apache-maven-3.6.2.zip这个压缩包能成为很多教程的默认推荐，核心原因就是它极少在“运行环境”这个层面上给你添乱，不像某些更早的3.5.x版本对JDK 11的支持还不够好，也不像3.8.x系列在某些私服配置上要求更严格。在兼容性这件事上，它属于那种“随遇而安”的类型。
1.2 什么时候不该用它，该换更高版本
当然，3.6.2不会永远正确。如果你在JDK 17或更高版本上工作，比如升级到JDK 21，Maven 3.6.2虽然也能跑，但在处理某些新版字节码、或者搭配新版插件的场景下，就会有隐约的力不从心。Spring Boot 3.x要求Maven 3.6.3以上，但实际体验下来，3.6.2在Spring Boot 3初期的几个版本也能编译通过，不过当你用上一些较新的Maven插件（比如新版protobuf插件或lombok版本）时，老版本Maven可能会暴露一些内部API调用问题。
这时候就不该抱着apache-maven-3.6.2.zip不放了，直接切到3.8.8或3.9.x系列更省心。我的建议是：如果你的项目还基于JDK 8或11，3.6.2完全可以长期使用；如果已经切到JDK 17以上，或者你在用Spring Boot 3.x全家桶，那就下载新版。选版本的关键在于“匹配你的JDK和项目插件”，而不是“追求最新”，这跟选地基一样，稳定比热闹重要。
2. 从压缩包到第一条命令：安装与验证全流程
2.1 下载之后先做三件事：解压、看目录、确认JAVA_HOME
拿到apache-maven-3.6.2.zip之后别急着双击或解压到随便某个文件夹。先建一个干净的路径，比如D:\DevTools\maven或者/opt/maven，再将压缩包解压到该目录下，最终得到类似/opt/maven/apache-maven-3.6.2这样的结构。在Windows上尽量避开“Program Files (x86)”这种带空格和括号的路径，因为虽然现代工具大多能处理空格，但某些老旧脚本或命令行工具会把路径截断，产生极其折磨人的“找不到命令”错误。
解压完成之后，打开文件夹确认两件事。第一，根目录下应该能看到bin、boot、conf、lib这四个核心目录，看到一个bin目录下的mvn.cmd（Windows）或mvn（类Unix）。第二，在配置环境变量之前，先打开终端/命令行，敲一句echo %JAVA_HOME%（Windows）或echo $JAVA_HOME（macOS/Linux）。Maven运行时并不关心你的项目目标JDK是什么，但它本身需要找到一个可用的JDK来启动。这条命令如果输出为空，说明你的JAVA_HOME根本没设置，那回头即使你配置了MAVEN_HOME，执行mvn -v也大概率会报错JAVA_HOME not found。
2.2 环境变量配置的差异点：Windows与macOS/Linux
Windows下配置环境变量的路径是“此电脑 -> 属性 -> 高级系统设置 -> 环境变量”。新建一个系统变量MAVEN_HOME，值为刚才解压的目录根路径（比如D:\DevTools\maven\apache-maven-3.6.2），然后在Path变量的末尾追加%MAVEN_HOME%\bin。这里有个细节，有些教程会让你直接把完整路径写进Path，我建议保留MAVEN_HOME变量，因为后续如果想切换Maven版本，只需改这一个值，不用在长长的Path列表里翻来翻去。
macOS和Linux用户通常用export的方式，把这几行加到~/.bashrc或~/.zshrc里：
export MAVEN_HOME=/opt/maven/apache-maven-3.6.2 export PATH=$MAVEN_HOME/bin:$PATH注意顺序，要把$MAVEN_HOME/bin放在$PATH前面，这样如果系统里已经有其他地方的mvn命令，你的新版本会被优先找到。改完之后别忘记source ~/.zshrc让它生效。
2.3 先用mvn -v验证，别急着敲install
配置完成后，开一个新的终端窗口，执行mvn -v。理想输出类似这样：
Apache Maven 3.6.2 (40f52351accba2141d3d0a39d0d5a1a0c8d8f0e) Maven home: /opt/maven/apache-maven-3.6.2 Java version: 1.8.0_202 Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_202.jdk/Contents/Home Default locale: zh_CN_CN这里要重点核对两行：一是Maven home指向的是不是你刚才解压的路径，二是Java version是否是Maven启动时用的JDK，而不是你希望项目用的JDK。很多新手在IDEA里看到项目的JDK是11，但Maven控制台输出的Java version还是1.8，就是因为IDEA里Maven的runner使用了单独的JRE设置，跟项目SDK是两套配置。在命令行验证这一步，能帮你把Maven本身和环境变量的关系先梳理清楚，避免后续排查时多一个干扰项。
3. settings.xml改三处，解决90%的配置问题
3.1 本地仓库为什么不能放在默认位置
settings.xml位于Maven安装目录的conf文件夹下，它是全局配置；用户级别的配置则在~/.m2/settings.xml。虽然Maven官方推荐在用户目录下放一份，但如果你手头只有apache-maven-3.6.2.zip，我建议先修改全局的conf/settings.xml，这样无论如何切换用户，配置都保持一致。
本地仓库默认在~/.m2/repository。理想状态下没什么问题，但Windows用户会遇到一个现实困扰：C盘空间被依赖库越撑越满，系统盘动不动就报警。更关键的是，如果操作系统管理了用户目录权限，某些自动化构建工具读取仓库时可能遇到权限问题。所以我会第一时间把localRepository改到别的盘或专用目录：
<localRepository>D:/DevTools/maven/repository</localRepository>这个路径要提前手动建好，Maven第一次下载依赖时如果发现目录不存在，它一般会自己创建，但有些情况下（比如路径带特殊字符、或没有写权限）会报错。提前创建并确认可读写，能省掉后续的麻烦。
3.2 镜像仓库：阿里云不是唯一选项，但优先级逻辑要弄懂
网络拉取依赖慢是Maven新手最常遇到的问题。默认情况下Maven从Maven Central拉取仓库，在国内网络环境下时快时慢，很多团队也因此长期使用阿里云中央仓库镜像。用的镜像配置通常长这样：
<mirrors> <mirror> <id>aliyunmaven</id> <name>aliyun maven</name> <url>https://maven.aliyun.com/repository/public</url> <mirrorOf>central</mirrorOf> </mirror> </mirrors>很多人抄完配置后发现还是不生效，多半是因为mirrorOf写错了。这里的central表示只对中央仓库生效。如果你把它改成*，那意味着所有仓库（包括你自己私服或其他三方仓库）都走镜像，这在有私服或多镜像的环境下会导致奇怪的拉取失败。我实际配置时，通常是单镜像场景直接用central，如果有多仓库需求，则把mirrorOf设置为external:*或列表，而不会图省事写*。
而镜像的选择上也不必吊死在一棵树上。如果阿里云某个时刻也不稳定，或者你在公司网络里，可以换成华为云镜像或腾讯云镜像，配置结构完全一致。重要的是理解镜像的核心机制：Maven访问某个仓库时，如果发现配置里有一个匹配的镜像，就把请求转发给镜像地址。这对我是很有用的思路，理解了它，之后处理不同团队环境下的拉取问题就很顺。
3.3 锁定JDK编译版本，避免“source 1.5”报错
有时候在命令行编译项目，明明本地环境是JDK 11，Maven却报错或警告说“source/target 1.5已过时”。这通常是因为项目里的pom.xml没有显式指定编译版本，而Maven默认的编译插件用的是老旧的1.5标准。虽然这个问题通常出现在缺少配置的pom中，但在团队协作时并不罕见。我习惯在settings.xml的profiles节点里放一个默认的编译profile，保证当前机器上的所有项目在没有pom显式配置时，也会采用统一且合理的编译级别：
<profiles> <profile> <id>jdk-8</id> <activation> <activeByDefault>true</activeByDefault> </activation> <properties> <maven.compiler.source>1.8</maven.compiler.source> <maven.compiler.target>1.8</maven.compiler.target> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> </properties> </profile> </profiles>这样配置之后，即便在命令行直接执行mvn clean install，也不会出现编译级别过低的意外。当然，具体编译版本还得和项目需求保持一致，比如项目如果跑在JDK 7上，你不能为了省事强行用1.8。
4. IDEA集成：用自带Maven还是自己装的Maven
4.1 指向自己的Maven，而不是依赖IDEA内置版本
IDEA长期内置了一个Maven版本，早期版本内置的是3.6.x系列，后来变为3.8.x或更高。既然你手头已经有apache-maven-3.6.2.zip并配好了环境变量，最好在IDEA里把它指过去。好处是显而易见的：命令行执行和IDEA导入的依赖解析方式完全一致，同一个本地仓库、同一套配置，不再出现命令行能构建但IDEA一跑就报错的割裂感。
具体操作路径是：File -> Settings -> Build, Execution, Deployment -> Build Tools -> Maven，右侧的Maven home path选择你自己的Maven安装目录，User settings file和Local repository可以勾上Override并显式指向刚才的settings.xml和仓库目录。这样一套下来，IDEA会重新读取配置，并在右下角提示你导入或刷新Maven项目。
4.2 三个必改设置：Runner的JRE、导入策略、代理
在IDEA的Maven设置里，有个隐藏比较深的选项：Runner -> JRE。如果这里显示的不是你预期的JDK版本，那Maven在IDEA里执行时就会用错Java环境。另外Importing选项卡里的JDK for importer也很容易忽略，建议一并检查并设置为你真正要用的项目JDK。这两个设置是我在遇到“IDEA里依赖能解析但mvn test跑不起来”时首先排查的，多数时候问题就藏在这里。
如果你的网络环境需要使用代理才能访问外网，可以在settings.xml里配置proxies节点。IDEA启动时除了读取自身的HTTP代理，也会尊重Maven的这个配置。我一般建议优先在IDE的网络设置中配置，但如果遇到某些依赖直接从IDE下载失败但浏览器能访问的情况，把代理写在settings.xml里可能反而更有效。
4.3 IDEA里手动导入依赖时，不要删掉本地仓库
有人喜欢在IDEA里右键某个依赖，选择“Download Sources”，或者用mvn dependency:sources拉源码。这里有一个我踩过的坑：如果本地仓库里的某个构件损坏了，比如上次下载中断留下了一个.lastUpdated文件，IDEA或Maven会拒绝重新下载，一直报“cannot be resolved”。很多人这时候会手抖把整个仓库目录删了重新下，代价很大。
正确做法是，先找到仓库里对应的目录，把损坏的目录整个删掉，再在IDEA里点击刷新或重新导入。如果是一个多模块项目的部分依赖都出问题，可以命令行执行mvn -U clean compile强制更新快照。-U参数的作用是强制检查远程更新，它能覆盖本地已有的快照缓存，但注意它不会干掉release版本，只对快照依赖有效。
5. 高频报错排查实录与冷门小技巧
5.1 “cannot be resolved”类报错的完整排查链路
关于“Maven cannot be resolved”的报错，点名率极高。长这样：The artifact 'com.mysql:mysql-connector-j:release' cannot be resolved in e...。碰到这类问题，第一件事别去翻pom文件，而是打开本地仓库对应的目录（比如~/.m2/repository/com/mysql/mysql-connector-j），看里面到底有什么。如果只有release这个文件夹但里面没jar，说明坐标写错了，com.mysql:mysql-connector-j这个坐标自从MySQL官方调整后，实际上更像是一个BOM依赖，真正可用的坐标是mysql:mysql-connector-java，版本不同写法不同。
如果你的报错出现在新拉下来的项目里，第二步就检查settings.xml里的镜像仓库是否真的可达。在浏览器里访问https://maven.aliyun.com/repository/public/com/mysql/mysql-connector-java/，按版本路径一路看下去，如果浏览器能打开但Maven报错，那多半是本地仓库有问题或Maven在解析时走了某个快照更新流程卡住了。第三步，检查项目pom里的parent依赖是否完整，有些项目继承了公司私服里的父pom，在本地没有私服的情况下解析会直接失败，报的可不只是某个具体依赖无法解析。
5.2 仓库损坏后的强制更新与“-U”的正确用法
本地仓库里常见的一种文件是.lastUpdated后缀，它记录了上次下载失败的时间戳。Maven默认在24小时或更长时间内不会重新尝试下载失败的依赖（取决于更新策略）。此时在IDEA里反复刷新，或者用mvn install重试，都会看到一模一样的错误。实际解决办法：
- 偶发性失败：先执行
mvn -U clean install强制更新快照并跳过本地失败缓存。 - 持续失败：先删掉对应目录下的
.lastUpdated文件和_remote.repositories文件，再重新下载。如果删完仍然失败，再去看网络或仓库地址。
帮人排查时发现不少人是“-U一敲、世界太平”的拥护者。-U其实很简单，就是让Maven忽略本地的过期缓存，强制从远端刷新。但在慢速网络下它会明显拖慢构建速度，因为每个快照都要核对远程。所以别把-U当常驻参数，只在出问题的时候用。
5.3 命令行直接执行clean install的坑与收获
用命令行构建Maven项目，是排查IDEA环境问题的有力手段。很多人只会用IDEA里的图形化Maven面板点“刷新”，而这对命令行构建能力是个浪费。其实，你完全可以关掉IDEA，在终端里进入项目根目录输入mvn clean install来构建整个项目。如果你看到命令行能成功而IDEA里失败，那问题大概率在IDEA本身的配置上；反过来，如果命令行也失败，那就可以集中火力排查Maven本身或代码问题。
命令行构建还有一个隐藏优势：它能暴露IDEA隐藏的某些“自动修复”行为。IDEA有时候会在后台帮你做一些隐式操作，比如强制刷新、跳过被忽略的依赖，导致你在图形界面里看不到真实错误。而在终端里，所有的构建日志都原原本本显示出来，定位问题会清晰很多。
5.4 冷门但实用：让Gradle项目也产出生本地Maven构件
最后说一个不太为人注意的点。很多人在Android或Java Gradle项目里想用mavenLocal()或本地Maven仓库，但又不想专门去看Gradle的发布插件文档。其实Gradle本身就有对应的做法，核心是在build.gradle里加上maven-publish插件并配置发布任务，执行后会在build目录或~/.m2里生成一份pom和jar包。这样同一台机器上的Maven项目就能直接用本地坐标依赖这个构件。
这个需求在团队联调时经常出现，比如A在维护一个公共的SDK，B在做调用方。没有私服时，A构建后，B从本地仓库拉取，效率非常高。当然项目规模大、人数多了之后，还是尽快搭一个内部Nexus或Artifactory，依赖解析路径统一且可留痕。
apache-maven-3.6.2.zip本身只是一个普通的二进制压缩包，真正重要的是包里这套构建逻辑和配置思路。Maven的很多问题归结起来就是：JDK环境、settings.xml配置、仓库策略三件事。把这三件事理清，即使哪天换一个更新的Maven版本，你也能很快上手。希望这篇围绕安装、配置、排查的梳理，能让你在下一次遇到Maven问题时少一些折腾。
本文还有配套的精品资源，点击获取
