启动流水线

2.1SpringApplication.run() 宏观三段

SpringApplication.run() 是一条线性流程：先建环境，再建容器，最后把容器跑起来。

SpringApplication.run() 内部依次调用五个大步骤：

1. prepareEnvironment() — 建 ConfigurableEnvironment，触发所有 EnvironmentPostProcessor（其中 ConfigDataEnvironmentPostProcessor 负责加载 application.yml/application.properties）。
2. createApplicationContext() — 按应用类型选择上下文实现：Servlet Web 对应 AnnotationConfigServletWebServerApplicationContext，响应式对应 AnnotationConfigReactiveWebServerApplicationContext，非 Web 对应 AnnotationConfigApplicationContext。
3. prepareContext() — 把主启动类注册成第一个 BeanDefinition，绑定 Environment，触发 ApplicationContextInitializer。
4. refreshContext() — 调用 AbstractApplicationContext.refresh()，这是本章的主角。
5. callRunners() — refresh 完成后，按 @Order 依次执行 ApplicationRunner 和 CommandLineRunner。

2.2refresh() 的 12 阶段

AbstractApplicationContext.refresh() 是 Spring 容器启动的主干，12 个方法调用按严格顺序执行，每步的前置条件都由上一步保证。

源码中 refresh() 的方法体如下（Spring Boot 4.0 / Spring Framework 7 起骨架未变）：

// 示意——12 个阶段按顺序调用
public void refresh() throws BeansException, IllegalStateException {
    prepareRefresh();                          // ① 标记启动时间、验证必需属性
    ConfigurableListableBeanFactory beanFactory
        = obtainFreshBeanFactory();            // ② 获取/刷新 BeanFactory
    prepareBeanFactory(beanFactory);           // ③ 注入 ClassLoader、BPP（ApplicationContextAwareProcessor 等）
    postProcessBeanFactory(beanFactory);       // ④ 子类扩展点（Servlet 上下文在此注册 Scope）
    invokeBeanFactoryPostProcessors(beanFactory); // ⑤ ★ 执行所有 BFPP（含 ConfigurationClassPostProcessor）
    registerBeanPostProcessors(beanFactory);   // ⑥ ★ 实例化并注册所有 BPP
    initMessageSource();                       // ⑦ 国际化 MessageSource
    initApplicationEventMulticaster();         // ⑧ 事件广播器
    onRefresh();                               // ⑨ ★ 子类扩展——Servlet 上下文在此启动 Tomcat
    registerListeners();                       // ⑩ 注册 ApplicationListener
    finishBeanFactoryInitialization(beanFactory); // ⑪ ★ preInstantiateSingletons：预实例化非懒单例
    finishRefresh();                           // ⑫ 发布 ContextRefreshedEvent、启动 Lifecycle bean
}

下图是本章的核心——12 阶段竖直流水线，四个关键阶段用朱红标出：

因果顺序：为什么必须这样排列

阶段 5 在阶段 6 之前：invokeBeanFactoryPostProcessors 负责收集并改写所有 BeanDefinition——包括解析 @Configuration 类、加载自动配置（第 3 章细讲）。只有 BeanDefinition 全部就绪，注册 BPP 时才能找到所有 BeanPostProcessor 类型的 Bean。如果顺序颠倒，部分 BPP 的 BeanDefinition 尚未存在，注册就会遗漏。

阶段 6 在阶段 11 之前：BPP 必须先注册，才能在实例化普通单例时介入生命周期（postProcessBeforeInitialization / postProcessAfterInitialization）。如果 BPP 没注册就开始造 Bean，代理（AbstractAutoProxyCreator，第 4 章）就没机会把 Bean 替换成代理对象。这是 第 1 章两类后置处理器 时序约束的直接体现。

改蓝图 → 注册 BPP → 实例化单例：这条因果链是理解容器启动顺序的第一刀。三步缺一不可，且顺序不可颠倒。

2.3反直觉：Tomcat 在 onRefresh（阶段 9）启动

大多数工程师直觉上认为"所有单例造好之后 Tomcat 才能接请求"——这个直觉是错的。

ServletWebServerApplicationContext 重写了 onRefresh()，在第 9 阶段调用 createWebServer()。此时 TomcatWebServer 被构造出来，端口绑定（connector 初始化）发生在这里。而非懒业务单例（包括各种 @Service、@Repository）要到阶段 11 的 preInstantiateSingletons 才开始构造。

关键细节：createWebServer() 只是建了 server 实例，真正让 Tomcat 开始接受外部流量的 start() 调用在阶段 12 的 finishRefresh() 内。因此阶段 9 之后，端口已被绑定但尚未对外服务；启动若在阶段 11 失败（某个 Bean 抛异常），Spring 会触发优雅关闭，Tomcat 随之关闭，不会有僵尸端口留下。

// 示意：ServletWebServerApplicationContext 重写 onRefresh
@Override
protected void onRefresh() {
    super.onRefresh();
    try {
        createWebServer(); // 构造 TomcatWebServer，绑定端口
    }
    catch (Throwable ex) {
        throw new ApplicationContextException("Unable to start web server", ex);
    }
}

// finishRefresh 内部才真正 start Tomcat（阶段 12）
@Override
protected void finishRefresh() {
    super.finishRefresh();
    WebServer webServer = startWebServer(); // 调用 TomcatWebServer.start()
    if (webServer != null) {
        publishEvent(new ServletWebServerInitializedEvent(webServer, this));
    }
}

2.4callRunners 与启动后扩展点

refresh() 结束后，SpringApplication.run() 调用 callRunners()，按 @Order 顺序依次执行所有 ApplicationRunner 和 CommandLineRunner。此时容器已完全就绪，Tomcat 也已开始接流量。

在 refresh 内部（阶段 11），当所有单例造好后，容器还会依次调用 SmartInitializingSingleton.afterSingletonsInstantiated()——这发生在 refresh 内部、callRunners 之前，也在 Tomcat 正式 start() 之前（阶段 12 之前）。这个时机适合做"需要所有单例就绪、但不想等到 HTTP 流量进来"的预热。