企业官网建设流程全解析

刚入行的同事抱着电脑过来问：“Maven到底装到哪一步才算真正能用？”这个问题看着简单，真回答起来却要拆成好几层——装了、配了、跑通了、进IDE了、知道怎么在命令行构建了，每一个环节都可能把人卡住。我这些年帮团队搭过不少次Java开发环境，几乎每次都会遇到同样一批问题：下载依赖慢到怀疑人生、IDEA里一堆红、clean install报错后不知道去哪查。所以干脆把Maven从安装到实战的完整链路整理成这篇文章，覆盖环境配置、镜像仓库、IDEA集成、命令行生命周期、依赖管理原理和排错方法论，小白照着走一遍就能落地，有经验的人也可以当作一份错题集来看。

1. 先搞清楚Maven到底帮你解决了什么问题

1.1 没有Maven的时候，开发Java项目有多痛苦

很多人第一次接触Maven，是被项目里的pom.xml文件逼着学的。如果不理解它存在的意义，装完也只是“会敲命令”而已，遇到问题依然懵。

我早些年做Java开发时，项目依赖真是纯手工管理。当时的流程大概是：到官网或者第三方站点下载jar包，然后拷到项目的lib目录下，再在IDE里逐个Add as Library。如果项目引了十几个jar包，这个过程还能应付；一旦项目膨胀到几十上百个jar包，噩梦就来了——jar包版本冲突、本机能跑换台机器就编译不过、别人用了新版本的依赖但svn里还没有提交lib目录，现状一片混乱。构建过程更是原始，要么靠IDE里的Build按钮，要么手写javac命令带上一长串classpath，打包部署全靠手工流程。

1.2 Maven的两个核心：仓库机制和构建生命周期

Maven把这堆烂账彻底理清了。它管两件大事。

第一件，依赖管理。你只需要在pom.xml里声明依赖的坐标，比如groupId、artifactId、version，Maven就会自动从仓库下载对应的jar包，并且把你没声明但依赖本身需要的传承 jar包也一并拉下来。每一个jar包都有唯一坐标，像人的身份证号一样，不会再出现“名字相同但版本不一样”的混乱。

第二件，构建管理。Maven内置了一套完整的构建生命周期，从编译源码、运行测试、打包生成、安装到本地仓库，到发布到远程仓库，都是标准流水线。你执行mvn clean install，它会自己安排顺序，不用你再操心“先编译还是先打包”这种问题。

1.3 “约定优于配置”：为什么Maven的目录结构那么死板

Maven强调“约定优于配置”：约定了一个标准目录结构，符合约定就不需要额外配置。

project-root ├── pom.xml ├── src │ ├── main │ │ ├── java # 主代码 │ │ └── resources # 资源配置文件 │ └── test │ ├── java # 测试代码 │ └── resources # 测试资源 └── target # 构建输出目录

这个结构看起来死板，但好处是显著的——任何一个人接手Maven项目，不用重新学目录规则；任何Maven项目拿到本地都能用同一套命令构建。团队协作时，这套约定省下的沟通成本非常可观。

另外，既然聊到坐标，就顺便提一下查坐标的关键入口。去mvnrepository.com或者Maven中央仓库的搜索页（search.maven.org），输入类名或关键词，能找到对应依赖的完整坐标。这个习惯养成后，新增依赖会快很多。

2. 下载和安装：版本选择、环境变量与JDK版本兼容

2.1 先装JDK，再装Maven，顺序不能反

Maven本身是Java写的，运行时必须依赖JDK，所以安装顺序永远是：JDK → Maven。很多人装完Maven后执行mvn -v报错，十有八九是因为JAVA_HOME没配置好，或者干脆就没装JDK。

JDK版本和Maven版本是有对应关系的。老项目还在跑JDK 8的话，建议用Maven 3.6.x或3.8.x；如果用了JDK 11或17，3.9.x是更合适的。这里要额外提醒一下，网上很多文章会写成“maven 3.88”，实际是3.8.8，不要被拼写误导了。

我自己目前主力用的是3.8.8，兼容性成熟，几个老项目和新项目都没出过问题。3.9.x也能用，但部分老旧插件如果不更新会碰到兼容报错。如果你只是给个人项目用，建议直接选择当前稳定版（以官方公布为准）；如果是公司项目，先问清楚团队统一用哪个版本，不要各自为政。

2.2 Windows下的安装流程：MAVEN_HOME与PATH配置

Windows安装Maven的完整步骤大概是：

