Maven POM 文件怎么配置才清晰？核心元素有哪些？

POM 是 Maven 项目的说明书，也是构建时最先被读取的配置入口。一个项目能不能稳定编译、依赖会不会乱、插件版本是否可控，很多时候不取决于命令写得多熟，而取决于 pom.xml 有没有把边界写清楚。POM 不需要堆满配置，真正重要的是坐标、依赖、版本管理和构建插件这几块各司其职。

POM 的核心元素怎么分工？

最基础的是项目坐标：groupId、artifactId、version 和 packaging。groupId 通常用组织域名倒序，artifactId 是模块名，version 表示当前产物版本，packaging 决定最终打成 jar、war 还是只作为父工程的 pom。坐标一旦发布到仓库，就会被其他项目当作依赖引用，所以不要随意改名。

xml
<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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.example</groupId>
  <artifactId>order-service</artifactId>
  <version>1.0.0-SNAPSHOT</version>
  <packaging>jar</packaging>
</project>

properties 适合放 Java 版本、编码、依赖版本这类会被复用的值。它的好处是集中修改，代价是过度抽象后不容易追踪真实版本。团队项目里可以把 Spring、MyBatis、JUnit 等版本写成属性，但不要把每个只用一次的小依赖都抽成变量。

dependencies 声明当前模块真的要用的依赖；dependencyManagement 只管理版本，不会自动引入依赖。这是很多人踩坑的地方：父 POM 里写了 dependencyManagement，子模块仍然需要在 dependencies 中声明依赖，只是可以省略版本。

xml
<properties>
  <java.version>17</java.version>
  <spring.boot.version>3.2.5</spring.boot.version>
</properties>

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-dependencies</artifactId>
      <version>${spring.boot.version}</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

<dependencies>
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
  </dependency>
</dependencies>

build 和插件应该怎么写？

build 负责资源处理、编译、测试、打包等构建行为。插件版本最好固定在父 POM 的 pluginManagement 中，子模块按需启用。这样既能避免不同机器拉到不同插件版本，也不会让每个模块都复制一大段配置。

xml
<build>
  <pluginManagement>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.13.0</version>
        <configuration>
          <release>${java.version}</release>
          <encoding>UTF-8</encoding>
        </configuration>
      </plugin>
    </plugins>
  </pluginManagement>
</build>

父子 POM 适合多模块工程。父 POM 用 packaging=pom，统一管理依赖版本、插件版本和公共属性；子模块通过 parent 继承。取舍点在于：公共配置越集中越容易维护，但父 POM 过重会让所有模块被迫背上无关配置。

xml
<parent>
  <groupId>com.example</groupId>
  <artifactId>platform-parent</artifactId>
  <version>1.0.0</version>
  <relativePath>../pom.xml</relativePath>
</parent>

profiles 可以处理环境差异，例如本地、测试、生产使用不同资源过滤或插件开关。不过它不适合承载业务配置，更不应该把数据库密码这类敏感信息直接写进 POM。更稳妥的做法是让 POM 只决定构建差异，运行时配置交给环境变量、配置中心或部署平台。这样构建产物更容易复现，也能减少“换个环境就重新打包”的问题。

追问

dependencies 和 dependencyManagement 有什么区别？

dependencies 会真正把依赖加入当前模块的 classpath，编译和运行都可能用到。dependencyManagement 只是提供版本约束，子模块没有声明依赖时不会自动生效。这个设计的好处是父 POM 能统一版本，又不会强行污染每个模块。踩坑最多的是以为导入 BOM 后依赖就存在，结果编译时报类找不到。

parent、modules 和 dependencyManagement 能互相替代吗？

不能。parent 是继承配置，modules 是聚合构建，dependencyManagement 是版本管理。一个父工程可以同时做继承和聚合，但大型仓库里也常把它们拆开，避免构建范围过大。边界是：如果只是统一版本，不一定要把所有项目都放进同一个聚合工程。

POM 里应该直接写仓库 repositories 吗？

一般不建议在业务项目里随意写公共仓库地址，企业项目更适合在 settings.xml 或私服里统一配置镜像。POM 中写仓库会影响所有使用该项目的人，甚至让构建依赖某个不稳定的外部源。只有项目确实依赖特殊仓库，且团队接受这个约束时，才应该写进 POM。否则后续排查“为什么我机器能构建、CI 不行”会很麻烦。

版本号放 properties 还是直接写在依赖上？

被多个依赖或多个模块共享的版本适合放进 properties，例如 Spring Boot、Jackson、JUnit。只出现一次的小依赖直接写版本反而更清楚。过度属性化会让读 POM 的人频繁跳转，维护成本上升。一个实用边界是：能被统一升级的版本集中管理，临时依赖不要为了“整齐”硬抽象。

POM 文件越完整越好吗？

不是。Maven 的默认约定已经覆盖了目录结构、编译阶段和基础生命周期，很多配置不写反而更稳定。真正需要显式写的是版本、插件行为差异、资源过滤和发布规则。把网上模板整段复制进来，常见后果是插件互相覆盖、构建阶段重复执行，最后没人敢改。

POM 写得好不是 XML 多，而是项目坐标稳定、依赖边界清楚、版本来源可追踪。先让默认约定发挥作用，再把团队确实需要统一的内容放进父 POM，通常比一开始就写“大而全模板”更可靠。