前阵子在技术群里看到有人问“Maven下载了但不会配置”点进去一看问的人还不少。其实Maven安装本身没什么难度真正的坑在于很多人装完之后不知道要改哪些配置、为什么改——环境变量是干吗的settings.xml里的镜像又是什么IDEA里明明有默认Maven为什么还要手动指定一遍。这篇我就把Maven安装与配置从头到尾讲透Windows和macOS都覆盖从原理到实操再附上我这些年踩过的坑。不管你是刚接触Java的小白还是被IDEA报红折腾到头疼的老手这篇文章应该都能帮到你。1. 先搞清楚Maven是干嘛的装它之前最好想明白这三件事1.1 没有构建工具时Java项目到底有多痛先回顾一下没有Maven的日子。早期的Java Web项目里一个典型的lib目录能塞几十个jar包mysql驱动、servlet-api、jstl、log4j、fastjson……这些jar要么去官网一个个下载要么从同事的U盘里拷要么在百度网盘碰运气。就算你好不容易把jar齐了还有两个问题版本冲突A依赖commons-lang 2.xB依赖commons-lang 3.x两个都放进去运行时直接NoSuchMethodError。你压根不知道谁依赖了谁。项目迁移困难新同事拉下代码光找jar包就得折腾半天更别提不同的操作系统、不同的JDK版本带来的差异。1.2 Maven解决的三件大事依赖、构建、项目结构Maven解决的就是上面这些让人抓狂的问题。具体来说它做了三件事依赖管理在pom.xml里声明依赖坐标groupId、artifactId、versionMaven自动去仓库下载还能把传递性依赖你依赖的库所依赖的其他库一并拉下来省去手工管理jar之苦。标准化构建Maven定义了一套完整的生命周期validate、compile、test、package、verify、install、deploy你想打包就执行mvn package想安装到本地仓库就mvn install想清理就mvn clean约定优于配置不需要每个项目去写复杂的构建脚本。统一项目结构Maven要求源代码放在src/main/java资源文件放src/main/resources测试代码放src/test/java。所有Maven项目长得都一样接手别人的代码成本大幅降低。1.3 和Ant、Gradle的区别以及为什么我说新手先学Maven很多人会把Maven和Ant搞混。简单说Ant是“过程式”的你必须在build.xml里一步步指定编译、复制、打包的指令灵活但繁琐Maven则是“声明式”的你只需要告诉它这是web项目还是jar项目它自己会走既定流程。和Gradle比Maven的XML配置确实啰嗦一点但Maven的优势是生态成熟、文档多、资料全——你工作中遇到的问题大概率有人已经踩过并给出答案了。Gradle更灵活、构建更快适合Android和复杂多模块项目但上手门槛稍高。我的建议是新手第一优先学Maven把构建理念和依赖管理搞清楚再碰Gradle不迟。2. 安装前的版本选型JDK与Maven的版本对应关系最容易被忽略2.1 版本对应关系看一眼这张表少走两小时弯路我见过太多人栽在版本不匹配上下了最新版Maven放到老JDK环境里一执行就报UnsupportedClassVersionError或者TLS相关的异常。Maven版本和JDK的对应关系其实官网写得很清楚这里直接给出一张速查表Maven版本最低JDK要求常见使用场景Maven 3.6.xJDK 1.7老项目中常见兼容性好Maven 3.8.xJDK 1.7修复了部分3.6的安全问题Maven 3.9.xJDK 8目前最稳妥的选择JDK 8~17都支持Maven 4.0.xJDK 17较新的版本适合新立项目但生态适配还不算全面如果你的JDK是8那直接选Maven 3.9.x这是目前最均衡的搭配。如果你用的是JDK 11或17也是Maven 3.9.x最稳。除非你明确知道自己要干嘛否则现阶段暂时不用急着追求Maven 4.x越来越多人用JDK 17后会有一定兼容问题。2.2 从官网下载的完整流程与版本识别Maven官网是maven.apache.org不要从第三方下载站找官网才是唯一可靠来源。下载页面在maven.apache.org/download.cgi里面会有一堆文件等你认领。需要注意区分apache-maven-3.9.6-bin.zip/apache-maven-3.9.6-bin.tar.gz这才是我们要下载的二进制包。apache-maven-3.9.6-src.zip/apache-maven-3.9.6-src.tar.gz源码包给开发者编译Maven本身用的普通用户别碰。还会看到apache-maven-3.9.6-bin.tar.gz.asc和.sha512等文件这是签名校验文件和SHA512校验值安全洁癖患者可以对一下日常使用一般用不到。选择的时候认准bin字样、对应操作系统的压缩包即可。Windows下意识选.zipmacOS和Linux选.tar.gz。2.3 为什么我建议大多数人选Maven 3.8.x或3.9.x而不是最新的4.x这是很多小白容易入的坑看到官网有4.0版本直接下了最新的。但Maven 4.x要求JDK 17才跑得起来如果你们的开发环境还是JDK 8这就是一个较大的麻烦即使你是JDK 17很多IDEA插件、持续集成脚本、企业私有仓库插件比如各类代码扫描工具对Maven 4.x的兼容性仍未完全验证。所以我的立场很简单生产环境求稳Maven 3.9.x是当下最保证体验的版本不是最新就是最好的。等你把整个项目构建链路吃透了再考虑升级版本不迟。3. Windows下安装与配置从解压到命令行跑通的完整步骤3.1 解压目录的规范与推荐路径第一步是把下载好的zip包解压。别小看这一步路径选择有很多需要注意的地方路径中绝对不能有中文和空格。D:\软件\Maven\apache-maven-3.9.6这种路径会导致各种诡异问题——环境变量解析不对、IDEA识别异常、脚本执行报错。我见过有人放在C:\Users\张三\maven结果后面根本跑不起来。建议放一个独立的、全英文的目录比如D:\apache-maven-3.9.6或者C:\dev\apache-maven-3.9.6。我习惯在D盘单独建一个dev目录JDK、Maven、IDEA这些开发工具都归拢在一起方便管理。解压完之后你会看到里面有一个bin目录所有的可执行脚本都在这里、conf目录核心配置settings.xml在这里、lib目录Maven运行所需的jar包。我们先不急着改任何一个文件先配置环境变量。3.2 环境变量配置的三个关键点Windows下配置环境变量的路径是右键“此电脑”→“属性”→“高级系统设置”→“环境变量”。有三个关键点必须处理第一个关键点新建MAVEN_HOME变量。在“系统变量”区域点“新建”变量名填MAVEN_HOME变量值填你的解压根目录比如D:\apache-maven-3.9.6。这个变量本身不直接执行但很多工具包括一些老版本的IDEA插件会读它来定位Maven。现在新版本Maven也支持M2_HOME但官方连个共识都没有为了避免混乱我们统一用MAVEN_HOME取值不要带\bin后缀——我说的是D:\apache-maven-3.9.6不是D:\apache-maven-3.9.6\bin这是初学者最常犯的错。第二个关键点PATH变量追加bin目录。在“系统变量”中找到Path双击打开点“编辑”→“新建”填入%MAVEN_HOME%\bin。我强调的是追加不是覆盖千万别把原来的一整串Path替换掉了。追加之后Windows才会在命令行里找到mvn命令。第三个关键点确认JAVA_HOME已配置。Maven启动靠Java环境它本身不会解压一个JDK给你用。如果JAVA_HOME没配置好后面执行mvn -v会直接报错。你用echo %JAVA_HOME%先看一眼没有就补上指向JDK安装路径比如C:\Program Files\Java\jdk1.8.0_202。老版本的IDEA或Tomcat还需要JRE_HOME但Maven只需要JAVA_HOME。3.3 验证安装的两种方式与常见失败原因配置完成后必须新开一个命令行窗口不是用之前已经打开的那个因为环境变量的读取是在窗口打开时加载的然后输入mvn -v正常输出应该类似这样Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3f08dccdde9a97a) Maven home: D:\apache-maven-3.9.6 Java version: 1.8.0_202, vendor: Oracle Corporation Java home: C:\Program Files\Java\jdk1.8.0_202 Default locale: zh_CN, platform encoding: GBK如果你看到的不是这个用下面几张表对号入座排查报错信息原因分析解决办法mvn 不是内部或外部命令PATH没配置对或者没有重开命令行窗口确认%MAVEN_HOME%\bin已追加到Path新开一个窗口再试Failed to determine java home或JAVA_HOME is not definedJAVA_HOME不存在或指向错误补充JAVA_HOME环境变量并确认指向JDK目录爆出UnsupportedClassVersionErrorMaven版本和JDK版本不匹配降级Maven到3.9.x或检查JDK版本这里再说一个经验如果你配完环境变量后还是提示命令找不到不要反复刷新窗口了干脆把命令行窗口全部关掉重新开。在Windows上环境变量是在进程启动时读取的老窗口不会感知新配置。4. macOS下安装与配置Homebrew和手动安装的对比实操4.1 方式一用Homebrew三分钟装完macOS上最省事的方式就是Homebrew。打开终端执行brew install maven装完可以用mvn -v直接验证。如果你用的Apple Silicon芯片Homebrew默认装到/opt/homebrew目录下对应的Maven路径是/opt/homebrew/Cellar/maven/版本号如果是Intel芯片则是/usr/local/Cellar/maven/版本号。实际使用中一般不需要手动指定这个路径Homebrew会把可执行文件软链到统一位置which mvn能帮你看到准确的执行入口。用Homebrew的好处是以后升级方便一条brew upgrade maven就完事但坏处是它装的位置有时和IDEA默认搜索路径不一致后面配置IDEA时你可能要用brew --prefix maven查一下真实路径。不过一般IDEA能自动识别问题不大。4.2 方式二手动安装并配置环境变量如果你想自己掌控安装位置或者公司内网机器上不方便用Homebrew那就手动装。下载apache-maven-3.9.6-bin.tar.gz。打开终端执行解压命令建议解压到/usr/local目录下sudo mkdir -p /usr/local cd /usr/local sudo tar -xzf ~/Downloads/apache-maven-3.9.6-bin.tar.gz为了好维护建一个软链接这样以后升级版本不需要改环境变量sudo ln -s /usr/local/apache-maven-3.9.6 /usr/local/maven接下来配置环境变量。macOS用户要根据自己用的shell来选择配置文件如果你用zshmacOS默认编辑~/.zshrc如果你还在用bash编辑~/.bash_profile。export MAVEN_HOME/usr/local/maven export PATH$MAVEN_HOME/bin:$PATH保存后执行source ~/.zshrc让配置生效然后mvn -v验证。4.3 macOS特有的坑zsh和.bash_profilemacOS上的配置最容易出问题的点就是shell配置文件的差异。Catalina之后macOS默认shell从bash换成了zsh很多人按网上老教程改~/.bash_profile结果怎么source都没用因为zsh启动时根本不会读这个文件。如果你不确定自己用的是哪个shell执行echo $SHELL看一下。输出是/bin/zsh就改~/.zshrc是/bin/bash就改~/.bash_profile。另一个值得注意的坑是如果你用brew安装Maven后又手动设置了MAVEN_HOME有概率导致IDEA或终端里的Maven路径指向混乱。我的建议是二选一别混着装。用brew就完全依赖brew手动装就不要执行brew install否则排查问题时很难定位到真正使用哪个Maven。5. settings.xml配置是安装之后的头等大事本地仓库、镜像源、JDK版本一次配齐5.1 settings.xml到底在哪哪个才是生效的那个安装完Maven后你一定会遇到两个settings.xml文件很多人搞不清哪个生效结果配置了半天却发现IDEA里没变化。全局配置文件在Maven安装目录的conf目录下比如D:\apache-maven-3.9.6\conf\settings.xml。它对该机器上的所有用户、所有项目生效。用户配置文件默认在~/.m2/settings.xmlmacOS和Windows路径都是用户主目录下的.m2文件夹。它只对当前用户生效会覆盖全局配置。两套配置文件的合并规则是用户配置优先于全局配置不存在的内容才从全局配置继承。实际工作中的建议是只改用户配置文件。因为如果你改全局配置哪天Maven升级、重装后配置就全丢了而用户配置文件独立于安装目录升级不丢失。第一次执行Maven命令时Maven会自动创建~/.m2目录但不会自动生成settings.xml文件。有需要的话把Maven安装目录下conf/settings.xml复制一份到~/.m2/再改。5.2 本地仓库位置先改这里否则C盘会炸Maven会把你从中央仓库下载的所有jar包缓存到本地这个目录默认叫.m2/repository如果你的用户目录在C盘那所有依赖都会堆在C盘时间一长几个G甚至几十个G就没了。对于用C盘小固态的人来说这是极大的优惠。修改方式很简单打开settings.xml找到被注释的localRepository标签改成你想要的磁盘路径settings xmlnshttp://maven.apache.org/SETTINGS/1.0.0 xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:schemaLocationhttp://maven.apache.org/SETTINGS/1.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd !-- 本地仓库路径按你的实际情况修改不要用中文路径 -- localRepositoryD:/maven-repo/localRepository /settings我说几个关于本地仓库的关键经验路径推荐使用正斜杠D:/maven-repo避免反斜杠转义问题。本地仓库不需要手动创建Maven会在第一次执行命令时自动创建。如果既要Windows开发、又要Linux服务器构建尽量保持同样的本地仓库路径风格减少跨平台踩坑的可能。本地仓库里如果有损坏的jar包最简单的处理办法是找到对应目录删掉让Maven重新下载。5.3 阿里云镜像与多镜像仓库配置告别下载走到99%卡死默认情况下Maven从Maven Central中央仓库下载jar包。对国内用户来说有时候访问Maven Central就像在高峰期挤地铁——连接超时、下载一般、到99%就卡住这些都是家常便饭。最有效的解决方案就是配置镜像仓库。在settings.xml里加上这么一段mirrors !-- 阿里云公共代理仓库国内强烈推荐 -- mirror idaliyunmaven/id mirrorOf*/mirrorOf nameAliyun Maven Central Mirror/name urlhttps://maven.aliyun.com/repository/public/url /mirror /mirrors这个aliyunmaven仓库是阿里云公共代理它同时代理了Maven Central、JCenter和Google等几个核心仓库对绝大多数Java项目来说都够用。如果你有特殊需求比如要同时配置多个镜像仓库比如一个私服仓库、一个阿里云镜像mirrorOf配合mirrorOf*,!repo1/mirrorOf这种写法可以实现“除了本地私服repo1其他都走阿里云”的效果。多镜像配置的语法不过多展开核心逻辑就是Maven按mirrorOf去匹配仓库ID匹配到的请求才走这个镜像。配置完成后可以使用mvn help:system命令测试一下镜像是否生效日志里会出现类似Downloading from aliyunmaven: https://maven.aliyun.com/repository/public/...的信息。如果还是看到下载地址指向repo.maven.apache.org那说明镜像没生效回去检查settings.xml的标签嵌套结构。5.4 用profile固定JDK编译版本这又是一个极其常见的坑本地JDK是8pom.xml里没有任何编译版本设置结果编译后生成了Java 17字节码部署到服务器上直接UnsupportedClassVersionError。为了防止这类事情最好的办法是在settings.xml的profiles里统一配置编译参数profiles profile idjdk-8/id activation activeByDefaulttrue/activeByDefault /activation properties maven.compiler.source1.8/maven.compiler.source maven.compiler.target1.8/maven.compiler.target maven.compiler.compilerVersion1.8/maven.compiler.compilerVersion /properties /profile /profiles这样所有项目默认都使用JDK 1.8的编译参数干净整齐。如果你的团队项目统一要求JDK 11或17把对应的值改掉即可。6. IDEA里配置Maven解决“项目报红”和“识别不了Maven工程”两大痛点6.1 IDEA的Maven设置为什么有三个地方每个地方都管什么很多人在IDEA里配置Maven找不着北因为IDEA里至少有三处和Maven相关的设置位置它们的关系理清了你就不会再被绕晕单个项目的配置File → Settings → Build, Execution, Deployment → Build Tools → MavenmacOS为IntelliJ IDEA → Settings。这里改的只对当前项目生效。新项目的默认配置File → New Projects Setup → Settings for New Projects → Build Tools → Maven。只对新创建的项目生效老项目不受影响。建议把这里的Maven配置也改好否则每次新建项目都要重新指定一遍。Build Tools → Maven → Runner这里决定Maven命令执行时用哪个JDK。如果你的项目编译报错显示“无效的源发行版”之类大概率是这个Runner里的JRE没选对。这三处的Maven home directory、User settings file、Local repository三项都应该保持一致否则你在A项目配好了新建B项目又回到默认值然后继续报错非常闹心。6.2 创建Maven项目与导入已有pom.xml的正确姿势如果你要新建Maven项目推荐直接选IDEA里的“New Project”左侧选择“Maven”——如果IDEA版本较新你可能需要从“Generators”里选“Maven Archetype”或干脆选“Maven”然后填Archetype坐标。这里我提醒一点IDEA新版默认初始模板里有个坑构建过程联网拉Archetype插件可能会卡住甚至卡在maven-archetype-plugin的下载上。解决办法有两条路选最简单的“Maven”项目模板IDEA会帮你生成一个最简单的pom.xml骨架不需要下载Archetype。手动创建文件夹结构自己写一份pom.xml然后用IDEA打开这个目录右键pom.xml选择“Add as Maven Project”IDEA立刻就能识别成Maven工程。第二种方式是我自己最习惯的——很多实际问题越不依赖IDE的自动化生成越不容易踩坑。手工写pom.xml本质上是把构建配置掌握在自己手里。6.3 依赖下载失败、报红的完整排查链路IDEA里pom.xml报红是最常见的现象——某个依赖坐标下面画着红波浪线错误信息类似Cannot resolve com.mysql:mysql-connector-j:8.0.33或者maven artifact com.mysql:mysql-connector-j:8.0.33 cannot be resolved in offline mode遇到这种问题不要慌按下面这条链路走基本能锁定根因确认网络能访问镜像仓库。如果用的是阿里云镜像IDE的日志里能看到请求明细。如果完全没有网络请求可能就是离线模式被勾选了Settings → Build Tools → Maven里“Work offline”选项被打开了取消即可。确认坐标是否正确。去mvnrepository.com搜一下最终版本号和groupId这个网站是Maven仓库的网页版入口日常查坐标用它最高效。有时候就是版本号写错了比如mysql-connector-j新版本改了groupId和artifactId老写法自然就拉不下来。确认本地仓库里是否有损坏文件。Maven下载过程中如果断网或强制中断本地仓库会留下一个.lastUpdated后缀的文件它会让Maven认为这个依赖已经尝试过且失败了导致后续所有构建都直接跳过下载、快速失败。处理办法是删除对应目录下的.lastUpdated文件或者直接把整个依赖目录删掉再执行一次强制刷新。用命令行验证。在IDEA的Terminal窗口执行mvn -U clean compile-U参数强制检查远程仓库的更新能帮你绕过本地缓存的过期失败状态。如果命令行能编译通过而IDEA还报红那是IDEA的索引问题用下面6.4里的方法处理。检查Settings里的Local repository。如果你在命令行里修改了settings.xml的本地仓库路径但IDEA里“Local repository”还指向旧的~/.m2/repository那IDEA会去旧仓库找依赖找不到自然就红了。把IDEA里这一项和你实际使用的仓库路径保持一致。6.4 强制刷新与清理本地仓库的技巧IDEA提供了几个刷新Maven依赖的入口我按使用频率排个序点击Maven工具窗口中的“Reload All Maven Projects”按钮圆形箭头图标。如果常规刷新没效果在IDEA里执行mvn -U clean install强制从远程仓库拉取最新快照。最粗暴但有效的方案退出IDEA把本地仓库整个删掉或者只删除报错相关的目录重启IDEA再Reload。虽然首次加载依赖会慢一点但这招能解决90%的“依赖莫名奇妙红”问题。另一个“external libraries完全没有maven依赖”的场景也很典型你的pom.xml看起来没问题但IDEA代码里引用的第三方类全部标红External Libraries里一个jar都没有。这通常是因为IDEA没有把pom.xml识别为Maven配置文件尤其出现在新导入项目或者git clone下来没加载完的时候。解决方式是右键pom.xml → “Add as Maven Project”或者File → Invalidate Caches清一下缓存。IDEA的Maven索引有时特别顽固这一步处理完基本就好了。7. 高频命令与实战组合从clean install到跳过测试一次讲透7.1 最核心的六条命令Maven命令本质上都是配置在pom.xml里的插件绑定但日常开发用到的就这六条效果和场景对照如下命令作用使用场景mvn clean删除target目录清理上一次构建产物mvn compile编译主代码写代码过程中快速验证语法mvn test运行单元测试执行src/test/java下的测试类mvn package打包成jar或war准备部署包mvn install把项目构建产物安装到本地仓库多模块项目里让其他模块引用mvn deploy上传到远程仓库/私服正式发布到团队私服7.2 日常开发中最常用的命令组合真正开发的时候大家很少只敲单个命令而是组合使用。我最常用的组合有这几个# 全量构建并跳过测试大幅提升速度 mvn clean install -DskipTests # 只重新编译并运行特定测试类 mvn test -DtestUserServiceTest # 强制刷新所有SNAPSHOT依赖并跳过测试打包 mvn clean install -U -Dmaven.test.skiptrue # 查看整个项目的依赖树排查版本冲突神器 mvn dependency:tree # 分析某个具体依赖为什么被引入 mvn dependency:tree -Dincludesorg.springframework:spring-core-DskipTests和-Dmaven.test.skiptrue是有区别的前者只跳过测试执行但会去编译测试代码后者直接跳过测试代码的编译构建更快但如果有测试类在编译期就报错用后者会直接暴露问题。平时写代码阶段我用-DskipTests赶时间上线的场景我才用-Dmaven.test.skiptrue。在多模块项目里处理模块间依赖时不要单独进子模块敲install正确姿势是去最上层的父目录执行mvn clean install -pl module-a -am其中-pl module-a表示只构建指定模块-am表示同时构建它依赖的其他模块这个组合在大型多模块项目里极其常用。7.3 命令执行失败时怎么看日志Maven执行失败时输出的日志一大片新手容易看懵。我的经验是直接搜几个关键字能快速定位问题搜ERROR直接看异常位置。搜BUILD FAILURE确认失败的这一段日志位置。搜Caused byMaven用Java异常链Caused by才是根因所在。搜Downloading from确认依赖是在哪个仓库下载的如果显示central而不是aliyunmaven说明镜像配置没生效。日志拉了很长一页也没关系只要有上面的几个关键定位习惯两分钟就能看出问题在哪。8. 安装配置过程中的高频报错与排查手册8.1 报错总表看一眼就知道往哪个方向修把文章里提过的各类报错汇总成一张表方便你直接对照报错现象可能原因优先排查项mvn 不是内部或外部命令环境变量未配置或未生效PATH、MAVEN_HOME、重开终端JAVA_HOME is not definedJDK环境变量缺失JAVA_HOME指向JDKCannot resolve ...依赖坐标错误或下载失败坐标版本、镜像仓库、.lastUpdated缓存Could not transfer artifact网络访问仓库失败换阿里云镜像、检查外网连通性Failed to execute goal ... compiler ... invalid target release编译参数与JDK版本不一致settings.xml的profile、pom.xml的source/targetjava.lang.OutOfMemoryError: PermGenMaven内存不足MAVEN_OPTS设置堆内存Unknown lifecycle phase命令拼错或参数缺引号mvn clean install -Dmaven.test.skiptrue注意参数被空格拆开8.2 “mvn不是内部或外部命令”的排查思路这个报错最常见但原因也最微妙。别上来就改环境变量按顺序排查新开一个命令行窗口执行echo %MAVEN_HOME%看看变量是否被正确读取。查看Path变量里%MAVEN_HOME%\bin前后的分号是否正确。直接在文件资源管理器里进入D:\apache-maven-3.9.6\bin看看目录下是否存在mvn.cmd文件。有的下载包不完整bin目录里只有mvn没有mvn.cmd这也会导致Windows命令行找不到命令重新解压或重新下载解决。检查MAVEN_HOME里是否误带了bin。如果你填的是D:\apache-maven-3.9.6\bin而Path里又写了%MAVEN_HOME%\bin那实际拼接出来的路径就是D:\apache-maven-3.9.6\bin\bin必挂。8.3 依赖下载不走镜像、一直报错无法解析的排查链路如果配置了阿里云镜像结果构建日志里依然看到Downloading from central说明镜像配置没生效。挨个检查settings.xml的mirrors标签是不是放在了settings根节点下正确位置有没有嵌套在其他标签里。有没有在项目pom.xml里显式指定了repositories项目级的仓库声明优先级高于镜像。settings.xml是不是用户级别生效如果你改的是全局conf/settings.xml而IDEA里明确指定了用户级别的settings文件指向另一个路径自然就冲突了。排查完毕后在命令行执行一次mvn help:system看输出里的下载地址是否变成了阿里云。如果还不行把本地仓库里对应的.lastUpdated文件删掉再试一次。8.4 本地仓库损坏的快速恢复方法本地仓库里的jar包偶尔会处于“只下了一半”的状态这种情况在依赖报错中最具欺骗性——因为文件看起来存在Maven也不会重新下载但类加载时就一直报ClassNotFoundException或NoClassDefFoundError。我的建议是别开始逐一手动删文件——效率低还容易误删。直接用命令# 找到所有.lastUpdated文件查看哪些依赖处于失败状态 find ~/.m2/repository -name *.lastUpdated # 彻底一点就直接删掉所有.lastUpdated find ~/.m2/repository -name *.lastUpdated -delete删除之后再执行mvn clean install -UMaven会重新尝试下载这些依赖。如果某个依赖反复下载失败大概率是网络不稳定或镜像仓库没有这个版本换个镜像或者换其他版本号再试。另一个更干净的兜底方案是把本地仓库全部删掉重新建。第一次构建虽然会下载所有依赖会比较耗时但这能确保本地仓库状态绝对干净。反正Maven的下载和缓存是自动的顶多是多等几分钟。以我实际维护过的项目来看安装配置Maven这件事80%的问题集中在第5章和第6章的配置细节上。把settings.xml改明白了IDEA里的三处设置保持一致依赖报错的大半问题就不会再找上你。剩下的各种报错归根结底都是网络、缓存和版本三个根源理解了这三个方向排查起来就行云流水了。