《SpringBoot系列十三》：图文精讲@Conditional条件装配实现原理

偏执的太偏执、 2023-09-29 15:09 3阅读 0赞

#### 文章目录 ####

*  一、前言
 *  二、@Conditional简介和使用
 *  三、条件装配什么时候执行？
 *   *  1、什么是ConfigurationClass配置类？
     *   *  1）如何判断一个类是不是配置类？
     *  2、配置类解析阶段发生的条件装配
     *   *  1> 第一次条件装配
         *  2> 第二次条件装配
         *   *  1）\*\*解析@ComponentScan注解时\*\*
             *  2）解析@Import注解时
         *  3> 第三次条件装配
     *  3、配置类注册为BeanDefinition阶段发生的条件装配（第四次）
 *  四、条件装配怎么执行？
 *   *  1、条件装配的阶段
     *  2、Condition\#matches()匹配逻辑
     *   *  1）OnClassCondition
         *  2）OnBeanCondition
         *   *  1> 按bean type匹配
             *  2> 按bean name匹配
             *   *  \*\*临时容器\`beanDefinitionMap\`是什么时候赋值？临时容器不是\`beanDefinitionNames\`吗？\*\*
 *  五、总结

## 一、前言 ##

在前一篇博文：[《SpringBoot启动流程六》：SpringBoot自动装配时做条件装配的原理（两万字图文源码分析）（含@ConditionalOnClass原理）][SpringBoot_SpringBoot_ConditionalOnClass]，聊了Spring自动装配时做的条件装配，其中@ConditionalOnBean实现的条件装配：居然不是根据Bean是否存在于Spring容器中来判断，而是和@ConditionalOnClass一样依靠类是否能被加载来判断。

本文着重讨论@Conditional各类衍生注解实现条件装配的原理。

注：Spring Boot版本：2.3.7.RELEASE（博主写博客时最新Spring-boot版本 – 2.6.X代码逻辑几乎一样）

## 二、@Conditional简介和使用 ##

@Conditional注解是从spring4.0版本才有的，其是一个条件装配注解，可以用在任何类型或者方法上面，以指定的条件形式限制bean的创建；即当所有条件都满足的时候，被@Conditional标注的目标才会被spring容器处理。

> 1.  @Conditional本身也是一个父注解，从SpringBoot1.0版本开始派生出了大量的子注解；用于Bean的按需加载。
> 2.  @Conditional注解和其所有子注解必须依托于被`@Component衍生注解`标注的类，即Spring要能扫描到@Conditional衍生注解所在的类，才能做进一步判断。
> 3.  @Conditional衍生注解可以加在类 或 类的方法上；加在类上表示类的所有方法都做条件装配、加在方法上则表示只有当前方法做条件装配。

**使用方式参考博文**：[《SpringBoot系列十一》：精讲如何使用@Conditional系列注解做条件装配][SpringBoot_Conditional]。

**自定义条件装配参考博文**：[《SpringBoot系列十二》：如何自定义条件装配][SpringBoot]。

## 三、条件装配什么时候执行？ ##

Spring Boot对ConfigurationClass配置类的处理分为2个阶段：配置类解析阶段、配置类注册为BeanDefinition阶段。  
![在这里插入图片描述][da7b802a85374defb8936c42886f49da.png]

### 1、什么是ConfigurationClass配置类？ ###

当一个类符合下列条件时：

> 1.  类上有@Component注解（或者说间接被@Component标注）；
> 2.  类上有@CompontentScan注解；
> 3.  类上有@Import注解；
> 4.  类上有@ImportResource注解；
> 5.  类中有@Bean标注的方法。

#### 1）如何判断一个类是不是配置类？ ####

`org.springframework.context.annotation.ConfigurationClassUtils`类提供了一个`isConfigurationCandidate(AnnotationMetadata)`方法用于判断一个类是不是配置类。

abstract class ConfigurationClassUtils {
        
        private static final Set<String> candidateIndicators = new HashSet<>(8);
    
    	static {
        
    		candidateIndicators.add(Component.class.getName());
    		candidateIndicators.add(ComponentScan.class.getName());
    		candidateIndicators.add(Import.class.getName());
    		candidateIndicators.add(ImportResource.class.getName());
    	}
        ...
    
        public static boolean isConfigurationCandidate(AnnotationMetadata metadata) {
        
    		// Do not consider an interface or an annotation...
    		if (metadata.isInterface()) {
        
    			return false;
    		}
    
    		// Any of the typical annotations found?
    		for (String indicator : candidateIndicators) {
        
    			if (metadata.isAnnotated(indicator)) {
        
    				return true;
    			}
    		}
    
    		// Finally, let's look for @Bean methods...
    		try {
        
    			return metadata.hasAnnotatedMethods(Bean.class.getName());
    		}
    		catch (Throwable ex) {
        
    			if (logger.isDebugEnabled()) {
        
    				logger.debug("Failed to introspect @Bean methods on class [" + metadata.getClassName() + "]: " + ex);
    			}
    			return false;
    		}
    	}
    
        ....
    }

### 2、配置类解析阶段发生的条件装配 ###

#### 1> 第一次条件装配 ####

![在这里插入图片描述][b98eadf1c5184797b8667eb5e331561b.png]  
结合上面的流程图 和 debug流程中可以看出，在`ConfigurationClassParser#processConfigurationClass(ConfigurationClass, Predicate<String>)`方法的最上层通过调用ConditionEvaluator\#shouldSkip(AnnotatedTypeMetadata,ConfigurationPhase)方法进行第一次条件装配，由于方法第二参数传的是`ConfigurationPhase.PARSE_CONFIGURATION`，表明此时在做的条件装配是解析配置类 类型的。

