1. 先搞清楚："下单"这条链路，为什么能把Bean生命周期串起来

面试被问Bean生命周期，几乎所有人都是张口就来"实例化、属性赋值、初始化、使用、销毁"，然后面试官只要往下追问一句"初始化阶段到底包含几个回调，顺序是什么"，脑子里的记忆链条就会开始松动。我自己当年也是这样，把五步法、七步法、十步法抄在笔记本上，背了三天，隔一周再看，发现只记住了"中间有个BeanPostProcessor"，具体卡在哪个缝隙里，完全说不出来。

问题不在记性，在于这些步骤是脱离场景的抽象标签。人的大脑对"标签序列"的记忆效率极低，但对"有因果关系的流程"记忆力强得离谱。你会忘记Bean生命周期第九步是什么，但你绝不会忘记下单要先扣库存、再扣款、最后发通知，因为那是一条有前后依赖的业务链路。

所以这篇内容的核心思路是：把Spring容器创建一个Bean的过程，完整映射到"用户下单时，订单服务这个对象怎么被造出来、怎么被塞进依赖、怎么被包上事务代理、最后怎么被关掉"。Bean生命周期的五步、七步、十步，本质上不是三套知识，而是同一根链条的三种颗粒度——五步是业务视角，七步是框架视角，十步是中间件/扩展开发视角。你之所以背不住，是因为你一直用业务视角去硬啃中间件视角的细节。

这篇文章适合三类人：写过Spring业务代码但没深挖过容器的；准备面试想一次讲清楚的；以及要写自定义starter、写BeanPostProcessor做埋点或权限校验的。代码基于Spring 6.1 + JDK 17，注解全部使用jakarta.annotation包，老项目用的是javax.annotation，这一点后面会专门说。

2. 五步法：能跑起来的最小闭环，也是面试的保底答案

2.1 五步到底指的是哪五步

社区里流传最广的五步法，是把整个链路压缩到"业务代码能感知到"的粒度：

这五步之所以好记，是因为它对应的是对象从生到死的自然直觉。但如果只停在这里，你其实什么也没学到——因为这五步换个说法就是"new 一个对象、set 几个字段、调一下 init、用、调一下 destroy"，任何一个手写工厂都能实现，Spring 的价值一点都没体现出来。

2.2 用下单场景把五步走一遍

假设我们有个订单服务，创建订单需要两个协作者：库存服务负责预占库存，支付服务负责发起扣款。容器启动时，OrderService这个Bean要被造出来。

第一步实例化，Spring 通过反射找到构造器。这里有个很多新手会忽略的细节：如果你的OrderService只有一个带参构造器（比如OrderService(InventoryService, PaymentService)），Spring 4.3 之后会走"隐式构造器注入"，不需要写@Autowired。但如果这个类有两个以上构造器，Spring 就不知道该用哪个，必须显式标注，否则直接抛NoUniqueBeanDefinitionException。我在实际项目里见过有人给类加了 Lombok 的@RequiredArgsConstructor之后又手写了一个无参构造器，结果容器启动直接失败，排查了半小时。

第二步属性赋值，注意这里填的是"壳子"里的属性。构造器注入的参数其实在第一步就已经传进去了，属性赋值这一步主要处理@Autowired字段和 setter 注入。所以严格意义上说，构造器注入的依赖在"实例化"阶段就到位了，字段注入的依赖在"属性赋值"阶段才到位——这个差异后面讲循环依赖的时候会变成关键。

第三步初始化，这是最容易出问题的一步。业务上我们经常需要"Bean 的所有依赖都就绪之后"再做点什么，比如加载一次全量商品价格快照、建立一次长连接探活。如果你把这些逻辑写在构造器里，依赖可能还没注入完，直接空指针；写在@PostConstruct里就安全，因为容器保证它在这个时点被调用。

第四步使用，这一步没什么好说的，就是你的 Controller 调到 Service 的那一刻。

