Maven使用教程
一、Maven 介绍
（一）Maven 是什么？
在 Java 项目开发中，Maven 专为解决项目构建与依赖管理的难题而生，是一款标准化的构建与依赖管理工具。在 Maven 诞生之前，Java 开发者常常在手动管理 Jar 包的泥沼中挣扎，不同项目的结构混乱无序，构建流程也缺乏统一标准，严重影响开发效率与项目的可维护性。Maven 秉持 “约定优于配置” 的先进理念横空出世，为 Java 开发带来了一股清新的变革之风。
Maven 的核心功能十分强大且实用。它为项目精心定义了标准化的目录结构，让开发者能够快速定位和管理各类文件。同时，Maven 实现了构建流程的全面自动化，从代码编译、测试执行、打包成可部署的文件，到最后的部署上线，每一个环节都能有条不紊地自动完成。更值得一提的是，其智能依赖管理功能堪称一绝，它能够自动解析项目所需的各种依赖，并妥善处理依赖之间的版本冲突问题，让开发者彻底告别手动下载和管理 Jar 包的繁琐工作，极大地提升了开发效率和项目的稳定性。在团队协作开发中，Maven 统一的标准和自动化流程，使得不同成员之间的协作更加顺畅高效，项目的可维护性也得到了显著增强。
（二）核心概念解析
1.项目对象模型（POM）
pom.xml 文件是整个项目的核心配置文件，位于项目的根目录下，详细地定义了项目的诸多关键信息。其中，项目坐标由 groupId、artifactId 和 version 三部分组成。groupId 通常采用公司的反向域名形式，比如 com.vvhz，用以明确项目所属的组织或团体，就像给项目贴上了所属团队的独特标签；artifactId 则是项目独一无二的标识，精准地定义了当前 Maven 项目在所属组中的独特身份，如同每个人的名字一样独一无二；version 遵循严格的语义化版本规范，精确地表示项目的版本号，例如 1.0.0、2.1.3 等，方便开发者进行版本管理和追踪。这三者紧密结合，能够唯一且准确地定位项目或其依赖，确保在复杂的软件生态中，项目及其依赖都能被清晰地识别和管理。
2.标准目录结构
Maven 为项目预设了一套严谨规范的目录结构（约定优于配置，我们需要按照maven定义好的目录结构来存放代码，maven就可以自动识别源代码、配置文件等，这样maven就可以自动编译、测试、打包），就像为项目搭建了一个有序的文件管理框架。src/main/java 文件夹用于存放主代码，开发者编写的核心业务逻辑代码都在这里；src/test/java 文件夹则专门用于存放测试代码，对主代码进行全面细致的测试，确保其质量和稳定性；src/main/resources 和 src/test/resources 文件夹分别承担着存储主程序和测试所需资源文件的重任，比如配置文件、静态资源等，这些资源文件为程序的正常运行提供了必要的支持；而 target 目录则是项目构建结果，编译后的字节码文件、打包生成的 JAR 包、WAR 包等构建产物都会被存放在这里，方便后续的部署和使用。
遵循 Maven 的标准目录结构有着诸多好处。一方面，它确保了项目的一致性和规范性，无论团队成员来自何方，都能迅速熟悉项目的文件布局，快速上手开发工作，极大地降低了沟通成本和学习成本；另一方面，标准化的目录结构使得各种开发工具链和插件能够更好地与项目集成，顺畅地运行各项构建任务，提高开发效率。例如，当使用 Maven 的编译插件时，它会默认从 src/main/java 目录中读取源代码进行编译，将编译结果输出到 target 目录中，如果项目遵循了标准目录结构，这些操作就能自动顺利完成，无需额外的复杂配置。
二、环境搭建与初始配置
（一）安装与环境变量配置
在开启 Maven 开发之前，首要任务是完成其安装与基础配置。更多的配置解析参考Maven setting.xml解析。
1.下载与安装
首先，我们要从 Maven 官网 获取最新稳定版，或者下载指定的历史版本。下载完成后，将下载的压缩包解压到一个合适的目录，比如 D:\apache-maven-3.9.1，确保路径中不包含中文和空格，以免引发不必要的问题。解压完成后，开始配置环境变量，右键点击 “此电脑”，选择 “属性”，在弹出的窗口中点击 “高级系统设置”，再点击 “环境变量” 按钮。在系统变量区域，点击 “新建”，变量名输入 “M2_HOME”，变量值则填写 Maven 的解压目录，即 D:\apache-maven-3.9.1。接着，找到系统变量中的 “Path” 变量，点击 “编辑”，在弹出的编辑环境变量窗口中，拼接上 “% M2_HOME%\bin”，点击 “确定” 保存所有设置，完成环境变量的配置。
完成上述操作后，打开命令行窗口，输入 “mvn -version”，如果显示出正确的 Maven 版本信息，包括 Maven 版本号、Java 版本以及相关的系统信息，则说明 Maven 安装成功，环境变量配置正确，我们已经成功迈出了使用 Maven 的第一步。
2.国内镜像加速
在实际项目开发中，从 Maven 中央仓库下载依赖时，由于网络原因，速度可能会不尽人意，甚至出现下载失败的情况。为了解决这个问题，我们可以配置国内镜像，以阿里云镜像为例，它不仅速度快，而且资源丰富，能极大地提高依赖下载效率。
在 Maven 中，D:\apache-maven-3.9.1/conf/settings.xml（全局配置）与用户目录下的.m2/settings.xml（用户配置）是层级互补且存在优先级的关系，Maven 加载配置时会遵循 “先全局、后用户，用户配置覆盖全局配置” 的原则。
配置过程也十分简单，使用文本编辑器打开 settings.xml 文件，在mirrors标签内添加如下阿里云镜像配置：
<mirror>
<id>aliyunmaven</id>
<name>阿里云公共仓库</name>
<url>https://maven.aliyun.com/repository/public</url>
<mirrorOf>central,!nexus-releases,!rdc-releases</mirrorOf>
</mirror>在这个配置中，标签定义了镜像的唯一标识符，这里使用 “aliyunmaven”；标签提供了该镜像的名称，方便识别；标签指定了镜像的 URL 地址，即阿里云镜像仓库的地址；标签指明了该镜像是中央仓库的镜像，这样 Maven 在下载依赖时，就会优先从阿里云镜像仓库获取，大大提升下载速度。保存 settings.xml 文件后，再次执行 Maven 命令下载依赖时，就能感受到明显的速度提升，为开发工作节省大量时间。
当settings.xml中配置多个<mirror>时，Maven 会根据镜像的<mirrorOf>标签匹配规则和精确性优先级选择合适的镜像，核心逻辑是 “最精确匹配优先，同精度按配置顺序选择”。
（二）本地仓库配置
Maven 在项目构建过程中，会将下载的依赖文件存储在本地仓库中，默认情况下，本地仓库位于用户目录下的.m2/repository 文件夹。这个默认位置可能会因为磁盘空间不足或其他原因，无法满足我们的需求，此时就可以在 settings.xml 文件中自定义本地仓库路径。
打开 settings.xml 文件，找到标签，默认情况下，该标签可能被注释掉了，取消注释并修改其值为我们自定义的路径，例如：
<localRepository>D:\maven\_repository</localRepository>这里将本地仓库路径设置为 D 盘下的 maven_repository 文件夹，你可以根据自己的实际情况选择合适的路径。设置完成后，保存 settings.xml 文件。当我们首次构建项目时，Maven 会自动根据新设置的路径创建本地仓库，并将下载的依赖缓存至此。在后续的项目开发中，若再次需要相同的依赖，Maven 会直接从本地仓库中获取，无需重复从远程仓库下载，这不仅节省了网络带宽，还大大提升了离线开发能力，即使在没有网络的情况下，也能正常进行项目构建和开发工作。通过合理配置本地仓库，我们能够更好地管理项目依赖，提高开发效率和项目的稳定性 。
三、依赖管理核心实战
（一）依赖声明与作用域
在 Maven 项目的构建过程中，依赖管理无疑是最为关键的一环，它直接关系到项目能否顺利运行以及运行的稳定性。而依赖声明与作用域的正确设置，则是依赖管理的基础和核心。
在 pom.xml 文件中，我们通过标签来配置依赖声明。在这个标签内部，每一个依赖都通过标签进行详细的描述。例如，当我们的项目需要引入 Apache Commons Logging 日志库时，就可以这样声明：
<dependencies>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-logging</artifactId>
<version>1.2</version>
</dependency>
</dependencies>这里的 groupId、artifactId 和 version 构成了依赖的唯一标识，也就是我们常说的 GAV 坐标。groupId 即这里的 org.apache.commons 表明这是 Apache 软件基金会下的一个通用库；artifactId 是 commons-logging 明确表示这是一个日志相关的库；version 则精确地指出了依赖的版本号，1.2 版本代表了这个库的特定功能和特性集合。通过这样清晰准确的 GAV 坐标，Maven 就能在茫茫的仓库中精准地找到并下载我们需要的依赖。
除了基本的坐标声明，依赖的作用域（Scope）也是一个至关重要的概念，控制着依赖在项目不同阶段的可用性和可见性。Maven 提供了多种作用域选项，每一种都有其特定的用途和适用场景。
1.compile（默认作用域）：这是 Maven 依赖的默认作用域，在项目的编译、测试、运行等各个阶段都能发挥作用。以 commons-logging 库为例，在编译阶段，它提供了日志相关的接口和类，帮助我们编写日志记录的代码；在测试阶段，测试用例同样需要使用这些日志功能来记录测试过程中的信息；而在项目运行时，日志更是不可或缺，用于记录系统的运行状态、错误信息等。因此，将 commons-logging 的作用域设置为 compile，确保它在整个项目生命周期中都能被正常使用。由于运行时需要，编译范围的依赖会被打包，随着项目一起发布，为项目的正常运行提供全面的支持。
2.test 作用域：test 作用域表明该依赖仅在测试阶段有效。JUnit 是 Java 项目中最常用的测试框架，它提供了丰富的注解和断言方法，帮助我们编写和执行单元测试。在项目的编译和运行阶段，我们并不需要 JUnit，只有在编写测试代码（如 src/test/java 目录下的测试类）或运行测试代码（使用 mvn test 命令）时，才会用到它。因此，JUnit 的依赖作用域应设置为 test，这样可以避免在生产环境中引入不必要的依赖，减小项目的体积和复杂度。由于运行时不需要，test 范围依赖不会被打包，保证了生产环境的纯净和简洁。如果Junit依赖的scope设置为了test，那么我们在src/main/java目录下正常编写代码的过程中是无法引用Junit包提供的类。
3.runtime 作用域：runtime 作用域表示在编译时并不需要，但在运行时却是必不可少的。以 JDBC 驱动为例，在编译 Java 代码时，我们只需要 JDK 提供的 JDBC 接口，这些接口定义了与数据库交互的规范和方法。而在项目实际运行时，需要具体的 JDBC 驱动来实现这些接口，与不同类型的数据库（如 MySQL、Oracle 等）进行连接和数据交互。因此，JDBC 驱动的依赖作用域设置为 runtime，确保它在运行时能够被正确加载和使用，而在编译时不会干扰编译过程。虽然编译时不可见，但运行时需要，runtime 范围的依赖会被打包，为项目的运行提供必要的支持。
4.provided 作用域：provided 作用域的依赖在编译和测试时需要它们的支持，但在运行时，这些依赖会由外部容器或环境来提供，而不是由项目自身打包携带。例如，在开发一个基于 Servlet 规范的 Web 应用时，我们需要引入 servlet-api 依赖，以便在编译时使用 Servlet 相关的接口和类来编写 Web 应用的逻辑。然而，当应用部署到 Tomcat 等 Servlet 容器中运行时，容器已经内置了 servlet-api 的实现，不需要我们的项目再次打包这个依赖。因此，将 servlet-api 的依赖作用域设置为 provided，既保证了开发和测试的顺利进行，又避免了与容器中已有的依赖产生冲突，同时减小了项目的打包体积。由于运行时由环境提供，provided 范围依赖不会被打包，提高了项目的部署效率和稳定性。
正确理解和设置依赖声明与作用域，是 Maven 项目成功构建和稳定运行的基石。通过合理地配置 GAV 坐标和作用域，我们能够精准地控制项目的依赖，确保项目在不同阶段都能获取到所需的资源，同时避免引入不必要的依赖，提升项目的性能和可维护性。在实际项目开发中，需要根据每个依赖的具体用途和项目的实际需求，仔细选择合适的作用域，让 Maven 的依赖管理功能发挥出最大的效能。
（二）依赖冲突解决
在 Maven 项目的依赖管理中，依赖冲突是一个常见且棘手的问题，可能会导致项目在运行时出现各种意想不到的错误，如类找不到异常（ClassNotFoundException）、方法不存在异常（NoSuchMethodError）等，严重影响项目的稳定性和正常运行。因此，掌握有效的依赖冲突解决方法至关重要。
1.依赖树分析
依赖树分析是解决依赖冲突的第一步，我们需要通过依赖树分析来了解项目中依赖的层级结构和版本信息，从而定位冲突的根源。Maven 为我们提供了一个强大的工具 ——mvn dependency:tree 命令，通过执行这个命令，Maven 会为我们绘制出项目的依赖树，展示出项目中所有依赖的层级关系和版本信息。
但是我们在开发过程中可以使用idea的依赖分析工具，可以更清晰的查看依赖关系。并且可以筛选冲突的依赖或者搜索指定的依赖。
从这个依赖树中，我们可以清晰地看到，项目中重复引入了哪些依赖，这就很可能导致依赖冲突。Maven 在处理这种情况时，默认采用 “最近声明优先” 原则（Nearest Wins），也就是会选择路径最短的依赖版本。例如，如果 library-a 和 library-b 到 commons-logging 的依赖路径长度相同，那么 Maven 会选择在 pom.xml 中后声明的那个版本。但这种默认的选择机制并不一定总是符合我们的需求，有时可能会导致项目运行出错。因此，我们需要根据具体情况，手动干预来解决依赖冲突。
2.手动排除冲突
当我们通过依赖树分析定位到冲突的依赖后，一种常用的解决方法就是手动排除不需要的传递依赖，我们可以使用标签来排除那些可能导致冲突的依赖。
例如，假设我们希望排除 library-a 中传递过来的 commons-logging:commons-logging:1.1.1 依赖，因为我们更倾向于使用 library-b 中引入的 1.2 版本，那么可以在 pom.xml 中对 library-a 的依赖声明进行如下修改：
<dependency>
<groupId>org.example</groupId>
<artifactId>library-a</artifactId>
<version>1.0.0</version>
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>在这个配置中，标签就像是一个 “过滤器”，子标签则详细定义了要排除的依赖的 groupId 和 artifactId。通过这样的配置，Maven 在解析依赖时，就会忽略掉 library-a 传递过来的 commons-logging:commons-logging:1.1.1 依赖，从而避免了版本冲突的问题。需要注意的是，一旦我们对依赖配置进行了变更，记得重新加载项目，让新的配置生效，可以使用 IDE 的相关功能（如在 IntelliJ IDEA 中，右键点击项目，选择 Maven -> Reload Project），或者再次执行 Maven 命令，确保项目能够正确地使用修改后的依赖配置。。
四、构建流程与常用命令
（一）生命周期与阶段
Maven 构建流程通过预定义的生命周期和阶段，有条不紊地完成从代码到可部署程序的转变，每个环节都紧密相扣，确保项目构建的高效与稳定。
Maven 预定义了三大生命周期，各自承担着独特而关键的职责。
clean 生命周期专注于清理构建产物，为全新的构建提供纯净的环境，其中核心的 clean 阶段，会删除 target 目录，将上一次构建遗留的所有文件一扫而空，确保项目的下一次构建。
default 生命周期涵盖了项目从诞生到部署的关键环节。compile 阶段率先将 src/main/java 目录下的主代码编译成字节码文件，为后续的流程奠定了基础；test 阶段使用 JUnit 等测试框架对编译后的代码进行单元测试，确保代码的质量和稳定性；package 阶段将编译后的代码打包成 JAR、WAR 等可发布的格式，方便项目的分发和部署；install 阶段会将打包好的文件安装到本地仓库；而 deploy 阶段则是将最终的包复制到远程仓库，与其他开发者和项目共享，实现项目的传播和应用 。
site 生命周期用于生成项目文档站点，为项目提供文档支持。
当我们执行 mvn clean package 命令时，Maven 会依次触发 clean 生命周期的 clean 阶段，将 target 目录清理干净，为后续的构建创造良好的条件；接着，default 生命周期的 package 阶段及之前的所有阶段（validate→compile→test→package）也会被依次执行，确保项目顺利完成编译、测试和打包等关键步骤，最终生成可发布的 JAR 或 WAR 包。
（二）常用命令速查表
（三）核心打包插件对比：spring-boot-maven-plugin vs maven-jar-plugin
Maven 打包功能依赖插件实现，maven-jar-plugin是默认打包插件，而spring-boot-maven-plugin是 Spring Boot 项目专属插件，二者在设计目标、产物特性等维度差异显著，具体对比如下：
1. 核心差异总览表
2. 配置示例对比
（1）maven-jar-plugin 配置（普通 Java 项目）
默认无需额外配置，若需指定主类或自定义清单文件，可在 pom.xml 中添加：
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>3.3.0</version>
<configuration>
<!-- 手动指定主类（仅当需要通过java -cp运行时配置） -->
<archive>
<manifest>
<mainClass>com.example.MyApplication</mainClass>
<!-- 可选：添加类路径（需手动维护依赖路径） -->
<addClasspath>true</addClasspath>
<classpathPrefix>lib/</classpathPrefix>
</manifest>
</archive>
<!-- 排除无需打包的文件 -->
<excludes>
<exclude>**/test/**</exclude>
</excludes>
</configuration>
</plugin>
</plugins>
</build>运行方式：需将依赖放在lib/目录下，执行java -cp my-project-1.0.jar:lib/* com.example.MyApplication。
（2）spring-boot-maven-plugin 配置（Spring Boot 项目）
Spring Boot 项目需在 pom.xml 中引入该插件（Spring Boot Starter Parent 已内置版本管理）：
spring-boot-maven-plugin的核心作用是在默认打包(maven-jar-plugin)后对产物进行二次处理，生成可执行的 “Fat JAR/WAR”（包含所有依赖和 Spring Boot 启动器）。并且将默认打包的原始文件重命名为myproject-1.0.jar.original作为备份。
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>3.1.2</version> <!-- 与Spring Boot版本一致 -->
<configuration>
<!-- 可选：手动指定主类（若自动识别失败时） -->
<mainClass>com.example.SpringBootApplication</mainClass>
<!-- 启用分层打包（优化Docker构建，减少层体积） -->
<layers>
<enabled>true</enabled>
</layers>
<!-- 排除无需打包的依赖（如测试依赖） -->
<excludes>
<exclude>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
</exclude>
</excludes>
</configuration>
<!-- 可选：绑定分层打包目标（执行mvn package时自动分层，用于优化Docker构建的） -->
<executions>
<execution>
<goals>
<goal>layers</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>运行方式：直接执行java -jar my-springboot-project-1.0.jar（无需额外处理依赖）。
3. 关键注意点
Spring Boot 项目误用问题：若 Spring Boot 项目未配置spring-boot-maven-plugin，仅使用默认的maven-jar-plugin，生成的 JAR 包会缺失依赖和启动器，执行java -jar时会报错no main manifest attribute或ClassNotFoundException。
依赖冲突风险：spring-boot-maven-plugin打包的 Fat JAR 中，依赖会被解压到BOOT-INF/lib，若存在依赖冲突，需通过<exclusions>排除冗余依赖（同前文 “依赖冲突解决” 逻辑）。
类库项目禁忌：若开发供其他项目依赖的 Spring Boot 类库（如通用组件），不可使用spring-boot-maven-plugin，否则生成的 Fat JAR 会导致依赖重复引入，需改用maven-jar-plugin。
五、总结
1.标准化优先：严格遵循 Maven 的标准目录结构和 POM 规范是项目成功的基石。这不仅确保了项目的一致性和规范性，还能让团队成员快速熟悉项目布局，降低沟通成本。例如，将源代码放置在 src/main/java 目录下，测试代码放置在 src/test/java 目录下，配置文件放置在 src/main/resources 目录下，这种清晰的结构使得项目的各个部分一目了然，便于管理和维护。同时，避免手动修改 Maven 的默认配置，除非有特殊需求，因为默认配置是经过精心设计的，能够满足大多数项目的常规需求，随意修改可能会引发意想不到的问题。
2.依赖管理精细化：依赖管理是 Maven 的核心功能之一，需要我们进行精细化管理。定期使用 mvn dependency:tree 命令检查依赖树，及时发现并解决依赖冲突问题。在多模块项目中，通过父项目的 dependencyManagement 标签统一管理子模块的依赖版本，确保所有模块使用相同的依赖版本，避免因版本差异导致的兼容性问题。同时，合理设置依赖的作用域，如 compile、test、runtime、provided 等，确保依赖在项目的不同阶段发挥正确的作用，避免引入不必要的依赖，减小项目的体积和复杂度。