1. 从Apache官网的archive目录或者软件源下载二进制压缩包，一般选择zip包为佳。
2. 解压到纯英文路径，比如D:\dev\apache-maven-3.8.8，路径中不要带中文和空格，否则后续配置容易出莫名其妙的问题。
3. 打开“环境变量”配置界面，新建MAVEN_HOME，值填Maven的解压目录。
4. 在Path变量中新增%MAVEN_HOME%\bin。
5. 重新打开命令提示符，执行mvn -v验证。

为什么很多人建议配MAVEN_HOME而不是直接在Path里写完整路径？因为后续想要切换Maven版本时，只需要改MAVEN_HOME这个变量值，Path里的内容不动就行。直接写完整路径的话，每次换版本就要动Path，麻烦且容易出错。

Windows上最常遇到的一个问题是：明明配好了环境变量，新开的命令行窗口还是提示'mvn' 不是内部或外部命令。这是因为命令行窗口启动时读取的环境变量是登录时缓存的，配置完环境变量后必须重新打开命令行窗口，不要复用已经存在的旧窗口。

2.3 macOS与Linux下的安装差异

macOS上安装有两种常见方式。用Homebrew的话，一条brew install maven就能完成，但Homebrew安装的Maven版本可能和自己项目的兼容性有偏差。我更推荐手动安装：

1. 把下载好的tar.gz包解压到/usr/local/maven/apache-maven-3.8.8。
2. 编辑~/.zshrc文件（Catalina之后默认shell是zsh），加上两行环境变量：

export MAVEN_HOME=/usr/local/maven/apache-maven-3.8.8 export PATH=$MAVEN_HOME/bin:$PATH

3. 执行source ~/.zshrc让配置立即生效，再执行mvn -v验证。

Linux服务器上建议下载tar.gz后解压，并做软链接，方便后续升级版本：

tar -zxvf apache-maven-3.8.8-bin.tar.gz -C /opt/ ln -s /opt/apache-maven-3.8.8 /opt/maven export MAVEN_HOME=/opt/maven export PATH=$MAVEN_HOME/bin:$PATH

软链接的好处是：新版本下载后，只需要把链接指到新目录，环境变量不用改动。

2.4 验证安装：mvn -v输出怎么看

执行mvn -v后，会输出类似下面一段内容：

Apache Maven 3.8.8 (b3f53f2c4d5d2f0f8c2e0a7d9d3c6d5e4f3b2a1) Maven home: D:\dev\apache-maven-3.8.8 Java version: 1.8.0_202, vendor: Oracle Corporation, runtime: C:\Program Files\Java\jdk1.8.0_202

重点看两个地方：一是Maven版本号，二是Java版本。如果JAVA_HOME没配置好，这里会直接提示找不到Java环境。如果你运行的是JDK 8，就乖乖用3.6.x/3.8.x，别强行上太高版本；反之，如果你用了JDK 17还配着很老的Maven版本，构建时也可能遇到垃圾回收器参数不识别等问题。

3. 国内环境必做的两件事：阿里云镜像与本地仓库规划

3.1 为什么不改镜像你会等很久

Maven默认从中央仓库下载依赖，而中央仓库服务器在海外，国内直连的速度很拉垮。一个Spring Boot项目首次构建要拉几百MB的jar包，不改镜像的话，等几分钟是常事，更严重的会直接超时失败。所以国内环境装好Maven之后，第一件事就是配镜像。

另外，Maven默认的本地仓库在~/.m2/repository，也就是用户目录下。如果你C盘空间紧张，依赖下载多了之后C盘被撑爆也是真实会发生的。所以本地仓库换盘规划也很重要。

3.2 settings.xml 到底在管什么

Maven的所有全局配置都集中在settings.xml文件里。这个文件有两级：

• 全局配置：在Maven安装目录的conf/settings.xml下，影响该Maven的所有使用者。
• 用户配置：在~/.m2/settings.xml下，只对当前用户生效。用户配置会覆盖全局配置。

配置生效优先级很高：同一项配置，用户级settings.xml的优先级大于全局。所以我建议你直接把个人配置写到用户级文件里，不要随便动全局配置，避免影响机器上其他项目。

如果用户目录下还没有settings.xml，可以直接从Maven安装目录复制一份过去的，然后按需修改。

3.3 本地仓库：换盘符、多项目复用

在settings.xml中配置本地仓库的方式很简单：

<settings> <localRepository>D:/maven/repository</localRepository> </settings>