第五步销毁，容器close()时触发。注意，只有单例Bean才会被容器管理销毁，prototype作用域的Bean被创建出来之后就交给调用方了，容器不再持有引用，销毁回调压根不会执行。这个坑后面第四节会展开。

2.3 五步法够用和不够用的分界线

我给自己定了一条判断线：只要你只是"写业务代码"，五步法就够用，甚至不需要知道七步。你只需要记住三件事：构造器里别写重逻辑、依赖就绪后的初始化放@PostConstruct、资源释放放@PreDestroy。这三条能覆盖 90% 的日常开发。

但只要你开始碰下面任何一种场景，五步法就会失效：需要给一批Bean统一加日志埋点、需要动态代理某个Bean、需要写自定义注解让容器识别、排查"为什么我的AOP在同类内部调用失效"。这些场景的共同点是——你需要知道Bean在什么时刻还没被代理，又在什么时刻已经被代理。这个信息五步法给不了你，得升到七步。

3. 七步法：把 BeanPostProcessor 的位置标出来，AOP 才不再是黑盒

3.1 七步比五步多出来的两步是什么

七步法的展开逻辑，是把"初始化"这一个抽象步骤劈开，露出里面的两个扩展点回调：

1. 实例化
2. 属性赋值
3. Aware 回调（BeanNameAware、BeanFactoryAware等）
4. BeanPostProcessor.postProcessBeforeInitialization
5. 初始化方法（@PostConstruct→afterPropertiesSet→init-method）
6. BeanPostProcessor.postProcessAfterInitialization
7. 销毁

这两步扩展点是整个Spring生态的命脉。你要知道一件事：Spring 里几乎所有"魔法"，都是在第4步和第6步里做出来的。@Autowired的注入靠第2步的postProcessProperties，@PostConstruct靠第4步里的CommonAnnotationBeanPostProcessor，而AOP事务、@Async、@Cacheable的代理对象，全部是在第6步生成的。

这句话解释了无数人的困惑：为什么@Transactional方法在同一个类内部调用不生效？因为容器里最终放进单例池的那个对象，是第6步被包装后的代理对象，而你this.xxx()调用的是原始对象自己的方法，压根没经过代理。

3.2 第6步的时机决定了代理的"面貌"

我们拿下单链路具体走一遍。OrderService.createOrder()上标了@Transactional，容器在第6步用AbstractAutoProxyCreator判断这个Bean是否需要被代理——它扫描所有 advisor，发现有一个BeanFactoryTransactionAttributeSourceAdvisor能匹配上，于是生成一个 CGLIB 子类，把原对象包进去。

关键点在于：代理对象是在"初始化方法执行完之后"才产生的。这意味着：

• 你的@PostConstruct里如果this.xxx()调了一个带事务的方法，事务不会生效，因为此刻this还是原始对象，代理还没生出来。
• 反过来，如果有人把事务逻辑写在@PostConstruct里期望它回滚，那更是想多了——初始化阶段压根没有事务上下文。

我在一个项目里就踩过这个坑：某个订单服务在@PostConstruct里调用自身的事务方法做数据预热，日志一切正常，但出错时数据脏写没能回滚，查了半天才定位到是代理时机问题。解决办法是把预热逻辑搬到ApplicationRunner或者监听ApplicationReadyEvent，那时候容器里拿到的已经是代理对象了。

顺带说一个第3步的细节，很多人以为ApplicationContextAware和BeanNameAware是同一批回调，其实不是。BeanNameAware、BeanClassLoaderAware、BeanFactoryAware这三个是在invokeAwareMethods()里硬编码调用的，位置非常靠前；而ApplicationContextAware、EnvironmentAware、ResourceLoaderAware这些是由ApplicationContextAwareProcessor这个BeanPostProcessor在第4步阶段处理的。所以严格来说，它们不在同一层。这个区别在写自定义扩展时会有影响——如果你自己实现了一个BeanPostProcessor且优先级排到了ApplicationContextAwareProcessor前面，那你在这个处理器里拿到的Bean，可能还没拿到ApplicationContext。