#### 2> 第二次条件装配 ####

![在这里插入图片描述][4f0e6aefef6f448e999e95b5e8e32e34.png]  
紧接着进入到`doProcessConfigurationClass(ConfigurationClass configClass, SourceClass sourceClass, Predicate<String> filter)`方法；方法的入参configClass、sourceClass是我们的启动类（被@SpringBootApplication注解标注的类 或者说 是main函数所在的类）。

方法中会依次解析@PropertySource、@ComponentScan、@Import、 @ImportResource、@Bean注解。一个最干净的Spring Boot 应用程序中，不会涉及到@PropertySource、@ImportResource、@Bean三个注解的解析。

![在这里插入图片描述][3af624b3349e4927a51eaf13470a7398.png]

##### 1）**解析@ComponentScan注解时** #####

会通过调用ConditionEvaluator\#shouldSkip(AnnotatedTypeMetadata,ConfigurationPhase)方法进行第二次条件装配，由于方法第二参数传的是`ConfigurationPhase.REGISTER_BEAN`，表明此时在做的条件装配是注册Bean 类型的。然后：

1.  首先@ComponentScan注解在 解析配置类阶段扫描到的所有 被@Component衍生注解 标注的配置类都会放入到`ConfigurationClassParser`类的configurationClasses映射中，并且放入到BeanFactory的beanDefinitionNames集合中。
    
    > 这里的configurationClasses映射（`Map<ConfigurationClass, ConfigurationClass>`）可以看做是一个缓存，其中放了所有符合配置类解析阶段条件装配的bean对象信息。  
    > 而BeanFactory的beanDefinitionNames集合（`List<String>`）则用于存放所有符合注册Bean阶段条件装配的bean对象信息。
    > 
    >  *  **那这里直接把@ComponentScan扫描到的所有被@Component衍生注解标注的类都直接放到了BeanFactory的beanDefinitionNames集合中是不是有问题啊？它还没做注册Bean阶段的条件装配吧？**
    >  *  **并且我们也知道，则配置类解析阶段@ConditionalOnBean、@ConditionalOnMissingBean注解大概率可能不会生效（因为此时很多类还没有注册到BeanFactory的beanDefinitionNames集合中）。我想Spring boot肯定不会不考虑这一层。看后面注册Bean阶段做的条件装配即可解答疑惑。**
2.  接着遍历所有扫描出来的类，通过递归的方式每一个扫描出来的类都去执行`ConfigurationClassParser#parse()`方法去解析自身的配置类信息。

##### 2）解析@Import注解时 #####

ImportSelector类型的类会被添加到ConfigurationClassParser类的deferredImportSelectors集合中，并且走完逻辑之后，集合中也只会有一个成员：AutoConfigurationImportSelector（在获取所有的自动装配类是需要使用它的process()方法）。对于其他类（ImportSelector类型、ImportBeanDefinitionRegistrar类型除外的）采用递归的方式走`processConfigurationClass()`方法将自身看做是一个ConfigurationClass做配置类的解析操作。  
![在这里插入图片描述][b9cca8df3824418098386d882b136835.png]

#### 3> 第三次条件装配 ####

