Maven 插件是怎样绑定生命周期并执行构建任务的？

Maven 真正干活的是插件。mvn package 看起来只是一条生命周期命令，背后会按阶段触发一串插件目标，比如编译、复制资源、运行测试、打包。理解插件时不要只背“plugin、goal、phase”三个词，关键是看它什么时候执行、执行几次、配置从哪里来。很多构建问题并不是 Maven 神秘，而是某个插件目标绑定错阶段，或者父 POM 里的默认配置被子模块悄悄继承了。

插件、目标和生命周期是什么关系？

插件是一组能力，目标是插件里的一个具体动作，生命周期阶段只是 Maven 预设的一条时间线。比如 maven-compiler-plugin 提供 compile 目标，通常绑定在 compile 阶段；maven-surefire-plugin 负责单元测试，通常在 test 阶段运行。你可以直接执行 mvn compiler:compile，也可以执行 mvn test 让 Maven 按生命周期自动调用绑定好的目标。

xml
<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-compiler-plugin</artifactId>
      <version>3.13.0</version>
      <configuration>
        <release>17</release>
        <encoding>UTF-8</encoding>
      </configuration>
    </plugin>
  </plugins>
</build>

source、target 和 release 的选择也有边界。JDK 9 以后更推荐 release，它会同时约束语言级别和可用 API；只配 source/target 时，代码仍可能误用高版本 JDK 的类库，运行到低版本环境才炸。

pluginManagement 和 plugins 不要混用错

父 POM 里常用 pluginManagement 统一版本，但它只提供默认配置，不会让插件自动执行。真正生效还需要在子模块的 <plugins> 中声明，或者由打包类型的默认生命周期绑定触发。这个边界很重要：pluginManagement 像菜单，plugins 才是点菜。大型项目推荐父 POM 锁版本，子模块按需启用，避免每个模块复制一堆插件配置。

xml
<build>
  <pluginManagement>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>3.2.5</version>
        <configuration>
          <includes>
            <include>**/*Test.java</include>
          </includes>
        </configuration>
      </plugin>
    </plugins>
  </pluginManagement>
</build>

如何把插件目标绑定到阶段？

需要额外产物时，用 executions 明确绑定目标。例如发布 SDK 时经常附带源码包，这可以让 source:jar-no-fork 在 verify 阶段执行。坑在于同一个插件可以有多个 execution，如果 id、phase、goal 写得含糊，最后可能重复打包或漏执行。

xml
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-source-plugin</artifactId>
  <version>3.3.1</version>
  <executions>
    <execution>
      <id>attach-sources</id>
      <phase>verify</phase>
      <goals>
        <goal>jar-no-fork</goal>
      </goals>
    </execution>
  </executions>
</plugin>

常用插件怎么取舍？

compiler、surefire、jar、resources 属于大多数 Java 项目的基础插件，应该在父 POM 里锁定版本。shade、assembly、spring-boot-maven-plugin 这类会重组产物的插件要谨慎使用，因为它们不仅影响构建过程，还会改变最终包的结构。比如 shade 能把依赖合进一个 fat jar，部署方便，但也可能带来类冲突、资源文件覆盖和许可证合规问题。团队里最好把“产物形态”写清楚：普通库只发布 jar，应用服务才打可执行包，不要每个模块都复制同一套打包插件。

这类约定看起来保守，却能减少很多“本地能跑、发布包不能跑”的隐性问题。

追问

为什么有些插件不用配置也会执行？

因为 Maven 对不同 packaging 有默认生命周期绑定，例如 jar 项目默认会编译、测试、打包。这个默认行为降低了入门成本，但也让人误以为所有插件都是“自动发现”的。边界是默认绑定只覆盖常见任务，像生成源码包、Docker 镜像、代码覆盖率通常需要自己声明。排查时可以用 mvn help:effective-pom 看最终绑定。

pluginManagement 里配置了插件，为什么没有生效？

pluginManagement 只是管理版本和默认配置，不等于启用插件。子模块没有在 <plugins> 声明时，它通常不会凭空执行。这样设计的取舍是父 POM 可以统一标准，又不会强迫每个模块跑不需要的插件。踩坑时先看插件到底出现在 effective POM 的哪个位置。

跳过测试应该用 skipTests 还是 maven.test.skip？

skipTests 通常只跳过测试执行，测试代码仍可能编译；maven.test.skip=true 连测试编译也跳过。前者适合临时加快打包，后者更激进，可能掩盖测试代码长期编译失败的问题。CI 主线不建议长期使用任何跳过测试的开关，除非有单独阶段补回。边界是本地调试可以求快，发布流水线要保守。

Maven 插件版本要不要每次都写？

建议写，至少在父 POM 里统一锁定。完全依赖 Maven 或超级 POM 的默认版本，会让不同 Maven 版本、不同时间创建的项目表现不一致。取舍是维护版本矩阵多一点工作，但构建可复现性更好。插件升级也要看 release note，特别是 surefire、compiler、shade 这类会影响产物的插件。

直接执行 mvn plugin:goal 和跑生命周期有什么区别？

直接执行目标只跑你点名的动作，生命周期命令会从前置阶段一路执行到指定阶段。比如 mvn jar:jar 可能不会先编译最新代码，而 mvn package 会按顺序处理资源、编译、测试、打包。前者适合诊断单个插件，后者适合日常构建。踩坑点是手动执行目标得到一个包，并不代表完整构建流程是健康的。