从写Spring代码的第一天起，你就会频繁听到一个词：Bean的生命周期。面试问、源码分析讲、项目排查看日志也绕不开。但说实话，很多人对这个概念的理解停留在“容器启动-构造-初始化-销毁”这种口诀层面。真要问你：BeanPostProcessor是在哪一步介入的？Aware接口回调为什么有顺序？循环依赖时生命周期哪里不一样？原型Bean的销毁为什么不归容器管？能一口气答清楚的人其实不多。
这篇内容我打算换个讲法，不按教科书顺序念一遍源码，而是直接把Spring Bean生命周期拆成一个可以“跟着跑”的实操过程，把每一条回调的执行时机、代码位置、设计意图全部对一遍，再附上我自己调试源码时踩过的一些坑。无论你是背面试题还是排查线上问题，看完应该都能有个更清楚的底。
1. 为什么所有框架都在聊“生命周期”
先扯点题外话。你去看我们现在常用的一堆技术概念，前端有Vue3的页面加载生命周期、Uniapp的组件生命周期、Android的Activity生命周期，后端有线程生命周期、Rust的所有权生命周期，甚至连项目管理里的缺陷都有自己的生命周期流转规则。
这些东西本质上是同一件事：管理一个对象从诞生到销毁的完整过程，在关键节点上留出回调口子，让使用框架的人可以在特定时机插入自己的逻辑。
举几个例子你就明白了。
1.1 Android和Vue的生命周期对比
Android的Activity生命周期大家都很熟：onCreate、onStart、onResume、onPause、onStop、onDestroy。你从A页面跳到B页面，再返回A页面时，A走的是onRestart、onStart、onResume那套流程，而不是重新onCreate一遍。这个“返回时走哪个生命周期”的问题，本质上是框架在帮你管理界面状态和资源。
Vue3的组件生命周期也一样，setup、onMounted、onUpdated、onUnmounted，每个钩子都对应组件状态的一个变化节点。页面加载完之后你会去onMounted里发请求、初始化第三方库，这些都是在用框架给的回调口子做自己的事。
1.2 线程和Rust的生命周期
线程的生命周期就不用多说了，new、runnable、blocked、waiting、timed_waiting、terminated，Java官方文档把状态转换画得清清楚楚。你调start()之后线程进入就绪态，抢到CPU执行权才进入运行态，sleep或wait又会把线程拽到等待队列里。
Rust的生命周期则是编译期概念，它不管理运行时的创建销毁，而是通过生命周期标注告诉编译器“这个引用在哪个范围内是有效的”。这个思想跟Spring Bean生命周期其实很像——都是在定义“一个对象在什么条件下是安全的、可用的”。
1.3 缺陷生命周期和Bean生命周期
关于缺陷生命周期，做测试的同学肯定清楚。一个bug从提交开始，状态流转是：新建、已指派、已修复、已验证、已关闭，中间还可能穿插重新打开、延期处理、挂起。严重级别S1-S4决定修复优先级，但要注意，严重级别高不等于优先级一定最高，因为还要看影响范围、用户反馈量、当前迭代目标等因素。
说这些是为了让你建立一个大局观：**Spring Bean生命周期不是什么Spring独有的黑科技，它只是把“状态管理+回调机制”这件事做到了极致而已。**你理解了这套大原则，再去看Spring的实现思路就顺了。
2. Spring Bean的生命周期到底长什么样
先给一个整体的骨架。一个普通的单例Bean，从诞生到销毁，大致经过下面这些阶段：
- BeanDefinition加载与解析
- 实例化（构造对象）
- 属性填充（依赖注入）
- Aware接口回调
- BeanPostProcessor前置处理
- 初始化（InitializingBean、init-method、@PostConstruct）
- BeanPostProcessor后置处理
- Bean就绪，可以被使用了
- 容器关闭，触发销毁
看起来是9个阶段，实际放进代码里大概几十个方法。我从面试和排查问题的角度，挑几个关键阶段详细拆解。
2.1 阶段一：BeanDefinition加载与解析
Spring容器启动的第一步，是读取配置信息，把它们转换成BeanDefinition。XML里的<bean>标签、@Component注解扫描、@Bean方法、@Import导入的类，最终都会变成一个个BeanDefinition对象，注册到BeanDefinitionRegistry里。
BeanDefinition里存了Bean的类名、作用域（singleton还是prototype）、懒加载标识、初始化方法名、销毁方法名、属性值、构造器参数等一堆信息。Spring这时候并不知道要创建多少个实例，它只知道“有哪些Bean要创建、怎么创建”。
这一步对日常开发的影响很小，因为Spring自动帮你处理了。但如果你做框架二次开发、写自定义starter，就经常需要手动注册BeanDefinition，甚至动态修改某个Bean的初始化方法。那时候你就知道，BeanDefinition是Spring所有后续操作的数据基础。
2.2 阶段二：实例化与属性填充
到了创建阶段，Spring开始真正去new对象。实例化方式有三种：构造器方式、工厂方法方式、Supplier方式。最常用的是构造器方式，Spring会推断构造器，找到合适的构造方法并调用。
实例化完成之后，Spring会接着做属性填充，也就是依赖注入。@Autowired、@Resource、@Value这些注解就是在这个阶段处理的。
我来手动写一个简单的过程伪代码，帮你理解Spring在这个阶段是“两段式”的：
// 第一步：实例化 Object bean = createBeanInstance(beanDefinition); // 第二步：属性填充 populateBean(beanDefinition, bean);**注意，这里有个很多新手搞混的点：构造器和属性注入的时机不同。**构造器注入是在实例化阶段完成的，属性注入是在populateBean阶段完成的。所以如果你在构造器里访问一个通过@Autowired注入的属性，会拿到null——因为这时候还没开始注入。
提示：实际开发中，我自己更推荐构造器注入而不是字段注入，除了定位和测试方便之外，还有一个好处：强制依赖可以在Bean创建时就确定，避免运行时才发现依赖没注入。
2.3 阶段三：Aware接口回调
属性填充完成后，Spring会检查Bean是否实现了一系列Aware接口。这些接口用于让Bean意识到自己身处Spring容器环境，从而获取容器资源。
常见的有：
- BeanNameAware：获得Bean在容器中的名字
- BeanFactoryAware：获得当前BeanFactory
- ApplicationContextAware：获得当前ApplicationContext
- EnvironmentAware：获得环境配置信息
- ResourceLoaderAware：获得ResourceLoader
这些Aware回调对业务代码用处不大，因为大部分时候你会直接使用@Autowired注入ApplicationContext或Environment。但在写框架组件、工具类时，Aware接口是获取容器能力的关键手段。
我见过不少人在自定义工具类里写ApplicationContext的静态持有者，再通过@Autowired注入——不是说不行，而是如果你愿意实现ApplicationContextAware，代码会更干净，生命周期也更明确。
2.4 阶段四：BeanPostProcessor的前后拦截
这是Spring生命周期里最核心的一个扩展点，没有之一。
BeanPostProcessor接口定义了两个默认方法：
public interface BeanPostProcessor { default Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException { return bean; } default Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException { return bean; } }这两个方法分别在初始化前后执行，Spring的AOP代理就是借助这个机制实现的。AbstractAutoProxyCreator这个BeanPostProcessor会在postProcessAfterInitialization阶段，判断当前Bean是否需要被代理，如果需要就返回一个代理对象，否则返回原始对象。
整个Spring的AOP、事务增强、权限切面、异步注解支持，全部建立在这个回调点之上。
2.5 阶段五：初始化的三种方式及执行顺序
初始化阶段有三种方式可以拿到回调：
- 使用@PostConstruct注解
- 实现InitializingBean接口的afterPropertiesSet()方法
- XML或者@Bean(initMethod = "xxx")指定的init-method方法
如果你用了多个方式，执行顺序是这样的：@PostConstruct方法先执行，接着是afterPropertiesSet()，最后是自定义的initMethod。
讲一个细节：@PostConstruct是JSR-250标准注解，它由CommonAnnotationBeanPostProcessor来处理。在实际执行时，Spring会优先调用该处理器，再调用InitializingBean的afterPropertiesSet，然后再反射调用init-method。
2.6 阶段六：销毁流程
Bean销毁的流程跟初始化是对称的：
- 先执行@PreDestroy注解标注的方法
- 再执行DisposableBean接口的destroy()方法
- 最后执行自定义的destroyMethod方法
**但这里有一个极易踩坑的地方：只有单例Bean的销毁方法才会被容器管理，原型Bean不会被容器管理销毁。**容器关闭时，Spring会遍历单例池，挨个调用销毁逻辑，但原型Bean是每次getBean都新创建，容器不持有它，自然不会去管它的销毁。
3. 硬核细节：一张流程图之外的暗坑
上面那个生命周期列表只是骨架，真要在源码级别搞清楚，有几个点必须单独拎出来讲。
3.1 BeanPostProcessor的注册时机和调用顺序
BeanPostProcessor本身也是Bean，但它必须在普通Bean创建之前完成注册。Spring的refresh()方法里有一步调用registerBeanPostProcessors()，这一步发生在普通bean创建之前。
有一点要注意：BeanPostProcessor之间的顺序是有讲究的。Spring会先处理实现了PriorityOrdered接口的，再处理实现了Ordered接口的，最后处理无顺序要求的。所以在自定义BeanPostProcessor时，如果你想保证它在某个内置处理器之前或之后执行，可以实现Ordered接口来指定顺序。
3.2 循环依赖时生命周期被打断
Spring的循环依赖解决靠三级缓存，这里不展开说三级缓存的完整细节，只强调一个关键点：在处理循环依赖时，Spring会提前暴露一个早期引用，这时候Bean只完成了实例化，还没有完成属性填充和初始化。
也就是说，如果A和B循环依赖，A的创建过程中会先把自己的半成品暴露到三级缓存，让B先完成创建并注入这个半成品A。等B创建完，A继续执行它的postProcessAfterInitialization等后续步骤，这时候A的代理对象才真正生成。
**这里会导致什么问题？**如果你Bean里存在AOP代理，又发生了循环依赖，那么最终注入到B里的A，可能不是postProcessAfterInitialization之后生成的代理对象，而是提前暴露的对象。Spring为了解决这个问题，会在提前暴露时检查“当前Bean是否需要被代理，是否允许提前引用”，如果允许，就提前生成代理对象放入二级缓存，保证后续所有地方拿到的都是同一个代理。
这种问题排查起来非常隐蔽，日志不报错，但行为不符合预期。你如果做中间件开发，一定要记得在允许循环依赖的情况下，早暴露对象必须用getEarlyBeanReference来保证代理一致性。
3.3 单例和原型在生命周期上的本质差异
单例Bean和原型Bean生命周期管理策略完全不同，这是面试高发题，我整理成表格方便你对比：
| 对比维度 | 单例Bean | 原型Bean |
|---|---|---|
| 创建时机 | 容器启动时或首次获取时 | 每次getBean时 |
| 实例数量 | 全局唯一 | 每次获取都新建 |
| 属性填充 | 创建时执行 | 创建时执行 |
| Aware回调 | 支持 | 支持 |
| 初始化回调 | 支持 | 支持 |
| 销毁管理 | 容器关闭时统一销毁 | 容器不管理销毁 |
**为什么原型Bean销毁不归容器管？**因为原型Bean对容器来说是一次性消费品。容器创建完交付给你，后续什么时候销毁、怎么销毁，容器一概不知。需要你自己在业务代码里调用销毁逻辑，或者依赖JVM的GC机制。
所以设计组件时有一个经验法则：如果你需要某个依赖频繁变化，考虑用原型Bean；如果你需要管理Bean的销毁资源（比如数据库连接、线程池），一定要用单例Bean并绑定destroy-method，否则连接池很可能泄漏。
4. 实操准备：把生命周期完整日志打出来
纸上谈兵没意思，我强烈建议你跟着做一次实验。用两三个关键类，把Bean从启动到销毁的完整日志打出来，你会有很直观的感受。
4.1 准备一个自定义Bean
先创建一个普通的Bean，实现所有关键接口：
package com.example.demo.lifecycle; import org.springframework.beans.BeansException; import org.springframework.beans.factory.BeanFactory; import org.springframework.beans.factory.BeanFactoryAware; import org.springframework.beans.factory.BeanNameAware; import org.springframework.beans.factory.DisposableBean; import org.springframework.beans.factory.InitializingBean; import org.springframework.context.ApplicationContext; import org.springframework.context.ApplicationContextAware; import javax.annotation.PostConstruct; import javax.annotation.PreDestroy; public class MyLifecycleBean implements BeanNameAware, BeanFactoryAware, ApplicationContextAware, InitializingBean, DisposableBean { private String message; public void setMessage(String message) { this.message = message; System.out.println("[1] 属性填充阶段：设置message=" + message); } public MyLifecycleBean() { System.out.println("[0] 实例化阶段：无参构造器执行"); } @Override public void setBeanName(String name) { System.out.println("[2] BeanNameAware回调：Bean名称为 " + name); } @Override public void setBeanFactory(BeanFactory beanFactory) throws BeansException { System.out.println("[3] BeanFactoryAware回调：拿到BeanFactory"); } @Override public void setApplicationContext(ApplicationContext applicationContext) throws BeansException { System.out.println("[4] ApplicationContextAware回调：拿到ApplicationContext"); } @PostConstruct public void postConstruct() { System.out.println("[5] @PostConstruct：初始化前执行"); } @Override public void afterPropertiesSet() throws Exception { System.out.println("[6] InitializingBean.afterPropertiesSet：初始化执行"); } public void customInit() { System.out.println("[7] init-method：自定义初始化方法执行"); } @PreDestroy public void preDestroy() { System.out.println("[8] @PreDestroy：销毁前执行"); } @Override public void destroy() throws Exception { System.out.println("[9] DisposableBean.destroy：销毁执行"); } public void customDestroy() { System.out.println("[10] destroy-method：自定义销毁方法执行"); } }4.2 添加BeanPostProcessor和配置
再定义一个BeanPostProcessor，观察它在生命周期里的切入位置：
package com.example.demo.lifecycle; import org.springframework.beans.BeansException; import org.springframework.beans.factory.config.BeanPostProcessor; public class MyBeanPostProcessor implements BeanPostProcessor { @Override public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException { if (bean instanceof MyLifecycleBean) { System.out.println("[BP-1] postProcessBeforeInitialization：初始化之前拦截"); } return bean; } @Override public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException { if (bean instanceof MyLifecycleBean) { System.out.println("[BP-2] postProcessAfterInitialization：初始化之后拦截"); } return bean; } }接着创建一个配置类，把Bean和Processor注册进去，顺便指定自定义的init-method和destroy-method：
package com.example.demo.lifecycle; import org.springframework.context.annotation.AnnotationConfigApplicationContext; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; @Configuration public class LifecycleConfig { @Bean(initMethod = "customInit", destroyMethod = "customDestroy") public MyLifecycleBean myLifecycleBean() { MyLifecycleBean bean = new MyLifecycleBean(); bean.setMessage("hello"); return bean; } @Bean public MyBeanPostProcessor myBeanPostProcessor() { return new MyBeanPostProcessor(); } }最后写一个启动类：
package com.example.demo.lifecycle; import org.springframework.context.annotation.AnnotationConfigApplicationContext; public class LifecycleDemoApplication { public static void main(String[] args) { System.out.println("========== 容器启动 =========="); try (AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(LifecycleConfig.class)) { System.out.println("========== 容器刷新完成，Bean已就绪 =========="); MyLifecycleBean bean = context.getBean(MyLifecycleBean.class); System.out.println("获取到Bean：" + bean); } System.out.println("========== 容器关闭 =========="); } }4.3 运行结果解读
控制台输出的顺序应该是：
========== 容器启动 ========== [0] 实例化阶段：无参构造器执行 [1] 属性填充阶段：设置message=hello [2] BeanNameAware回调：Bean名称为 myLifecycleBean [3] BeanFactoryAware回调：拿到BeanFactory [4] ApplicationContextAware回调：拿到ApplicationContext [BP-1] postProcessBeforeInitialization：初始化之前拦截 [5] @PostConstruct：初始化前执行 [6] InitializingBean.afterPropertiesSet：初始化执行 [7] init-method：自定义初始化方法执行 [BP-2] postProcessAfterInitialization：初始化之后拦截 ========== 容器刷新完成，Bean已就绪 ========== 获取到Bean：com.example.demo.lifecycle.MyLifecycleBean@xxxx [8] @PreDestroy：销毁前执行 [9] DisposableBean.destroy：销毁执行 [10] destroy-method：自定义销毁方法执行 ========== 容器关闭 ==========注意几个细节：
- 属性填充发生构造之后、Aware回调之前。这个顺序决定了：如果你在构造器里无法访问注入的属性，那就别访问，等Aware回调之后再说。
- BeanPostProcessor的Before是在@PostConstruct之前执行的，After是在所有初始化方法之后执行的。也就是说，整个初始化过程被BeanPostProcessor夹在中间。
- try-with-resources里关闭容器，会自动触发所有单例Bean的销毁方法。如果你手动调用close()，也是一样的效果。
- 如果你把@Bean注解里的destroyMethod去掉，自定义销毁方法不生效；去掉initMethod，自定义初始化方法不生效。
我建议你把initMethod和destroyMethod都去掉跑一遍，然后把MyBeanPostProcessor注释掉再跑一遍，对比两次日志，你会更清楚哪些回调是Spring帮你默认加的，哪些是自定义扩展的。
5. 生命周期相关的高频坑与排查实录
日常开发里，生命周期相关的坑比你想的要多得多。我挑选几个有代表性的，按排查难度排个序。
5.1 @PostConstruct不执行
这是一个很经典的问题。代码看着没问题，但@PostConstruct标注的方法就是没跑。排查思路：
- 确认你是否引用了javax.annotation包（或jakarta.annotation）。Spring Boot 2.x用javax，Spring Boot 3.x用jakarta，搞错了注解路径，Spring根本不认识。
- 确认CommonAnnotationBeanPostProcessor是否被注册。正常Spring Boot项目是自动注册的，但如果你自定义了BeanPostProcessor注册逻辑，或者使用极简容器，需要手动注册。
- 确认你的Bean是不是被CGLIB代理，且代理方式有问题。极端情况下代理对象不触发生命周期回调，不过Spring Boot场景很少出现这个。
5.2 原型Bean的销毁方法不执行
这个坑我前面说过了。你给原型Bean配了destroyMethod，容器关闭时就是不调用。原因就是容器不持有原型Bean的引用。
解决办法有两个：一是自己接管销毁逻辑，在getBean返回后手动调用销毁方法；二是通过自定义Scope，实现自己的销毁管理逻辑。第二种方法适合造轮子场景，平时开发还是直接用单例Bean省心。
5.3 循环依赖时，postProcessAfterInitialization拿到的Bean不对
假设A和B循环依赖，A需要切面代理。如果没有特殊处理，B注入的A可能是未增强的原始对象，这就导致A的方法在B里调用时没有走切面逻辑。
排查方向：
- 打开日志：spring.main.allow-circular-references=true是Spring Boot 2.6之后的新配置项，默认禁止循环依赖。如果你在线下环境能启动但线上不能，第一件事查这个配置。
- 检查DefaultAdvisorAutoProxyCreator的earlyProxyReferences是否正确触发。真出问题时，看看A对象的增强是否能提前暴露。
- 从设计层面讲，循环依赖本身是代码异味，能避免就避免。不要为了支持循环依赖而盲目调整全局配置。
5.4 初始化方法的执行顺序和预期不一致
如果同时用了@PostConstruct、InitializingBean、init-method，顺序一定是：@PostConstruct → afterPropertiesSet → init-method。这个顺序有历史包袱原因：
- @PostConstruct是最新加的，语义上更贴近“普通用户接口”，所以放最前。
- InitializingBean是Spring原生接口，作为框架级扩展点放在第二位。
- init-method是XML时代的老配置，兼容性考虑放在最后。
如果你在某个第三方的Bean里看到初始化执行顺序怪异，很可能是因为这个Bean间接实现了多个接口，或者某个BeanPostProcessor在中间做了代理包装。
5.5 生命周期日志与AOP代理的关系
当Bean被AOP代理后，BeanPostProcessor的Before方法执行时传入的还是原始对象，After方法执行前，AOP已经生成了代理对象。所以postProcessAfterInitialization方法返回的对象，不一定就是传入的对象，它会被放回容器，作为最终暴露出去的Bean。
**如果你在自定义BeanPostProcessor里做了类型转换或者标记，请务必注意：传入和返回必须是同一个对象，除非你有意使用代理替换。**另外，如果你在postProcessAfterInitialization中返回了和传入不同的对象，Spring会直接用新对象替换旧对象，但这个替换不会影响已经被其他Bean引用的早期引用。这是很多奇怪问题的源头。
6. 生命周期机制给我们的设计启发
理解了Spring Bean生命周期，不只是为了面试，它在实际设计里能给你不少启发。
我们经常要写一些需要在特定阶段做资源的初始化和清理的组件，比如连接池、线程池、定时任务、消息监听。把这些组件的启动和关闭绑定到Spring Bean的生命周期上，就能让资源管理和容器共存亡，不用自己手动写一堆启动钩子和关闭钩子。
举个实际例子。我之前写过一个内部MQ消费组件，需要消费启动前连接Broker，应用关闭时优雅断开。实现方式就是实现SmartLifecycle接口：
public class MqConsumerLifecycle implements SmartLifecycle { private volatile boolean running = false; @Override public void start() { System.out.println("MQ消费者启动，建立连接..."); this.running = true; } @Override public void stop() { System.out.println("MQ消费者停止，释放连接..."); this.running = false; } @Override public boolean isRunning() { return this.running; } }SmartLifecycle还支持isAutoStartup、getPhase等方法，可以控制启动顺序、是否自动启动。对于需要依赖其他Bean先初始化完毕，或者需要优先关闭的组件，这个接口比单纯的@PostConstruct和@PreDestroy灵活太多。
如果你要做的组件生命周期比较长，牵涉到多阶段启动、优雅关闭、预热、灰度开关切换，完全可以把状态机也做进去，参考Spring的AbstractLifecycle实现，在start和stop方法里维护状态流转。
**这套思路放到微服务里也一样。**服务的注册发现、配置拉取、健康检查上报，本质上就是在不同生命周期节点上挂自定义逻辑。理解了一个Bean的生命周期，你就理解了几乎所有中间件启动时的那堆动作。
7. 生命周期的本质
我从Android、Vue、线程、Rust、缺陷管理一路扯到Spring，其实就想说明一个观点：**生命周期管理不是某一种技术独有的，它是工程世界里管理复杂系统的基本手段。**每个对象、每个进程、每一段资源，都有开始和结束，关键是在适当的时机做适当的事。
Spring Bean生命周期最大的贡献，是提供了一套清晰、可扩展的回调机制，让你既不用侵入Spring内核，又能在恰当的时候执行自己的逻辑。理解了这套机制，你写业务代码时会更清楚“什么时候该做什么”，排查问题时不至于一头扎进日志堆里找不到方向。
我个人的习惯是：每学一个框架，第一件事就是把这个框架的核心对象生命周期画出来，标注出扩展点。因为框架的绝大部分黑魔法，都藏在生命周期回调里。你把回调时机摸透了，剩下的一切都是逻辑问题。