注意这里路径用正斜杠，Windows下写成D盘路径即可。

本地仓库的作用是缓存所有下载过的依赖。换盘符之后有个明显好处：无论你装了多少个Maven版本，它们共用同一个本地仓库，依赖不会重复下载。我之前把本地仓库放在用户目录时，换Maven版本就以为要重新下载依赖，其实只要仓库路径不变，缓存依然是有效的。

3.4 阿里云镜像配置与多镜像并存

在settings.xml里<mirrors>标签下添加mirror节点，最经典的阿里云配置如下：

<mirror> <id>aliyunmaven</id> <mirrorOf>central</mirrorOf> <name>阿里云公共仓库</name> <url>https://maven.aliyun.com/repository/public</url> </mirror>

这里的<mirrorOf>central</mirrorOf>意思是：拦截掉对中央仓库（central仓库）的请求，转去阿里云拉取。如果你写的是<mirrorOf>*</mirrorOf>，那意味着所有仓库请求都会被这个镜像接管。这两个写法的区别要记住：

• central：只镜像中央仓库，更适合公司里还有私有仓库（Nexus/Artifactory）的场景。
• *：所有仓库都走镜像，包含自定义仓库ID，可能导致私有仓库的依赖拉取也被强制转发到镜像，容易出问题。

如果你要配置多个镜像，比如阿里云为主、华为云兜底，就要注意Maven只会使用第一个匹配到的mirror，后面的不会生效。所以多镜像配置并不是“自动切换”，而是要根据mirrorOf的匹配规则来精确控制。日常使用中，一个阿里云镜像就够覆盖绝大多数情况了。

此外，如果你公司内部搭建了Nexus私服，建议在mirrorOf中写成external:*或者直接指定仓库ID，不要把私服请求也转发到阿里云。

最后，设置完settings.xml后，建议在命令行执行一次验证：

mvn help:effective-settings

这个命令会打印出最终生效的settings.xml内容，能看到本地仓库路径和镜像是否生效，排查配置问题时非常有用。

4. IDEA集成：从配置到新建项目的完整链路

4.1 是内置Maven还是自己装的Maven？

IDEA自带了Maven，开箱即用。但我强烈建议把IDEA指向你自己安装的Maven，原因有三：

1. IDEA内置的Maven版本相对固定，可能和团队统一版本不一致。
2. 内置Maven读取的是IDEA默认的settings，镜像和本地仓库路径不好统一管理。
3. 命令行和IDEA共用同一套Maven，能保证两边行为一致，避免“IDE里能跑，命令行构建却失败”的尴尬。

4.2 IDEA中配置的三个关键路径

打开IDEA，进入Settings → Build, Execution, Deployment → Build Tools → Maven，这里有三个核心配置项：

• Maven home path：选择你自己安装的Maven目录，比如D:\dev\apache-maven-3.8.8，点下拉框选择即可。
• User settings file：这里要勾选Overrides，然后手动指定到你自己的settings.xml路径。勾选Override的意义在于，IDEA默认可能读取不到用户目录下的settings.xml，尤其是Windows环境权限问题。
• Local repository：当你正确指定了settings.xml后，这里的本地仓库路径会自动读取并变成灰色，显示为settings.xml中配置的路径。

配置完毕后，点击Apply和OK，IDEA会自动重新索引Maven项目。

4.3 新建Maven项目与导入已有项目的要点

新建Maven项目：File → New → Project，左侧选Maven，右侧选择Create from archetype。一般新手直接用maven-archetype-quickstart这个模板即可。然后填写GroupId（一般是公司域名反写，如com.example）、ArtifactId（项目名，如my-demo）、Version。

这里有个常见坑：新建项目时IDEA会去中央仓库下载archetype相关的模板元数据，国内网络经常会卡很久。解决办法是在IDEA的VM Options里加上：

-DarchetypeCatalog=internal

意思是直接使用IDEA本地自带的archetype模板，不从远程拉取，速度会快很多。

导入已有Maven项目更简单，直接File → Open选择项目根目录下的pom.xml，IDEA会识别为Maven项目并自动加载依赖。如果你是先打开了一个普通目录，可以看到pom文件右键也有Add as Maven Project选项。

4.4 实际使用中容易翻车的几个细节

第一个细节，JDK级别不一致。Maven项目构建时，IDEA默认读pom.xml里配置的maven.compiler.source和maven.compiler.target。如果这里配了1.8，但你的Project SDK选的是17，虽然代码能跑，但编译级别其实是1.8，部分新特性用不了。建议统一在Project Structure → Project里设置SDK，并确认pom里编译级别一致。

