企业官网建设流程全解析

1. 为什么JavaWeb项目离不开Maven：一个最容易被低估的起步问题

1.1 没有Maven的时候，JavaWeb项目是怎么乱成一锅粥的

这几年我陆陆续续带着一些刚接触JavaWeb的同学写项目，发现一个共同的奇怪现象：很多人学JavaSE时还能轻松写单文件，一到JavaWeb阶段立刻被各种jar包折磨到崩溃。你去下载依赖，一会儿缺这个包，一会儿缺那个包，更难受的是同一个jar包还会出现多个版本，编译的时候不报错，一运行就给你甩一个ClassNotFoundException或者NoSuchMethodError，排查半天也不知道是哪里的版本对不上。

JavaWeb项目和普通的控制台程序不一样，它天生就是"多依赖"项目。Servlet、JSP、数据库驱动、日志组件、JSON处理库……每个功能都要往后端项目里塞一坨第三方代码。在没有Maven这类工具的时候，大家的方式很原始：上网找到jar包下载地址，把文件拖到项目的lib目录，然后在IDEA里右键Add as Library。这套流程看着简单，实际维护起来非常痛苦。我有过一个真实经历：接手一个老课设，lib目录里躺着servlet-api.jar、jsp-api.jar，同时项目里又塞了一份旧版本的catalina.jar，代码里的HttpServletRequest一会儿指向这个包，一会儿又被另一个包影响，IDE的代码提示完全失灵。最后我只能靠最笨的办法——每隔半小时删干净重新编译一次。

所以当你第一次在JavaWeb教程里听到"Maven"这个词时，别把它理解成一个可有可无的小插件，它对这个阶段的开发几乎是救命级别的存在。它解决的，正是上面那堆jar包相关的麻烦，以及"项目怎么从一堆源代码变成一个能部署运行的war包"这件事。

1.2 Maven到底帮你干了哪几件事：坐标、仓库、生命周期

Maven的核心逻辑，我一般用三句话给新手讲清楚。

第一句话叫**"坐标"**。每个第三方库在Maven的世界里都有一个唯一编号，由三部分组成：groupId:artifactId:version，简称GAV。比如你写JavaWeb基本绕不开Servlet API，它对应的坐标里，groupId是javax.servlet，artifactId是javax.servlet-api，version是具体版本号如4.0.1。你在pom.xml里写一行依赖声明，Maven就能根据这三个字段精准定位到那个jar包。

第二句话叫**"仓库"**。Maven会先去本地仓库（默认在系统用户目录下的.m2/repository文件夹）找这个坐标对应的jar包，找不到就去远程仓库下载。远程仓库里最基础的是Maven中央仓库，全世界开源Java项目的jar包几乎都汇聚在那里，你也可以额外配置镜像仓库和私服来加速或托管自有包。

第三句话叫**"生命周期"**。Maven把"编译→测试→打包→部署"定义成了一套固定流程，你只需要执行mvn clean package这样的命令，它就会自动帮你按顺序完成。JavaWeb项目的产出物通常是war包，之后丢进Tomcat的webapps目录就能运行。

这套设计相当于你请了一个"自动进货员"，你只需要提交一份GAV格式的购物清单（pom.xml），他负责跑仓库拿货，再把货物按统一流程装配好。这也是为什么JavaWeb开发人员几乎人手必备Maven——它不是语言的语法，而是项目的"骨架和供应链"。

2. 环境安装前必须想清楚的几件事：JDK版本、Maven版本和镜像源的选择

2.1 JDK与Maven版本的前置关系

很多第一次接触Maven的人上手就踩坑，问题往往不是安装动作错了，而是版本搭配从一开始就埋了雷。Maven本身是用Java写的，所以它运行的前提条件是机器上必须装有JDK。

这里有个容易混淆的点：项目编译时用的JDK版本，和Maven运行时的JDK版本，可以不一样，但都必须已经安装好。当前实践中大量JavaWeb教程仍然基于JDK 8，它足够稳，适配广泛，各种框架的兼容性也最好。如果你用的是JDK 11、JDK 17这类更高版本，同样没问题，但要注意对应的pom.xml编译配置。