第三次条件装配仅针对自动装配类，上面提到AutoConfigurationImportSelector\#process()方法将所有自动装配类全路径名放入到configurationClasses集合中，其中也牵扯到条件装配。那么多的自动装配类，我并不是每一个都需要用到，对于不需要用到的就要过滤掉。  
![在这里插入图片描述][52a96ae7ca4d44df8302627e4cc76231.png]  
针对这里我们在博文：[《SpringBoot启动流程六》：SpringBoot自动装配时做条件装配的原理（万字图文源码分析）][SpringBoot_SpringBoot]详细聊过。

其中有一点需要格外注意，在过滤自动装配类时，就OnBeanCondition过滤器而言（即@ConditionalOnBean、@ConditionalOnMissingBean），功能和OnClassConditionCondition类似， 装配条件为Class是否存在；因为此时ConfigClass几乎都还没有注册到BeanFactory的临时容器beanDefinitionNames中，而正常情况下`Bean Conditions`条件注解的使用需要开发人员特别小心BeanDefinition的添加顺序，所以  
SpringBoot官网的JavaDoc强烈建议开发人员仅在自动装配中使用Bean Conditions条件注解。  
![在这里插入图片描述][d4379880c96c4b16a8857297a140db36.png]  
Bean Conditions条件注解的使用参考博文：[《SpringBoot系列十一》：精讲如何使用@Conditional系列注解做条件装配][SpringBoot_Conditional]。

### 3、配置类注册为BeanDefinition阶段发生的条件装配（第四次） ###

![在这里插入图片描述][480fc125ee7e46b19cdfee6786f38348.png]  
在解析配置类阶段，所有符合条件装配的配置类都会放到ConfigurationClassParser对象的configurationClasses映射（`Map<ConfigurationClass, ConfigurationClass>`）中，在配置类注册为BeanDefinition阶段要做的就是把映射里所有的`ConfigurationClass`转为`BeanDefinition`注册到BeanFactory的String集合类型的beanDefinitionNames成员中，供后续注册到Spring IOC容器中使用。

**具体代码执行流程如下：**  
![在这里插入图片描述][939aa7b9af7d4ce6a6d5b50fa3b804e8.png]

除了对获取到的自动装配类做第一遍条件装配时，其余条件装配的执行入口均为：`ConditionEvaluator#shouldSkip(AnnotatedTypeMetadata,ConfigurationPhase)`。

下面沿着这个入口，讨论一下条件装配是怎么执行的？

## 四、条件装配怎么执行？ ##

`ConditionEvaluator#shouldSkip(AnnotatedTypeMetadata,ConfigurationPhase)`方法的返回值为boolean类型，方法返回true表示当前类应该被过滤掉（即不符合条件装配的规则）、否则表示当前类应该被留下（即符合条件装配的规则）。

/**
     * Determine if an item should be skipped based on {@code @Conditional} annotations.
     * @param metadata the meta data
     * @param phase the phase of the call
     * @return if the item should be skipped
     */
    public boolean shouldSkip(@Nullable AnnotatedTypeMetadata metadata, @Nullable ConfigurationPhase phase) {
        
    	// 如果类没被@Conditional衍生注解标注，则直接返回FALSE，表示当前类不应该被过滤掉
    	if (metadata == null || !metadata.isAnnotated(Conditional.class.getName())) {
        
    		return false;
    	}
    
    	// 如果没设置条件装配的阶段，当类是配置类时，为 PARSE_CONFIGURATION 阶段，否则默认为 REGISTER_BEAN 阶段
    	if (phase == null) {
        
    		if (metadata instanceof AnnotationMetadata &&
    				ConfigurationClassUtils.isConfigurationCandidate((AnnotationMetadata) metadata)) {
        
    			return shouldSkip(metadata, ConfigurationPhase.PARSE_CONFIGURATION);
    		}
    		return shouldSkip(metadata, ConfigurationPhase.REGISTER_BEAN);
    	}
    
    	// 获取类上所有的@Conditional 子注解，返回@Conditional注解中的value值
    	List<Condition> conditions = new ArrayList<>();
    	for (String[] conditionClasses : getConditionClasses(metadata)) {
        
    		for (String conditionClass : conditionClasses) {
        
    			Condition condition = getCondition(conditionClass, this.context.getClassLoader());
    			conditions.add(condition);
    		}
    	}
    
    	// 对获取到的所有Condition接口的实现类进行排序
    	AnnotationAwareOrderComparator.sort(conditions);
    
    	// 遍历所有的Condition，进行match
    	for (Condition condition : conditions) {
        
    		ConfigurationPhase requiredPhase = null;
    		if (condition instanceof ConfigurationCondition) {
        
    			// 获取当前Condition的执行阶段
    			requiredPhase = ((ConfigurationCondition) condition).getConfigurationPhase();
    		}
    		// 如果入参传入的阶段和Condition的阶段不同，直接返回FALSE。
    		// 如果阶段相同 或 Condition的阶段为null，再使用Condition#matches(this.context, metadata)做真正的条件装配逻辑，不符合则返回TRUE。
    		if ((requiredPhase == null || requiredPhase == phase) && !condition.matches(this.context, metadata)) {
        
    			return true;
    		}
    	}
    
    	return false;
    }

