1. Maven到底是干嘛的先搞清楚这工具解决什么问题我记得刚接触Java那会儿项目里还用的是传统方式去网站下载jar包手动放进lib目录然后右键Add to Build Path。听起来是不是很熟悉当时最痛苦的是两件事第一jar包版本冲突A类需要这个版本的库B类需要那个版本两边还互不兼容第二换一台电脑整个lib目录重来一遍稍微漏一个依赖就启动报ClassNotFoundException。Maven出现之后这两种痛苦都成了历史。它的本质就是一个“依赖管家 构建流水线”。依赖管家负责帮你下载jar包、管理版本、处理传递依赖——什么是传递依赖举个例子你只用了一个FastJSON库但FastJSON自己可能依赖了其他工具包Maven会自动把这些间接依赖一起带上不需要你手动去找。构建流水线则负责编译代码、运行测试、打包成jar或者war一条命令全部搞定。所以这个标题下的需求其实分三块下载安装、环境配置、仓库配置。很多人卡在第三步因为即使装好了Maven默认配置也未必好用——最典型的就是中央仓库在国内访问极慢一个spring-boot依赖能下十分钟还失败。这次我直接一并讲透保证你照着做完之后新建项目、拉依赖、打包发布这些事都能顺顺当当。适用人群很明确刚开始学Java的初学者、刚入职需要搭环境的应届生、以及电脑上Maven配了很多次但一直稀里糊涂的老开发——最后这类人其实不少每次都是搜个教程照着点一遍下次遇到问题又忘了原理。我尽量把原理也说明白这样无论你有没有配置基础都能真正看明白自己到底在配什么。2. 环境准备与版本选型先别急着下载想清楚要装哪个2.1 JDK版本和Maven版本的匹配关系很多人直接跳过这一步下个Maven就开始配结果编译项目时提示Unsupported major.minor version或者干脆启动都起不来。这个报错本质上就是JDK版本和Maven版本不匹配。Maven是Java写的工具它运行在自己的JVM上所以你必须先装好JDK才能运行Maven。版本匹配关系大致如下Maven版本要求JDK版本说明Maven 3.3.xJDK 1.7比较老现在基本不用了Maven 3.6.xJDK 1.8很多老项目还在用Maven 3.8.xJDK 1.8目前最主流的稳定版本Maven 3.9.xJDK 8-21支持新特性也是当前推荐版本Maven 4.xJDK 8-21新版本但生态还在过渡期以2025年来看Java生态早就进入了JDK 17甚至21的时代——JDK 17是LTS长期支持版本很多公司线上生产环境都在用它所以我现在一般建议装JDK 17加Maven 3.9.x。这个组合的好处是既兼容新的Spring Boot 3.x企业级项目也不至于太激进到踩了不兼容的坑。如果你还在用JDK 1.8那Maven 3.6.3其实是用了很多年的经典搭配稳定性没什么问题。我给一个明确建议新装环境默认JDK 17 Maven 3.9.x老项目要JDK 8就用Maven 3.6.3不要在这个选择上花太多时间纠结。2.2 JDK 17的下载与安装要点JDK下载现在已经非常方便Oracle JDK和OpenJDK都可以。我建议直接去Oracle官网下载JDK 17或者用Adoptium/Eclipse Temurin的版本都是免费的。如果你不知道去哪下载就搜“JDK 17 download”认准Oracle官方域名或者Adoptium官网别去第三方站点下载来路不明的安装包里面塞点什么你根本不知道。JDK安装的时候有几点容易踩坑的地方我单独列出来安装路径不要带空格和中文。Windows下默认路径是C:\Program Files\Java\jdk-17虽然带空格理论上也能用但某些老工具解析路径时会出问题我习惯改成C:\Java\jdk-17这类简洁路径。记得配置JAVA_HOME环境变量。变量值指向JDK安装目录的根路径不包含bin目录。PATH环境变量里追加%JAVA_HOME%\bin这样才能在任意路径下执行java -version。安装完成之后打开命令行执行java -version看到类似openjdk version 17.0.x的输出就说明成功了。这里有个细节我要多说一句JDK版本的检查别只看java -version还要看javac -version。如果javac显示版本不对通常是环境变量配置错了或者PATH里有两套JDK在打架。我遇到过好几回这样的情况用户说装好JDK了但一查发现系统里还残留着一个老版本的JDK 8导致Maven编译时用的是旧版编译器。2.3 从官网下载Maven的正确姿势Maven的官方下载页面是maven.apache.org/download.cgi。进入后你会看到几个下载链接分别是Binary zip archive和Binary tar.gz archive前者是Windows系统用的zip包后者是Linux和macOS系统用的压缩包。下载之前你要认清楚一点Maven不需要安装程序它就是一个压缩包解压之后配置好环境变量就能用。很多新手习惯性地去找.exe安装文件以为像安装QQ那样双击下一步就行——完全不是这么回事。这点恰恰是很多人卡住的地方也是Maven和普通Windows软件最不一样的地方。选择下载文件时注意看版本号。目前3.9.x系列是稳定的主流版本例如apache-maven-3.9.9-bin.zip。带-source或-beta字样的不要碰。下载完成后解压同样放在一个没有中文、没有空格、路径不要太深的目录下比如C:\Maven\apache-maven-3.9.9。解压完看一眼bin目录里面应该有个mvn文件mac/Linux和mvn.cmd文件Windows。cluster.io这个文件看到它基本就说明解压没损坏。顺手说一句如果下载慢或者官网打不开国内可以用阿里云或者清华镜像站下载但更推荐的做法是去官网拿个种子自己想办法后续我会重点讲镜像配置那才是解决下载慢的核心手段。3. 环境变量配置这一步错了Maven永远起不来3.1 MAVEN_HOME到底配不配很多教程没说明白搜Maven安装教程你大概率会看到两个变量MAVEN_HOME和M2_HOME。这两个到底是干嘛的都要配吗早期的Maven版本确实需要配置M2_HOME一些老教程就是这么教的。但从Maven 3.5开始官方推荐使用MAVEN_HOME。不过实操中我发现只要你在PATH里面正确指向了bin目录这两个环境变量其实都不影响Maven运行——Maven真正依赖的是PATH里的路径。之所以还建议配一个MAVEN_HOME是因为后续IDE或者一些构建脚本可能通过这个变量来定位Maven的安装位置。环境变量怎么配置Windows系统下具体步骤如下右键“此电脑” → 属性 → 高级系统设置 → 环境变量。在系统变量区域点击“新建”变量名填MAVEN_HOME变量值填你的Maven解压路径比如C:\Maven\apache-maven-3.9.9。注意变量值只需要到Maven根目录不要加\bin。选择系统变量里的Path点击“编辑”新建一条内容为%MAVEN_HOME%\bin。一路点击“确定”保存。这里有个关键操作顺序问题配置完成之后一定要重新打开命令行窗口因为环境变量的读取是在窗口启动时进行的已经在运行的窗口不会自动刷新。有些人配置完之后在当前窗口执行mvn -v还是提示找不到命令就以为是配置错了其实只是没有重启窗口而已。这里还要注意一个细节如果系统里装了多个Maven版本Path变量中谁写在前面谁生效。你可以用where mvn命令查看实际命中路径来确认当前使用的是哪个版本。3.2 怎么验证安装成功配置完成后打开一个全新的命令行窗口输入mvn -v正常输出大概长这样版本号可能略有差异Apache Maven 3.9.9 (8e9479a1e8f2a9e2e1e8f2a9e2e1e8f2a9e2e1e8) Maven home: C:\Maven\apache-maven-3.9.9 Java version: 17.0.12, vendor: Oracle Corporation, runtime: C:\Java\jdk-17 Default locale: zh_CN, platform encoding: UTF-8 OS name: windows 11, version: 10.0, arch: amd64, family: windows看到这个输出有两个关键信息要检查第一Maven home是否指向你刚才配置的目录。如果你之前装过别的Maven版本这里可能会指向旧目录那就需要注意是不是PATH环境变量里的顺序问题导致的。第二Java version是否是预期的JDK版本。Maven默认会使用JAVA_HOME环境变量指定的JDK即使你的Path里有个新版本Java只要JAVA_HOME指向旧版本Maven就会用旧版本。如果这里版本不对去检查JAVA_HOME配置。如果执行mvn -v的时候提示“不是内部或外部命令”大概率是配置完Path没有重启命令行或者Path里那一条写错了。如果提示“JAVA_HOME is set to an invalid directory”那是JAVA_HOME指向的环境不存在或者配置有误。macOS和Linux配置方法类似编辑~/.zshrc或~/.bashrcexport MAVEN_HOME/opt/apache-maven-3.9.9 export PATH$MAVEN_HOME/bin:$PATH执行source ~/.zshrc使其生效。4. settings.xml配置实战让Maven下载快得飞起4.1 本地仓库Maven下载的jar包到底放哪了Maven从远程仓库下载依赖之后会存在本地磁盘上。这个本地缓存目录在Linux/macOS下默认是~/.m2/repositoryWindows下就是C:\Users\你的用户名\.m2\repository。问题来了默认放在C盘如果你C盘空间不足或者你用的是云桌面、虚拟环境这类重启即还原的机器依赖每次都要重新下载那体验会非常糟糕。所以我一般强烈建议把本地仓库改到其他盘。设置方法是在settings.xml里找到localRepository这一项它默认是被注释掉的。打开Maven安装目录/conf/settings.xml找到这段!-- localRepository | the path to the local repository maven will use to store artifacts. | | Default: ${user.home}/.m2/repository localRepository${user.home}/.m2/repository/localRepository --把注释去掉改成你要的路径localRepositoryD:/maven-repository/localRepository修改完建议马上做一件事新建一个Maven项目或者跑一次mvn help:system命令让Maven把基础依赖下载下来检查生成的目录结构是否正确。如果D:/maven-repository目录下出现了org/apache之类的目录层级说明本地仓库生效了。路径这里故意用正斜杠而不是反斜杠Windows环境下Maven对两种都兼容但正斜杠写起来更省事、转义问题少。4.2 阿里云镜像彻底解决依赖下载慢本地仓库设好了接下来最关键的一步配置镜像。Maven默认从中央仓库repo.maven.apache.org下载依赖这个仓库在国外国内访问速度时快时慢运气不好一个依赖卡上几分钟都有可能。解决办法就是配置国内镜像阿里云镜像是最常用的。在settings.xml文件里的mirrors标签中添加mirror idaliyunmaven/id mirrorOfcentral/mirrorOf name阿里云公共仓库/name urlhttps://maven.aliyun.com/repository/public/url /mirror这个配置的含义是所有从中央仓库central发起的请求都改从阿里云的地址下载。mirrorOf写central的意思是只镜像中央仓库不影响其他仓库的访问。如果你想更省事也可以写成*表示所有仓库请求都走阿里云但一般没有必要而且可能会影响一些私有仓库的访问。配置完记得保存。同样的如果你有正在运行的IDE要重启IDE或者重新导入项目才能生效。这里也顺带提一下有些公司会把依赖仓库换成私有Nexus仓库思路完全一样只需要把URL换成公司内网地址然后可能需要设置server节点里的用户名和密码信息。理解了镜像的机制换什么仓库你都能自己搞定。4.3 代理配置与JDK版本覆盖遇到就顺便解决了有时候在公司网络环境下访问外网仓库需要通过HTTP代理。那就在settings.xml的proxies节点配置代理信息proxy idcustom-proxy/id activetrue/active protocolhttp/protocol host127.0.0.1/host port7890/port username/username password/password /proxy注意host写代理服务器的地址port写代理端口。这里多说一句前面我提过Maven会用JAVA_HOME指定的JDK但Maven 3.9.x里有一个更灵活的方式你可以在settings.xml里通过activeProfiles来覆盖默认的JDK版本。比如你的JAVA_HOME是JDK 17但某个老项目必须用JDK 8编译可以在profile里指定jdk1.8/jdk。不过这个配置日常用到不多大家知道有这回事就行。我个人的原则是本地环境只保留一个JDK和一个Maven版本遇到需要多版本共存的项目用IDE里的项目级配置来切换这样最省心。4.4 关于“zyfun2026配置源”这类热词的说明标题相关的相关搜索里出现了不少配置源相关的热词像“zyfun2026配置源”这种。我看了下这东西和Maven本身没什么直接关系更像是某种软件或游戏模组的配置源。这里我只提醒一点任何来路不明的“配置源”在加入你的环境之前一定看清楚它到底要访问哪些域名、下载什么内容、把什么文件写在什么位置。很多所谓的加速源和配置源往往是通过替换DNS或者改写hosts来工作用不好反而会干扰其他网络请求。回到Maven这边最靠谱的、用得最多、坑也最少的就是阿里云镜像其他花里胡哨的源没必要冒险去试。5. IDE里的Maven配置IDEA如何正确识别你装的Maven5.1 IDEA内置Maven 与 自己安装Maven 的区别IntelliJ IDEA很好心它每次都会自带一个Maven版本开箱即用。但也正因为开箱即用很多人就忽略了配置一直用着IDEA内置的Maven。这种做法有什么问题呢第一个问题是IDEA内置Maven的版本跟着IDEA走IDEA升级版本内置Maven也跟着变新版本不一定兼容你项目里的老配置。第二个问题是内置Maven加载的settings.xml可能是IDEA默认的不会读到我们刚配置好的阿里云镜像和本地仓库下载依赖依然可能慢得像蜗牛。第三个问题是你本地命令行里Maven能正常跑但IDE里构建结果却和命令行不一致排查问题时很容易造成混乱。所以强烈建议把IDEA里的Maven指向你自己安装的版本。配置很简答依顺序操作打开IDEA进入File → Settings。在弹出的设置面板左侧选择Build, Execution, Deployment → Build Tools → Maven。右侧有一个Maven home path选项点击旁边的下拉框选择你的Maven路径。下方两个关键配置项User settings file指向你修改过的settings.xml文件。默认会显示~/.m2/settings.xml但我们改的是Maven安装目录下的setting.xml如果IDEA没有自动识别就点旁边的“Override”勾选框手动选择C:\Maven\apache-maven-3.9.9\conf\settings.xml。Local repositoryIDEA会自动根据settings.xml的配置解析出本地仓库路径。这里显示的是D:/maven-repository就说明配置生效了。点击Apply和OK保存。这里有个细节User settings file这里IDEA默认会优先读取~/.m2/settings.xml而不是Maven安装目录下的那个。你可以把settings.xml拷贝到~/.m2目录下这样用户级别的配置对所有Maven项目都生效而安装目录下的配置只对这台机器和当前用户可见。我个人的习惯是直接在~/.m2/settings.xml维护一份这样IDEA和命令行用起来完全一致。5.2 IDEA新建项目并验证Maven是否生效配置好之后我们可以新建一个测试项目验证一下在IDEA主界面选择New Project。左侧语言选择Java构建工具选择MavenJDK选择17。点击Next填好项目名比如maven-test。项目创建完成后IDEA会默认加载pom.xml并开始Downloading依赖。首次加载时右下角会有进度条可以点进去看它具体下的是什么依赖。如果走的阿里云镜像下载速度应该是每秒几MB几秒钟就把基础依赖拉完了。如果你看到某个依赖卡了很久不动那就回头看配置有没有生效或者直接打开pom.xml看仓库地址是否正常。顺带看一下External Libraries如果里面出现了Maven管理的Spring框架之类的库当然空项目不会自动加这些你可以先随便加一个测试依赖比如JUnit能够正常解析出来说明IDEA、Maven、仓库三者已经完全打通。5.3 项目级Maven配置当你需要多版本共存时有一种情况需要项目级配置你同时维护一个老项目用JDK 8一个新项目用JDK 17两个项目的Maven版本也不一样。那就不应该依赖IDEA的全局设置而是要每开一个项目就检查一下File → Settings → Maven里有没有被改掉。我自己的习惯是先在全局配一遍再按项目需要调整。项目级配置的位置在IDEA右侧的Maven面板点击右上角的“齿轮”图标选择Maven Settings。你可以在这里单独设置当前项目使用哪个Maven home、哪个settings.xml、哪个JDK。这样不同项目各配各的互不干扰。6. 新建一个Maven项目用命令行的方式彻底验证配置6.1 手把手创建一个简单的Java项目配置了半天最好用实战验证一下。手动创建一个Maven项目并不难在命令行里执行mvn archetype:generate -DgroupIdcom.example -DartifactIddemo-project -DarchetypeArtifactIdmaven-archetype-quickstart -DinteractiveModefalse这条命令的意思是使用Maven的archetype插件生成一个基础的Java项目结构。groupId一般填公司域名倒写artifactId填项目名archetypeArtifactId指定项目模板类型quickstart就是最简单的模板。执行之后你会看到一堆下载信息——第一次跑的时候Maven会下载相关的插件看到Downloading开始也意味着你配置的阿里云镜像生效了。如果下载很快、过程顺利说明前面所有配置都正常工作。生成的项目结构如下可以用tree命令查看Windows下是tree /fdemo-project/ ├── pom.xml └── src ├── main/java/com/example/App.java └── test/java/com/example/AppTest.java然后进入项目目录执行mvn package这一步会做完整构建编译主代码、运行测试、打包成jar包。成功后target目录下会出现demo-project-1.0-SNAPSHOT.jar。整个过程走通一遍你甚至不需要打开IDEA就能写出一个可运行的Java程序这就是Maven作为构建工具的核心价值。6.2 扒开pom.xml看一眼最常用的几个配置这里再花点时间看看项目的核心文件pom.xml它叫Project Object Model是Maven项目的“图纸”。下面是一个常见Spring Boot项目的pom.xml开头部分project xmlnshttp://maven.apache.org/POM/4.0.0 xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:schemaLocationhttp://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd modelVersion4.0.0/modelVersion groupIdcom.example/groupId artifactIddemo-project/artifactId version1.0.0/version packagingjar/packaging properties maven.compiler.source17/maven.compiler.source maven.compiler.target17/maven.compiler.target project.build.sourceEncodingUTF-8/project.build.sourceEncoding /properties dependencies dependency groupIdorg.junit.jupiter/groupId artifactIdjunit-jupiter/artifactId version5.10.2/version scopetest/scope /dependency /dependencies /project几个关键点groupId、artifactId、version三者合起来叫坐标仓库里每一个jar都由这个坐标唯一定位。packaging决定打包格式普通jar是jarWeb项目是war。properties里可以定义全局属性比如Java编译版本。dependencies就是依赖声明的地方。依赖的scope也很重要它控制依赖的生效范围常见的有compile默认编译和运行时都需要、provided编译期需要但运行时由容器提供典型的是servlet-api、test只在测试时生效理解scope可以减少很多不必要的包冲突。6.3 生命周期和常用命令mvn clean、compile、test、installMaven内置了一套构建生命周期可以理解成一条流水线验证→编译→测试→打包→验证→安装→部署。我们平时用得最多的是这几个命令mvn clean清理target目录把上一次构建的产物全部删掉。mvn compile只编译主代码。mvn test运行测试代码。mvn package编译测试打包产物放到target目录。mvn install把jar安装到本地仓库供其他项目引用。mvn deploy把jar上传到远程仓库一般是公司内网的Nexus。说一个很多新手会问的问题package和install到底有什么区别package只是把jar打包到当前项目的target目录下install不仅打包还会把这个jar“装”到本地仓库。如果你有B项目依赖A项目直接引用坐标而你本地仓库里没有A的jar的话就必须先对A执行mvn install否则B怎么都找不到依赖。这也是“明明代码没问题但是编译不过”的常见原因之一。7. 常见问题与排查技巧这些坑我都替你踩过了7.1 依赖下载慢或者下载失败这是配置Maven之后遇到最多的问题典型表现是IDEA右下角一直转圈或者命令行卡在Downloading进度不动。解决办法按优先级排列第一确认阿里云镜像配置正确。打开settings.xml检查mirrors节点有没有生效mirrorOf是不是写了central。一个经常被忽略的细节是mirrors节点的顺序是有讲究的Maven会优先匹配mirrorOf最具体的镜像如果你的mirrorOf写的是*且放在最前面那么所有仓库请求都会走它有时候反而会出问题。稳妥起见就只保留一个阿里云镜像。第二确认网络问题。实在镜像也不行可以先试试浏览器直接访问镜像URL能不能打开。如果URL都打不开说明是网络问题而不是Maven问题。第三本地仓库出现损坏文件。有时候下载到一半中断本地仓库会残留*.lastUpdated文件Maven看到本地有记录就会跳过下载结果依赖永远不完整。处理方式是手动清理本地仓库里的.lastUpdated后缀文件find ~/.m2/repository -name *.lastUpdated -deleteWindows下用PowerShellGet-ChildItem -Path $HOME\.m2\repository -Recurse -Filter *.lastUpdated | Remove-Item删完之后重新构建一般就能恢复。7.2 依赖报红RED标记问题IDEA里pom.xml某一行依赖标红鼠标移上去提示cannot find或者无法解析。常见原因有几个一坐标写错。groupId、artifactId、version拼写错误或者版本号不存在。去Maven中央仓库的搜索页验证一下坐标最直接。二本地仓库缓存了错误版本的元数据。可以把对应目录从本地仓库里删掉然后重新导入。三依赖作用域和打包类型问题。有些依赖是pom类型的需要加typepom/type才能解析不过这种情况少见。四IDEA的缓存问题。有时候依赖明明存在IDEA还是标红可以试试File → Invalidate Caches / Restart重启之后让IDEA重新索引。7.3 idea导入maven项目只编译不下载依赖有时候把项目import进IDEA项目能正常编译运行但外部库里就是没有对应的jar包或者反编译看不到依赖源码。这种通常是IDEA的依赖解析模式问题。可以在项目上右键选择Maven → Reload Project或者点击右侧Maven面板的“刷新”按钮强制重新加载。如果还不行看一下File → Settings → Build Tools → Maven → Importing里JDK for importer的配置是否正确。7.4 多模块项目的依赖管理parent和dependencyManagement如果你维护过稍微大一点的项目大概率会遇到多模块的结构顶层一个父pom下面多个子模块。这时就涉及两个容易混淆的标签dependencies写在父pom里所有子模块都会继承这些依赖。dependencyManagement只定义依赖的版本和管理信息子模块引用对应的坐标时不需要再写版本号。用dependencyManagement可以有效统一各模块的依赖版本避免出现A模块用Jackson 2.15、B模块用Jackson 2.13这种版本分裂。Spring Boot的父pomspring-boot-starter-parent大量使用了这种方式来锁定依赖版本。如果你在子模块里引入依赖时发现版本号是灰色不能填的说明版本已经被父pom锁定了。7.5 环境变量配置了还是找不到mvn命令这个问题我接到的求助最多但也最简单。排查顺序检查MAVEN_HOME指向的目录是否存在且包含bin目录。检查Path变量里是否有%MAVEN_HOME%\bin注意不要写成%、M2_HOME%bin这类格式错误。确保新开的命令行窗口再次执行mvn -v。用echo %MAVEN_HOME%看一下实际读到的变量值确认是否被覆盖。如果是在Git Bash或Cygwin环境里执行有时候找不到mvn那是因为这些终端的环境变量和Windows系统变量同步不完全可以试试直接在CMD窗口里执行。我碰过最离谱的案例是用户配置了MAVEN_HOME为D:\tools\mvn\apache-maven-3.9.9Path里也加了但mvn -v就是报错。最后发现他Path里其他程序把mvn这个命令的地址指到了C:\Windows\System32\mvn.bat——系统里有一个残留下来的同名脚本。用where mvn查到实际命中路径问题就水落石出了。环境变量这种事出错时别瞎猜先查证据。8. 一点个人经验Maven配置的长期维护建议最后分享几个我在实际使用中养成的小习惯能让后面省掉不少麻烦。第一settings.xml里做好注释。每改一个配置就加一行注释标注日期和原因。比如“2025年11月加了阿里云镜像”“2025年11月把本地仓库从C盘挪到D盘”。看起来多余但过半年再回来看的时候你会感谢当年的自己。第二不要随意下载最新版的Maven。在Java生态里“最新版本”在发布后半年内都不一定是“最稳版本”。我经历过的几次坑都是因为项目用了刚发布的新版Maven第三方插件还没跟上导致构建失败。主流的3.9.x用了很久经过大量项目检验就是最稳的选择。第三理解配置文件的优先级。Maven从上到下找配置的顺序是全局settings.xml安装目录conf下的→ 用户settings.xml~/.m2下的→ 项目pom.xml。如果你改了安装目录下的settings.xml但发现配置没生效大概率是用户目录下有一份settings.xml在覆盖。用的时候确认到底哪份生效别改错了文件。第四日常用IDEA就够但关键时候命令行要能用。不管你喜欢用IDE还是命令行mvn -v和mvn clean package这两个操作一定要做到闭眼能敲。当IDE靠不住的时候命令行是你最后的诊断工具。我排查过很多“IDE里编译报错但命令行能通过”或者反过来“命令行报错但IDE没事”的情况根源都是IDE和命令行用的Maven配置不一致。配置好一套顺手的Maven环境之后你会明显感觉到“从零开始的新项目到能跑起来”这件事时间从依赖管理的手动时代的一点磨蹭变成了Maven时代的极速拉取和自动构建。之后无论是学Spring Boot全家桶还是跟进公司老项目都会顺畅非常多。把这篇文章里涉及的基础概念、配置文件、习惯动作都过一遍以后遇到任何依赖相关的问题都不至于两眼一抹黑了。