我最近在做一个内部平台的 Spring Boot 中间件重构时，需要在 容器刷新（refresh）之前动态注入一批配置项，同时注册少量基础设施类的 BeanDefinition。然而普通的 BeanFactoryPostProcessor 太晚了，EnvironmentPostProcessor 又不适合做 BeanDefinition 修改。

在查阅 Spring 的启动流程后，我发现 ApplicationContextInitializer 正好解决了我当时遇到的问题。因此，我把踩过的一些点整理成这篇文章，希望能帮助正在研究 Spring 启动过程、或正在开发自定义 Starter 的同学理解这个扩展点的价值。

---

一、ApplicationContextInitializer 的角色定位是什么？

ApplicationContextInitializer 是 Spring 在 ApplicationContext 刚创建，但尚未 refresh 时触发的扩展接口。

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

它的定位非常明确：

• BeanDefinition 已加载
• Environment 已就绪但未最终固化
• Bean 尚未实例化
• Spring Boot 自动配置体系还未开始运转

也就是说，它介于 “环境准备” 和 “容器刷新” 之间，是一个非常操底层、但也非常适合框架开发者的小而强的入口。

---

二、它能解决什么问题？（结合真实案例）

在我的平台中，需要在容器启动非常早的阶段做两件事情：

1. 根据外部环境动态生成配置键值（例如从 K8s ConfigMap 中拉取应用级别元数据）。
2. 为平台监控体系注入一个底层组件，让所有上层模块都可以透明访问到它。

这两个操作都 必须发生在容器 refresh 之前，否则会影响后续自动配置。

最终选择 ApplicationContextInitializer 的原因很简单：

✔ 适合：修改 Environment

applicationContext.getEnvironment()
    .getPropertySources()
    .addLast(new MapPropertySource("platformMeta", metaMap));

✔ 适合：注册 BeanDefinition

GenericBeanDefinition bd = new GenericBeanDefinition();
bd.setBeanClass(PlatformMonitor.class);
applicationContext.getBeanFactory()
    .registerBeanDefinition("platformMonitor", bd);

这两个操作放到 BeanFactoryPostProcessor 中都太晚了。

这也是我写这篇文章的原因：这个扩展点虽小，却能真正解决一类“容器启动早期处理”相关的问题。

---

三、它在整个 Spring 启动流程中的位置

为了让读者理解它的位置，我画了一份我自己内部文档中使用的小图（使用文字描述，避免版权争议）：

[Prepare Environment]
        ↓
[create ApplicationContext]
        ↓
★ ApplicationContextInitializer.initialize()
        ↓
[load BeanDefinitions]
        ↓
[BeanFactoryPostProcessor]
        ↓
[Bean instantiate]
        ↓
[ApplicationListener]
        ↓
[refresh complete]

可以看到：
它是在 所有 BeanFactoryPostProcessor 之前执行的。

---

四、如何使用 ApplicationContextInitializer？

1. 在 Spring Boot 中直接添加（开发中最常用）

SpringApplication application = new SpringApplication(MyApplication.class);
application.addInitializers(new PlatformContextInitializer());
application.run(args);

2. 使用 application.properties 配置（无需改代码）

context.initializer.classes=com.example.PlatformContextInitializer

3. 在 META-INF/spring.factories 中注册（用于 Starter 开发）

org.springframework.context.ApplicationContextInitializer=\
com.example.PlatformContextInitializer

---

五、一个完整、可运行、可复用的示例

以下是我在实际项目中精简过的代码版本，保留了关键细节和扩展点。

public class PlatformContextInitializer
        implements ApplicationContextInitializer<ConfigurableApplicationContext> {

    @Override
    public void initialize(ConfigurableApplicationContext context) {

        // （1）动态添加平台元信息
        Map<String, Object> meta = loadPlatformMeta(); // 自定义加载逻辑
        context.getEnvironment()
                .getPropertySources()
                .addLast(new MapPropertySource("platformMeta", meta));

        // （2）注册平台监控组件
        GenericBeanDefinition def = new GenericBeanDefinition();
        def.setBeanClass(PlatformMonitor.class);
        context.getDefaultListableBeanFactory()
                .registerBeanDefinition("platformMonitor", def);
    }
}

这个类运行时机足够早，因此可以非常灵活地扩展上下文结构。

---

六、使用时的注意事项（实际踩坑总结）

• 不要访问 Bean 实例 —— 它们不存在
• 不要写业务逻辑 —— 否则你会打乱启动顺序
• 不要在这里注入太多配置 —— 影响 Environment 的可控性
• 适合用于框架开发，不适合业务代码

我在平台中曾经把一个业务层的初始化逻辑放在这里，导致 Autowired 失效，最终调试了半天才意识到是启动顺序太早导致的“天然注入失败”。
这一点建议所有初学者务必注意。

---

七、结语

在 Spring 体系中，很多人熟悉 BeanPostProcessor 和自动配置，却不一定了解 ApplicationContextInitializer。但在某些需要“抢跑”的启动场景下，它可以提供极高的灵活性。