3.3 手写一个下单耗时统计的后置处理器

光讲不如动手。假设产品经理要求统计每个订单服务的初始化耗时，方便排查启动慢的问题。这就是典型的第4步/第6步扩展点场景：

@Component public class InitCostPostProcessor implements BeanPostProcessor, Ordered { private final Map<String, Long> startTimeMap = new ConcurrentHashMap<>(); @Override public Object postProcessBeforeInitialization(Object bean, String beanName) { if (beanName.startsWith("order")) { startTimeMap.put(beanName, System.nanoTime()); } return bean; } @Override public Object postProcessAfterInitialization(Object bean, String beanName) { Long start = startTimeMap.remove(beanName); if (start != null) { long cost = (System.nanoTime() - start) / 1_000_000; System.out.printf("[启动耗时] %s 初始化花了 %d ms%n", beanName, cost); } return bean; } @Override public int getOrder() { return Ordered.LOWEST_PRECEDENCE; } }

这段代码有几个实操要点值得说：

第一，必须返回bean本身，不能返回 null。返回 null 会导致后续的 BeanPostProcessor 拿到 null，直接空指针。我见过有人为了"过滤"某个Bean写了return null，结果启动报了一堆莫名其妙的错。

第二，getOrder()返回LOWEST_PRECEDENCE是有意为之。因为 Spring 内置的处理器（比如负责AOP的那个）优先级通常很高，你的埋点处理器排在最后，测出来的耗时才包含前面的处理时间，数据才有意义。如果你想测的是"纯业务初始化耗时"，那就该排在最前面。

第三，startTimeMap用ConcurrentHashMap而不是HashMap。虽然默认单例Bean是串行创建的，但如果你开启了spring.main.lazy-initialization或者有@Async触发的懒加载，就可能并发。这个细节属于防御性编程，成本几乎为零。

4. 十步法：拆到 Aware 和销毁，中间件开发者的视角

4.1 十步的完整顺序与记忆锚点

十步法是给要写框架扩展、写 starter、排查诡异问题的人准备的。完整的顺序是这样的：

记忆锚点我推荐用一个比喻：造车。第1步是"看看有没有现成的车可以直接交付"（postProcessBeforeInstantiation如果返回非 null，整个后续流程直接跳过，这是短路机制）；第2步是"焊车架"；第3、4、5步是"装零件"；第6步是"贴车牌、告诉这辆车归属哪个车主"；第7到9步是"出厂检测、贴膜、上牌"；第10步是"报废回收"。

第1步的短路机制特别值得单独说一句。postProcessBeforeInstantiation如果返回了一个非 null 的对象，Spring 会认为"你已经替我把Bean造好了"，直接跳到第9步做后置处理，中间的实例化、属性赋值、初始化全部跳过。AbstractAutoProxyCreator就是靠这个机制处理某些特殊代理场景的。如果你自己写处理器时不小心在这里返回了对象，会导致依赖注入完全不生效，然后你会收获一堆空指针。

4.2 初始化和销毁的内部顺序，别再记混了

第7和第8步合并起来就是"初始化"，但内部的三个回调顺序是固定的，很多人记反：

初始化顺序：@PostConstruct→afterPropertiesSet()→init-method

为什么是这个顺序？因为@PostConstruct是由CommonAnnotationBeanPostProcessor在postProcessBeforeInitialization里通过反射调用的，天然属于"初始化前"；而afterPropertiesSet()是InitializingBean接口方法，由invokeInitMethods()直接调用；init-method排在最后，是留给使用者的"最后一道口子"。

销毁顺序：@PreDestroy→DisposableBean.destroy()→destroy-method

逻辑是镜像的。@PreDestroy由CommonAnnotationBeanPostProcessor的postProcessBeforeDestruction调用，destroy()由适配器直接调，destroy-method收尾。