至于Maven版本，我建议把它理解为"工具软件的版本"——不必盲目追求最新，选一个被IDEA主流版本兼容的稳定版本即可。常见的Maven 3.6.x、3.8.x、3.9.x，都能很好地支持JDK 8及以上。到官网下载页选择二进制压缩包（apache-maven-3.9.x-bin.tar.gz或对应的zip文件），Windows用户选zip，macOS或Linux用户选tar.gz，你下载的是编译好的成品，不需要再自行构建源码。

2.2 下载解压与环境变量配置

安装过程本身不复杂，真正让新手卡住的往往是环境变量的配置方式。你下载得到一个压缩包后，先解压到本地目录。这里有一个重要的经验：路径中尽量不要出现中文、空格等特殊字符，Windows下尤其注意，C:\Program Files这种路径虽然能配，但后面在脚本解析和IDEA关联时容易出现奇怪问题。稳妥的做法是解压到类似D:\tools\apache-maven-3.9.x这样的目录。

解压完成后，需要配置两个环境变量。第一个是MAVEN_HOME，内容就是Maven解压后的根目录；第二个是在Path环境变量里新增一行%MAVEN_HOME%\bin。这两步都做完，Maven的启动命令才能在任何命令行窗口中被识别。

我见过不少同学只配了MAVEN_HOME，忘了加Path，结果执行mvn -v时说找不到命令，还总觉得是自己安装坏了。所以这里必须强调：环境变量的本质是让系统找到可执行文件所在的目录，MAVEN_HOME只是个引路变量，真正起作用的是Path里的%MAVEN_HOME%\bin。

2.3 settings.xml里的两个"保命"配置：本地仓库与镜像

装好Maven之后，还有一个隐藏配置文件比安装本身更重要——settings.xml。它位于Maven解压目录下的conf文件夹里，控制着本地仓库位置、远程镜像、代理等全局行为。

第一个必改项是本地仓库路径。默认情况下，Maven会把下载到的所有jar包放到C:\Users\你的用户名\.m2\repository。这个设计在绝大多数情况下没问题，但你一旦开始做复杂项目，依赖的数量会迅速膨胀，动辄几万个文件，全塞在C盘不是什么舒服的事。所以我习惯把它改到另一个分区：先手动新建一个目录比如D:\maven-repo，然后在settings.xml中把：

<localRepository>D:/maven-repo</localRepository>

填入配置项。注意这里的路径分隔符用正斜杠，Windows下也没问题。

第二个必改项是远程仓库镜像。默认直连Maven中央仓库在国内网络环境下经常慢到让人怀疑人生，有时一个拉取请求要卡好几分钟。解决的办法是在settings.xml里配置一个镜像站地址。你可以在网上找一个公共Maven仓库镜像，然后把URL填进去。配置模板大概长这样：

<mirrors> <mirror> <id>public-mirror</id> <mirrorOf>central</mirrorOf> <name>Public Maven Mirror</name> <url>https://你的镜像地址/repository/maven-public/</url> </mirror> </mirrors>

这里最关键的是<mirrorOf>central</mirrorOf>，意思是"凡是中央仓库的请求，都转发到这个镜像上"。选用哪个镜像，取决于你所在网络环境哪个快，教程里常见列出不同选项，我的建议很简单：把你搜到的候选地址一个一个试，选最快的那个长期用。这个配置配好的收益立竿见影，依赖下载速度通常能从"等一首歌"变成"眨个眼"。

2.4 用mvn -v验证环境

配置完环境变量和settings.xml后，别急着开IDEA，先打开命令行或者PowerShell，输入：

mvn -v

正常输出会包含Apache Maven的版本、Java版本和操作系统信息。看到类似Apache Maven 3.9.x和Java version: 1.8.x这样的内容，就说明Maven本身装好了。

这一步看似简单，却值得反复确认，因为它是后面所有问题排查的基准。如果你在命令行里能正常执行mvn -v，但在IDEA里却报告Maven找不到，问题大概率出在IDEA侧的配置，而不是安装本身。反之两边都异常，才需要回头检查环境变量顺序和JDK的安装情况。

3. IDEA中Maven的集成：把内置Maven换成自己安装版本，配置项逐个说清

3.1 为什么要替换IDEA内置Maven

IDEA这个开发工具相当贴心，出厂时就内置了一个Maven插件。也就是说，你不做任何配置就能在项目里使用Maven功能。但这里藏着一个小隐患：IDEA内置的Maven版本，通常不是最新的，也不一定与你自己习惯的settings.xml配置挂钩。它会使用一套默认的、位于IDEA安装目录内的Maven，本地仓库路径也比较隐蔽。

