1. EnvironmentPostProcessor有什么作用？

EnvironmentPostProcessor 是 Spring 框架中一个功能强大的接口，位于 org.springframework.boot.env 包中。它允许开发者在 Spring 应用上下文启动之前 对 Environment 进行修改或扩展。下面是对 EnvironmentPostProcessor 的详细解释：

1. 定义与位置

EnvironmentPostProcessor 是一个接口，定义如下：

@FunctionalInterface
public interface EnvironmentPostProcessor {
    void postProcessEnvironment(ConfigurableEnvironment environment, SpringApplication application);
}

方法解释:
- postProcessEnvironment: 核心方法，用于在 Spring Boot 应用上下文创建前对 Environment 对象进行处理。
- 参数说明:
  - ConfigurableEnvironment environment: Spring Boot 的运行环境对象，可用于访问和修改属性源（Property Sources）。
  - SpringApplication application: 当前运行的 Spring 应用实例，可以获取上下文的配置信息。
包路径: org.springframework.boot.env

2. 作用与特点

修改环境变量:
- 可以在应用启动前添加、修改、删除 Environment 中的属性。
- 例如，从自定义配置文件加载配置、动态修改默认属性值等。
添加/移除属性源:
- 可以向 Environment 中动态添加新的 PropertySource 或移除已有的 PropertySource。
运行时定制化:
- 适合根据运行时的条件（如操作系统、JVM 参数、外部配置等）动态调整应用的行为。
早期执行:
- 它在 ApplicationContext 初始化之前执行，因此比其他如 @Configuration 或 @Bean 的机制更早介入。

3. 使用场景

加载自定义的配置文件。
动态调整属性值，例如根据环境变量设置。
配合外部系统提供环境参数。
为不同环境（如开发、测试、生产）提供定制化支持。

4. 实现步骤

以下是实现 EnvironmentPostProcessor 的一般步骤：

(1) 创建一个类实现接口

import org.springframework.boot.SpringApplication;
import org.springframework.boot.env.EnvironmentPostProcessor;
import org.springframework.core.env.ConfigurableEnvironment;
import org.springframework.core.env.MapPropertySource;

import java.util.HashMap;
import java.util.Map;

public class CustomEnvironmentPostProcessor implements EnvironmentPostProcessor {
    @Override
    public void postProcessEnvironment(ConfigurableEnvironment environment, SpringApplication application) {
        // 定义一个自定义的属性源
        Map<String, Object> customProperties = new HashMap<>();
        customProperties.put("custom.property", "customValue");

        // 将自定义属性源添加到环境中
        environment.getPropertySources().addLast(new MapPropertySource("customPropertySource", customProperties));
    }
}

(2) 注册 `EnvironmentPostProcessor`

在 META-INF/spring.factories 文件中添加如下内容：

org.springframework.boot.env.EnvironmentPostProcessor=\
com.example.CustomEnvironmentPostProcessor

spring.factories 文件通常位于 src/main/resources/META-INF 目录中。
这个配置将告诉 Spring Boot 在应用启动时自动加载这个 EnvironmentPostProcessor。

(3) 使用场景验证

启动应用后，可以通过访问 Environment 来验证自定义属性是否生效。

示例代码：

@RestController
public class TestController {
    @Value("${custom.property}")
    private String customProperty;

    @GetMapping("/property")
    public String getCustomProperty() {
        return customProperty;
    }
}

5. 执行顺序

EnvironmentPostProcessor 的执行顺序由 spring.factories 文件中的加载顺序决定。如果有多个实现类，可以通过实现 Ordered 接口或使用 @Order 注解来定义优先级。

6. 常见问题

属性覆盖问题: 如果一个属性已经存在于环境中，且处于较高优先级的属性源中，自定义的属性可能不会生效。
- 解决办法：使用 addFirst 或 replace 方法调整优先级。
配置文件路径问题: 如果需要加载额外的配置文件，确保文件路径正确且可以被访问。
依赖加载问题: EnvironmentPostProcessor 的逻辑在 ApplicationContext 初始化之前运行，因此不能依赖任何上下文中的 Bean。

7. 示例：动态加载配置文件

以下示例展示了如何通过 EnvironmentPostProcessor 动态加载一个自定义配置文件：

代码示例