这里有个实操技巧：如果你只想写一处初始化和一处销毁，写@PostConstruct/@PreDestroy就够了，理由有三：不需要让类实现 Spring 的接口（减少耦合）、符合 JSR-330 标准（换框架也能用）、顺序最靠前/最靠后（初始化最早、销毁最晚，语义最清晰）。InitializingBean唯一的优势是能拿到更精确的容器语义，但绝大多数业务场景用不上。

还有一个容易被忽略的点：如果你用@Bean(initMethod = "xxx")声明Bean，而xxx方法不存在，编译期不会报错，只有运行到初始化阶段才会抛异常，而且异常信息是NoSuchMethodException，非常不直观。我现在的习惯是：能用注解就不用initMethod字符串，实在要用就在单元测试里覆盖一次启动。

4.3 原型Bean的销毁谁来管

这个问题在面试里出现的频率很高，也很能区别人是不是真跑过。结论是：prototype作用域的Bean，容器不负责销毁。

原因是容器压根不持有原型Bean的引用——每次getBean()都造一个新的交给你，容器内部不会缓存，所以close()的时候它根本不知道有这么个对象存在。@PreDestroy、DisposableBean、destroy-method在原型Bean上全部失效。

那业务上要释放资源怎么办？两个办法。一是让调用方自己负责，调用完手动调销毁方法，但这在业务代码里很难保证不漏。二是实现DestructionAwareBeanPostProcessor，在处理器里记录所有创建过的原型Bean引用，容器关闭时统一清理。这个方案能解决问题，但会引入内存泄漏风险，必须保证引用能被正确移除。说白了，原型Bean + 需要释放的资源，本身就是个设计味道很重的组合，能避开就避开，改成单例 + 连接池复用是更稳妥的做法。

5. 实操：搭一条能打出完整生命周期的下单链路

5.1 环境与依赖

只依赖spring-context就够了，不需要 Spring Boot：

<dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>6.1.6</version> </dependency>

JDK 用 17 或以上。如果你从旧项目迁移过来，第一个要改的是 import：javax.annotation.PostConstruct要换成jakarta.annotation.PostConstruct，否则@PostConstruct会被静默忽略——不报错、不生效、初始化方法压根不执行。这个坑我在迁移时踩过一次，排查了整整一个下午，因为日志里什么异常都没有，只有"依赖注入为 null"这个间接症状。

5.2 一个把全部回调都打点的 OrderService

为了让顺序一目了然，我把所有扩展点全实现一遍：

public class OrderService implements BeanNameAware, BeanFactoryAware, ApplicationContextAware, InitializingBean, DisposableBean { private final InventoryService inventoryService; private PaymentService paymentService; public OrderService(InventoryService inventoryService) { this.inventoryService = inventoryService; System.out.println("1. 构造器：拿到库存服务 " + inventoryService); } @Autowired public void setPaymentService(PaymentService paymentService) { this.paymentService = paymentService; System.out.println("2. setter注入：拿到支付服务 " + paymentService); } @Override public void setBeanName(String name) { System.out.println("3. BeanNameAware: " + name); } @Override public void setBeanFactory(BeanFactory beanFactory) { System.out.println("4. BeanFactoryAware: " + beanFactory.getClass().getSimpleName()); } @Override public void setApplicationContext(ApplicationContext ctx) { System.out.println("5. ApplicationContextAware"); } @PostConstruct public void postConstruct() { System.out.println("6. @PostConstruct：预热商品价格快照"); } @Override public void afterPropertiesSet() { System.out.println("7. InitializingBean.afterPropertiesSet"); } public void customInit() { System.out.println("8. init-method: customInit"); } public void createOrder(String userId) { inventoryService.deduct(userId); paymentService.pay(userId); System.out.println("9. 业务调用：下单完成"); } @PreDestroy public void preDestroy() { System.out.println("10. @PreDestroy"); } @Override public void destroy() { System.out.println("11. DisposableBean.destroy"); } public void customDestroy() { System.out.println("12. destroy-method: customDestroy"); } }