第二个细节，settings.xml没生效。很多人改了~/.m2/settings.xml后，发现IDEA里下载依然慢。大概率是IDEA没有勾选Override，或者在Maven设置里指定的settings路径和实际修改的路径不一致。建议把设置页截图保存，每次配置完检查Local repository路径是否正确变成自己的路径。

第三个细节，首次导入大项目时依赖下载慢。可以先在命令行执行一次mvn clean install让依赖完整下载到本地仓库，然后再用IDEA打开项目，这样IDEA加载时大部分依赖已有本地缓存，速度会快很多。

第四个细节，构建输出乱码。在Maven Runner的VM Options里加一行-Dfile.encoding=UTF-8，同时在环境变量里加MAVEN_OPTS=-Dfile.encoding=UTF-8，可以解决大部分编译输出中文乱码问题。

5. 命令行实战：clean、install、package背后的构建生命周期

5.1 mvn clean install 到底做了什么

很多人把mvn clean install当成一句咒语，背下来了却不知道它分两步干什么。拆开看：

• clean：清空target目录，把所有上一次构建的产物删掉，保证这次构建是从干净状态开始的。
• install：执行从编译到打包再到安装的完整生命周期，把最终产物安装到本地仓库中。

Maven有三套生命周期：clean生命周期（清理）、default生命周期（核心构建）、site生命周期（生成站点文档）。日常使用最多的就是前两套。

install命令本身会触发default生命周期中的所有前置阶段。default生命周期的核心阶段顺序大致如下：

validate（校验） compile（编译主代码） test（运行测试） package（打包） verify（检查） install（安装到本地仓库） deploy（部署到远程仓库）

重点是阶段之间是顺序依赖的：执行mvn install时，会自动执行compile、test、package，不用你手动一步步来。同理，执行mvn package会先编译和跑测试，执行mvn test就会先compile。

5.2 高频命令组合速查表

日常开发中，我用得最多的命令基本是下面这些：

-DskipTests和-Dmaven.test.skip=true的区别值得多讲一句。前者是“测试代码我编译了但我不跑”，后者是“测试代码根本不编译”。日常只想跳过测试跑，用-DskipTests更稳妥，至少能发现测试代码编译错误。

5.3 多模块项目的构建技巧

当一个项目由多个Maven模块组成时，比如：

parent-project ├── pom.xml ├── common-module ├── service-module └── web-module

如果只想构建web-module，并且需要它依赖的其他模块也一并构建，可以这样：

mvn clean install -pl web-module -am

• -pl：指定要构建的模块列表。
• -am（also make）：同时构建被指定模块依赖的其他模块。

如果不用-am，当web-module依赖的service-module还没有安装到本地仓库时，构建会报找不到依赖。这个参数在多模块开发中几乎每天都会用到。

5.4 自定义属性、Profile与资源过滤

POM中常用<properties>来统一管理版本号：

<properties> <spring.version>5.3.20</spring.version> </properties>

然后在依赖中引用：

<dependency> <groupId>org.springframework</groupId> <artifactId>spring-core</artifactId> <version>${spring.version}</version> </dependency>

这样升级Spring版本时只需要改一处属性值，所有相关依赖同步更新，避免东改一个西漏一个。

<profiles>则用于构建环境的差异化配置，例如区分开发环境、测试环境和生产环境。你可以在不同profile下定义不同的properties值，构建时通过-P激活对应profile：

mvn clean package -P prod

Profile的典型应用是资源文件替换：把src/main/resources/中的配置文件里，用${db.url}这类占位符代替真实值，然后为每个环境配置不同的profile属性。构建时Maven会按激活的profile替换占位符。这块涉及到资源过滤：

<build> <resources> <resource> <directory>src/main/resources</directory> <filtering>true</filtering> </resource> </resources> </build>

加上<filtering>true</filtering>后，占位符才会被替换，否则Maven会原样保留${db.url}，导致运行时报配置错误。

6. 依赖管理：从“下载jar包”到“自动解析”的转变，以及冲突排查

6.1 坐标体系：groupId、artifactId、version

Maven把所有依赖都抽象成坐标三个要素，在pom.xml里通过这三个坐标唯一定位一个jar包：

• groupId：组织或公司的标识，一般用域名反写，比如com.alibaba。
• artifactId：项目或模块的名字，比如fastjson。
• version：版本号，比如1.2.83。

