Spring5源码分析系列（四）IOC容器

浅浅的花香味﹌ 2022-05-09 09:54 239阅读 0赞

本章开始进入Spring5源码分析，文章有点长，参考自Tom老师视频。

### 什么是IOC/DI？ ###

IOC(InversionofControl)控制反转：所谓控制反转，就是把原先我们代码里面需要实现的对象创建、依赖的代码，反转给容器来帮忙实现。那么必然的我们需要创建一个容器，同时需要一种描述来让容器知道需要创建的对象与对象的关系。这个描述最具体表现就是我们可配置的文件。

DI(DependencyInjection)依赖注入：就是指对象是被动接受依赖类而不是自己主动去找，换句话说就是指对象不是从容器中查找它依赖的类，而是在容器实例化对象的时候主动将它依赖的类注入给它。

先从我们自己设计这样一个视角来考虑：

对象和对象关系怎么表示？

可能是classpath，filesystem，或者是URL网络资源，servletContext等。

回到正题，有了配置文件，还需要对配置文件解析。

不同的配置文件对对象的描述不一样，如标准的，自定义声明式的，如何统一？在内部需要有一个统一的关于对象的定义，所有外部的描述都必须转化成统一的描述定义。

如何对不同的配置文件进行解析？需要对不同的配置文件语法，采用不同的解析器

### Spring核心容器体系结构 ###

(1)BeanFactory

SpringBean的创建是典型的工厂模式，这一系列的Bean工厂，也即IOC容器为开发者管理对象间的依赖关系提供了很多便利和基础服务，在Spring中有许多的IOC容器的实现供用户选择和使用，其相互关系如下：

![70][]

其中BeanFactory作为最顶层的一个接口类，它定义了IOC容器的基本功能规范，BeanFactory有三个子类：ListableBeanFactory、HierarchicalBeanFactory和AutowireCapableBeanFactory。但是从上图中我们可以发现最终的默认实现类是DefaultListableBeanFactory，他实现了所有的接口。那为何要定义这么多层次的接口呢？查阅这些接口的源码和说明发现，每个接口都有他使用的场合，它主要是为了区分在Spring内部在操作过程中对象的传递和转化过程中，对对象的数据访问所做的限制。例如ListableBeanFactory接口表示这些Bean是可列表的，而HierarchicalBeanFactory表示的是这些Bean是有继承关系的，也就是每个Bean有可能有父Bean。AutowireCapableBeanFactory接口定义Bean的自动装配规则。这四个接口共同定义了Bean的集合、Bean之间的关系、以及Bean行为.

最基本的IOC容器接口BeanFactory

![70 1][]    在BeanFactory里只对IOC容器的基本行为作了定义，根本不关心你的Bean是如何定义怎样加载的。正如我们只关心工厂里得到什么的产品对象，至于工厂是怎么生产这些对象的，这个基本的接口不关心。

而要知道工厂是如何产生对象的，我们需要看具体的IOC容器实现，Spring提供了许多IOC容器的实现。比如XmlBeanFactory，ClasspathXmlApplicationContext等。其中XmlBeanFactory就是针对最基本的IOC容器的实现，这个IOC容器可以读取XML文件定义的BeanDefinition（XML文件中对bean的描述）,如果说XmlBeanFactory是容器中的屌丝，ApplicationContext应该算容器中的高帅富.

ApplicationContext是Spring提供的一个高级的IOC容器，它除了能够提供IOC容器的基本功能外，还为用户提供了以下的附加服务。

从ApplicationContext接口的实现，我们看出其特点：

1.支持信息源，可以实现**国际化**。（实现MessageSource接口）

2.访问**资源**。(实现ResourcePatternResolver接口，后面章节会讲到)

3.支持应用**事件**。(实现ApplicationEventPublisher接口)

(2)BeanDefinition

SpringIOC容器管理了我们定义的各种Bean对象及其相互的关系，Bean对象在Spring实现中是以BeanDefinition来描述的，其继承体系如下：

