Spring Bean生命周期由模板模式驱动，AbstractAutowireCapableBeanFactory定义createBean()等骨架方法；Aware接口与BeanPostProcessor提供解耦扩展点；作用域决定实例管理方式，singleton走缓存，prototype每次新建；销毁需显式调用context.close()触发。
理解 Spring Bean 生命周期，关键不在死记阶段名称，而在看清设计模式如何驱动每一步、源码中哪些类和方法真正串联起“创建→使用→销毁”全过程。它不是线性流程图，而是一套可插拔、可扩展的控制机制。
模板模式：生命周期骨架由 AbstractAutowireCapableBeanFactory 定义
Spring 把 Bean 创建与初始化的主干逻辑封装在 AbstractAutowireCapableBeanFactory 中，它用模板方法（如 createBean()）定义流程骨架，把具体步骤延迟到子类或回调中实现。比如：
-
createBeanInstance()负责实例化（反射 or 工厂方法） -
populateBean()执行依赖注入（字段、setter、构造器） -
initializeBean()触发 Aware 回调、BeanPostProcessor、init-method 等初始化动作
这种设计让容器能统一调度，又不耦合具体实现——你换一个自定义 BeanDefinition 或注入策略，主流程完全不受影响。
Aware 接口与 BeanPostProcessor：解耦的扩展点设计
Spring 不靠继承或修改核心类来支持定制，而是提供两组轻量级扩展钩子：
立即学习“Java免费学习笔记（深入）”；
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
Aware 系列接口（如
ApplicationContextAware、BeanFactoryAware）：在初始化早期主动“喂给”Bean 它需要的上下文能力，属于容器向 Bean 单向注入 -
BeanPostProcessor：在
initializeBean()前后各执行一次，允许对任意 Bean 实例做包装、代理、属性增强等操作，是 AOP、@Async、@Transactional 的底层支撑
二者都基于“好莱坞原则”——不是 Bean 去找容器，而是容器在恰当时候把资源或处理权交给 Bean。
作用域决定生命周期归属，源码里看缓存与创建时机
Bean 的“活多久”，本质是容器怎么管它的实例：
-
Singleton：默认作用域，实例存在
DefaultSingletonBeanRegistry.singletonObjects（ConcurrentHashMap）中，getBean()时先查缓存，无则创建并注册——整个容器生命周期内只一份 -
Prototype：每次
getBean()都调用createBean()新建实例，不进单例池，容器不负责销毁（需手动或靠 JVM GC） -
Request/Session/Application：由
RequestScope、SessionScope等实现类配合 Web 环境的生命周期监听器（如ServletRequestListener）动态管理
看懂 AbstractBeanFactory.doGetBean() 如何根据 mbd.isSingleton() 或 mbd.isPrototype() 分支处理，就抓住了作用域与生命周期绑定的源码入口。
从启动到 close：完整链路必须手动触发才能观察全貌
很多开发者只看到 Bean 初始化，却漏掉销毁环节——因为默认 Web 应用中容器由 Servlet 容器托管，close() 不显式调用。要验证 @PreDestroy、DisposableBean.destroy() 或 destroy-method，得这样写测试：
ConfigurableApplicationContext context = SpringApplication.run(App.class, args); // ... 使用 Bean context.close(); // 必须调用，否则销毁逻辑不执行
此时源码会进入 AbstractApplicationContext.close() → destroyBeans() → 遍历单例池逐个触发销毁回调。原型 Bean 不在此列，这也印证了“作用域即生命周期契约”。
