Spring 中的 ApplicationContext 是什么？
- 标签：后端、Spring
🏛 业务架构师
ApplicationContext 是 BeanFactory 的高级形态，即"应用上下文"——业务系统真正使用的容器。它在基础容器能力之上，叠加了一整套企业级特性：
- 启动即预实例化单例：把装配错误拦在上线前；
- 事件发布订阅（
ApplicationEventPublisher）：模块间解耦通信； - 国际化（MessageSource）：多语言业务文案；
- 环境抽象与 Profile：一套代码适配多环境（测试/预发/生产）；
- 注解驱动：
@ComponentScan、@Autowired等注解的解析都构建在它之上。
从业务架构视角，我认为 ApplicationContext 最大的价值是**"约定优于配置"的载体**：Spring Boot 的自动配置、外部化配置（application.yml）、配置中心（Nacos）的动态刷新，全部挂在这套上下文体系上。理解它，等于理解了 Spring Boot 应用"从配置到可运行业务系统"的装配主线。
实战中两个高频使用点：一是启动后的 run() 返回的正是 ConfigurableApplicationContext，需要时可以编程式取 Bean（但应克制，多数时候说明设计有问题）；二是 K8s 优雅停机时，调用 close() 触发 Bean 销毁回调、释放连接池，配合 preStop 保证滚动发布不丢请求——容器的生命周期管理能力直接服务发布安全，这是它常被忽视的业务价值。
🏗 系统架构师
定位：应用运行时内核。相比 BeanFactory，它把容器从「对象工厂」升级为「应用上下文」：
- 事件发布订阅（
ApplicationEventPublisher）； - 国际化（MessageSource）、资源加载（ResourceLoader）、环境抽象（Profile 加属性源层级）；
- 统一的
refresh()生命周期：BeanFactoryPostProcessor 处理 → BeanPostProcessor 注册 → onRefresh（Web 场景启动内嵌服务器） → 单例预实例化 → 发布 ContextRefreshedEvent。
架构上我关注两点：
refresh()是全系统装配的总闸——Spring Boot 的自动配置、外部化配置绑定都挂在这条流水线上，理解它就理解了框架扩展点全景；- 启动成本：大应用上万 Bean，全量 refresh 要几十秒，在弹性伸缩场景这就是扩容延迟。所以近年的主流优化是 AOT（构建期把装配结果固化为代码）加 GraalVM Native Image，把启动压到毫秒级、内存显著下降——这是 Spring 保持云原生竞争力的关键演进。
💻 全栈开发专家
ApplicationContext 是日常打交道的容器接口，BeanFactory 的超集。在基础容器能力之上叠加了：
- 国际化：
MessageSource，按 locale 取文案 - 事件机制：
ApplicationEventPublisher，publishEvent+@EventListener - 资源加载：
ResourceLoader，统一类路径/文件/URL 资源 - 环境抽象：
Environment+@Profile多环境 - 自动 BeanPostProcessor/AOP：refresh 时自动注册，不用像纯 BeanFactory 手动 add
常见实现：注解驱动的 AnnotationConfigApplicationContext；Boot Servlet 应用实际用的 AnnotationConfigServletWebServerApplicationContext（带内嵌 Tomcat 启动逻辑）。
SpringApplication.run() 返回的就是 ConfigurableApplicationContext，我在启动后用它动态注册过 BeanDefinition、手动 publishEvent 触发联动。Boot 3.2+ 开 spring.threads.virtual.enabled=true 后，这个上下文里的 Tomcat 请求处理会切到虚拟线程——2026 年做吞吐优化常用的一手。