配置类用@Bean方式声明，显式指定initMethod和destroyMethod：

@Configuration @ComponentScan("com.demo.order") public class OrderConfig { @Bean(initMethod = "customInit", destroyMethod = "customDestroy") public OrderService orderService(InventoryService inventoryService) { return new OrderService(inventoryService); } }

启动类：

public class Main { public static void main(String[] args) { AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext(OrderConfig.class); OrderService service = ctx.getBean(OrderService.class); service.createOrder("U1001"); ctx.close(); } }

5.3 实测输出与逐行解读

跑起来之后，控制台输出的顺序是固定的：

1. 构造器：拿到库存服务 com.demo.order.InventoryService@1a2b3c 3. BeanNameAware: orderService 4. BeanFactoryAware: DefaultListableBeanFactory 2. setter注入：拿到支付服务 com.demo.order.PaymentService@4d5e6f 5. ApplicationContextAware 6. @PostConstruct：预热商品价格快照 7. InitializingBean.afterPropertiesSet 8. init-method: customInit 9. 业务调用：下单完成 10. @PreDestroy 11. DisposableBean.destroy 12. destroy-method: customDestroy

注意这里第2和第3、4行的顺序反了，这不是打印bug。原因是：@Autowired标注在 setter 上时，注入发生在populateBean阶段（十步法第4、5步），而BeanNameAware、BeanFactoryAware的回调发生在initializeBean阶段（十步法第6步）。所以 setter 注入必然排在 Aware 回调之前。

这个细节非常值得记下来——它告诉我们，如果你在BeanNameAware里想用一个@Autowired注入的字段，是可以用的；反过来，如果你在 setter 注入方法里想用beanName，那是拿不到的。我见过有人在 setter 里写日志想带上 beanName，结果全是 null，就是这个原因。

而ApplicationContextAware排在 setter 之后、@PostConstruct之前，也符合前面的分析——它由ApplicationContextAwareProcessor处理，属于"初始化前"阶段，且这个处理器的优先级高于CommonAnnotationBeanPostProcessor。

销毁阶段@PreDestroy在最前，是因为它由DestructionAwareBeanPostProcessor的postProcessBeforeDestruction触发，在DisposableBeanAdapter.destroy()里第一个被调用。

5.4 加一个代理，看第9步的变化

现在给createOrder加个@Transactional，同时引入spring-tx和spring-jdbc，配置一个内存数据库。重新跑一次，你会发现输出里多了一行提示：

8. init-method: customInit [代理生成] orderService 被包装为 CGLIB 代理 9. 业务调用：下单完成

这行"代理生成"可以自己写个 BeanPostProcessor 打印AopUtils.isAopProxy(bean)验证。它的位置证明了一件事：代理对象是在初始化完成之后才被替换进单例池的。所以如果你在@PostConstruct里调用了事务方法，事务不会生效。

想进一步验证的话，在createOrder前后各打一行日志，然后在外部调用service.createOrder()、在内部再调一次this.otherTxMethod()，你会看到只有外部调用有事务日志。这就是七步法最直接的商业价值——它让你能预测而不是试错。

6. 常见问题与排查技巧实录

6.1 典型问题速查表

6.2 三个我踩过的坑

坑一：在 BeanPostProcessor 里注入了业务Bean，导致整个切面失效。这个坑非常隐蔽。BeanPostProcessor本身也是Bean，如果它依赖了某个业务Bean，容器为了保证处理器能正常工作，会提前创建那个业务Bean。但这时候其他 BeanPostProcessor 还没注册完，导致提前创建的业务Bean绕过了 AOP 代理，直接变成裸对象。表现就是"这个Service的事务莫名其妙不生效"。解法很简单：BeanPostProcessor里不要注入业务Bean，需要的话用ObjectProvider延迟获取，或者用ApplicationContext按需getBean()。