import org.springframework.boot.SpringApplication;
import org.springframework.boot.env.EnvironmentPostProcessor;
import org.springframework.core.env.ConfigurableEnvironment;
import org.springframework.core.env.PropertiesPropertySource;
import org.springframework.util.ResourceUtils;

import java.io.FileInputStream;
import java.io.IOException;
import java.util.Properties;

public class CustomConfigFileLoader implements EnvironmentPostProcessor {
    @Override
    public void postProcessEnvironment(ConfigurableEnvironment environment, SpringApplication application) {
        try {
            // 加载自定义配置文件
            Properties properties = new Properties();
            properties.load(new FileInputStream(ResourceUtils.getFile("classpath:custom-config.properties")));

            // 将配置文件内容加入到环境属性源中
            environment.getPropertySources().addLast(new PropertiesPropertySource("customConfig", properties));
        } catch (IOException e) {
            throw new RuntimeException("Failed to load custom-config.properties", e);
        }
    }
}

自定义配置文件

src/main/resources/custom-config.properties:

custom.config.key=customValueFromConfigFile

总结

EnvironmentPostProcessor 是 Spring Boot 提供的一个非常灵活的扩展点，主要用于在应用启动前动态调整 Environment。它适合加载额外的配置、设置默认值、根据条件动态改变属性值等操作。在多模块、多环境的应用中非常实用。

2. 源码中被回调的时机和ApplicationContextInitializer 有什么异同？

EnvironmentPostProcessor 和 ApplicationContextInitializer 都是 Spring 提供的扩展机制，用于在应用启动的不同阶段自定义 Spring 的行为。尽管它们看起来有相似的作用，但回调执行时间和适用场景有所不同，具体在源码层面也有一些明显区别。

1. 概述

`EnvironmentPostProcessor`

作用: 专门用于在 Spring Boot 启动阶段，Environment 准备完成后但在 ApplicationContext 刷新之前，对 Environment 进行自定义配置。

接口定义:

public interface EnvironmentPostProcessor {
    void postProcessEnvironment(ConfigurableEnvironment environment, SpringApplication application);
}

核心功能: 操作 Environment 对象，比如添加/修改 PropertySource。

`ApplicationContextInitializer`

作用: 在 ApplicationContext 刷新之前，允许对 ConfigurableApplicationContext 进行自定义初始化操作。

接口定义:

public interface ApplicationContextInitializer<C extends ConfigurableApplicationContext> {
    void initialize(C applicationContext);
}

核心功能: 对 ApplicationContext 的初始化逻辑进行扩展，比如注册 Bean、调整配置等。

2. 执行时机

`EnvironmentPostProcessor` 执行时机

在 Environment 准备完成后立即执行，优先于所有其他扩展点。

在 SpringApplication 的 prepareEnvironment 方法中被调用，具体位置如下：

// SpringApplication.java
protected ConfigurableEnvironment prepareEnvironment(SpringApplicationRunListeners listeners,
                                                     ApplicationArguments applicationArguments) {
    ConfigurableEnvironment environment = getOrCreateEnvironment();
    configureEnvironment(environment, applicationArguments.getSourceArgs());
    listeners.environmentPrepared(environment);
    // 此时会执行 EnvironmentPostProcessor
    return environment;
}

重要时间点:
- Environment 已完成加载和初始化。
- ApplicationContext 尚未创建。
- 属性和配置文件加载调整的最佳时机。

`ApplicationContextInitializer` 执行时机

在 ApplicationContext 被创建之后，refresh 之前执行。

在 SpringApplication 的 prepareContext 方法中被调用，具体位置如下：

// SpringApplication.java
protected void prepareContext(ConfigurableApplicationContext context, ConfigurableEnvironment environment,
                              SpringApplicationRunListeners listeners, ApplicationArguments applicationArguments,
                              Banner printedBanner) {
    context.setEnvironment(environment);
    postProcessApplicationContext(context);
    applyInitializers(context);
    // 此时会执行 ApplicationContextInitializer
    listeners.contextPrepared(context);
}

重要时间点:
- ApplicationContext 已被创建，但未刷新。
- 可以操作 ApplicationContext 的配置，如注册 Bean、添加 Listener 等。

3. 源码层面差异

调用入口

EnvironmentPostProcessor:

被 SpringApplication 调用，在 prepareEnvironment 中通过 SpringFactoriesLoader 加载：

