Spring 有一个特点，就是创建出来的 Bean 对容器是无感的，一个 Bean 是怎么样被容器从一个 Class 整成一个 Bean 的，对于 Bean 本身来说是不知道的，当然也不需要知道，也就是 Bean 对容器的存在是无感的。

今天再来聊一个 Spring 中的冷门知识：Bean 的处理不走正常流程，而是提前进行 AOP。

一些使用小细节就是在不断的源码探索中逐步发现的，今天就来和小伙伴们聊一下通过 beanName 的设置，可以让一个 bean 拒绝被代理！

今天来和各位小伙伴详细分析一下 BeanPostProcessor。今天这篇是原理分析，基本用法松哥之前已经讲过了，有视频也有文章，对视频感兴趣的小伙伴戳这里：Spring源码应该怎么学？。

不同于前面和大家分享的 BeanFactoryPostProcessor，BeanPostProcessor 从名字上就能看出来，这是一个 Bean 的后置处理器，也就是说，BeanPostProcessor 其实主要是对已经创建出来的 Bean 做一些后置处理，而 BeanFactoryPostProcessor 主要是针对 BeanDefinition 做后置处理（此时 Bean 对象还没创建出来）。

当我们想在 Spring 容器启动或者关闭的时候，做一些初始化操作或者对象销毁操作，我们可以怎么做？

scope 属性，相信大家都知道，一共有六种：

今天我们来思考这样一个问题：在 Spring AOP 中，被代理的对象是单例的吗？当我们每次获取到代理对象的时候，都会重新获取一个新的被代理对象吗？还是被代理的对象始终是同一个？

前面松哥写文章和小伙伴们仔细捋了捋 Spring 中的 BeanDefinition 存在的几种情况，那么 BeanDefinition 是谁来加载呢？如果是 Java 代码配置，那不用说，都是注解扫描去加载 BeanDefinition 的，但是如果是 XML 或者其他格式的配置文件，则有专门的 BeanDefinition 加载器，今天咱们就来看看这个专门的 BeanDefinition 加载器。

这个问题松哥想了很久要怎么和大家展开介绍，最早我是想整一篇文章把 Spring 容器整个从头到尾捋一遍，但是，东西太多显然不现实，我还是倾向于通过不同的文章，从不同的角度来介绍 Spring 容器的一些使用细节，最后再将整体串通起来～

在前面的文章中，松哥已经和大家分享了 BeanPostProcessor 和 BeanFactoryPostProcessor 的基本用法以及差别，但是没有去分析其原理，今天我们就来聊一聊这两个后置处理器的工作原理。