maven运行服务器一直报错，绝大多数情况下是环境变量、依赖冲突、端口占用或maven配置这四类问题导致的，按顺序排查就能定位。
maven运行服务器一直报错什么原因？先别慌，按这四步定位
很多人遇到maven报错就习惯去网上搜一段mac的配置命令，结果越搞越乱，其实你只需要一步步看自己的环境,大多数问题都能在十分钟内解决。
- 先跑一遍
mvn -v，看看maven版本和你当前设置的JAVA_HOME是不是匹配，如果这里正常,说明maven本身没毛病。 - 抓完整日志，控制台最下面几行红色字往往只是结果，真正的报错原因藏在中间的某一行，搜
BUILD FAILURE上方的关键字，比如Port already in use、Could not resolve、Failed to execute。 - 回忆最近动了什么，是刚加了依赖，还是改了
settings.xml？大部分maven服务器启动失败都发生在改动之后。 - 分清错误类型，端口问题、依赖问题、插件配置问题、环境变量问题，处理方式完全不同,别拿一个命令套所有场景。
下面这张表能帮你快速对号入座。
| 报错关键词 | 大概率原因 | 处理方向 |
|---|---|---|
Port already in use |
端口被占用 | 换端口或杀进程 |
Could not resolve dependencies |
本地仓库缺包或下载失败 | 清除.lastUpdated重新拉取 |
invalid directory |
JAVA_HOME路径不对 | 重设环境变量 |
Plugin execution not covered |
插件版本或配置问题 | 检查pom插件配置 |
maven启动tomcat报错：先看端口和插件配置
端口占用是tomcat启动失败的第一大坑
你之前启动过一次，但没有正常关闭，再次运行
mvn tomcat7:run就会报Port already in use，这种情况别急着改代码,先查端口。
- Windows用
netstat -ano | findstr 8080，Linux用lsof -i:8080,拿到PID后结束进程。 - 如果8080被别的服务占用了，直接在pom.xml里给插件配置改成
<port>8081</port>。
还有一个容易被忽略的情况：IDEA里残留了旧的tomcat运行实例，去进程列表里找找java进程,干掉之后再启动。
tomcat插件版本和参数配置不对
很多老手踩过坑后都清楚，tomcat7-maven-plugin不兼容Servlet 4.0，高版本JDK环境下直接换个tomcat9-maven-plugin或者用cargo-maven3-plugin更省事。<path>配置里别带斜杠结尾，<uriEncoding>最好显式写UTF-8。
下面是一个会被坑到的配置样例，注意<port>和<path>的值：
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<version>2.2</version>
<configuration>
<port>8081</port>
<path>/web</path>
<uriEncoding>UTF-8</uriEncoding>
</configuration>
</plugin>
配置没问题但还是起不来？执行一下mvn clean再跑,旧构建产物有时候会带来奇怪的问题。
依赖冲突和jar包缺失：maven项目运行不起来原因的两个大头
用依赖树排查冲突
maven项目运行不起来原因里，依赖冲突是重灾区，你本地编译可能没毛病，但服务器启动时抛ClassNotFoundException或者NoSuchMethodError,多半是两个jar包版本打架。
- 在项目根目录执行
mvn dependency:tree,看依赖树里有没有同一个groupId和artifactId出现多次。 - 找到冲突后，在pom.xml里用
<exclusions>排除掉旧版本，或者在dependencyManagement里统一指定版本。
比如spring-boot-starter用的2.7，某个第三方库却引了spring-web 5.3,这种时候就需要你手动锁版本。
本地仓库损坏导致maven服务器启动失败怎么解决
日志里出现Failed to read artifact descriptor或者Could not resolve dependencies，基本可以断定是本地仓库的jar包下载不完整，有个很典型的场景：同事的代码能跑，你的就跑不了,而且每次报错的jar还不一样。
- 进入本地仓库目录
~/.m2/repository，找到报错对应的jar包文件夹，删除其中的.lastUpdated后缀文件。 - 更彻底的办法是直接删掉整个子目录,让maven重新下载。
- 如果公司有私有仓库，检查
settings.xml里的mirror配置有没有写错地址。
maven服务器启动失败怎么解决,这个清理操作能解决其中相当一部分情况。
环境变量和JDK版本，maven服务器报错的隐藏元凶
JAVA_HOME路径里的坑
Windows系统上，maven启动服务器报JAVA_HOME is set to an invalid directory很常见，原因是你把JDK装到了Program Files带空格的路径下面,maven的脚本没正确处理空格。
解决办法很简单：
- 重装JDK到不带空格的路径，比如
D:\Java\jdk17。 - 或者在IDE的Run Configuration里指定正确的JRE路径。
如果是Mac环境，用/usr/libexec/java_home来定位JDK路径更稳。
编译级别与服务器版本不匹配
maven编译器默认有source和target参数，如果pom里写的是1.8，但运行环境是JDK 17,高版本JDK的强封装机制可能让tomcat反射访问失败。
建议在pom.xml里显式指定
maven-compiler-plugin的release参数：
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.10.1</version>
<configuration>
<release>11</release>
</configuration>
</plugin>
行业共识认为，高版本JDK下用<release>比单独配<source>加<target>更安全,因为它会约束整个编译链。
日常避免maven运行报错的三个习惯
- 项目里带上Maven Wrapper，用
mvnw脚本固定maven版本,避免每个人本地环境不一样。 - 定期清理本地仓库里的
.lastUpdated残留文件,一个季度一次就够。 - 每次改完pom.xml先跑
mvn validate，再启动服务器,能提前暴露配置问题。
记住上面的排查顺序，maven运行服务器一直报错多数情况下不是玄学，端口、依赖、环境变量、配置这四个维度覆盖了绝大多数场景，你只需要多看几行日志，多花两分钟验证环境,就能避免大部分启动失败。
关于maven服务器报错排查的常见问题解答
为什么很多报错只出现在服务器启动阶段，编译阶段却没问题？
编译阶段只处理语法和类型，不做运行时加载，但maven启动服务器时会创建类加载器，去加载所有依赖并解析web.xml和Spring上下文，依赖冲突或运行时库缺失都是在启动阶段引爆的，遇到编译通过但启动失败,优先查依赖和资源文件配置。
mvn spring-boot:run和tomcat插件启动报错的处理方式一样吗？
不一样，spring-boot:run内置tomcat，端口冲突时用server.port属性修改，而tomcat插件需要改插件配置，另外spring-boot启动报错更多是组件扫描或配置类问题，看看堆栈第一行就能定位，两者都可以先试试mvn clean再启动。