List<EnvironmentPostProcessor> postProcessors = loadPostProcessors();
for (EnvironmentPostProcessor postProcessor : postProcessors) {
    postProcessor.postProcessEnvironment(environment, this);
}

在 META-INF/spring.factories 中声明。

ApplicationContextInitializer:

被 SpringApplication 调用，在 prepareContext 方法中通过 SpringFactoriesLoader 加载：

List<ApplicationContextInitializer<?>> initializers = getInitializers();
for (ApplicationContextInitializer<?> initializer : initializers) {
    initializer.initialize(context);
}

同样通过 META-INF/spring.factories 声明。

操作对象

EnvironmentPostProcessor:
- 操作的是 ConfigurableEnvironment 对象，关注属性源和环境变量的修改。
- 无法直接操作 ApplicationContext。
ApplicationContextInitializer:
- 操作的是 ConfigurableApplicationContext 对象，可以访问和修改 ApplicationContext 的内容，例如注册 BeanDefinition 或设置默认属性。

加载顺序

EnvironmentPostProcessor:
- 在 Environment 准备阶段加载并执行，比 ApplicationContextInitializer 早。
ApplicationContextInitializer:
- 在 ApplicationContext 准备阶段加载并执行，比 EnvironmentPostProcessor 晚。

4. 使用场景

`EnvironmentPostProcessor` 的典型场景

动态加载配置文件。
修改环境变量，调整 PropertySource。
根据环境动态调整系统参数（如 JVM 参数）。

`ApplicationContextInitializer` 的典型场景

动态注册 Bean。
初始化某些需要依赖 ApplicationContext 的组件。
自定义 ApplicationContext 的生命周期逻辑。

5. 对比总结

特性	EnvironmentPostProcessor	ApplicationContextInitializer
执行时机	`Environment` 准备完成后，`ApplicationContext` 创建之前。	`ApplicationContext` 创建后，`refresh` 方法之前。
操作对象	`ConfigurableEnvironment`	`ConfigurableApplicationContext`
用途	修改环境变量、加载属性源。	自定义上下文逻辑，注册 Bean 或调整上下文配置。
注册方式	在 `spring.factories` 中注册。	在 `spring.factories` 中注册。
执行优先级	更早，适合调整环境属性。	更晚，适合配置上下文依赖项。
典型场景	动态配置加载、属性源调整。	Bean 动态注册、生命周期调整。

6. 示例对比

`EnvironmentPostProcessor` 示例

动态加载自定义配置文件：

public class CustomEnvironmentPostProcessor implements EnvironmentPostProcessor {
    @Override
    public void postProcessEnvironment(ConfigurableEnvironment environment, SpringApplication application) {
        Properties properties = new Properties();
        properties.put("custom.key", "customValue");
        environment.getPropertySources().addFirst(new PropertiesPropertySource("customSource", properties));
    }
}

`ApplicationContextInitializer` 示例

动态注册 Bean：

public class CustomApplicationContextInitializer implements ApplicationContextInitializer<ConfigurableApplicationContext> {
    @Override
    public void initialize(ConfigurableApplicationContext applicationContext) {
        applicationContext.getBeanFactory().registerSingleton("customBean", new CustomBean());
    }
}

7. 总结建议

如果目标是修改环境变量、加载配置文件或调整环境属性，请使用 EnvironmentPostProcessor。
如果目标是对 ApplicationContext 进行自定义，如注册 Bean 或初始化逻辑，请使用 ApplicationContextInitializer。
两者可以结合使用，先用 EnvironmentPostProcessor 准备环境，再用 ApplicationContextInitializer 初始化上下文。
实际上EnvironmentPostProcessor的回调是在容器启动时发布ApplicationEnvironmentPreparedEvent事件时进行调用的。

3. EnvironmentPostProcessor 无法覆盖nacos已有的配置，这是为什么？

你理解得非常正确！如果你尝试通过实现 EnvironmentPostProcessor 来覆盖 Nacos 配置，是无法实现的。这是因为 Nacos 配置的加载基于 ApplicationContextInitializer，而 EnvironmentPostProcessor 的执行时机早于 ApplicationContextInitializer。

具体原因如下：

1. Nacos 配置的加载机制

Nacos 配置加载的核心逻辑通常通过 ApplicationContextInitializer 实现，例如：