![70 2][]

Bean的解析过程非常复杂，功能被分的很细，因为这里需要被扩展的地方很多，必须保证有足够的灵活性，以应对可能的变化。Bean的解析主要就是对Spring配置文件的解析。这个解析过程主要通过下图中的类完成：

![70 3][]

### IOC容器的初始化 ###

IOC容器的初始化包括BeanDefinition的Resource定位、载入和注册这三个基本的过程。我们以ApplicationContext为例讲解，ApplicationContext系列容器也许是我们最熟悉的，因为Web项目中使用的XmlWebApplicationContext就属于这个继承体系，还有ClasspathXmlApplicationContext等，其继承体系如下图所示：

![70 4][]

ApplicationContext允许上下文嵌套，通过保持父上下文可以维持一个上下文体系。对于Bean的查找可以在这个上下文体系中发生，首先检查当前上下文，其次是父上下文，逐级向上，这样为不同的Spring应用提供了一个共享的Bean定义环境。

下面我们分别简单地演示一下两种IOC容器的创建过程

1、XmlBeanFactory(屌丝IOC)的整个流程

通过XmlBeanFactory的源码，我们可以发现:

![70 5][]

![70 6][]通过前面的源码，XmlBeanDefinitionReaderreader=newXmlBeanDefinitionReader(this);中其中this传的是factory对象

2、FileSystemXmlApplicationContext的IOC容器流程

(1)、高富帅版IOC解剖

![70 7][]其实际调用的构造函数为：

![70 8][]

(2)、设置资源加载器和资源定位

通过分析FileSystemXmlApplicationContext的源代码可以知道，在创建FileSystemXmlApplicationContext容器时，构造方法做以下两项重要工作：

首先，调用父类容器的构造方法(super(parent)方法)为容器设置好Bean资源加载器。

然后，再调用父类AbstractRefreshableConfigApplicationContext的setConfigLocations(configLocations)方法设置Bean定义资源文件的定位路径。

通过追踪FileSystemXmlApplicationContext的继承体系，发现其父类的父类AbstractApplicationContext中初始化IOC容器所做的主要源码如下：

![70 9][]AbstractApplicationContext构造方法中调用PathMatchingResourcePatternResolver的构造方法创建Spring资源加载器：

![70 10][]在设置容器的资源加载器之后，接下来FileSystemXmlApplicationContext执行setConfigLocations方法通过调用其父类AbstractRefreshableConfigApplicationContext的方法进行对Bean定义资源文件的定位，该方法的源码如下：

![70 11][]

通过这两个方法的源码我们可以看出，我们既可以使用一个字符串来配置多个SpringBean定义资源文件，也可以使用字符串数组，即下面两种方式都是可以的：

ClasspathResourceres=newClasspathResource(“a.xml,b.xml,......”);多个资源文件路径之间可以是用”,;\\t\\n”等分隔。

B.ClasspathResourceres=newClasspathResource(newString\[\]\{“a.xml”,”b.xml”,......\});至此，SpringIOC容器在初始化时将配置的Bean定义资源文件定位为Spring封装的Resource。

(3)、AbstractApplicationContext的refresh函数载入Bean定义过程：

SpringIOC容器对Bean定义资源的载入是从refresh()函数开始的，refresh()是一个模板方法，refresh()方法的作用是：在创建IOC容器前，如果已经有容器存在，则需要把已有的容器销毁和关闭，以保证在refresh之后使用的是新建立起来的IOC容器。refresh的作用类似于对IOC容器的重启，在新建立好的容器中对容器进行初始化，对Bean定义资源进行载入

FileSystemXmlApplicationContext通过调用其父类AbstractApplicationContext的refresh()函数启动整个IOC容器对Bean定义的载入过程：

![70 12][]

refresh()方法主要为IOC容器Bean的生命周期管理提供条件，SpringIOC容器载入Bean定义资源文件从其子类容器的refreshBeanFactory()方法启动，所以整个refresh()中“ConfigurableListableBeanFactory beanFactory=obtainFreshBeanFactory();”这句以后代码的都是注册容器的信息源和生命周期事件，载入过程就是从这句代码启动。

