pom.xml是Maven项目的灵魂文件，任何一个基于Maven构建的Java项目，根目录下都会有一个pom.xml。Maven读取这个文件，就能知道项目叫什么、依赖哪些第三方库、用什么插件打包、按什么顺序构建。可以说，理解了pom.xml，就理解了Maven的一半。本文将从文件结构讲起，带你逐步掌握依赖管理的各项核心配置。
pom.xml的基本结构与项目坐标
pom.xml的根元素是<project>，所有配置都写在这个标签内部。一个最小可用的pom.xml包含三个核心坐标：groupId、artifactId和version。这三者组合起来唯一标识一个构件（artifact），无论是你自己的项目还是引用的第三方库，在Maven世界里都靠这套坐标来定位。
groupId通常表示组织或团体的标识，一般采用倒写的域名形式，比如com.example；artifactId是项目或模块的名称；version是版本号。此外还有packaging元素，决定项目打包成什么格式，常见的取值有jar、war、pom三种，默认是jar。当packaging为pom时，这个项目通常是一个父工程，只负责聚合和管理子模块。
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<!-- 项目坐标：Maven世界里的唯一标识 -->
<groupId>com.example.demo</groupId>
<artifactId>order-service</artifactId>
<version>1.0.0-SNAPSHOT</version>
<packaging>jar</packaging>
<name>order-service</name>
<description>订单服务模块</description>
<properties>
<maven.compiler.source>17</maven.compiler.source>
<maven.compiler.target>17</maven.compiler.target>
<spring.version>6.1.5</spring.version>
</properties>
</project>上面的<properties>标签用来定义全局变量，最常见的就是统一JDK版本和第三方库版本号。在properties里定义了spring.version之后，下面的依赖就可以用${spring.version}引用，等将来升级版本时只需要改一处，避免版本号散落各处造成不一致。
依赖声明与scope作用范围详解
依赖管理是pom.xml最核心的用途。所有依赖都写在<dependencies>标签下，每个<dependency>同样需要groupId、artifactId、version三要素。Maven会根据这些坐标去本地仓库（默认在C:\Users\用户名\.m2\repository）查找jar包，找不到就从中央仓库或私服下载。
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>${spring.version}</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.13.2</version>
<scope>test</scope>
</dependency>
</dependencies><scope>是个容易被忽视但非常重要的配置，它决定依赖在什么阶段可用、是否参与传递。compile是默认值，编译、测试、运行全程有效；provided表示编译和测试时可用，但打包时不会包含，典型例子是Servlet API，因为Tomcat容器自己会提供；runtime表示编译时不需要、运行时才需要，比如JDBC驱动；test只在测试编译和执行时生效，不会打进最终包里。
这里要特别讲一下Maven的依赖传递机制。假设A依赖B，B依赖C，那么A默认也能使用C，这叫传递性依赖。好处是不用重复声明，坏处是可能引入不想要的依赖或者产生版本冲突。当出现同一个构件的多个版本时，Maven遵循两个原则：路径最短优先和先声明优先。如果传递进来的某个依赖有漏洞或者体积巨大，可以用<exclusions>把它排除掉：
<dependency>
<groupId>com.example.demo</groupId>
<artifactId>common-core</artifactId>
<version>1.0.0</version>
<exclusions>
<!-- 排除传递进来的低版本日志包，避免与项目内版本冲突 -->
<exclusion>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
</exclusion>
</exclusions>
</dependency>排查依赖冲突时，可以在项目目录执行mvn dependency:tree命令，它会以树状结构打印出整个依赖链路，哪个版本被谁引入、哪条路径生效一目了然，这是定位NoClassDefFoundError、ClassNotFoundException这类诡异问题的利器。
dependencyManagement与多模块项目实践
在单模块项目里，直接把依赖写进dependencies就够了。但一旦项目拆分成多个模块，问题就来了：order模块用了Spring 6.1.5，user模块还在用Spring 5.3，运行时极易出现兼容性问题。正确做法是在父工程的pom.xml中用<dependencyManagement>统一锁定版本：
<!-- 父工程 pom.xml -->
<packaging>pom</packaging>
<modules>
<module>order-service</module>
<module>user-service</module>
</modules>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>6.1.5</version>
</dependency>
</dependencies>
</dependencyManagement>需要注意，dependencyManagement只是声明版本，并不会真正引入依赖。子模块继承父工程后，声明同样的依赖时可以省略version，实际采用的就是父工程锁定的版本。这种方式相当于给全家的依赖版本立了一份契约，既保证了版本统一，又让子模块保持灵活，不会被迫接收一堆用不到的jar包。
子工程的pom.xml通过<parent>标签建立继承关系，然后在dependencies中按需引入，不写版本号即可：
<parent>
<groupId>com.example.demo</groupId>
<artifactId>parent-pom</artifactId>
<version>1.0.0</version>
</parent>
<artifactId>order-service</artifactId>
<dependencies>
<!-- 无需version，自动使用父工程管理的版本 -->
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
</dependency>
</dependencies>另外，pom.xml还支持<profiles>配置，可以为开发、测试、生产环境定义不同的依赖或属性，构建时通过mvn package -P prod激活指定环境。配合<repositories>配置私服地址（如企业内部的Nexus），可以显著提升依赖下载速度并减少对外网的依赖。
总结一下，pom.xml的基本套路是：单项目用dependencies加properties管理依赖，多模块项目用父工程加dependencyManagement锁定版本，遇到冲突用exclusions排除，定位问题用dependency:tree。掌握这几个要点，日常开发中的依赖管理基本不会再踩坑。建议养成两个习惯：一是版本号统一收敛到properties中，二是每次引入新依赖前先用依赖树确认它带来了什么，防患于未然。