Nacos 的配置加载逻辑会在 ApplicationContext 初始化时被触发。
它会将 Nacos 的配置属性合并到 Environment 中，通常是添加到 PropertySource 的较高优先级位置。

其加载顺序如下：

Spring Boot 在 prepareContext 阶段调用 ApplicationContextInitializer。
此时 Nacos 的相关逻辑会将 Nacos 配置注入到 Environment。

在源码层面，ApplicationContextInitializer 的逻辑是后加载的，优先级比 EnvironmentPostProcessor 高，因此即使你在 EnvironmentPostProcessor 中修改了某些配置，Nacos 的配置可能会覆盖你的更改。

2. 为什么无法覆盖 Nacos 配置？

EnvironmentPostProcessor 的作用是在 Environment 完成初始化后对其进行加工，但 Nacos 的配置加载晚于 EnvironmentPostProcessor。这导致以下问题：

你在 EnvironmentPostProcessor 中所做的更改（如添加或覆盖 PropertySource）可能会在 ApplicationContextInitializer 加载 Nacos 配置时被重新覆盖。

更直观的时序：

EnvironmentPostProcessor：
- 你尝试在这里修改 Environment。
- 此时 Nacos 的配置尚未加载，相关属性不存在。
ApplicationContextInitializer（Nacos 的加载逻辑）：
- Nacos 将配置加载到 Environment，覆盖早期的变更。

3. 如何实现覆盖 Nacos 配置？

如果你确实需要覆盖 Nacos 的配置，可以考虑以下几种方式：

方案 1: 自定义 `ApplicationContextInitializer`

通过实现自己的 ApplicationContextInitializer，在 Nacos 的配置加载之后调整 Environment。

示例代码：

public class CustomInitializer implements ApplicationContextInitializer<ConfigurableApplicationContext> {
    @Override
    public void initialize(ConfigurableApplicationContext applicationContext) {
        ConfigurableEnvironment environment = applicationContext.getEnvironment();
        MutablePropertySources propertySources = environment.getPropertySources();

        // 覆盖 Nacos 配置的某些值
        Properties properties = new Properties();
        properties.put("my.custom.key", "myValue");
        propertySources.addFirst(new PropertiesPropertySource("customSource", properties));
    }
}

注册方式：

# META-INF/spring.factories
org.springframework.context.ApplicationContextInitializer=your.package.CustomInitializer

此方法会在所有 ApplicationContextInitializer 执行时生效，可以保证在 Nacos 配置加载之后再覆盖。

方案 2: 使用 `@PostConstruct` 或监听器

如果需要动态覆盖，可以在 Spring 容器启动完成后（例如 Nacos 配置已加载时）覆盖属性。例如：

@Component
public class CustomNacosConfigProcessor {

    @PostConstruct
    public void overrideNacosProperties() {
        ConfigurableEnvironment environment = (ConfigurableEnvironment) ApplicationContextHolder.getContext().getEnvironment();
        MutablePropertySources propertySources = environment.getPropertySources();

        // 动态修改属性
        Properties properties = new Properties();
        properties.put("my.custom.key", "newValue");
        propertySources.addFirst(new PropertiesPropertySource("customOverride", properties));
    }
}

方案 3: 修改 Nacos 的加载逻辑

如果你对 Nacos 的加载逻辑有完全的控制权限，可以考虑自定义 Nacos 配置源的加载顺序，确保你的逻辑在 Nacos 之后生效。这需要深入研究 Nacos 的实现方式并在其加载逻辑中插入自定义代码。

4. 总结

EnvironmentPostProcessor 无法覆盖 Nacos 配置，因为其执行时机早于 Nacos 配置的加载。
如果需要覆盖 Nacos 配置，推荐通过自定义 ApplicationContextInitializer 或监听器，在 Nacos 加载完成后再修改 Environment。
对于动态场景，也可以结合 Spring 的事件机制，在容器启动完成后调整配置。

4. EnvironmentPostProcessor的所有扩展方式

在 Spring Boot 中，EnvironmentPostProcessor 是一个重要的扩展点，主要用于在 Environment 初始化后进行配置或属性的调整。尽管最常见的方式是在 META-INF/spring.factories 文件中指定，实际上还有其他方式可以扩展和使用它。

以下是所有常见的扩展方式：

1. 在 `spring.factories` 中声明

这是最常见和标准的方式，也是 Spring Boot 官方推荐的方式。

步骤:

