如何在Java Spring Boot构建阶段按需移除功能？

下面给你几个直接可用的方案，都是在构建阶段就把配置或代码固化死，完全避免运行时被篡改：

一、用Maven Profiles+Jar插件直接剔除不需要的报表类/包 #

这是最彻底的方式——直接把禁用的报表相关类从最终Jar里删掉，连字节码都不存在，根本没机会被启用。

步骤：

1. 在pom.xml里定义不同环境的Profiles，按需求配置要排除的报表包：

<profiles>
    <profile>
        <id>prod-with-report1</id>
        <properties>
            <excluded.report.packages>com.example.reports.report2,com.example.reports.report3</excluded.report.packages>
        </properties>
    </profile>
    <profile>
        <id>test-only-report2</id>
        <properties>
            <excluded.report.packages>com.example.reports.report1,com.example.reports.report3</excluded.report.packages>
        </properties>
    </profile>
</profiles>

2. 配置maven-jar-plugin，根据Profile属性排除指定包：

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-jar-plugin</artifactId>
            <version>3.3.0</version>
            <configuration>
                <excludes>
                    <exclude>${excluded.report.packages}/**/*.class</exclude>
                </excludes>
            </configuration>
        </plugin>
    </plugins>
</build>

构建时指定Profile即可：mvn clean package -P prod-with-report1，最终Jar里只剩允许的报表类。

如果觉得Jar插件的排除不够彻底（编译阶段仍会编译这些类），可以配合maven-antrun-plugin在编译后直接删除目标目录里的禁用类：

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-antrun-plugin</artifactId>
    <version>3.1.0</version>
    <executions>
        <execution>
            <phase>compile</phase>
            <goals>
                <goal>run</goal>
            </goals>
            <configuration>
                <tasks>
                    <delete dir="${project.build.outputDirectory}/com/example/reports/report2"/>
                    <delete dir="${project.build.outputDirectory}/com/example/reports/report3"/>
                </tasks>
            </configuration>
        </execution>
    </executions>
</plugin>

二、构建时把配置硬编码到类中，彻底锁死 #

如果不想删除类，只是要让开关配置无法被运行时修改，可以把开关常量直接编译进Java类，用Maven插件实现替换。

1. 编写配置类，预留占位符：

public class ReportConfig {
    // 构建时会被替换为true/false
    public static final boolean REPORT1_ENABLED = ${report1.enabled};
    public static final boolean REPORT2_ENABLED = ${report2.enabled};
}

2. 在pom.xml的Profile里定义开关属性：

<profile>
    <id>enable-report1-only</id>
    <properties>
        <report1.enabled>true</report1.enabled>
        <report2.enabled>false</report2.enabled>
    </properties>
</profile>

3. 用maven-replacer-plugin在编译前替换类中的占位符：

<plugin>
    <groupId>com.google.code.maven-replacer-plugin</groupId>
    <artifactId>replacer</artifactId>
    <version>1.5.3</version>
    <executions>
        <execution>
            <phase>process-sources</phase>
            <goals>
                <goal>replace</goal>
            </goals>
            <configuration>
                <file>src/main/java/com/example/config/ReportConfig.java</file>
                <replacements>
                    <replacement>
                        <token>${report1.enabled}</token>
                        <value>${report1.enabled}</value>
                    </replacement>
                    <replacement>
                        <token>${report2.enabled}</token>
                        <value>${report2.enabled}</value>
                    </replacement>
                </replacements>
            </configuration>
        </execution>
    </executions>
</plugin>

编译后的ReportConfig类里就是硬编码的布尔值，运行时无论怎么改环境变量、配置文件都无法修改——因为代码已经写死。

三、配合Spring条件注解+Maven Profiles控制类加载 #

如果想用Spring的条件化机制，同时在构建阶段决定是否加载类，可以结合@ConditionalOnProperty和Maven资源过滤。

1. 给报表类添加条件注解：

@Service
@ConditionalOnProperty(name = "report1.enabled", havingValue = "true", matchIfMissing = false)
public class Report1Service {
    // ...
}

2. 在src/main/resources/application.properties中预留占位符：

report1.enabled=${report1.enabled}
report2.enabled=${report2.enabled}

3. 在pom.xml开启资源过滤，构建时将Profile属性写入配置文件：

<build>
    <resources>
        <resource>
            <directory>src/main/resources</directory>
            <filtering>true</filtering>
        </resource>
    </resources>
</build>

这个方案适合轻度固化场景，若要彻底避免运行时篡改，还是推荐前两个方案——毕竟Jar里的配置文件仍存在被修改的可能。

总结：最安全的是直接删除禁用类的方案；硬编码常量适合保留类但锁死开关的场景；条件注解方案适合对固化要求稍低的场景。

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