如果你只是随便写点小Demo，内置Maven确实够用。但JavaWeb项目一旦认真做起来，你会频繁和依赖、打包、部署打交道，必须有一个能完全掌控的Maven环境。我最推荐的做法是：在IDEA中把Maven显式切换到自己安装的那个版本，同时让IDEA直接读取同一个settings.xml，这样命令行里执行mvn和IDEA内部执行mvn行为完全一致，不会出现"命令行能编译，IDEA里却报缺包"这种割裂局面。

3.2 Settings里必改的三处配置

打开IDEA，进入设置界面（不同系统叫法不同，但操作入口大体一致），找到构建相关工具设置，通常路径是Build, Execution, Deployment下选择Build Tools里的Maven。这里面有三个字段非常关键。

第一个是Maven home path，也就是"要使用哪个Maven"。点选Bundled (Maven 3.x)或手动输入你刚才解压的目录路径。选择完自定义路径后，下方有一行辅助文字会随即变化，显示你选中的Maven版本，这能帮你确认切换是否生效。

第二个是User settings file。它通常默认指向~/.m2/settings.xml，但这个文件你可能一开始并没有创建，所以IDEA的聪明做法是：如果文件不存在，它就使用Maven安装目录下conf/settings.xml作为替代。为了让配置统一，我习惯在这里勾选Override，然后手动指定到我改过的那个settings.xml文件。完成后IDEA会自动读取并显示对应的Local repository路径。

第三个是Local repository，也就是本地仓库位置。只要你指定了正确的settings.xml，这个值会自动跟着变。如果没有自动变，就要小心了，很可能IDEA并没有真正读取你指定的配置文件，它显示的还是默认路径。一旦出现这种情况，依我的排查经验，先检查settings.xml的XML格式是否正确——多一个标签、少一个闭合，IDEA静默跳过的情况很常见。

3.3 Runner与Project SDK之间的关联

Maven配置页里还藏着一个很容易被忽略的角落：Runner设置。打开 Runner 面板，里面有个JRE下拉选项，它决定了IDEA调用Maven执行编译、打包时使用哪个Java环境。这里如果和你项目使用的SDK不一致，就会出现典型的"无效的源发行版"编译错误。

举个例子：你的Project Structure里Project SDK设为JDK 8，但Runner的JRE选项却被设成了更高版本，默认情况下IDEA让Maven使用了自己运行时对应的JDK。如果内部JDK版本与项目语言级别不匹配，你看到的报错就是Error: java: 无效的源发行版或者invalid target release。

解决方式并不复杂：回到项目结构设置，确认Project SDK、Project language level，再回到Maven设置页的 Runner 里，把JRE也调成对应版本。两者保持一致，编译错误就会消失。这个"版本一致性"原则，在整个JavaWeb开发中会反复出现，早点养成检查的习惯能省很多时间。

4. 在IDEA中用Maven构建第一个JavaWeb项目的完整过程

4.1 两种创建方式的取舍：骨架模板还是空项目

配置弄清楚了，接下来就是重头戏：亲手用Maven在IDEA里构建一个能跑的JavaWeb项目。创建项目时，IDEA实际上提供了两条路线。

一条是直接勾选Maven骨架模板，比如maven-archetype-webapp。这个模板能一次性生成JavaWeb的目录结构和标准web.xml，看起来很省事，但它有个明显的缺点：骨架生成的模板版本通常比较老，web.xml头还是Servlet 2.3/2.5时代的老写法，很多现代JavaWeb教程里用到的注解式Servlet它根本不会帮你创建，后续还得手动改一堆配置。

另一条路线是创建一个普通的空Maven项目，不带任何骨架，生成之后再手动添加上JavaWeb需要的目录和依赖。整个过程看似麻烦，但每一步都是可控的，也更贴合"从入门到进阶"的路径——因为你能清楚知道每个目录和文件的用途。

我强烈推荐新手走第二条路。原因不是骨架模板不能用，而是空项目可以帮助你建立对Web项目结构的整体认知。后期你遇到问题，至少知道问题出在哪个层级，而不是对着一个自动生成的陌生项目发呆。

4.2 手工搭建JavaWeb标准目录结构