创建 EnvironmentPostProcessor 的实现类：

public class CustomEnvironmentPostProcessor implements EnvironmentPostProcessor {
    @Override
    public void postProcessEnvironment(ConfigurableEnvironment environment, SpringApplication application) {
        // 自定义逻辑，如动态添加 PropertySource
        Properties properties = new Properties();
        properties.put("custom.key", "customValue");
        environment.getPropertySources().addLast(new PropertiesPropertySource("customSource", properties));
    }
}

在 META-INF/spring.factories 中注册：

org.springframework.boot.env.EnvironmentPostProcessor=your.package.CustomEnvironmentPostProcessor

优点:

简单易用，无需额外代码逻辑。
自动被 Spring Boot 启动时加载。

局限:

加载逻辑由 SpringFactoriesLoader 统一处理，不支持动态条件或细粒度控制。

2. 手动注册

你可以通过显式调用 EnvironmentPostProcessor 的逻辑来执行，而不依赖 spring.factories 自动加载机制。

使用场景:

需要手动控制 EnvironmentPostProcessor 的执行时机。
在非 Spring Boot 环境中使用。

示例代码:

public class ManualEnvironmentPostProcessor {
    public static void main(String[] args) {
        SpringApplication application = new SpringApplication(MyApplication.class);
        ConfigurableEnvironment environment = application.run(args).getEnvironment();

        // 手动调用自定义的 EnvironmentPostProcessor
        new CustomEnvironmentPostProcessor().postProcessEnvironment(environment, application);
    }
}

优点:

可以精确控制执行时机和条件。
不依赖 Spring Boot 自动配置机制。

局限:

需要手动管理执行逻辑，无法自动集成到 Spring Boot 生命周期。

3. 使用 `SpringApplication` 的 `addListeners`

通过添加 SpringApplicationRunListener，间接实现类似于 EnvironmentPostProcessor 的功能。

示例代码:

public class CustomApplicationListener implements ApplicationListener<ApplicationEnvironmentPreparedEvent> {
    @Override
    public void onApplicationEvent(ApplicationEnvironmentPreparedEvent event) {
        ConfigurableEnvironment environment = event.getEnvironment();

        // 添加或修改 PropertySource
        Properties properties = new Properties();
        properties.put("listener.key", "listenerValue");
        environment.getPropertySources().addLast(new PropertiesPropertySource("listenerSource", properties));
    }
}

注册方式:

在主方法中添加：

public static void main(String[] args) {
    SpringApplication application = new SpringApplication(MyApplication.class);
    application.addListeners(new CustomApplicationListener());
    application.run(args);
}

优点:

无需使用 spring.factories。
可以结合其他 Listener 使用，灵活性更高。

局限:

不是真正的 EnvironmentPostProcessor 扩展，但功能上相似。

4. 使用 `@Configuration` 配置类

通过 @Configuration 和 @EventListener 的方式，也可以实现类似于 EnvironmentPostProcessor 的功能。

示例代码:

@Configuration
public class CustomEnvironmentConfiguration {
    @EventListener
    public void handleEnvironmentPrepared(ApplicationEnvironmentPreparedEvent event) {
        ConfigurableEnvironment environment = event.getEnvironment();

        // 添加自定义配置
        Properties properties = new Properties();
        properties.put("config.key", "configValue");
        environment.getPropertySources().addLast(new PropertiesPropertySource("configSource", properties));
    }
}

优点:

与 Spring 的事件机制紧密结合。
可以基于条件动态执行。

局限:

需要依赖 ApplicationEnvironmentPreparedEvent，不完全等同于 EnvironmentPostProcessor 的职责。

5. 自定义 `SpringApplication`

你可以通过扩展 SpringApplication 类，自定义启动逻辑，包括手动注册 EnvironmentPostProcessor。

示例代码:

public class CustomSpringApplication extends SpringApplication {
    public CustomSpringApplication(Class<?>... primarySources) {
        super(primarySources);
    }

    @Override
    protected void configureEnvironment(ConfigurableEnvironment environment, String[] args) {
        super.configureEnvironment(environment, args);

        // 添加自定义逻辑
        new CustomEnvironmentPostProcessor().postProcessEnvironment(environment, this);
    }
}

使用方式:

public static void main(String[] args) {
    SpringApplication application = new CustomSpringApplication(MyApplication.class);
    application.run(args);
}

