Maven的构建体系由三套相互独立的生命周期构成，分别是clean、default和site。每一套生命周期都包含若干有序的阶段，阶段之间具有前后依赖关系。在pom.xml中配置插件时，我们常常通过execution元素下的phase子元素，把某个插件目标显式绑定到特定生命周期的某个阶段上。如果未指定phase，该目标就会使用自身预设的默认阶段。很多构建异常其实都源于对phase与生命周期对应关系的误判。
一、Maven三套生命周期与阶段概览
Maven之所以让人困惑，是因为它并不是单条流水线，而是三套并行的生命周期。clean生命周期负责项目清理，包含pre-clean、clean、post-clean三个阶段；default生命周期承载核心构建任务，从validate、compile、test、package到install、deploy等二十余个阶段；site生命周期用于生成站点文档，含pre-site、site、post-site、site-deploy。同一时刻只能触发其中一套的某个阶段，且该阶段之前的同生命周期阶段都会被依次执行。
这种隔离设计意味着，你在default生命周期的package阶段绑定的插件，永远不会在clean生命周期运行时被调用。不少初学者在clean阶段想做代码格式化，却发现配置的插件没生效，就是因为没有把execution的phase写成clean，而是错误地写成了default里的compile。明确生命周期边界，是正确绑定phase的前提。
二、execution中phase的绑定机制
在pom.xml里，plugin下的executions可以声明多个execution，每个execution通过goals指定目标，通过phase指定生命周期阶段。当Maven执行到对应生命周期的该阶段时，就会调用此目标。下面是一段典型的绑定示例，把maven-antrun-plugin的run目标绑到default生命周期的process-resources阶段：
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>3.1.0</version>
<executions>
<execution>
<id>print-info</id>
<phase>process-resources</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target>
<echo>资源处理阶段已触发自定义任务</echo>
</target>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
如果去掉上面的phase配置，maven-antrun-plugin的run目标其实没有默认阶段，它就不会自动参与任何生命周期，必须靠命令行直接调用。相反，maven-compiler-plugin的compile目标内置默认phase为compile，因此即便不写phase，执行mvn compile时也会自动编译主代码。理解“默认phase”与“显式phase”的差异，能减少大量冗余配置。
三、常见插件目标与默认phase对照
掌握常用插件目标的默认阶段，有助于我们判断是否需要显式写phase。下表列出几个高频插件及其目标默认所属生命周期与阶段：
| 插件 | 目标 | 生命周期 | 默认phase |
|---|---|---|---|
| maven-clean-plugin | clean | clean | clean |
| maven-resources-plugin | resources | default | process-resources |
| maven-compiler-plugin | compile | default | compile |
| maven-surefire-plugin | test | default | test |
| maven-jar-plugin | jar | default | package |
从表中可见，default生命周期的阶段排列直接决定了构建顺序。比如执行mvn package，会依次走过validate、compile、test直到package，于是compiler和surefire的目标都会在相应阶段自动运行。若你把单元测试插桩写到了integration-test阶段，那么普通package不会触发它，必须执行mvn verify或deploy才会覆盖到该阶段。
四、绑定错误导致的典型问题与排查
一种常见误区是把生成源码的插件绑到了compile之后，例如用插件自动生成DTO却绑到package阶段，结果编译主代码时因找不到类而失败。正确做法应绑到generate-sources阶段，让代码在compile之前就绪。另一个误区是在clean生命周期之外期望执行清理，例如在default的initialize阶段写删除target的逻辑，但用户只运行mvn clean时根本不会进入default，清理自然不发生。
排查时可以使用mvn help:effective-pom查看最终生效的插件绑定，或用mvn <phase> -X打开调试日志，观察生命周期进入哪个阶段、哪些execution被触发。当发现某插件未按预期执行，第一反应应是确认execution的phase是否属于当前调用的生命周期，以及该phase是否在命令所及阶段范围之内。
五、实践建议
写pom.xml时，优先依赖插件目标的默认phase，减少显式声明以降低配置复杂度；只有当默认阶段不符合需求，或目标本身无默认阶段时，才通过execution的phase精确绑定。对于跨生命周期需求，如清理加构建，应在命令行组合调用，例如mvn clean package，而不是试图在一个execution里跨越clean与default。
此外，建议把同一类任务集中在相邻阶段，避免把资源拷贝分散到process-resources和process-classes两处，增加维护成本。只要理清三套生命周期的边界、阶段顺序以及execution的phase指向，Maven构建过程就会变得透明且可控。
Mavenpom_xmllifecycle_phase修改时间：2026-08-10 02:33:28