1. 别再背“Maven是构建工具”了——先搞懂它到底在替你管什么你刚学Java装完JDK写了个HelloWorld.java用javac编译、java运行一切顺利。可当项目加到5个类、3个包、还要连数据库、发HTTP请求、生成PDF时你突然发现光靠命令行敲javac已经不行了。文件越来越多依赖jar包手动下载、复制、粘贴、版本冲突、路径错乱……这时候有人告诉你“用Maven吧。”你点开官网看到“Apache Maven is a software project management and comprehension tool”心里一咯噔——“项目管理理解工具这说的是人话吗”别急。我带过二十多届校招新人几乎所有人第一次接触Maven都被这个“高大上”的定义吓退过。但真相特别朴素Maven不是在帮你“构建”而是在帮你“管家”——管代码结构、管依赖关系、管构建流程、管发布归档而且是按一套公认的家庭规矩来管。它不生产代码也不执行编译但它像一个经验丰富的项目经理行政主管档案管理员的合体把所有琐事标准化、自动化、可追溯。你搜“maven是干嘛的”首页答案千篇一律“自动化构建工具”。这没错但毫无指导性。就像问“冰箱是干嘛的”答“制冷电器”——技术上正确实操中毫无价值。真正该问的是它解决了我手敲javac时哪几个具体痛点我给你列出来全是真实踩过的坑你从网上下载了一个commons-lang3-3.12.0.jar放进lib目录两周后发现另一个库也依赖lang3但要求3.9.0两个版本共存Classpath里谁优先你删了又试试了又删最后程序跑起来报NoClassDefFoundError查了三小时才发现是版本打架你写了DAO层想用MySQL驱动去mysql.com下载mysql-connector-java-8.0.33.jar结果发现IDE里提示“Driver not found”翻文档才发现要加Class.forName(com.mysql.cj.jdbc.Driver)而新版本其实已支持SPI自动注册——你根本不知道自己在填一个早已过时的坑你把项目打包成jar发给同事对方双击打不开说“no main manifest attribute”你翻Maven文档才明白原来MANIFEST.MF不是自动生成的得配maven-jar-plugin你本地跑得好好的扔到测试服务器就报“Could not resolve dependencies”一查日志原来是公司内网没连外网中央仓库访问不了而你根本没配过镜像源。这些都不是“不会用Maven”的问题而是没有理解Maven设计哲学的必然结果。它强制你接受一套约定Convention over Configuration源码必须放src/main/java资源文件放src/main/resources测试代码放src/test/java……这不是教条是降低协作成本的共识。就像交通规则——红灯停绿灯行本身没技术含量但没了它整个系统瘫痪。所以本教程不从“下载安装”开始而是从你写第一行Java代码那一刻的真实困境切入。我们不背概念只解决你明天就要面对的问题怎么让五个类的项目不用手动管理jar包一键编译、测试、打包、运行怎么确保换台电脑、换个人接手结果完全一致怎么让别人看你项目3秒内就知道它用了哪些库、版本多少、怎么启动这才是Maven存在的全部意义。提示本文所有操作均基于Maven 3.9.x当前最新稳定版JDK 17。如果你还在用JDK 8请立刻升级——不是为了时髦而是因为Maven 3.9已默认要求Java 11且JDK 17的长期支持LTS特性对现代Java开发更友好。别让环境问题成为你理解Maven的第一道墙。2. 配置不是“复制粘贴”而是建立你的本地Maven宇宙坐标系很多人卡在第一步Maven安装与配置。网上教程清一色教你“下载zip → 解压 → 配环境变量 → 验证mvn -v”。做完发现命令行能打印版本号就以为成了。结果新建项目pom.xml里写个 IDE报红mvn compile报错“Could not resolve artifact”你懵了“明明装好了为啥找不到jar”问题不在安装而在配置没完成闭环。Maven的配置不是单点动作而是一套三层坐标系的建立过程本地仓库Local Repository→ 远程仓库Remote Repository→ 仓库镜像Mirror。缺任何一层你的Maven宇宙就是残缺的。2.1 本地仓库你的私有jar保险柜位置比内容更重要当你执行mvn compileMaven做的第一件事不是编译而是检查本地仓库有没有所需依赖。本地仓库默认在用户主目录下的.m2/repositoryWindows是C:\Users\用户名.m2\repository。这个路径可以改但强烈建议不要改——不是因为不能而是因为几乎所有IDE、CI工具、团队规范都默认读这里。你改了同事拉你代码IDE认不出依赖CI流水线跑不通最后还得改回来。验证本地仓库是否健康最直接的方法不是看目录是否存在而是看它是否被正确初始化。打开终端执行mvn help:system这条命令不编译项目只输出Maven运行时的系统信息。重点看两行maven.home: C:\apache-maven-3.9.6 user.home: C:\Users\yourname localRepository: C:\Users\yourname\.m2\repository如果localRepository路径是你预期的说明Maven已识别到你的家目录。此时你可以手动创建一个空的pom.xml内容先空着执行mvn validateMaven会尝试解析pom.xml并初始化本地仓库结构——你会看到.m2/repository下开始出现org/apache/maven/...等目录。这是Maven在为你铺路。注意不要手动往.m2/repository里拖jar包这是Maven的“禁区”。所有jar必须由Maven自己下载、校验、解压、索引。手动放进去Maven不认识下次更新依赖时可能覆盖或忽略导致诡异的ClassNotFoundException。2.2 远程仓库中央仓库只是起点不是唯一真理Maven默认从Maven Centralhttps://repo.maven.apache.org/maven2/下载依赖。但现实很骨感中央仓库在国内访问极慢经常超时很多企业内部库如自研中间件、加密SDK根本不在中央仓库开源项目有时会把快照版SNAPSHOT放在其他仓库如Sonatype OSSRH。所以远程仓库配置的本质是告诉Maven“当我要找一个jar时按这个优先级顺序去哪些地方找。” 这个顺序写在settings.xml里而不是pom.xml。为什么因为仓库地址是环境相关的公司内网用私服家里用阿里云镜像而pom.xml是项目相关的这个项目需要哪些库必须分离。settings.xml有两个位置全局$MAVEN_HOME/conf/settings.xml影响本机所有Maven项目用户级$USER_HOME/.m2/settings.xml推荐只影响当前用户不污染全局我们只配用户级。新建C:\Users\yourname\.m2\settings.xml内容如下以阿里云镜像为例?xml version1.0 encodingUTF-8? 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 http://maven.apache.org/xsd/settings-1.0.0.xsd mirrors mirror idaliyunmaven/id mirrorOfcentral/mirrorOf name阿里云公共仓库/name urlhttps://maven.aliyun.com/repository/public/url /mirror /mirrors /settings关键字段解释id镜像唯一标识随便起但别用特殊字符mirrorOf这是核心它表示“这个镜像替代哪个仓库”。central代表Maven Central*代表所有仓库慎用external:*代表除localhost和file协议外的所有仓库url镜像地址阿里云、腾讯云、华为云都有公开镜像选一个即可。配完后执行mvn help:effective-settings能看到生效的配置。再执行mvn dependency:get -Dartifactorg.springframework:spring-core:5.3.30观察下载日志——如果URL显示的是maven.aliyun.com说明镜像生效。2.3 环境变量PATH只是入口MAVEN_HOME才是灵魂很多教程只教设PATH漏了MAVEN_HOME。后果是什么mvn -v能运行但某些插件如maven-release-plugin会因找不到MAVEN_HOME而报错IDE如IntelliJ集成Maven时如果只设PATH可能无法正确识别Maven版本和配置CI工具如Jenkins脚本里常需引用$MAVEN_HOME/bin/mvn没设MAVEN_HOME就失败。正确做法Windows新建系统环境变量MAVEN_HOME值为Maven解压目录如C:\apache-maven-3.9.6编辑PATH添加%MAVEN_HOME%\bin重启终端重要环境变量修改后已打开的cmd不生效。验证echo %MAVEN_HOME% mvn -v如果mvn -v输出里显示Maven home: C:\apache-maven-3.9.6说明MAVEN_HOME设置成功。实操心得我见过太多人反复重装Maven就因为PATH里写了C:\apache-maven-3.9.6\bin却没设MAVEN_HOME。记住口诀“PATH让你能敲命令MAVEN_HOME让Maven知道自己是谁。”3. pom.xml不是XML文件而是你项目的DNA说明书新手最怕pom.xml。打开一个别人的pom.xml满屏projectmodelVersiongroupIdartifactId...像天书。于是抄一个模板改几个名字勉强跑通但完全不懂每个标签在干什么。结果升级Spring Boot版本时把parent删了项目直接编译不过想排除某个传递依赖写了exclusion却放错位置没生效打包时想包含配置文件配了resources却忘了filteringtrue/filtering占位符没替换。pom.xml的核心是用声明式语法描述项目元数据和构建契约。它不写“怎么做”只写“是什么”和“要什么”。Maven根据这份说明书自动推导出怎么做。理解它关键是抓住三个核心维度身份标识、能力声明、行为契约。3.1 身份标识groupId/artifactId/version——你的项目全球身份证这是pom.xml最顶层的三要素缺一不可groupIdcom.example/groupId artifactIdmy-web-app/artifactId version1.0.0-SNAPSHOT/versiongroupId公司/组织域名倒写不是包名。com.example代表example.com这个组织不是com.example.controller这个包。它定义了你在Maven宇宙中的“国家”artifactId项目在组织内的唯一名称不是模块名。my-web-app是项目名不是web或app这种模糊词。它定义了你的“城市”version版本号遵循语义化版本SemVer主版本.次版本.修订号。1.0.0-SNAPSHOT中的SNAPSHOT表示“快照版”即正在开发中、随时可能变更的版本。发布正式版时去掉-SNAPSHOT如1.0.0Maven会将其发布到远程仓库的release区禁止覆盖。为什么必须严格因为Maven用这三者生成坐标Coordinatecom.example:my-web-app:1.0.0-SNAPSHOT。这个坐标是jar包在仓库里的唯一地址也是你引用它的唯一方式。就像快递单号——少一位数字包裹就寄丢。常见错误把groupId写成com.example.project认为“project”是项目名。错groupId应稳定不变即使你重构项目只要还是example.com的产品groupId就不变。变的是artifactId如从my-web-app改成my-cloud-service和version。3.2 能力声明dependencies——你向世界借的“能力许可证”依赖管理是Maven的灵魂。dependencies块声明你的项目需要哪些外部能力dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId version3.2.0/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version scoperuntime/scope /dependency /dependencies关键点每个dependency是一个独立的能力申请scope属性定义该能力的使用范围和生命周期这是新手最容易忽略的致命点compile默认编译、测试、运行都需要打包进最终jarprovided编译和测试需要但运行时由容器如Tomcat提供不打包。例如servlet-apiruntime编译不需要但测试和运行需要。例如JDBC驱动编译时用接口运行时才加载实现类test仅测试阶段需要如junit不参与编译主代码不打包system指向本地绝对路径的jar强烈不推荐破坏可移植性。scope错了轻则包体积爆炸重则运行时ClassCastException比如同时打包了两个不同版本的slf4j-api。3.3 行为契约plugins——你委托Maven执行的“定制化任务清单”buildplugins定义Maven在构建生命周期中要执行的额外任务build plugins plugin groupIdorg.springframework.boot/groupId artifactIdspring-boot-maven-plugin/artifactId version3.2.0/version executions execution goals goalrepackage/goal /goals /execution /executions /plugin /plugins /buildplugin是Maven的“扩展程序”每个插件解决一类问题编译、测试、打包、部署executions定义插件在哪个生命周期阶段执行什么目标goal。repackage是Spring Boot插件的目标它把普通jar重打包成可执行fat jar插件版本必须与项目框架版本兼容。Spring Boot 3.x要求spring-boot-maven-plugin 3.x用2.x会报错。实操避坑不要盲目复制网上pom.xml的plugin配置。先确认你用的框架版本再去对应官网查插件版本。Spring Boot官方文档的“Getting Started”章节永远是最准的source of truth。4. 依赖管理不是“加jar”而是构建一张可追溯的协作信任网络“依赖管理”这个词太抽象。实际工作中它解决的是三个具体问题怎么找jar怎么选版本怎么防冲突新手常犯的错误是把依赖当“下载列表”——看到项目需要log4j就去mvnrepository.com搜复制最新版坐标粘贴进pom.xml。结果项目跑起来但日志不输出因为log4j2需要log4j-api log4j-core两个jar只加一个没用单元测试通过生产环境报错因为测试用的H2内存数据库生产用MySQL但两个驱动的API不完全兼容升级Spring版本后项目启动失败因为旧版Spring依赖的Jackson版本与新版本冲突。Maven的依赖管理本质是基于坐标和传递性自动生成一张有向无环图DAG。理解这张图才能掌控依赖。4.1 传递依赖你没写的jarMaven自动帮你“顺藤摸瓜”当你声明spring-boot-starter-web它本身不包含Tomcat、Jackson、Spring MVC代码而是声明了对它们的依赖。Maven会递归解析自动下载所有间接依赖。这就是传递依赖Transitive Dependency。查看依赖树用命令mvn dependency:tree -Dverbose输出类似[INFO] com.example:my-web-app:jar:1.0.0-SNAPSHOT [INFO] \- org.springframework.boot:spring-boot-starter-web:jar:3.2.0:compile [INFO] - org.springframework.boot:spring-boot-starter:jar:3.2.0:compile [INFO] | - org.springframework.boot:spring-boot:jar:3.2.0:compile [INFO] | \- org.springframework.boot:spring-boot-autoconfigure:jar:3.2.0:compile [INFO] \- org.springframework.boot:spring-boot-starter-json:jar:3.2.0:compile [INFO] \- com.fasterxml.jackson.core:jackson-databind:jar:2.15.2:compile关键洞察-表示直接依赖你写的\表示传递依赖Maven自动引入最右边的compile是该依赖的scope。问题来了如果A依赖jackson-databind 2.15.2B依赖2.14.0Maven怎么选答案是最近依赖原则Nearest Definition谁离你的pom.xml层级近就用谁的版本。但这个原则有陷阱——如果A和B都是直接依赖且版本不同Maven会随机选一个实际按pom.xml中声明顺序导致构建结果不可预测。4.2 版本仲裁用dependencyManagement锁定“全家桶”解决版本冲突最佳实践是统一管理BOM, Bill of Materials。Spring Boot官方提供了spring-boot-dependenciesBOM它预定义了所有starter的兼容版本。在pom.xml中这样用dependencyManagement dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-dependencies/artifactId version3.2.0/version typepom/type scopeimport/scope /dependency /dependencies /dependencyManagementscopeimport/scope是关键——它表示“导入这个pom的dependencyManagement块”而不是添加一个jar。效果是所有spring-boot-starter系列的依赖无需写versionMaven自动采用BOM里定义的版本。为什么不用properties有人用propertiesjackson.version2.15.2/jackson.version/properties然后在dependency里引用${jackson.version}。这只能管住你直接写的依赖管不住传递依赖。BOM是唯一能约束整个依赖树的方案。4.3 排除依赖不是删除而是“礼貌地拒绝”有时你需要排除某个传递依赖。比如你用spring-boot-starter-data-jpa它会引入Hibernate而Hibernate又依赖javax.transaction:javax.transaction-api。但你的项目用的是Jakarta EE 9需要jakarta.transaction:jakarta.transaction-api。这时你不能删掉Hibernate而是排除旧的引入新的dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-jpa/artifactId exclusions exclusion groupIdjavax.transaction/groupId artifactIdjavax.transaction-api/artifactId /exclusion /exclusions /dependency dependency groupIdjakarta.transaction/groupId artifactIdjakarta.transaction-api/artifactId /dependency注意exclusion必须写在直接依赖里不能写在传递依赖上。因为Maven只允许你排除“上游给你的”不能排除“上游的上游”。实操技巧用mvn dependency:tree -Dverbose | findstr omittedWindows或grep omittedLinux/Mac查看哪些依赖被排除了。这是验证exclusion是否生效的黄金命令。5. 从零开始用Maven创建第一个可运行的Web项目不依赖IDE现在我们把前面所有概念串起来动手创建一个最小可行项目。全程用命令行不打开IDE——这是检验你是否真懂Maven的终极测试。很多教程教你在IDE里“New Project”那只是封装了Maven你根本不知道背后发生了什么。5.1 创建骨架archetype是Maven的“项目模板生成器”Maven提供archetype机制用预定义模板快速生成项目结构。执行mvn archetype:generate \ -DgroupIdcom.example \ -DartifactIdmy-first-web-app \ -DarchetypeArtifactIdmaven-archetype-webapp \ -DinteractiveModefalse参数说明-DgroupId/-DartifactId项目身份-DarchetypeArtifactIdmaven-archetype-webapp选择Web应用模板生成标准WAR结构-DinteractiveModefalse关闭交互式提问全用命令行参数。执行后会在当前目录生成my-first-web-app文件夹结构如下my-first-web-app/ ├── pom.xml └── src/ └── main/ ├── resources/ ├── webapp/ │ └── index.jsp └── webapp/WEB-INF/ └── web.xml这就是Maven约定的Web项目结构。注意src/main/java目录不存在因为maven-archetype-webapp是老式Servlet项目模板不包含Java源码目录。我们要手动补上。5.2 补全结构添加Java源码目录并编写HelloController进入项目目录cd my-first-web-app mkdir -p src/main/java/com/example/controller创建src/main/java/com/example/controller/HelloController.javapackage com.example.controller; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import java.io.IOException; public class HelloController extends HttpServlet { Override protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException { resp.setContentType(text/html;charsetUTF-8); resp.getWriter().println(h1Hello from Maven Web App!/h1); } }此时mvn compile会失败因为缺少Servlet API依赖。编辑pom.xml在dependencies中添加dependency groupIdjavax.servlet/groupId artifactIdjavax.servlet-api/artifactId version4.0.1/version scopeprovided/scope /dependency再执行mvn compile成功target/classes/com/example/controller/HelloController.class已生成。5.3 配置Webweb.xml声明Servlet映射编辑src/main/webapp/WEB-INF/web.xml添加Servlet配置?xml version1.0 encodingUTF-8? web-app xmlnshttp://xmlns.jcp.org/xml/ns/javaee xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:schemaLocationhttp://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd version4.0 servlet servlet-nameHelloServlet/servlet-name servlet-classcom.example.controller.HelloController/servlet-class /servlet servlet-mapping servlet-nameHelloServlet/servlet-name url-pattern/hello/url-pattern /servlet-mapping /web-app5.4 打包与运行用Tomcat插件一键启动Maven本身不运行Web应用但可通过插件集成Tomcat。在pom.xml的buildplugins中添加plugin groupIdorg.apache.tomcat.maven/groupId artifactIdtomcat7-maven-plugin/artifactId version2.2/version configuration port8080/port path//path /configuration /plugin执行mvn clean package tomcat7:runclean清空target目录package编译、测试、打包成WARtomcat7:run启动嵌入式Tomcat监听8080端口。打开浏览器访问http://localhost:8080/hello看到Hello from Maven Web App!——恭喜你亲手用Maven构建并运行了第一个Web项目。关键体会整个过程你没下载一个jar包没配置一次classpath没手动复制任何文件。所有依赖、编译、打包、部署都由Maven根据pom.xml的声明自动完成。这就是约定优于配置的力量——你只需描述“要什么”Maven负责“怎么做”。6. 面试高频题实战拆解为什么Maven依赖冲突时有时选A版本有时选B版本“Maven依赖冲突如何解决”是Java面试必问题。网上答案千篇一律“用mvn dependency:tree看然后exclude”。这就像回答“心脏怎么跳动”只说“靠心肌收缩”——技术上没错但没讲清机制。真实场景远比想象复杂。我整理了5个真实面试题每个都附带底层原理和实操验证6.1 题目1A依赖log4j 1.2.17B依赖log4j 2.17.1最终用哪个答案取决于A和B在pom.xml中的声明顺序。原理Maven采用第一声明优先First Declaration Wins。如果A写在B前面且两者都是直接依赖则用A的版本反之用B的版本。这不是“最近原则”而是解析pom.xml时的文本顺序。验证创建测试项目在pom.xml中先写A依赖执行mvn dependency:tree | findstr log4j记录版本再交换A、B顺序重新执行版本改变。6.2 题目2父POM声明了log4j 2.17.1子模块没声明但子模块的某个依赖如spring-boot-starter传递引入了log4j 2.15.0用哪个答案用父POM声明的2.17.1。原理dependencyManagement的优先级高于传递依赖。父POM的dependencyManagement块相当于给所有子模块设定了“版本上限”子模块的传递依赖必须服从。验证在父pom.xml中配置dependencyManagement锁定log4j版本子模块只声明spring-boot-starter不写log4j执行mvn dependency:tree确认log4j版本是父POM指定的。6.3 题目3为什么排除了spring-boot-starter-tomcat项目还能启动Web服务答案因为spring-boot-starter-web默认使用嵌入式Tomcat但Spring Boot提供了Jetty和Undertow替代方案。排除Tomcat后Maven会自动选择下一个可用的Servlet容器。原理spring-boot-starter-web的pom.xml中Tomcat依赖的scope是compile但它是optionaltrue可选依赖。当排除后Maven会检查其他optional依赖如spring-boot-starter-jetty如果存在且未被排除则启用。验证在pom.xml中排除Tomcat添加Jetty依赖执行mvn spring-boot:run观察启动日志是否显示“Jetty started”。6.4 题目4profile激活时为什么某些依赖在dev环境存在prod环境不存在答案因为profiles中配置了不同dependency且通过activation条件控制。原理Profile是Maven的“环境开关”。activationactiveByDefaulttrue/activeByDefault/activation表示默认激活activationpropertynameenv/namevalueprod/value/property/activation表示当系统属性envprod时激活。每个profile可定义独立的dependencies、plugins。验证在pom.xml中定义dev和prod profiledev中加lombokprod中排除执行mvn compile -Pdev和mvn compile -Pprod对比target/classes中是否有lombok注解处理器。6.5 题目5为什么mvn install后本地仓库里jar包的SHA256校验和与中央仓库不一致答案因为Maven下载时会对jar包进行校验但校验文件.sha256可能被镜像源篡改或缓存失效。原理Maven下载jar时会同时下载同名的.sha256文件计算本地jar的SHA256并与之比对。如果镜像源提供的.sha256文件损坏或过期校验失败Maven会报错并删除jar导致重复下载。验证手动下载中央仓库的jar和.sha256文件用certutil -hashfile xxx.jar SHA256Windows或shasum -a 256 xxx.jarMac/Linux计算校验和对比是否一致。面试提醒回答这类问题切忌只说结论。一定要带“原理验证方法”证明你不是死记硬背。面试官真正想考察的是你解决问题的思维路径而不是标准答案本身。7. 终极避坑指南那些让Maven新手崩溃的10个隐形陷阱最后分享我在一线带新人时总结的10个最高频、最隐蔽、最让人抓狂的Maven陷阱。它们不写在任何官方文档里却是真实发生过的血泪教训7.1 陷阱1IDE的Maven配置与命令行不一致现象命令行mvn clean compile成功但IDEA里标红提示“Cannot resolve symbol”。原因IDEA默认使用内置Mavenbundled而非你系统安装的Maven。它的settings.xml路径、本地仓库路径、JDK版本都可能不同。解决方案File → Settings → Build → Maven → 取消勾选“Use wrapper”在“Maven home path”中指定你的MAVEN_HOME在“User settings file”中指定$USER_HOME/.m2/settings.xml。7.2 陷阱2pom.xml编码格式为GBK导致中文注释乱码现象pom.xml里写!-- 数据库配置 --保存后变成!-- ݿ --Maven解析失败。原因Windows记事本默认用GBK保存而Maven要求UTF-8。解决方案用VS Code或Notepad打开pom.xml右下角切换编码为UTF-8保存。在pom.xml顶部加?xml version1.0 encodingUTF-8?。7.3 陷阱3IDEA自动导入时把scopetest/scope的依赖加到了编译路径现象JUnit依赖被标记为“Provided”导致测试代码编译失败。原因IDEA的Maven Importer有个bug会错误处理test scope。解决方案File → Project Structure → Modules → Dependencies → 找到junit依赖将Scope从“Provided”改为“Test”。7.4 陷阱4mvn clean不清理target/generated-sources导致旧代码残留现象用MyBatis Generator生成代码后修改配置重新生成target/generated-sources里仍有旧文件编译报错。原因mvn clean只清理target目录但某些插件如mybatis-generator-maven-plugin生成的代码在target/generated-sources而clean不递归删除子目录。解决方案在pom.xml中配置maven-clean-plugin添加额外清理路径plugin artifactIdmaven-clean-plugin/artifactId version3.3.2/version configuration filesets fileset directorytarget/generated-sources/directory /fileset /filesets /configuration /plugin7.5 陷阱5relativePath指向错误导致父POM解析失败现象多模块项目中子模块mvn compile报错“Could not find artifact com.example:parent:pom:1.0.0”。原因子模块pom.xml中parentrelativePath默认为../pom.xml但如果父POM不在上一级目录或路径有误就会失败。解决方案显式指定relativePath如relativePath../parent/pom.xml/relativePath并确保路径真实存在。7.6 陷阱6mv