refresh()方法的作用是：在创建IOC容器前，如果已经有容器存在，则需要把已有的容器销毁和关闭，以保证在refresh之后使用的是新建立起来的IOC容器。refresh的作用类似于对IOC容器的重启，在新建立好的容器中对容器进行初始化，对Bean定义资源进行载入

(4)、AbstractApplicationContext的obtainFreshBeanFactory()方法调用子类容器的refreshBeanFactory()方法，启动容器载入Bean定义资源文件的过程，代码如下：

![70 13][]AbstractApplicationContext类中只抽象定义了refreshBeanFactory()方法，容器真正调用的是其子类AbstractRefreshableApplicationContext实现的refreshBeanFactory()方法，方法的源码如下：

![70 14][]在这个方法中，先判断BeanFactory是否存在，如果存在则先销毁beans并关闭beanFactory，接着创建DefaultListableBeanFactory，并调用loadBeanDefinitions(beanFactory)装载bean定义。

(5)、AbstractRefreshableApplicationContext子类的loadBeanDefinitions方法：

AbstractRefreshableApplicationContext中只定义了抽象的loadBeanDefinitions方法，容器真正调用的是其子类AbstractXmlApplicationContext对该方法的实现，AbstractXmlApplicationContext的主要源码如下：

loadBeanDefinitions方法同样是抽象方法，是由其子类实现的，也即在AbstractXmlApplicationContext中。

![70 15][]

XmlBean读取器(XmlBeanDefinitionReader)调用其父类AbstractBeanDefinitionReader的reader.loadBeanDefinitions方法读取Bean定义资源。

由于我们使用FileSystemXmlApplicationContext作为例子分析，因此getConfigResources的返回值为null，因此程序执行reader.loadBeanDefinitions(configLocations)分支。

(6)、AbstractBeanDefinitionReader读取Bean定义资源,在其抽象父类AbstractBeanDefinitionReader中定义了载入过程。

AbstractBeanDefinitionReader的loadBeanDefinitions方法源码如下：

![70 16][]![70 17][]loadBeanDefinitions(Resource...resources)方法和上面分析的3个方法类似，同样也是调用XmlBeanDefinitionReader的loadBeanDefinitions方法。

从对AbstractBeanDefinitionReader的loadBeanDefinitions方法源码分析可以看出该方法做了以下两件事：

首先，调用资源加载器的获取资源方法resourceLoader.getResource(location)，获取到要加载的资源。其次，真正执行加载功能是其子类XmlBeanDefinitionReader的loadBeanDefinitions方法。

![70 18][]

![70 19][]

看到上面的ResourceLoader与ApplicationContext的继承系图，可以知道其实际调用的是DefaultResourceLoader中的getSource()方法定位Resource，因为FileSystemXmlApplicationContext本身就是DefaultResourceLoader的实现类，所以此时又回到了FileSystemXmlApplicationContext中来。

(7)、资源加载器获取要读入的资源：

XmlBeanDefinitionReader通过调用其父类DefaultResourceLoader的getResource方法获取要加载的资源，其源码如下

![70 20][]FileSystemXmlApplicationContext容器提供了getResourceByPath方法的实现，就是为了处理既不是classpath标识，又不是URL标识的Resource定位这种情况。

![70 21][]这样代码就回到了FileSystemXmlApplicationContext中来，他提供了FileSystemResource来完成从文件系统得到配置文件的资源定义。

这样，就可以从文件系统路径上对IOC配置文件进行加载，当然我们可以按照这个逻辑从任何地方加载，在Spring中我们看到它提供的各种资源抽象，比如ClassPathResource,URLResource,FileSystemResource等来供我们使用。上面我们看到的是定位Resource的一个过程，而这只是加载过程的一部分.

(8)、XmlBeanDefinitionReader加载Bean定义资源：