**shouldSkip()方法执行的逻辑概括如下：**

> 1.  首先，如果入参类 为 null 或者 没有被@Conditional衍生注解标注，则直接返回FALSE，表示当前类不应该被过滤掉；
> 2.  如果入参没有传条件装配的阶段；当类是配置类时，为 PARSE\_CONFIGURATION 阶段，否则默认为 REGISTER\_BEAN 阶段；
> 3.  接着，获取类上所有的@Conditional 子注解，返回@Conditional注解中的value值。并对获取到的所有Condition接口的实现类进行排序。
> 4.  遍历所有的Condition，进行匹配；如果入参传入的阶段和Condition的阶段不同，直接返回FALSE。如果阶段相同 或 Condition的阶段为null，再使用Condition\#matches(this.context, metadata)做真正的条件装配逻辑，不符合则返回TRUE。

下面我们接着一次讨论条件装配的阶段、Condition\#matches()方法的具体匹配逻辑；

### 1、条件装配的阶段 ###

public interface ConfigurationCondition extends Condition {
        
    
    	/**
    	 * 返回当前Condition应该被评估的阶段
    	 */
    	ConfigurationPhase getConfigurationPhase();
    
    
    	/**
    	 * 可以评估装配条件的几个阶段.
    	 */
    	enum ConfigurationPhase {
        
    
    		/**
    		 * 类解析阶段
    		 */
    		PARSE_CONFIGURATION,
    
    		/**
    		 * 类注册阶段
    		 */
    		REGISTER_BEAN
    	}
    
    }

`PARSE_CONFIGURATION`表示解析配置类的时候执行、`REGISTER_BEAN`表示注册Bean的时候执行；这里和上面讨论的条件装配的入口（Spring Boot 配置类加载的两阶段）相呼应。

`getConfigurationPhase()`表示每个Condition执行器，都可以指定一个阶段去执行，并且只有在此阶段才会评估装配条件。  
![在这里插入图片描述][fbcf5b3f06be429ea715ea28fa653953.png]  
就OnClassCondition、OnBeanCondition、OnWebApplicationCondition三个常用的Condition执行器来看，仅有`OnBeanCondition`指定了评估装配条件的阶段（具体阶段为REGISTER\_BEAN）。即：OnBeanCondition仅在注册Bean阶段才会评估装配条件，而OnClassCondition 和 OnWebApplicationCondition在任意阶段都会评估装配条件。

### 2、Condition\#matches()匹配逻辑 ###

这里讨论OnClassCondition 和 OnBeanCondition两种Condition执行器。

#### 1）OnClassCondition ####

**代码执行流程如下：**  
![在这里插入图片描述][bccf0860e0a3450daa5a119fe72c3378.png]  
最后进入到FilteringSpringBootCondition\#matches()方法（根据上层逻辑，此处的matches()方法可能命名为notMatches更易理解）：  
![在这里插入图片描述][0d3b3e440c88487bb829186493946b5e.png]  
**代码流程解析：**

> 1.  根据当前ClassLoader使用反射Class.forNam()加载类：
>     
>      *  如果MISSING枚举能加载到Class，matches()方法则向上返回false，表示当前类符合条件装配；
>      *  如果PRESENT枚举加载Class时报错（即加载不到Class），matches()方法则向上返回false，表示当前类符合条件装配。
> 2.  如果Class Conditions中存在多个Class，则for循环判断，不符合条件装配的类先添加到一个`List<String>`集合missing/present，上层判断如果集合不为空，则返回一个`ConditionOutcome`对象，内容为：@ConditionalOnClass did not find required classes ‘xxxxx’ 或 @ConditionalOnMissingClass found unwanted classes ‘xxxxx’。并给到Logger打印。
> 3.  否则表示符合条件装配。

#### 2）OnBeanCondition ####

