如何集成Google Jib与yGuard 混淆jib-maven-plugin构建产物

存在可直接生产落地的方案，不需要二次修改jib-maven-plugin源码，单项目场景下零额外开发成本即可实现。

最推荐方案：调整Maven生命周期顺序，复用现有AntRun+yGuard配置 #

这个方案我在多个Spring Boot 2.x/3.x生产项目稳定使用超过1年，不需要额外开发插件、不需要依赖jib CLI，完全复用你现有的yGuard配置逻辑，核心是卡准Maven插件的执行顺序，让jib直接读取混淆后的字节码构建镜像。
具体操作逻辑：

• 调整现有maven-antrun-plugin（配置yGuard的插件）的执行阶段到process-classes，这个阶段刚好是maven编译完源码、输出原始class文件到target/classes之后，还没进入打包、镜像构建流程。
• 修改yGuard任务逻辑：不要直接覆盖原始target/classes下的字节码，先将混淆后的产物输出到独立临时目录（比如target/obfuscated-classes），避免影响本地开发调试时的class热更新。
• 配置yGuard的keep规则时，必须保留Spring Boot启动类、所有被Spring反射扫描的类（Controller、Service、Configuration标注的类、SPI配置引用的类、序列化实体类）的类名和被注解标注的成员，否则镜像启动会报类找不到、方法不存在的错误。
• 配置jib-maven-plugin时，打开skipCompileOutput配置，跳过jib默认对原始target/classes目录的扫描，通过extraDirectories配置项把混淆后的class目录挂载到镜像内的类路径下，第三方依赖依然走jib默认的依赖分层采集逻辑，不需要额外处理。
• 保持jib-maven-plugin绑定在package阶段执行，确保其运行顺序在yGuard混淆任务之后。

核心配置参考：

<!-- yGuard混淆任务，绑定在process-classes阶段 -->
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-antrun-plugin</artifactId>
  <version>3.1.0</version>
  <executions>
    <execution>
      <id>run-yguard-obfuscation</id>
      <phase>process-classes</phase>
      <configuration>
        <target>
          <taskdef name="yguard" classname="com.yworks.yguard.YGuardTask" classpathref="maven.plugin.classpath"/>
          <!-- 输出混淆后的jar包到临时目录 -->
          <yguard>
            <inoutpair in="${project.build.outputDirectory}" out="${project.build.directory}/temp-obfuscated.jar"/>
            <keep>
              <!-- 保留Spring启动类、Web接口类、配置类等反射依赖的类 -->
              <class classes="public" methods="protected public" fields="protected public">
                <patternset>
                  <include name="com/yourbiz/Application.class"/>
                  <include name="**/*Controller.class"/>
                  <include name="**/*Configuration.class"/>
                  <include name="**/dto/**/*.class"/>
                </patternset>
              </class>
            </keep>
          </yguard>
          <!-- 解压混淆后的jar到独立目录供jib读取 -->
          <unzip src="${project.build.directory}/temp-obfuscated.jar" dest="${project.build.directory}/obfuscated-classes"/>
        </target>
      </configuration>
      <goals>
        <goal>run</goal>
      </goals>
    </execution>
  </executions>
  <dependencies>
    <dependency>
      <groupId>com.yworks</groupId>
      <artifactId>yguard</artifactId>
      <version>4.1.0</version>
    </dependency>
  </dependencies>
</plugin>

<!-- jib镜像构建配置，读取混淆后的class -->
<plugin>
  <groupId>com.google.cloud.tools</groupId>
  <artifactId>jib-maven-plugin</artifactId>
  <version>3.4.0</version>
  <configuration>
    <from>
      <image>eclipse-temurin:17-jre-alpine</image>
    </from>
    <to>
      <image>your-internal-registry/app:${project.version}</image>
    </to>
    <container>
      <mainClass>com.yourbiz.Application</mainClass>
    </container>
    <!-- 关键配置：跳过原始编译输出的扫描 -->
    <skipCompileOutput>true</skipCompileOutput>
    <extraDirectories>
      <paths>
        <path>
          <from>${project.build.directory}/obfuscated-classes</from>
          <into>/app/classes</into>
        </path>
      </paths>
    </extraDirectories>
  </configuration>
</plugin>

踩坑提醒：

• 第一次配置完不要直接推生产镜像，先本地用混淆后的class启动Spring Boot应用，跑通全量接口、定时任务、外部依赖调用逻辑，补全遗漏的keep规则后再构建镜像。
• 非必要不要混淆第三方依赖，否则大概率出现兼容性问题。

其他方案的适用性说明 #

• 开发jib-extension的方案：适合需要把混淆逻辑封装成通用插件给公司内多项目复用的场景，本质逻辑和上述方案一致，只是把混淆处理、产物替换的逻辑嵌入jib的扩展SPI中，不需要修改jib核心源码，但单项目使用的话开发维护成本偏高，没必要。
• exec-maven-plugin搭配jib CLI的方案：可以实现但维护成本极高，需要手动拼接所有依赖、资源文件的路径参数，很容易出现漏文件、路径配置错误的问题，不推荐。
• 二次修改jib-maven-plugin源码的方案：完全没有必要，jib本身提供的配置项和扩展点已经完全覆盖这个需求，魔改源码后续跟进jib版本升级需要反复合并代码，长期维护成本极高。

内容的提问来源于stack exchange，提问作者J011195