spring 参数校验Validation示例详解

在实际开发中，我们无法保证客户端传来的请求都是合法的。比如一些要求必传的参数没有传递，传来的参数长度不符合要求等，这种时候如果放任不管，继续执行后续业务逻辑，很有可能就会出现意想不到的bug。

有人可能会说，这不是前端的问题吗，让前端校验去。话是这么说，但我们也不能前端校验百分百不会出现问题。并且有些请求可能也不是正规通过客户端发来的，可能是黑客恶意攻击，又或是通过Postman等发来的，这些请求就不一定会“合法”了。

因此，对客户端传来的每个请求都进行必要的参数校验是十分重要的。而很多简单的校验如果都需要程序员自己去写的话，就会导致代码过于冗长、繁琐。为了让校验更加简洁明了，Spring为我们提供了Validation工具类来提供各种校验方法。

一、Validation常见的校验注解

空校验注解：

• @Null：被注释的元素必须为null。
• @NotNull：被注释的元素必须不为null。
• @NotBlank：被注释的字符串去掉前后空格后长度必须非零。
• @NotEmpty：被注释的字符串、集合或数组不能为空（字符串长度非零、集合大小非零）。

布尔校验注解：

• @AssertTrue：被注释的元素必须为true。
• @AssertFalse：被注释的元素必须为false。

日期校验注解：

• @Past：被注释的元素必须是一个过去的日期。
• @Future：被注释的元素必须是一个将来的日期。

数字校验注解：

• @Min(value)：被注释的元素必须是一个数字，其值必须大于等于指定的最小值。
• @Max(value)：被注释的元素必须是一个数字，其值必须小于等于指定的最大值。
• @DecimalMin(value)：被注释的元素必须是一个数字，其值必须大于等于指定的最小值。
• @DecimalMax(value)：被注释的元素必须是一个数字，其值必须小于等于指定的最大值。

长度校验注解：

• @Size(max, min)：被注释的元素（如字符串、集合、数组）的大小必须在指定的范围内。

模式匹配校验注解：

• @Pattern(regexp)：被注释的元素必须符合指定的正则表达式。

邮箱校验注解：

• @Email：被注释的元素必须是电子邮箱地址。

范围校验注解：

• @Range(min, max)：被注释的元素必须在合适的范围内。

二、Validation的简单应用

首先我们需要导入Validation的依赖：

接着在需要使用校验的类上添加@Validation注解

接着主要有两种方式使用校验注解：

1、直接在对应参数上加上注解

@RestController
@RequestMapping("/user")
@Validation
public class UserController {
    @RequestMapping("/login")
    public Result login(@Size(max = 12,min = 4) String username, @Pattern(regexp = "^\\S{5,16}$") String password){
        //登录
        return Result.success();
    }
}

2、实体类添加校验

对于一些实体类来说，直接在参数上加注解就不太可取了，程序会无法定位到指定参数。

需要再实体类内部对应的变量上添加注解：

@Data
@NoArgsConstructor
@AllArgsConstructor
public class Category {
    @NotNull
    private Integer id;//主键ID
    @NotEmpty
    private String categoryName;//分类名称
    @NotEmpty
    private String categoryAlias;//分类别名
    private Integer createUser;//创建人ID
    @JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")
    private LocalDateTime createTime;//创建时间
    @JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")
    private LocalDateTime updateTime;//更新时间
}

三、分组校验

前面我们介绍了如何在实体类中添加校验注解。但是，事实上在实现不同功能时，对同一个实体类的校验规则可能是会有差异的。

比如在添加用户的场景下，用户的id值就是在存入数据库后生成的，在参数传递时自然就不是必传项；而在更新用户的场景下，我们需要通过id定位指定用户，完成信息更新操作，这时在参数传递时id就是必传项了。

这样，对id值的校验就会产生冲突了。如果将id设定为必传值，那么就会导致添加用户的操作可能出现错误。不把id设定为必传值，更新用户的操作又会出现错误。

为了应对这一问题，就可以对校验项进行分组归类。具体操作步骤如下：

在实体类内部定义相应组别接口：

public class User {
    //各成员变量
    //添加用户类分组
    public interface Add extends Default {
    }
    //更新用户类分组
    public interface Update extends Default{
    }
}