继续回到XmlBeanDefinitionReader的loadBeanDefinitions(Resource...)方法看到代表bean文件的资源定义以后的载入过程。

![70 22][]通过源码分析，载入Bean定义资源文件的最后一步是将Bean定义资源转换为Document对象，该过程由documentLoader实现

(9)、DocumentLoader将Bean定义资源转换为Document对象：

DocumentLoader将Bean定义资源转换成Document对象的源码如下：

![70 23][]该解析过程调用JavaEE标准的JAXP标准进行处理。

至此SpringIOC容器根据定位的Bean定义资源文件，将其加载读入并转换成为Document对象过程完成。接下来我们要继续分析SpringIOC容器将载入的Bean定义资源文件转换为Document对象之后，是如何将其解析为SpringIOC管理的Bean对象并将其注册到容器中的。

(10)、XmlBeanDefinitionReader解析载入的Bean定义资源文件：

XmlBeanDefinitionReader类中的doLoadBeanDefinitions方法是从特定XML文件中实际载入Bean定义资源的方法，该方法在载入Bean定义资源之后将其转换为Document对象，接下来调用registerBeanDefinitions启动SpringIOC容器对Bean定义的解析过程，registerBeanDefinitions方法源码如下：

![70 24][]Bean定义资源的载入解析分为以下两个过程：

首先，通过调用XML解析器将Bean定义资源文件转换得到Document对象，但是这些Document对象并没有按照Spring的Bean规则进行解析。这一步是载入的过程

其次，在完成通用的XML解析之后，按照Spring的Bean规则对Document对象进行解析。

按照Spring的Bean规则对Document对象解析的过程是在接口BeanDefinitionDocumentReader的实现类DefaultBeanDefinitionDocumentReader中实现的。

(11)、DefaultBeanDefinitionDocumentReader对Bean定义的Document对象解析：

BeanDefinitionDocumentReader接口通过registerBeanDefinitions方法调用其实现类DefaultBeanDefinitionDocumentReader对Document对象进行解析，解析的代码如下：

![70 25][]

![70 26][]

![70 27][]

![70 28][]

![70 29][]

![70 30][]

通过上述SpringIOC容器对载入的Bean定义Document解析可以看出，我们使用Spring时，在Spring配置文件中可以使用<import>元素来导入IOC容器所需要的其他资源，SpringIOC容器在解析时会首先将指定导入的资源加载进容器中。使用<ailas>别名时，SpringIOC容器首先将别名元素所定义的别名注册到容器中。

对于既不是<import>元素，又不是<alias>元素的元素，即Spring配置文件中普通的<bean>元素的解析由BeanDefinitionParserDelegate类的parseBeanDefinitionElement方法来实现。

(12)、BeanDefinitionParserDelegate解析Bean定义资源文件中的<bean>元素：

Bean定义资源文件中的<import>和<alias>元素解析在DefaultBeanDefinitionDocumentReader中已经完成，对Bean定义资源文件中使用最多的<bean>元素交由BeanDefinitionParserDelegate来解析，其解析实现的源码如下：

![70 31][]

![70 32][]![70 33][]![70 34][]

只要使用过Spring，对Spring配置文件比较熟悉的人，通过对上述源码的分析，就会明白我们在Spring配置文件中<Bean>元素的中配置的属性就是通过该方法解析和设置到Bean中去的。

注意：在解析<Bean>元素过程中没有创建和实例化Bean对象，只是创建了Bean对象的定义类BeanDefinition，将<Bean>元素中的配置信息设置到BeanDefinition中作为记录，当依赖注入时才使用这些记录信息创建和实例化具体的Bean对象。

上面方法中一些对一些配置如元信息(meta)、qualifier等的解析，我们在Spring中配置时使用的也不多，我们在使用Spring的<Bean>元素时，配置最多的是<property>属性，因此我们下面继续分析源码，了解Bean的属性在解析时是如何设置的。