在IDEA里新建Project，选择Maven作为构建系统，填好groupId、artifactId、version这三个坐标信息，然后一路下一步。生成的空项目目录长这样：

项目名 ├── src │ ├── main │ │ ├── java │ │ └── resources │ └── test │ └── java ├── .idea ├── pom.xml

你会发现里面没有任何web相关的目录。此时需要手工创建两样东西。第一，是必须在src/main下新建一个webapp文件夹，后续Web资源、JSP页面都放这里。第二，是在webapp/WEB-INF下新建一个web.xml文件，这是JavaWeb项目的部署描述文件，掌控着Servlet映射、欢迎页等配置。

创建完成后，还有一个关键但很容易忘记的动作：在IDEA中把webapp目录标记为Web资源目录。不同版本的IDEA操作流程略有差异，通常可以在目录上右键，选择Mark Directory as里的Web Resources Root；或者通过Project Structure→Modules→Web→Web Resource Directories添加路径。这一步如果不做，你的JSP页面和静态资源可能无法被正确编译和打包，最终的war包里就会缺东西。

4.3 在pom.xml中声明war包与Servlet依赖

现在打开项目根目录下的pom.xml，这是JavaWeb项目的"购物清单"。最初生成的格式大致是：

<project xmlns="http://maven.apache.org/POM/4.0.0"> <modelVersion>4.0.0</modelVersion> <groupId>com.example</groupId> <artifactId>demo-web</artifactId> <version>1.0-SNAPSHOT</version> </project>

要让这个普通Java项目变成Web项目，第一件事是告诉Maven打包成war格式。在<version>后面加上：

<packaging>war</packaging>

war就是JavaWeb项目的标准打包产物，内含编译后的类、依赖jar包、静态资源和web.xml，可以直接放入Tomcat的webapps目录。这一步决定了后续mvn package会生成什么类型文件。

第二件是引入Servlet相关依赖。既然写JavaWeb，Servlet API是绕不开的。以最常见的Servlet 4.0为例，在<dependencies>里添加：

<dependencies> <dependency> <groupId>javax.servlet</groupId> <artifactId>javax.servlet-api</artifactId> <version>4.0.1</version> <scope>provided</scope> </dependency> </dependencies>

这里有个值得专门说明的细节：为什么Servlet API的scope是provided？因为Servlet API这套东西，Tomcat运行环境本身已经自带了。如果你打包时将Servlet API一起打进去，部署到Tomcat时反而可能因为两份API重复引发冲突。provided的含义是"编译时需要，运行时由运行环境提供"，所以打包时会自动排除这一点。这个理解非常重要，它对你以后使用Spring、MyBatis等库时选择scope同样有指导意义。

4.4 写一个能跑通的Servlet

依赖配好、目录建好，现在写一个最简Servlet。在src/main/java下新建包，比如com.example.web，然后写一个类：

package com.example.web; import javax.servlet.annotation.WebServlet; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import java.io.IOException; @WebServlet("/hello") public class HelloServlet extends HttpServlet { @Override protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException { resp.setContentType("text/html; charset=UTF-8"); resp.getWriter().write("<h1>Hello JavaWeb, Maven 构建成功</h1>"); } }

这里我没有在web.xml里做任何Servlet映射，而是直接用了@WebServlet("/hello")注解。JavaWeb从Servlet 3.0开始就支持注解式配置，省掉了大量XML内容，也是当前主流写法。

如果你之前学过一点老式的JavaWeb，看到web.xml里密密麻麻的<servlet>和<servlet-mapping>配置不要太紧张。实际开发里注解和XML两种方式都存在，只是注解的方式更简洁，适合学习和中小型项目。但web.xml本身不能删，它是项目作为Web应用被容器识别的基础。

写完Servlet后，你可以先在IDEA里执行一次mvn clean package，观察控制台输出。如果一切顺利，target目录下会生成一个类似demo-web-1.0-SNAPSHOT.war的文件，里面的WEB-INF/classes/com/example/web/HelloServlet.class也能找到，说明编译打包链路已经通了一半。

4.5 在IDEA里配置Tomcat并跑起来