![在这里插入图片描述][9423a39a64674e0b898f71b5b0ee3c5e.png]  
以`WebMvcAutoConfiguration的WebMvcAutoConfigurationAdapter静态内部类的@Bean方法viewResolver()`为例，其上标注了`@ConditionalOnMissingBean`注解，需要满足条件：类型为ViewResolver的Bean存在，且beanName名称为”viewResolver“、类型为`org.springframework.web.servlet.view.ContentNegotiatingViewResolver`的bean不存在时，才会将`ContentNegotiatingViewResolver`注册到Spring容器中。

##### 1> 按bean type匹配 #####

**整体代码执行流程如下：**  
![在这里插入图片描述][e63730524b974c92ae951089a95071cd.png]  
上述代码流程为 根据条件装配注解中设置的Xxx.class（即类的类型），最终进入到DefaultListableBeanFactory\#doGetBeanNamesForType(ResolvableType type, boolean includeNonSingletons, boolean allowEagerInit)方法；  
![在这里插入图片描述][0734920b5c814406b1ef7171d19151a7.png]  
从beanDefinitionNames和manualSingletonNames中查找到相应类型的所有bean。

>  *  `beanDefinitionNames`中存储通过配置类解析阶段和Bean注册阶段的一些Bean；比如：启动类、自动装配类、@Bean方法注入的Bean、Controller、Service等等。
>  *  `manualSingletonNames`，从名字（手工单例名称）来看：在 spring Bean注册的过程中，会手动触发一些bean的注册。比如在springboot启动过程中，会显示的注册一些配置 bean：springBootBanner，springApplicationArguments，systemEnvironment，systemProperties等等。  
>     ![在这里插入图片描述][106a3d2abf80464081911c1f6fb7e520.png]  
>     就`org.springframework.web.servlet.ViewResolver`类型的类而言，找到三个bean，如下：  
>     ![在这里插入图片描述][8437f7abff05477a8e5009f521bd0b11.png]  
>     往上返回，回到`OnBeanCondition#getMatchingBeans()`方法，将获取到的三个bean添加到MatchResult的`matchedTypes`属性（`private final Map<String, Collection<String>> matchedTypes = new HashMap<>();`）中。  
>     ![在这里插入图片描述][616246d6eb3f416580a3902cfcf8505a.png]  
>     后续会继续判断bean的名称，由于`@ConditionalOnBean(ViewResolver.class)`中只有type，没有name，所以跳过。

再往上返回，@ConditionalOnBean条件装配通过；  
![在这里插入图片描述][c18ed14d57224268935c734bc6ff06d7.png]

##### 2> 按bean name匹配 #####

再看`@ConditionalOnMissingBean(name = "viewResolver", value = ContentNegotiatingViewResolver.class)`其中会判断：名称为viewResolver、类型为ContentNegotiatingViewResolver的Bean不存在；

代码执行逻辑如下：  
![在这里插入图片描述][82300b03de4f4971b6a42a66dc8777ce.png]  
这里最后会判断Spring的最终容器`singletonObjects`和临时容器`beanDefinitionMap`是否包含name为`viewResolver`的Bean，最终返回FALSE，表示不存在。  
![在这里插入图片描述][f339ec3f0b5a4e30802754a189d58506.png]

###### **临时容器`beanDefinitionMap`是什么时候赋值？临时容器不是`beanDefinitionNames`吗？** ######

>  *  beanDefinitionNames中存放的只是类的全路径名，而beanDefinitionMap中存放的是类的全路径名和BeanDefinition信息的键值对。
>  *  在`registerBeanDefinition(String beanName, BeanDefinition beanDefinition)`方法中会同时对beanDefinitionNames 和 beanDefinitionMap赋值；所以它俩的元素个数是一样的。  
>     ![在这里插入图片描述][d57a3ae6647945029db3c7208479c4fd.png]

最终`WebMvcAutoConfiguration的WebMvcAutoConfigurationAdapter静态内部类的@Bean方法viewResolver()`符合条件装配的条件。可以注册到Spring的IOC容器中。  
![在这里插入图片描述][f38ef0f28799400c86c0b18f9497b9cc.png]

## 五、总结 ##

> 1.  @Conditional注解可以标注在ConfigurationClass配置类、@Bean方法上，相当于加了个条件判断，通过判断的结果最终决定是否将Bean注册到spring容器中。
> 2.  Spring在处理配置类时有两个阶段：解析配置类、注册bean；这两个阶段中都会使用@Conditional注解来做条件装配；
> 3.  另外，@Conditional 的这套机制很大程度上是用于 自动配置 上，尤其是针对Bean Conditions类的注解，否则需要考虑Bean 的加载顺序，不然容易出现@ConditionalOnBean 或 @ConditionalOnMissingBean注解失效的问题。