可以打个比方：groupId是“哪个城市的哪个街道”，artifactId是“小区名字”，version是“楼栋号”。三者组合起来，才能精确找到一个jar包。

6.2 依赖传递与scope

Maven依赖有一个重要特性：传递性。如果你的项目引用了某个jar包A，而A又引用了B和C，那么你的项目也会自动获得B和C。这个机制省去了手动补依赖的麻烦，但也带来了6.3节要讲的冲突问题。

每个依赖可以通过<scope>控制生效范围。最常见的几种scope：

provided这个scope值得单独说明：它表示编译时需要这个jar包，但部署到容器后，容器自己会提供同款jar包，所以打包时不能打进去。最典型的就是javax.servlet-api，tomcat里已经有了，如果打进去反而会产生冲突。

6.3 依赖冲突是怎么产生的

依赖传递带来了一个副作用：你项目的依赖树里，同一个库可能出现多个不同的版本。

比如项目直接依赖了A 1.0，而A 1.0内部依赖了C 1.0；同时项目还依赖了B 1.0，B 1.0内部依赖了C 2.0。那么依赖树里同时存在两个版本的C，到底用哪个？

Maven有自己的仲裁规则：

1. 最短路径优先：谁的依赖路径深度短，谁获胜。
2. 第一声明优先：如果路径深度相同，谁在pom.xml中声明得更靠前，谁获胜。

举个反直觉的例子。项目直接依赖了guava 28.0（路径深度为1），同时某个传递依赖又带入了guava 30.0-jre（路径深度为2）。按最短路径优先规则，Maven会选择直接依赖的guava 28.0，而不是版本号更新的30。如果代码里用到了30才有的API，运行时就会出NoSuchMethodError。

这种问题最阴险的地方在于：编译时一般不会报错，因为28.0也能编译通过；到了运行阶段，某个方法找不到实现，才突然崩溃。排查难度极大。

6.4 冲突排查：mvn dependency:tree 实战

排查依赖冲突的第一利器是mvn dependency:tree。它能把整个依赖树完整打印出来：

mvn dependency:tree

如果只想看某个特定包的情况，加上-Dincludes参数：

mvn dependency:tree -Dincludes=com.google.guava:guava

输出会显示出guava在依赖树中的所有出现路径：