war包产生后，还需要一个运行环境来承载它。JavaWeb的标准运行环境通常是Tomcat。到官网下载Tomcat时注意两个版本分支：Tomcat 9及以前对应的是Java EE规范下的javax.servlet包名；Tomcat 10及以后的开源版切换到了新命名空间，包名变成了jakarta.servlet。前面如果用javax.servlet写的代码，配Tomcat 9最稳妥；如果你装的是Tomcat 10，那么所有导入语句都要改成jakarta.servlet。保持一致，这句提醒请牢记。

在IDEA里，你可以走这样的流程：菜单里选择运行配置，添加一个Tomcat Server类型的本地运行配置（若IDEA团队版不支持此项，也可以先用外置Tomcat把war包手动丢进webapps目录启动）。在配置界面里指定Tomcat安装路径，Deployment页签中添加Artifact选择刚打好的war包，然后点击启动按钮。

浏览器访问http://localhost:8080/hello，看到那句"Hello JavaWeb"，你的第一个Maven构建的JavaWeb项目就跑通了。到这一步，你实际上已经体验了从"写代码→声明依赖→构建打包→部署运行"的整个JavaWeb完整链路。

5. 新手最常踩的6个坑：现象、根因与排查顺序

5.1 mvn命令直接显示找不到

新手第一个高频报错，就是打开命令行输入mvn -v，系统提示找不到命令。排查顺序很简单：先在控制台执行echo %MAVEN_HOME%和echo %Path%，看看环境变量是否生效。如果MAVEN_HOME是空的，说明变量没建或者没保存；如果有值但命令还是找不见，再去看Path里有没有%MAVEN_HOME%\bin这一项。

还有一个少见的坑：你新设置了环境变量，但当前命令行窗口是设置之前就打开的，环境变量的读取发生在窗口启动时，所以不会更新。重开一个命令行窗口再试，绝大多数"找不到命令"的问题都能解决。

5.2 依赖解析进展慢、卡死在一个进度条上

IDEA底部Maven工具窗口的依赖下载状态一直停在那里，或者一编译就卡在某个下载任务上，第一个想到的原因一定是网络问题。此时先看本地仓库对应目录下，是否已经存在一个后缀为.lastUpdated的文件。这个后缀表示"上次下载失败遗留的标记"，Maven遇到它会认为依赖不可用，反复重试但难以成功。

处理方式有三步：第一，确认settings.xml中的镜像配置无误；第二，手动删除本地仓库里报错依赖的整个文件夹，让Maven重新下载；第三，如果还是慢，换一个更快的镜像地址。这个.lastUpdated的机制一度坑过很多新手，知道它的存在能少走弯路。

5.3 IDEA编译报"无效的源发行版"

这个报错非常常见，原因在3.3节里已经点破：Project SDK和Maven Runner的JRE不一致。比如Project SDK是JDK 8，但IDEA内部执行编译时的语言级别被设置成了17，就会出现低级版本源码发行版无效的提示。排查拆成两步走：先看Project Structure里Project SDK和语言级别；再看Settings → Maven → Runner里的JRE选项。把两边统一成同一个JDK版本，报错基本消失。

这里补一句我的经验：哪怕你最后一个项目是JDK 17，另一个老项目是JDK 8，两个项目在同一个IDEA里切换时，这种版本不一致问题特别容易冒出来。进入每个项目时花十秒钟看一眼这两个配置，能避免很多莫名其妙的编译失败。

5.4 Servlet导入始终标红：javax与jakarta的前缀迷局

代码里import javax.servlet.*老是标红，或者编译报"程序包javax.servlet不存在"，八成是遇到了两个问题之一。一是你没有把Servlet API依赖写到pom.xml里；二是你使用的Tomcat 10环境要求的是jakarta.servlet前缀，而你写的是javax.servlet。

JavaWeb的这个命名变更特别有迷惑性，因为网上新老教程混杂，老教程全用javax，新教程可能有jakarta。判断依据只有一个：看你实际使用的Tomcat版本。Tomcat 9及更早用javax.servlet，Tomcat 10及更新用jakarta.servlet。项目里所有import保持一致即可，混用必报错。

5.5 项目能编译但打成war包后缺class文件

有一种隐蔽情况：代码在IDEA里能运行，但把打包好的war包丢进独立Tomcat后，访问页面报404或者说找不到某个类。打开war包里的WEB-INF/classes一看，里面只有几个空目录，编译出的class文件根本不在。