(13)、BeanDefinitionParserDelegate解析<property>元素：BeanDefinitionParserDelegate在解析<Bean>调用parsePropertyElements方法解析<Bean>元素中的<property>属性子元素，解析源码如下：![70 35][]

/![70 36][]

![70 37][]

通过对上述源码的分析，我们可以了解在Spring配置文件中，<Bean>元素中<property>元素的相关配置是如何处理的：

a.ref被封装为指向依赖对象一个引用。

b.value配置都会封装成一个字符串类型的对象。

c.ref和value都通过“解析的数据类型属性值.setSource(extractSource(ele));”方法将属性值/引用与所引用的属性关联起来。

在方法的最后对于<property>元素的子元素通过parsePropertySubElement方法解析，我们继续分析该方法的源码，了解其解析过程。

(14)、解析<property>元素的子元素：

在BeanDefinitionParserDelegate类中的parsePropertySubElement方法对<property>中的子元素解析，源码如下：

![70 38][]

![70 39][]

通过上述源码分析，我们明白了在Spring配置文件中，对<property>元素中配置的array、list、set、map、prop等各种集合子元素的都通过上述方法解析，生成对应的数据对象，比如ManagedList、ManagedArray、ManagedSet等，这些Managed类是Spring对象BeanDefiniton的数据封装，对集合数据类型的具体解析有各自的解析方法实现，解析方法的命名非常规范，一目了然，我们对<list>集合元素的解析方法进行源码分析，了解其实现过程。

(15)、解析<list>子元素：

在BeanDefinitionParserDelegate类中的parseListElement方法就是具体实现解析<property>元素中的<list>集合子元素，源码如下：

![70 40][]

经过对SpringBean定义资源文件转换的Document对象中的元素层层解析，SpringIOC现在已经将XML形式定义的Bean定义资源文件转换为SpringIOC所识别的数据结构——BeanDefinition，它是Bean定义资源文件中配置的POJO对象在SpringIOC容器中的映射，我们可以通过AbstractBeanDefinition为入口，看到了IOC容器进行索引、查询和操作。

通过SpringIOC容器对Bean定义资源的解析后，IOC容器大致完成了管理Bean对象的准备工作，即初始化过程，但是最为重要的依赖注入还没有发生，现在在IOC容器中BeanDefinition存储的只是一些静态信息，接下来需要向容器注册Bean定义信息才能全部完成IOC容器的初始化过程

(16)、解析过后的BeanDefinition在IOC容器中的注册：

让我们继续跟踪程序的执行顺序，接下来我们来分析DefaultBeanDefinitionDocumentReader对Bean定义转换的Document对象解析的流程中，在其parseDefaultElement方法中完成对Document对象的解析后得到封装BeanDefinition的BeanDefinitionHold对象，然后调用BeanDefinitionReaderUtils的registerBeanDefinition方法向IOC容器注册解析的Bean，BeanDefinitionReaderUtils的注册的源码如下：

![70 41][]

当调用BeanDefinitionReaderUtils向IOC容器注册解析的BeanDefinition时，真正完成注册功能的是DefaultListableBeanFactory。

(17)、DefaultListableBeanFactory向IOC容器注册解析后的BeanDefinition：DefaultListableBeanFactory中使用一个HashMap的集合对象存放IOC容器中注册解析的BeanDefinition，向IOC容器注册的主要源码如下：

![70 42][]

![70 43][]

![70 44][]

![70 45][]

至此，Bean定义资源文件中配置的Bean被解析过后，已经注册到IOC容器中，被容器管理起来，真正完成了IOC容器初始化所做的全部工作。现在IOC容器中已经建立了整个Bean的配置信息，这些BeanDefinition信息已经可以使用，并且可以被检索，IOC容器的作用就是对这些注册的Bean定义信息进行处理和维护。这些的注册的Bean定义信息是IOC容器控制反转的基础，正是有了这些注册的数据，容器才可以进行依赖注入。

总结：

