Spring 源码精要20问 —— 基于第一性原理

第一层：容器根基（IoC 容器的本质）

Q1. BeanFactory 与 ApplicationContext 到底是什么关系？

推理思路： 从 BeanFactory 接口出发，逐层查看其子接口 ListableBeanFactory、HierarchicalBeanFactory、AutowireCapableBeanFactory，再追踪 ApplicationContext 的继承树，画出完整的接口图谱。核心追问：ApplicationContext 比 BeanFactory 多了什么能力？这些能力从何而来？

第一性原理：为什么要拆三个 BeanFactory 子接口？

ListableBeanFactory、HierarchicalBeanFactory、AutowireCapableBeanFactory 三者彼此平行，并不互相继承，对应容器三种正交能力：

第一性原理：单一职责 + 接口隔离原则（ISP）。Spring 没有把这些能力塞进一个大接口，而是按"语义动词"拆分，让 DefaultListableBeanFactory 同时实现它们，从而具备完整能力——这是 Java SPI 设计的范本。

第一性原理：ApplicationContext的核心能力

ApplicationContext 真正的杀手锏，不是那些继承的接口，而是 AbstractApplicationContext.refresh()（约 581 行起）的"自动注册"约定：

第一性原理解读：

• BeanFactory 是 "惰性工厂（lazy factory）" —— 你不问我就不做；
• ApplicationContext 是 "主动容器（eager container）" —— 启动时把基础设施（事件、国际化、后置处理器）一切就绪，约定优于配置。

这也是为什么 Spring 推荐业务代码 99% 场景用 ApplicationContext，只有在极简场景（如纯配置加载、嵌入第三方框架）才退回到 BeanFactory。

④ 还应该提及的两个易混淆点

1. ConfigurableApplicationContext（spring-context/.../ConfigurableApplicationContext.java）：可配置/可刷新的 ApplicationContext，是启动期操作的接口（refresh()、close()）。这就是为什么 ClassPathXmlApplicationContext、AnnotationConfigApplicationContext 都要实现它，否则没法 refresh。
2. BeanDefinitionRegistry：ApplicationContext 内部那个 DefaultListableBeanFactory 还实现了 BeanDefinitionRegistry，承担 "注册 BeanDefinition" 的职责，但 ApplicationContext 自身不再继承它，因为注册动作只在启动期进行，不属于运行时 client API。

📌 本题一句话第一性原理总结

Spring 把"管理对象"这件事按"动词"拆成 4 个正交接口（取/列/层叠/注入），又按"运行时/启动期"拆成 2 个层次（BeanFactory 运行时按需取，ApplicationContext 启动期主动装配一切）。前者是基础设施，后者是企业级容器入口。