优点:

可以完全控制 EnvironmentPostProcessor 的加载和执行。
灵活性高。

局限:

需要自定义启动逻辑，不适合标准化项目。

6. 使用 `@Conditional` 和 Bean 配置

通过定义一个 @Bean 并结合条件注解，可以有条件地加载类似 EnvironmentPostProcessor 的功能。

示例代码:

@Configuration
public class ConditionalEnvironmentConfiguration {

    @Bean
    @ConditionalOnProperty(name = "custom.environment.enabled", havingValue = "true")
    public EnvironmentPostProcessor customEnvironmentPostProcessor() {
        return new CustomEnvironmentPostProcessor();
    }
}

优点:

灵活支持条件加载。
结合 Spring Boot 的自动配置机制，方便扩展。

局限:

需要通过其他方式手动触发 postProcessEnvironment 方法。

总结

扩展方式	是否依赖 `spring.factories`	优点	局限
`spring.factories` 声明	是	标准方式，自动加载	无法动态控制加载条件
手动注册	否	可精确控制执行时机	需要手动管理逻辑
`addListeners`	否	灵活支持动态逻辑	不是真正的 `EnvironmentPostProcessor`
使用 `@Configuration`	否	与事件机制结合，支持动态扩展	依赖事件机制，不完全等同于扩展点
自定义 `SpringApplication`	否	灵活性最高，可完全定制	复杂度较高，侵入性强
条件加载 (`@Conditional`)	否	支持条件控制	需手动调用扩展点

文档信息

本文作者：Marshall

EnvironmentPostProcessor详细解释

1. EnvironmentPostProcessor有什么作用？

1. 定义与位置

2. 作用与特点

3. 使用场景

4. 实现步骤

(1) 创建一个类实现接口

(2) 注册 EnvironmentPostProcessor

(3) 使用场景验证

5. 执行顺序

6. 常见问题

7. 示例：动态加载配置文件

代码示例

自定义配置文件

总结

2. 源码中被回调的时机和ApplicationContextInitializer 有什么异同？

1. 概述

EnvironmentPostProcessor

ApplicationContextInitializer

2. 执行时机

EnvironmentPostProcessor 执行时机

ApplicationContextInitializer 执行时机

3. 源码层面差异

调用入口

操作对象

加载顺序

4. 使用场景

EnvironmentPostProcessor 的典型场景

ApplicationContextInitializer 的典型场景

5. 对比总结

6. 示例对比

EnvironmentPostProcessor 示例

ApplicationContextInitializer 示例

7. 总结建议

3. EnvironmentPostProcessor 无法覆盖nacos已有的配置，这是为什么？

1. Nacos 配置的加载机制

2. 为什么无法覆盖 Nacos 配置？

3. 如何实现覆盖 Nacos 配置？

方案 1: 自定义 ApplicationContextInitializer

方案 2: 使用 @PostConstruct 或监听器

方案 3: 修改 Nacos 的加载逻辑

4. 总结

4. EnvironmentPostProcessor的所有扩展方式

1. 在 spring.factories 中声明

步骤:

优点:

局限:

2. 手动注册

使用场景:

示例代码:

优点:

局限:

3. 使用 SpringApplication 的 addListeners

示例代码:

注册方式:

优点:

局限:

4. 使用 @Configuration 配置类

示例代码:

优点:

局限:

5. 自定义 SpringApplication

示例代码:

使用方式:

优点:

局限:

6. 使用 @Conditional 和 Bean 配置

示例代码:

优点:

局限:

总结

推荐使用

文档信息

Search

Table of Contents

(2) 注册 `EnvironmentPostProcessor`

`EnvironmentPostProcessor`

`ApplicationContextInitializer`

`EnvironmentPostProcessor` 执行时机

`ApplicationContextInitializer` 执行时机

`EnvironmentPostProcessor` 的典型场景

`ApplicationContextInitializer` 的典型场景

`EnvironmentPostProcessor` 示例

`ApplicationContextInitializer` 示例

方案 1: 自定义 `ApplicationContextInitializer`

方案 2: 使用 `@PostConstruct` 或监听器

1. 在 `spring.factories` 中声明

3. 使用 `SpringApplication` 的 `addListeners`

4. 使用 `@Configuration` 配置类

5. 自定义 `SpringApplication`

6. 使用 `@Conditional` 和 Bean 配置