这个问题的根源通常是Web资源目录没有正确标记。如果webapp没有被IDEA标记为Web目录，打包工具就只会收集classes等常规内容，局部资源缺失自然会发生。排查路径很简单：右键src/main/webapp目录，确认Mark Directory as里选的是Web相关选项；或者打开Project Structure，在Modules里检查Web模块的资源路径是否指向了webapp。改完重新mvn clean package再看。

5.6 Tomcat端口被占用，访问直接失败

启动Tomcat时报端口冲突，往往是你之前某个Java进程没关干净，或者其它软件占用了8080端口。手忙脚乱之前，先在命令行执行netstat -ano | findstr 8080，看看哪个进程占用了这个端口。如果你的Tomcat配置里说的是默认8080，而别的服务抢先占用，改端口即可。

我知道一个更常见的"伪报错"场景：在IDEA里启动Tomcat，日志明明已经打出Tomcat started，但浏览器访问却一直加载不出来。这时候先别急着杀进程，可能是项目Artifact没部署到位——IDEA只启动了Tomcat却没有把编译好的war包挂载到Deployment里。检查运行配置的Deployment页签有没有选择对应的Artifact，就这一个地方能卡住不少人。

6. 进阶路上的两个关键习惯：把Maven当构建工具而不是"下载器"

6.1 生命周期命令：clean、compile、package到底该用哪个

很多同学熟悉了Maven之后，反而容易养成一个坏习惯：不管项目怎么变化，永远是执行mvn package，或者干脆在IDEA里点"绿色三角"运行，完全不管Maven在背后做了什么。这其实只停留在"能用"的层次，进阶的第一步是理解Maven生命周期里几个核心命令的分工。

mvn clean负责删除target目录——也就是之前的构建产物，目的是从干净状态重启。mvn compile只编译源码，不做打包。mvn test会执行测试代码。而mvn package在生命周期里的位置是"编译、测试、打包连续进行"。所以最稳妥的组合是mvn clean package：先清掉旧产物，再完整构建一遍，避免增量构建时残留垃圾文件干扰结果。

在遇到诡异问题，比如明明改了代码但运行结果还是旧的，多半就是没有clean。养成一步到位执行mvn clean package的习惯，能消灭一大类"玄学Bug"。

6.2 依赖scope：一句话解释provided和test

依赖的scope（作用范围）虽然只是pom.xml里一个标签，但它决定了一个jar包在整个生命周期中的参与程度。初学者一般只了解compile（默认值，参与编译、打包，运行时都在）。JavaWeb场景另外两个特别实用：provided和test。

provided前面已经举例过，Servlet API、JSP API都该用这个范围，因为运行环境自带了，打包时不必重复带。test则用于JUnit这类测试库，它只在运行测试代码时有用，编译主代码和最终打包都不参与。理解scope能帮你想明白很多"为什么这个依赖加进去没生效""为什么打包后体积这么大"的情况。

6.3 给后续扩展留个口子：多模块与版本统一管理

入门项目的pom.xml一般就一个文件，但真实JavaWeb项目往往会把结构拆成多个模块：一个放通用工具，一个放数据访问层，一个放Web接口。这种结构在Maven里叫多模块工程，父级pom.xml通过<modules>聚合子模块，子模块又通过<parent>继承父模块的公共依赖和配置。

现在你先不用真的拆成多模块，但有一个习惯可以从第一天就养成：把公共依赖的版本号提取到<properties>里。比如：

<properties> <servlet.version>4.0.1</servlet.version> </properties>

后面引用时写成：

<version>${servlet.version}</version>

好处是升级版本时只改一处，整个项目随之统一。这个"一处修改，全局生效"的思路，往后在Spring Boot、微服务阶段会一次又一次用到，现在打底绝对不亏。

我在实际带项目时经常看到一种情况：某个同学把项目从A机器挪到B机器，或者换了个新的IDEA版本，Maven配置就乱了，依赖下载个不停，然后开始怀疑人生。后来我发现，他们绝大多数是忘记了开头那一步——没有把IDEA里的Maven明确指向自己的安装目录和settings.xml。如果你也常被这类问题困扰，建议把配好的settings.xml单独备份一份，换环境时直接覆盖过去，再顺手确认一次Runner的JRE，基本就能一路顺畅走完开发流程。Maven这东西的价值，用久了你会愿意让项目里每一条依赖都"有据可查"，这也是JavaWeb从入门走向进阶很重要的一个分水岭。