一个bug是bug，多个bug能work

​   在前面的博客中我们已经详细分析过Spring的启动源码，包括beanDefinition的加载、bean的初始化以及各种后处理器的回调，这个过程还是比较复杂的。​   作为Spring全家桶中的一员，SpringCloud也是对Spring做的封装，底层逻辑其实一致，我们先来看看SpringCloud的入口方法：​    我们直接去看看的方法，根据调用形式可以看到这里调用的是的静态方法：​   这部分的代码逻辑是：先创建一个对象，然后调用这个对象的的方法。的构造方法和它的非静态方法。

​   作为一个刚步入职场的小白，对Spring（SpringBoot）的了解只停留在会用，并未对其内部的原理有过学习。在公司导师的指导下，开始进一步学习Spring的源码，毕竟Spring源码是Spring全家桶的基础，学习了源码对Spring其他框架也能更好上手。​   由于本人的基础并不太好，因此文章中有错误的地方欢迎指出。

​方法内部会根据不同通知的类型创建不同类型的beanDefinition，然后设置beanDefinition中的属性值。特殊的是，方法内部还会设置构造器参数：​​   我们进入到方法内部可以看到，不同通知类型对应着不同类型的class：​   从类的继承关系来看，这五个通知类型都继承至​   我们先来看看实现了哪些接口，可以看到这些接口在我们Spring初始化启动源码分析时都有讲到过，特别是这个超级接口，我们会回调里面的方法干很多事情。​   获取当前bean的自定义目标源。如果获取到了。

​方法会解析XML文件，将其解析成一个文档树（主要是靠），继续调用的会遍历这个文档树中的节点，对符合条件的节点进行解析，得到BeanDefinition。​ 所以委托给又进一步委托给。​ 我们最终得到的beanDefinition是类型的，该类型是的实现类，也是的子类。因此会走那两个if逻辑。1.根据标签的命名空间找到对应的命名空间处理器；2.根据命名空间处理器找到当前标签的解析器；3.创建并配置一个扫描器，加入包含和排除哪些注解；4.找到符合条件的候选Bean；

​ beanFactory在经过一系列配置后可以开始真正的加载Bean，从这篇开始主要是讲述Bean的实例化过程。

​ Spring在启动后，方法中容器会注销已有的beans，关闭已有的beanFactory，创建一个新的beanFactory，然后获得所有的Bean定义（基于注解或者基于XML文件）。这一步其实还未实例化任何Bean，只是取得了beanDefinitions，这一篇主要讲解在获得beanDefinitions到真正开始实例化这些beans中间，Spring容器会干的一些事情。​是Spring提供的一个扩展接口，Spring中大部分功能都是通过后处理器的方式进行扩展的。