前言
在日常的开发中，经常需要对参数进行校验，如果采用代码硬编码去校验，不但代码可扩展性差、复用率低，并且新增字段时可能会漏掉校验，维护成本比较高。简述JSR303/JSR-349，hibernate validation，spring validation之间的关系。
- JSR303是一项标准,JSR-349是其的升级版本，添加了一些新特性，他们规定一些校验规范即校验注解，如@Null，@NotNull，@Pattern，他们位于javax.validation.constraints包下，只提供规范不提供实现。
- hibernate validation是对这个规范的实践（不要将hibernate和数据库orm框架联系在一起），他提供了相应的实现，并增加了一些其他校验注解，如@Email，@Length，@Range等等，他们位于org.hibernate.validator.constraints包下。
- spring validation 给开发者提供便捷，对hibernate validation进行了二次封装，显示校验validated bean时，你可以使用spring validation或者hibernate validation，而spring validation另一个特性，便是其在springmvc模块中添加了自动校验，并将校验信息封装进了特定的类中。这无疑便捷了我们的web开发。
注意：通常情况下hibernate validation 和 Spring validation结合使用
@validated和@valid使用说明
@validated和@valid区别
在检验 Controller 的入参是否符合规范时，使用 @Validated 或者 @Valid 在基本验证功能上没有太多区别。但是在分组、注解地方、嵌套验证等功能上两个有所不同：
- 分组。@Validated：提供了一个分组功能，可以在入参验证时，根据不同的分组采用不同的验证机制，这个网上也有资料，不详述。@Valid：作为标准JSR-303规范，还没有吸收分组的功能。
- 注解地方。@Validated：可以用在类型、方法和方法参数上。但是不能用在成员属性（字段）上。@Valid：可以用在方法、构造函数、方法参数和成员属性（字段）上。两者是否能用于成员属性（字段）上直接影响能否提供嵌套验证的功能。
- 嵌套验证。@Valid加在方法参数时并不能够自动进行嵌套验证，而是用在需要嵌套验证类的相应字段上，来配合方法参数上@Validated或@Valid来进行嵌套验证。
@validated的使用注意点
- @validated和@valid都可以用在controller层的参数前面，但这只能在controller层生效。
- @validated如果要开启方法验证。注解应该打在类上，而不是方法参数上。
- 方法验证模式下，被jsr303标准的注解修饰的可以是方法参数也可以是返回值，类似如下 public @NotNull Object myValidMethod(@NotNull String arg1, @Max(10) int arg2)
- @validated不支持嵌套验证。所以jsr303标准的注解修饰的对象只能基本类型和包装类型。其他类型只能做到检测是否为空，对于对象里面的jsr303标准的注解修饰的属性，不支持验证。
依赖引入
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-validator</artifactId>
<version>5.1.1.Final</version>
</dependency>