下一篇文章，我们继续讨论：条件装配时各个Condition执行的顺序问题

[SpringBoot_SpringBoot_ConditionalOnClass]: http://www.baidu.com
[SpringBoot_Conditional]: https://blog.csdn.net/Saintmm/article/details/124884831
[SpringBoot]: https://blog.csdn.net/Saintmm/article/details/124885010
[da7b802a85374defb8936c42886f49da.png]: https://img-blog.csdnimg.cn/da7b802a85374defb8936c42886f49da.png
[b98eadf1c5184797b8667eb5e331561b.png]: https://img-blog.csdnimg.cn/b98eadf1c5184797b8667eb5e331561b.png
[4f0e6aefef6f448e999e95b5e8e32e34.png]: https://img-blog.csdnimg.cn/4f0e6aefef6f448e999e95b5e8e32e34.png
[3af624b3349e4927a51eaf13470a7398.png]: https://img-blog.csdnimg.cn/3af624b3349e4927a51eaf13470a7398.png
[b9cca8df3824418098386d882b136835.png]: https://img-blog.csdnimg.cn/b9cca8df3824418098386d882b136835.png
[52a96ae7ca4d44df8302627e4cc76231.png]: https://img-blog.csdnimg.cn/52a96ae7ca4d44df8302627e4cc76231.png
[SpringBoot_SpringBoot]: https://blog.csdn.net/Saintmm/article/details/124838375
[d4379880c96c4b16a8857297a140db36.png]: https://img-blog.csdnimg.cn/d4379880c96c4b16a8857297a140db36.png
[480fc125ee7e46b19cdfee6786f38348.png]: https://img-blog.csdnimg.cn/480fc125ee7e46b19cdfee6786f38348.png
[939aa7b9af7d4ce6a6d5b50fa3b804e8.png]: https://img-blog.csdnimg.cn/939aa7b9af7d4ce6a6d5b50fa3b804e8.png
[fbcf5b3f06be429ea715ea28fa653953.png]: https://img-blog.csdnimg.cn/fbcf5b3f06be429ea715ea28fa653953.png
[bccf0860e0a3450daa5a119fe72c3378.png]: https://img-blog.csdnimg.cn/bccf0860e0a3450daa5a119fe72c3378.png
[0d3b3e440c88487bb829186493946b5e.png]: https://img-blog.csdnimg.cn/0d3b3e440c88487bb829186493946b5e.png
[9423a39a64674e0b898f71b5b0ee3c5e.png]: https://img-blog.csdnimg.cn/9423a39a64674e0b898f71b5b0ee3c5e.png
[e63730524b974c92ae951089a95071cd.png]: https://img-blog.csdnimg.cn/e63730524b974c92ae951089a95071cd.png
[0734920b5c814406b1ef7171d19151a7.png]: https://img-blog.csdnimg.cn/0734920b5c814406b1ef7171d19151a7.png
[106a3d2abf80464081911c1f6fb7e520.png]: https://img-blog.csdnimg.cn/106a3d2abf80464081911c1f6fb7e520.png
[8437f7abff05477a8e5009f521bd0b11.png]: https://img-blog.csdnimg.cn/8437f7abff05477a8e5009f521bd0b11.png
[616246d6eb3f416580a3902cfcf8505a.png]: https://img-blog.csdnimg.cn/616246d6eb3f416580a3902cfcf8505a.png
[c18ed14d57224268935c734bc6ff06d7.png]: https://img-blog.csdnimg.cn/c18ed14d57224268935c734bc6ff06d7.png
[82300b03de4f4971b6a42a66dc8777ce.png]: https://img-blog.csdnimg.cn/82300b03de4f4971b6a42a66dc8777ce.png
[f339ec3f0b5a4e30802754a189d58506.png]: https://img-blog.csdnimg.cn/f339ec3f0b5a4e30802754a189d58506.png
[d57a3ae6647945029db3c7208479c4fd.png]: https://img-blog.csdnimg.cn/d57a3ae6647945029db3c7208479c4fd.png
[f38ef0f28799400c86c0b18f9497b9cc.png]: https://img-blog.csdnimg.cn/f38ef0f28799400c86c0b18f9497b9cc.png