现在通过上面的代码，总结一下IOC容器初始化的基本步骤：

(1).初始化的入口在容器实现中的refresh()调用来完成。

(2).对bean定义载入IOC容器使用的方法是loadBeanDefinition,其中的大致过程如下：

通过ResourceLoader来完成资源文件位置的定位，DefaultResourceLoader是默认的实现，同时上下文本身就给出了ResourceLoader的实现，可以从类路径，文件系统,URL等方式来定为资源位置。如果是XmlBeanFactory作为IOC容器，那么需要为它指定bean定义的资源，也就是说bean定义文件时通过抽象成Resource来被IOC容器处理的，容器通过BeanDefinitionReader来完成定义信息的解析和Bean信息的注册,往往使用的是XmlBeanDefinitionReader来解析bean的xml定义文件-实际的处理过程是委托给BeanDefinitionParserDelegate来完成的，从而得到bean的定义信息，这些信息在Spring中使用BeanDefinition对象来表示-这个名字可以让我们想到loadBeanDefinition,RegisterBeanDefinition这些相关方法-他们都是为处理BeanDefinitin服务的，容器解析得到BeanDefinition以后，需要把它在IOC容器中注册，这由IOC实现BeanDefinitionRegistry接口来实现。注册过程就是在IOC容器内部维护的一个HashMap来保存得到的BeanDefinition的过程。这个HashMap是IOC容器持有Bean信息的场所，以后对Bean的操作都是围绕这个HashMap来实现的。

然后我们就可以通过BeanFactory和ApplicationContext来享受到SpringIOC的服务了,在使用IOC容器的时候，我们注意到除了少量粘合代码，绝大多数以正确IOC风格编写的应用程序代码完全不用关心如何到达工厂，因为容器将把这些对象与容器管理的其他对象钩在一起。基本的策略是把工厂放到已知的地方，最好是放在对预期使用的上下文有意义的地方，以及代码将实际需要访问工厂的地方。Spring本身提供了对声明式载入web应用程序用法的应用程序上下文,并将其存储在ServletContext中的框架实现。

以下是容器初始化全过程的时序图：

![70 46][]

在使用SpringIOC容器的时候我们还需要区别两个概念:

BeanFactory和FactoryBean，其中BeanFactory指的是IOC容器的编程抽象，比如ApplicationContext，XmlBeanFactory等，这些都是IOC容器的具体表现，需要使用什么样的容器由客户决定,但Spring为我们提供了丰富的选择。FactoryBean只是一个可以在IOC而容器中被管理的一个Bean,是对各种处理过程和资源使用的抽象,FactoryBean在需要时产生另一个对象，而不返回FactoryBean本身,我们可以把它看成是一个抽象工厂，对它的调用返回的是工厂生产的产品。所有的FactoryBean都实现特殊的org.springframework.beans.factory.FactoryBean接口，当使用容器中FactoryBean的时候，该容器不会返回FactoryBean本身,而是返回其生成的对象。Spring包括了大部分的通用资源和服务访问抽象的FactoryBean的实现，其中包括:对JNDI查询的处理，对代理对象的处理，对事务性代理的处理，对RMI代理的处理等，这些我们都可以看成是具体的工厂,看成是Spring为我们建立好的工厂。也就是说Spring通过使用抽象工厂模式为我们准备了一系列工厂来生产一些特定的对象,免除我们手工重复的工作，我们要使用时只需要在IOC容器里配置好就能很方便的使用了。