[INFO] +- com.example:project:jar:1.0-SNAPSHOT [INFO] | \- com.google.guava:guava:jar:28.0:compile [INFO] +- com.example:service-a:jar:2.0:compile [INFO] \- com.google.guava:guava:jar:30.0-jre:compile (versions selected from...

从输出里能直观看到哪个路径短、哪个路径长、最终被选择了哪个版本。解决冲突有几种方案：

方案一，在pom.xml中显式声明你想要的版本。因为直接声明的依赖路径深度为1，必然最短，直接压制传递来的版本。

方案二，使用<exclusions>排除某个依赖：

<dependency> <groupId>com.example</groupId> <artifactId>service-a</artifactId> <version>2.0</version> <exclusions> <exclusion> <groupId>com.google.guava</groupId> <artifactId>guava</artifactId> </exclusion> </exclusions> </dependency>

方案三，在父POM中用<dependencyManagement>统一定版本。这个方案最优雅，它不直接引入依赖，但会控制所有直接和传递依赖的版本。子模块里声明依赖时如果不写version，就会自动使用dependencyManagement里统一的版本。

6.5 依赖管理的日常习惯

依赖冲突没法完全避免，但可以通过好习惯减少发生频率：

1. 新增依赖时，尽量通过mvnrepository或IDE的依赖搜索功能查询，确认版本之间的兼容性。
2. 每次换版本号，构建后跑一次mvn dependency:tree，养成扫一眼的习惯。
3. 核心依赖的版本尽量收敛到<properties>里统一管理，不要散落在各个子模块中。
4. 遇到NoSuchMethodError或ClassNotFoundException这类运行时异常时，首先怀疑依赖冲突，直接跑dependency:tree查一下，往往能找到答案。

7. 高频问题排查与我的实操建议

7.1 安装配置阶段最常见的错误

错误一：'mvn' 不是内部或外部命令。原因只可能是环境变量没配好。检查MAVEN_HOME是否指向正确目录，Path里有没有%MAVEN_HOME%\bin，以及命令行窗口是不是旧窗口没重开。Windows上还有一个隐蔽问题：如果系统还装了Scoop、Chocolatey之类的包管理器，可能把另一个Maven版本加入了PATH，导致执行的是旧版本，用where mvn能看到实际执行的路径。

错误二：JAVA_HOME is not defined correctly。说明JAVA_HOME路径配置有问题。Windows环境变量中，JAVA_HOME应该指向JDK安装根目录，比如C:\Program Files\Java\jdk1.8.0_202，而不是深入到bin目录。macOS/Linux上，注意JAVA_HOME不能带上/bin，否则也会报同样的错。

错误三：Maven版本和JDK不兼容。我见过不少使用JDK 17却搭配Maven 3.5的项目，构建时报奇怪的警告或错误。遇到这种问题，先查兼容性对照表，把Maven升到3.8.8+再试。

7.2 依赖下载报错的原因与处理顺序

依赖下载失败是最常见也最让人抓狂的问题。典型的报错有Could not resolve dependencies、Cannot access central、PKIX path building failed等。

我的排查顺序一般是：

1. 首先检查网络，确认是否能访问配置的镜像仓库地址。
2. 打开~/.m2/repository，找到报错依赖对应的目录，把里面以.lastUpdated结尾的文件删掉。这些文件是Maven下载失败后留下的“失败标记”，它存在的时候，Maven会认为这个依赖已经尝试过了，即使网络恢复了也不会重新下载。
3. 如果本地仓库里已经有一堆损坏的半截jar包，可以把整个~/.m2/repository目录备份后清空，让它重新下载，虽然耗时，但能排除缓存损坏的问题。
4. 切换或补充镜像源。如果阿里云的镜像本身也抽风，可以临时换成华为云镜像：

<mirror> <id>huaweicloud</id> <mirrorOf>central</mirrorOf> <url>https://repo.huaweicloud.com/repository/maven/</url> </mirror>

遇到过证书报错（PKIX path building failed）时，不要想着导入证书这种偏门操作，直接换用HTTPS的镜像源，大多能绕过去。

7.3 编码问题：GBK乱码与UTF-8配置

Java开发环境默认编码不统一，经常导致两种问题：一是Maven编译时报告无法读取某个文件的字符，二是编译输出到控制台的中文乱码。

在pom.xml中显式指定编译编码是最直接的方式：

<properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> </properties>

同时在Maven的配置里加上MAVEN_OPTS=-Dfile.encoding=UTF-8，确保Maven进程自身也使用UTF-8。

Windows上如果IDEA控制台依然乱码，还可以在IDEA的Help → Edit Custom VM Options里加上一行-Dfile.encoding=UTF-8，然后重启IDEA。

7.4 我这几年的实操建议

最后分享几条实操层面的经验。

第一，Maven版本和JDK版本一样属于团队级基础配置，最好在入职文档或项目README里写明。我见过太多“本机能跑，同事那边死活编译不过”的案例，最后查下来往往是Maven版本不一致导致插件行为不同。有条件的话，在项目里用Maven Wrapper（mvnw）把Maven版本锁定在项目级，这样任何人拉代码后执行./mvnw都会自动下载并使用项目指定的Maven版本，彻底消除版本差异问题。

第二，settings.xml一定要做好备份。Windows重装、换电脑、升级Maven前，先把~/.m2/settings.xml复制一份。这个文件里的本地仓库地址、镜像配置、私服账号密码都是花时间攒出来的，丢了重配很痛苦。我自己的做法是把settings.xml放到Git仓库里，换电脑直接拉下来用。

第三，给Maven分配足够的内存。大型项目构建时OOM并不罕见，可以在MAVEN_OPTS里配置：

export MAVEN_OPTS="-Xms512m -Xmx2048m -Dfile.encoding=UTF-8"

Windows在环境变量里添加同名变量即可。这个配置还能顺手解决编码问题。

第四，不要贪新。Maven的新版本出来之后，不要急着在核心项目上升级，先在个人项目里跑一段时间验证兼容性。稳定比新版本特性更重要，这是所有构建工具的共同哲学。

我折腾Maven这些年，最大的体会是：安装只是热身，真正决定使用体验的其实是三个点——镜像配得好不好、本地仓库规划得合不合理、IDE和命令行有没有用同一套配置。这三个点理顺了，后续的日常开发和排错都会顺畅得多。如果你现在还在被“装好之后下载依赖慢、IDEA一直报红”困住，回头检查一下是不是只装了Maven却没配置settings.xml，大概率一下就能破案。