坑二：循环依赖和构造器注入的组合。字段注入的循环依赖 Spring 能靠三级缓存解决（提前暴露ObjectFactory），但构造器注入的循环依赖无解，因为对象还没造出来，没法提前暴露引用，直接抛BeanCurrentlyInCreationException。Spring Boot 2.6 之后默认还关闭了循环依赖引用，所以你会看到双重报错。我的建议是：看到循环依赖就去重构，抽出第三个类或者用事件解耦，别第一时间去改配置开关，那是把定时炸弹往后推。

坑三：@Bean方法的返回类型写成接口，导致代理类型不匹配。如果@Bean方法返回OrderApi接口类型，但实际返回的是OrderServiceImpl，而OrderServiceImpl上没有实现接口方法上的注解，AOP 匹配就会出问题。这个坑的排查成本极高，因为你看到的是"注解明明写了但不生效"。稳妥做法是@Bean方法的返回类型和实际类型保持一致，别为了"面向接口"牺牲可预测性。

7. 选型与决策：几个容易做错的地方

7.1 五步、七步、十步，日常该按哪套来想问题

我给自己的使用规则是这样的：

• 写业务代码时，脑内只装三件事：构造器别做重活、依赖就绪后的初始化放@PostConstruct、资源释放放@PreDestroy。这套规则简单粗暴，能覆盖绝大多数场景。
• 写切面、写中间件、写 starter 时，切到七步。核心就问一个问题：我要操作的这个Bean，此刻是原始对象还是代理对象？答案取决于我在第4步还是第6步动手。
• 排查诡异问题、写自定义BeanPostProcessor排序时，切到十步。绝大部分"注解不生效"的问题，本质都是"你以为的执行时机"和"实际的执行时机"错位了。

这套分层思路的好处是：你不会在写 CRUD 的时候被迫回忆postProcessProperties和postProcessAfterInstantiation的区别，也不会在写框架的时候还停留在"实例化、属性赋值"这种粗粒度上。

7.2 关于懒加载和提前初始化

@Lazy是个双刃剑。它的作用是把这个Bean的创建推迟到第一次使用时，好处是加快启动速度，坏处是把启动期的错误推迟到了运行期。我在一个项目里给某个订单相关服务加了@Lazy解决启动慢的问题，结果第一次真实下单时才爆出配置缺失，监控直接告警。

我的经验是：懒加载只对"确实不常用且创建成本高"的Bean开，比如某些冷门的报表导出服务。核心链路（下单、支付、库存）一律不要懒加载，宁可启动慢两秒，也要把错误暴露在发布阶段而不是业务高峰。

另外，如果你确实需要"所有单例都创建完之后再做点什么"，用SmartInitializingSingleton.afterSingletonsInstantiated()，它的执行时机在所有单例Bean初始化完成之后、容器刷新完成之前。这个点比@PostConstruct更晚，比ApplicationReadyEvent更早，是个很好用但很少人用的扩展点。

7.3 关于 Spring 6 的几个实际变化

迁移到 Spring 6 时，除了jakarta包名之外，还有两点要留意。一是Spring 6 要求 JDK 17 起步，如果你的项目还挂在 JDK 8 上，那就先别动。二是部分老的扩展点被废弃或调整，比如InstantiationAwareBeanPostProcessor的某些方法签名有变化，自定义处理器时最好直接对着 6.x 的源码写，别照抄网上的老博客，那些大多是 4.x 时代的代码，能编译不代表语义正确。

我个人在实际操作中的体会是：Bean生命周期这东西，看十遍图不如自己打一遍日志。把上面那段OrderService完整跑一遍，把@Transactional加进去再跑一遍，把@Lazy加上再跑一遍，三遍下来你就再也不用背了——因为每次你都能从输出里"看见"它在哪一步。我到现在也没能完整背出十步法的名字，但只要给我一个断点，我知道该往哪个方向找。这比背诵有用得多。