前言
Spring Validation 验证框架提供了十分便当的参数验证性能，只须要@Validated或者@Valid以及一些规定注解即可校验参数。
自己看网上很多 SpringBoot 参数校验教程以 "单个参数校验" 和 "实体类参数校验" 这两个角度来分类（或者"Get 办法"和"Post 办法"分类，实际上也是一样的，甚至这种更容易让人产生误解）。
这种分类很容易让人感觉凌乱：注解 @Validated一会要标在类下面，一会又要标在参数前；异样又要解决BindException，又要解决ConstraintViolationException。
刚看的时候可能还记得住，过一段时间就容易记混了，特地是当两种形式同时在一个类里，就不记得到底怎么用，最初可能罗唆全副都加上@Validated注解了。
本文就从校验机制的角度进行分类，SpringBoot 的参数校验有两套机制，执行的时候会同时被两套机制管制。 两套机制除了管制各自的部份外，有局部是重叠的，这部分又会波及优先级之类的问题。 然而只有晓得了两个机制是什么，且理解
Spring 流程，就再也不会搞混了。
校验机制
这两套校验机制，第一种由 SpringMVC 管制。这种校验只能在"Controller"层应用，须要在被校验的对象前标注@Valid，@Validated，或者自定义的名称以'Valid'结尾的注解，如：
@Slfj@RestController@RequestMappingpublic class ValidController { @GetMapping("get1") public void get1(@Validated ValidParam param) { log.info("param: {}", param); }}@Datapublic class ValidParam { @NotEmpty private String name; @Min(1) private int age;}另一种被 AOP 管制。这种只有是 Spring 治理的 Bean 就能失效，所以"Controller"，"Service"，"Dao"层等都能够用这种参数校验。 须要在被校验的类上标注@Validated
注解，而后如果校验单个类型的参数，间接在参数前标注@NotEmpty之类的校验规定注解；如果校验对象，则在对象前标注@Valid注解（这里只能用@Valid，其余都无奈失效，起因前面阐明），如：
import javax.validation.constraints.Max;@Slf4j@Validated@RestController@RequestMappingpublic class ValidController { /** * 校验对象 */ @GetMapping("get2") public void get2(@Valid ValidParam param) { log.info("param: {}", param); } /** * 校验参数 */ @GetMapping("get3") public void get3(@NotEmpty String name, @Max(1) int age) { log.info("name: {}, age: {}", name, age); }}@Datapublic class ValidParam { @NotEmpty private String name; @Min(1) private int age;}SpringMVC 校验机制详解
首先大抵理解一下 SpringMVC 执行流程：
- 通过 DispatcherServlet 接管所有的前端发动的申请
- 通过配置获取对应的 HandlerMapping，将申请映射到处理器。即依据解析 url, http 协定，申请参数等找到对应的 Controller 的对应 Method 的信息。
- 通过配置获取对应的 HandlerAdapter，用于理论解决和调用 HandlerMapping。即实际上是 HandlerAdapter 调用到用户本人写的 Controller 的 Method。
- 通过配置获取对应的 ViewResolver，解决上一步调用获取的返回数据。
参数校验的性能是在步骤 3 做的，客户端申请个别通过RequestMappingHandlerAdapter
一系列配置信息和封装，最终调用到ServletInvocableHandlerMethod.invokeHandlerMethod()
办法。
HandlerMethod
这个ServletInvocableHandlerMethod继承了InvocableHandlerMethod，作用就是负责调用HandlerMethod。HandlerMethod是 SpringMVC 中十分重要的一个类，大家最常接触的中央就是在拦截器HandlerInterceptor中的第三个入参Object handler，尽管这个入参是Object
类型的，但通常都会强转成HandlerMethod。 它用于封装“Controller”，简直所有在调用时可能用到的信息，如办法、办法参数、办法上的注解、所属类，都会被提前解决好放到这个类里。
HandlerMethod自身只封装存储数据，不提供具体的应用办法，所以InvocableHandlerMethod就呈现了，它负责去执行HandlerMethod
，而ServletInvocableHandlerMethod在其根底上减少了返回值和响应状态码的解决。
这里贴一下源码作者对这两个类的正文：
InvocableHandlerMethod调用HandlerMethod的代码：
public Object invokeForRequest(NativeWebRequest request, @Nullable ModelAndViewContainer mavContainer, Object... providedArgs) throws Exception { Object[] args = getMethodArgumentValues(request, mavContainer, providedArgs); if (logger.isTraceEnabled()) { logger.trace("Arguments: " + Arrays.toString(args)); } return doInvoke(args);}第一行getMethodArgumentValues()就是把申请参数映射到 Java 对象的办法，来看看这个办法：
protected Object[] getMethodArgumentValues(NativeWebRequest request, @Nullable ModelAndViewContainer mavContainer, Object... providedArgs) throws Exception { // 1. 获取 Method 办法中的入参信息 MethodParameter[] parameters = getMethodParameters(); if (ObjectUtils.isEmpty(parameters)) { return EMPTY_ARGS; } Object[] args = new Object[parameters.length]; for (int i = 0; i < parameters.length; i++) { MethodParameter parameter = parameters[i]; // 2. 初始化参数名的查找形式或框架，如反射，AspectJ、Kotlin 等 parameter.initParameterNameDiscovery(this.parameterNameDiscoverer); // 3. 如果 getMethodArgumentValues() 办法第三个传参提供了一个参数，则这里用这个参数。（失常申请不会有这个参数，SpringMVC 解决异样的时候外部本人生成的） args[i] = findProvidedArgument(parameter, providedArgs); if (args[i] != null) { continue; } if (!this.resolvers.supportsParameter(parameter)) { throw new IllegalStateException(formatArgumentError(parameter, "No suitable resolver")); } try { // 4. 用对应的 HandlerMethodArgumentResolver 转换参数 args[i] = this.resolvers.resolveArgument(parameter, mavContainer, request, this.dataBinderFactory); } catch (Exception ex) { // Leave stack trace for later, exception may actually be resolved and handled... if (logger.isDebugEnabled()) { String exMsg = ex.getMessage(); if (exMsg != null && !exMsg.contains(parameter.getExecutable().toGenericString())) { logger.debug(formatArgumentError(parameter, exMsg)); } } throw ex; } } return args;}办法里最次要的就是this.resolvers.resolveArgument(parameter, mavContainer, request, this.dataBinderFactory);这行
，调用HandlerMethodArgumentResolver接口的实现类解决参数。
HandlerMethodArgumentResolver
HandlerMethodArgumentResolver也是 SpringMVC 中十分重要的一个组件局部，用于将办法参数解析为参数值的策略接口，咱们常说的自定义参数解析器。接口有两个办法：supportsParameter办法用户断定该 MethodParameter 是否由这个 Resolver 解决，resolveArgument办法用于解析参数成办法的入参对象。
public interface HandlerMethodArgumentResolver { boolean supportsParameter(MethodParameter parameter); Object resolveArgument(MethodParameter parameter, @Nullable ModelAndViewContainer mavContainer, NativeWebRequest webRequest, @Nullable WebDataBinderFactory binderFactory) throws Exception;}SpringMVC 本身提供了十分多的HandlerMethodArgumentResolver实现类，如 RequestResponseBodyMethodProcessor（@RequestBody注解的参数）
、RequestParamMethodArgumentResolver（@RequestParam注解的参数，或者没其余 Resolver 匹配的 Java 根本数据类型）
、RequestHeaderMethodArgumentResolver（@RequestHeaderMethodArgumentResolver注解的参数）
、ServletModelAttributeMethodProcessor（@ModelAttribute注解的参数，或者没其余 Resolver 匹配的自定义对象） 等等。
咱们以ServletModelAttributeMethodProcessor为例，看看其resolveArgument是怎么样的：
public final Object resolveArgument(MethodParameter parameter, @Nullable ModelAndViewContainer mavContainer, NativeWebRequest webRequest, @Nullable WebDataBinderFactory binderFactory) throws Exception { // ... // 获取参数名称以及异样解决等，这里省略。.. if (bindingResult == null) { // bindingResult 为空示意没有异样 // 1. binderFactory 创立对应的 DataBinder WebDataBinder binder = binderFactory.createBinder(webRequest, attribute, name); if (binder.getTarget() != null) { if (!mavContainer.isBindingDisabled(name)) { // 2. 绑定数据，即理论注入数据到入参对象里 bindRequestParameters(binder, webRequest); } // 3. 校验数据，即 SpringMVC 参数校验的入口 validateIfApplicable(binder, parameter); if (binder.getBindingResult().hasErrors() && isBindExceptionRequired(binder, parameter)) { // 4. 查看是否有 BindException 数据校验异样 throw new BindException(binder.getBindingResult()); } } if (!parameter.getParameterType().isInstance(attribute)) { // 如果入参对象为 Optional 类型，SpringMVC 会帮忙转一下 attribute = binder.convertIfNecessary(binder.getTarget(), parameter.getParameterType(), parameter); } bindingResult = binder.getBindingResult(); } // 增加绑定后果到 mavContainer 中 Map<String, Object> bindingResultModel = bindingResult.getModel(); mavContainer.removeAttributes(bindingResultModel); mavContainer.addAllAttributes(bindingResultModel); return attribute;}在代码中步骤 4 调用validateIfApplicable办法看名字就是校验的，看看代码：
protected void validateIfApplicable(WebDataBinder binder, MethodParameter parameter) { for (Annotation ann : parameter.getParameterAnnotations()) { // 断定是否要做校验，同时获取 Validated 的分组信息 Object[] validationHints = ValidationAnnotationUtils.determineValidationHints(ann); if (validationHints != null) { // 调用校验 binder.validate(validationHints); break; } }}ValidationAnnotationUtils.determineValidationHints(ann)办法用于断定这个参数对象是否有满足参数校验条件的正文，并且返回对应的分组信息 （@Validated的分组性能）。
public static Object[] determineValidationHints(Annotation ann) { Class<? extends Annotation> annotationType = ann.annotationType(); String annotationName = annotationType.getName(); // @Valid 注解 if ("javax.validation.Valid".equals(annotationName)) { return EMPTY_OBJECT_ARRAY; } // @Validated 注解 Validated validatedAnn = AnnotationUtils.getAnnotation(ann, Validated.class); if (validatedAnn != null) { Object hints = validatedAnn.value(); return convertValidationHints(hints); } // 用户自定义的以 "Valid" 结尾的注解 if (annotationType.getSimpleName().startsWith("Valid")) { Object hints = AnnotationUtils.getValue(ann); return convertValidationHints(hints); } return null;}这里就是结尾说的『这种校验只能在"Controller"层应用，须要在被校验的对象前标注@Valid，@Validated，或者自定义的名称以'Valid'结尾的注解』的 SpringMVC 断定是否要做校验的代码。
如果是@Validated则返回@Validated里的分组数据，否则返回空数据，如果没有符合条件的注解，则返回 null。
断定完校验条件，接着binder.validate(validationHints);会调用到SmartValidator
解决分组信息，最终调用到org.hibernate.validator.internal.engine.ValidatorImpl.validateValue办法去做理论的校验逻辑。
总结一下：
SpringMVC 的校验是在
HandlerMethodArgumentResolver的实现类中，resolveArgument 办法实现的代码中编写相应的校验规定，是否校验的断定是由ValidationAnnotationUtils.determineValidationHints(ann)来决定。然而只有
ModelAttributeMethodProcessor、AbstractMessageConverterMethodArgumentResolver这两个抽象类的 resolveArgument 办法编写了校验逻辑，实现类别离为：ServletModelAttributeMethodProcessor（
@ModelAttribute注解的参数，或者没其余 Resolver 匹配的自定义对象），HttpEntityMethodProcessor（
HttpEntity或RequestEntity对象），RequestPartMethodArgumentResolver（
@RequestPart注解的参数或MultipartFile类），RequestResponseBodyMethodProcessor（@RequestBody注解的对象）开发中常常应用的
@RequestParam注解的参数或者说单个参数的 Resolver 并没有实现校验逻辑，然而这部分在应用中也能被校验，那是因为这部分校验是交给 AOP 机制的校验规定解决的。
AOP 校验机制详解
在下面『SpringMVC 校验机制详解』局部提到在 DispatcherServlet 的流程中，会有InvocableHandlerMethod调用HandlerMethod的代码，这里再回顾一下：
public Object invokeForRequest(NativeWebRequest request, @Nullable ModelAndViewContainer mavContainer, Object... providedArgs) throws Exception { Object[] args = getMethodArgumentValues(request, mavContainer, providedArgs); if (logger.isTraceEnabled()) { logger.trace("Arguments: " + Arrays.toString(args)); } return doInvoke(args);}这个getMethodArgumentValues办法在下面剖析了，会获取到 request 中的参数并校验组装成 Method 须要的参数，这一节看看doInvoke(args)办法做了什么。
protected Object doInvoke(Object... args) throws Exception { Method method = getBridgedMethod(); ReflectionUtils.makeAccessible(method); try { if (KotlinDetector.isSuspendingFunction(method)) { return CoroutinesUtils.invokeSuspendingFunction(method, getBean(), args); } return method.invoke(getBean(), args); } catch (IllegalArgumentException ex) { // ... // 一堆异样的解决，这里省略 }}doInvoke获取到HandlerMethod里的 Method 和 Bean 对象，而后通过 java 原生反射性能调用到咱们编写的 Controller 里的业务代码。
MethodValidationInterceptor
既然这里获取的是 Spring 治理的 Bean 对象，那么必定是被"代理"过的，要代理必定就要有切点切面，那就看看@Validated注解被什么类调用过。发现有个名叫MethodValidationInterceptor
的类调用到了，这名字一看就和校验性能无关，且是个拦截器，看看这个类的正文。
正文写的很间接，第一句就说这是 AOP 的MethodInterceptor的实现类，提供了办法级的校验性能。
MethodValidationInterceptor算是 AOP 机制中的告诉（Advice）局部，由MethodValidationPostProcessor类注册到 Spring 的 AOP 治理中：
public class MethodValidationPostProcessor extends AbstractBeanFactoryAwareAdvisingPostProcessor implements InitializingBean { private Class<? extends Annotation> validatedAnnotationType = Validated.class; // ... // 省略一部分 set 代码。.. @Override public void afterPropertiesSet() { // 切点断定是否由 Validated 注解 Pointcut pointcut = new AnnotationMatchingPointcut(this.validatedAnnotationType, true); this.advisor = new DefaultPointcutAdvisor(pointcut, createMethodValidationAdvice(this.validator)); } protected Advice createMethodValidationAdvice(@Nullable Validator validator) { return (validator != null ? new MethodValidationInterceptor(validator) : new MethodValidationInterceptor()); }}afterPropertiesSet初始化 Bean
的时候，留神Pointcut pointcut = new AnnotationMatchingPointcut(this.validatedAnnotationType, true);这行代码，
创立了一个AnnotationMatchingPointcut的切点类，会把类上有Validated注解的做 AOP 代理。
所以 AOP 机制做校验的首要条件就是类上要有Validated注解。所以只有是被 Spring 治理的 Bean 就能够用 AOP 机制做参数校验。
当初来看一下MethodValidationInterceptor里的代码逻辑：
public class MethodValidationInterceptor implements MethodInterceptor { // ... // 省略构造方法和 set 代码。.. @Override @Nullable public Object invoke(MethodInvocation invocation) throws Throwable { // 跳过 FactoryBean 类的一些要害办法不校验 if (isFactoryBeanMetadataMethod(invocation.getMethod())) { return invocation.proceed(); } // 1. 获取 Validated 里的 Group 分组信息 Class<?>[] groups = determineValidationGroups(invocation); // 2. 获取校验器类 ExecutableValidator execVal = this.validator.forExecutables(); Method methodToValidate = invocation.getMethod(); Set<ConstraintViolation<Object>> result; Object target = invocation.getThis(); Assert.state(target != null, "Target must not be null"); try { // 3. 调用校验办法校验入参 result = execVal.validateParameters(target, methodToValidate, invocation.getArguments(), groups); } catch (IllegalArgumentException ex) { // 解决对象里的泛型信息 methodToValidate = BridgeMethodResolver.findBridgedMethod( ClassUtils.getMostSpecificMethod(invocation.getMethod(), target.getClass())); result = execVal.validateParameters(target, methodToValidate, invocation.getArguments(), groups); } if (!result.isEmpty()) { throw new ConstraintViolationException(result); } Object returnValue = invocation.proceed(); // 4. 调用校验办法校验返回值 result = execVal.validateReturnValue(target, methodToValidate, returnValue, groups); if (!result.isEmpty()) { throw new ConstraintViolationException(result); } return returnValue; } protected Class<?>[] determineValidationGroups(MethodInvocation invocation) { Validated validatedAnn = AnnotationUtils.findAnnotation(invocation.getMethod(), Validated.class); if (validatedAnn == null) { Object target = invocation.getThis(); Assert.state(target != null, "Target must not be null"); validatedAnn = AnnotationUtils.findAnnotation(target.getClass(), Validated.class); } return (validatedAnn != null ? validatedAnn.value() : new Class<?>[0]); }}这里invoke代理办法次要做了几个步骤：
- 调用
determineValidationGroups办法获取 Validated 里的 Group 分组信息。优先查找办法上的Validated注解来获取分组信息，如果没有则用类上的Validated注解的分组信息。 - 获取校验器类，通常为
ValidatorImpl - 调用校验办法
ExecutableValidator.validateParameters校验入参，如果抛出IllegalArgumentException
异样，尝试获取其泛型信息再次校验。如果参数校验不通过会抛出ConstraintViolationException异样 - 调用校验办法
ExecutableValidator.validateReturnValue校验返回值。如果参数校验不通过会抛出ConstraintViolationException异样
总结一下：
SpringMVC 会通过反射调用到 Controller 对应的业务代码，被调用的类就是被 Spring AOP 代理的类，会走 AOP 机制。
校验性能是在MethodValidationInterceptor类中调用的，调用ExecutableValidator.validateParameters办法校验入参，调用ExecutableValidator.validateReturnValue办法校验返回值
SpringMVC 和 AOP 校验机制总结与比对
- SpringMVC 只有办法入参对象前有
@Valid，@Validated，或者自定义的名称以'Valid'结尾的注解才失效；AOP 须要先在类上标注@Validated
, 而后办法入参前标注校验规定注解（如：@NotBlank），或者校验对象前标注@Valid。 - SpringMVC 在
HandlerMethodArgumentResolver实现类中做参数校验，所以只能在 Controller 层校验失效，并且只有局部HandlerMethodArgumentResolver实现类有校验性能（如RequestParamMethodArgumentResolver就没有）；AOP 是 Spring 的代理机制，所以只有 Spring 代理的 Bean
即可做校验。 - 目前 SpringMVC 校验只能校验自定义对象的入参，无奈校验返回值（当初 Spring 提供的
HandlerMethodArgumentResolver没有做这个性能，能够通过本人实现 Resolver 来实现）；AOP 能够校验根本数据类型，能够校验返回值。 - SpringMVC 在校验不通过时会抛出
BindException异样（MethodArgumentNotValidException在 Spring5.3 版本也变为BindException的子类）;AOP
校验在校验不通过时抛出ConstraintViolationException异样。（Tip: 所以能够通过抛出的异样来断定走的哪个校验流程，不便定位问题）。 - 在 Controller 层校验时会先走 SpringMVC 流程，而后再走 AOP 校验流程。
原文地址：详解SptingBoot参数校验机制，应用校验不再凌乱