在之前的分析中我们知道要想了解一个场景启动器的原理就必须要找到它对应的自动配置类。下面我们就来探索一下数据校验spring-boot-starter-validation场景启动器的原理吧？

ValidationAutoConfiguration 配置类

  首先我们来看在这个配置类上都有哪些条件注解，并且这些条件注解分别都是什么？

@AutoConfiguration
@ConditionalOnClass(ExecutableValidator.class)
@ConditionalOnResource(resources = "classpath:META-INF/services/javax.validation.spi.ValidationProvider")
@Import(PrimaryDefaultValidatorPostProcessor.class)
public class ValidationAutoConfiguration {
   

  会看到的还是我们熟悉的那些条件注解，对于条件注解，这里没有什么好说的，只有满足了条件之后才会进行实例化。包括在这其中通过@Import注解引入了
PrimaryDefaultValidatorPostProcessor 它的意思就是注入了一个默认的校验后置处理器。对于后置处理器，我们在后续分析Spring源码的时候会为大家详细说明，如果有兴趣的读者可以搜索一下后置处理是干什么用的？知道的读者在这里就很容易理解这个原理了。

  这里简单地来说明一下，我们在之前的文章中提到了数据校验具体操作，当我们在实体类上标注有对应的数据校验注解的时候，我们在调用了对应的接口之后要从一个JSON格式的数据转化到一个实体对象。在这个过程中，就会有这样一个过程，就是说我们的实体对象要通过一系列的操作来注入到容器中。也就是需要去实现一个反向代理的操作，什么意思呢？之前我们创建实体对象的时候是通过new，或者是其他的方式进行创建的。这里我们将这个过程交给了容器来完成。而后置处理器的意思就是在这些操作都完成之后，再执行，这里我们注入了一个数据检查的后置处理器，意思就是在完成所有的操作之后，然后通过这个后置处理器对数据值进行检查，看是否满足条件。

  当然上面描述的这个场景如果能看懂就看懂了，如果看不懂的话在后续我们分享完关于Spring原理的相关内容之后也就会了解。

  在ValidationAutoConfiguration自动注入类中，其实最关键的不是上面的这个过程，而是下面这段代码。

@Bean
	@Role(BeanDefinition.ROLE_INFRASTRUCTURE)
	@ConditionalOnMissingBean(Validator.class)
	public static LocalValidatorFactoryBean defaultValidator(ApplicationContext applicationContext) {
   
		LocalValidatorFactoryBean factoryBean = new LocalValidatorFactoryBean();
		MessageInterpolatorFactory interpolatorFactory = new MessageInterpolatorFactory(applicationContext);
		factoryBean.setMessageInterpolator