[70]: /images/20220509/9dc23dba39b04105a2bb4c7aed9939f9.png
[70 1]: /images/20220509/71c7cc3f3c07436c9bac756870d28870.png
[70 2]: /images/20220509/ce20c98c8afb4671bd2aad542f8b5968.png
[70 3]: /images/20220509/3fc59dd998fb4cdc9daa693404e5e01e.png
[70 4]: /images/20220509/9460d906c1764c039605861d3d551df6.png
[70 5]: /images/20220509/97e94c1539ae4740bf12a22e9d7d9ae1.png
[70 6]: /images/20220509/a90b8f0bcdca4d029dd03968e3b2f4b0.png
[70 7]: /images/20220509/4fbf6e16f5044cf38c14274d5d6f676d.png
[70 8]: /images/20220509/852653c744854c6faeaed5a92c9108df.png
[70 9]: /images/20220509/c5a6faf128864163a2da3d9663c32461.png
[70 10]: /images/20220509/9f3e7807999b4e5280d6c373bddf88c0.png
[70 11]: /images/20220509/3318356de65444a8998a42737d40c87b.png
[70 12]: /images/20220509/26f4c33d496a43858150291fd57f4296.png
[70 13]: /images/20220509/3ad15ea334c2449b81ab71752dd9c079.png
[70 14]: /images/20220509/9add5e83437c48c19b1a9c9676e4d120.png
[70 15]: /images/20220509/e8397f269f80463485ae5fc08b8fcde5.png
[70 16]: https://img-blog.csdn.net/20181006094452787?watermark/2/text/aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2h1eWFuZzAzMDQ=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70
[70 17]: /images/20220509/cfa9927e34284ffbbaaf296a54636fd3.png
[70 18]: /images/20220509/f0a1002cb52e4ba28769c4f8bb5329f1.png
[70 19]: /images/20220509/6f2ccea87e6446a4bc81ceedcb7242f4.png
[70 20]: /images/20220509/148695aaf4b54ba4af0a523b9e98ba9b.png
[70 21]: /images/20220509/259af6017ab34f4689b39c9f764b6652.png
[70 22]: /images/20220509/60f03a56ae334462ab564a2629155fb2.png
[70 23]: /images/20220509/274c174cda7d47dfbce559cec5b2b523.png
[70 24]: /images/20220509/5b20752e91254d5380bc00299a4e00c3.png
[70 25]: /images/20220509/fa10e71f0c304be9a058700d30a360bc.png
[70 26]: /images/20220509/e7134a8034e046e8b6beee1a6a65ccf0.png
[70 27]: /images/20220509/ab3dca35552c4e42a9f2facb9d216f6a.png
[70 28]: /images/20220509/e1afc3719c714f8e97e29b602cf4b23e.png
[70 29]: /images/20220509/01e5bbec65cd4dafab7b03708cd97bf1.png
[70 30]: /images/20220509/f31116b3ab3b4b2cb9beb7ffd54618e4.png
[70 31]: /images/20220509/4b98906842dc40b989f3fa1b6d683907.png
[70 32]: https://img-blog.csdn.net/20181006094543995?watermark/2/text/aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2h1eWFuZzAzMDQ=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70
[70 33]: https://img-blog.csdn.net/20181006094608586?watermark/2/text/aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2h1eWFuZzAzMDQ=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70
[70 34]: /images/20220509/479c93b8bf1548c7b48893fa8debec80.png
[70 35]: /images/20220509/9b65603a8a8149a2997b607a179331a9.png
[70 36]: /images/20220509/b956976400b94ea5abf5695296d82c85.png
[70 37]: /images/20220509/752434cec8744844b70b80fb8963df87.png
[70 38]: /images/20220509/fd390575393f4c2da9295e8e8be833a9.png
[70 39]: /images/20220509/67802593a07245e8993a4ff873a2bf61.png
[70 40]: /images/20220509/fda4082ab84248d5857583af569b3cb3.png
[70 41]: /images/20220509/fe1f239dcdb749ea896ac402aaab710c.png
[70 42]: /images/20220509/6cb6c63ae26c41cf92f1a5a3f672632f.png
[70 43]: /images/20220509/91be37998dec43eaba8ecacfef1ff6bf.png
[70 44]: /images/20220509/c3003dc0eec6479094f2093a4a508621.png
[70 45]: /images/20220509/3eda83df915c47dd85d105d6394702ca.png
[70 46]: /images/20220509/ff11d8a243b547fdbf31cf320b384f2f.png