1. 校验注解的本质区别
在Java开发中，数据校验是保证系统健壮性的重要环节。@Valid和@Validated这两个注解看似相似，实则有着本质的区别。
@Valid源自Jakarta Bean Validation规范（原JSR-303），是JavaEE/JakartaEE标准的一部分。它的核心职责是触发对象属性的级联校验。当你在字段上标注@Valid时，校验框架会递归检查该字段内部的所有约束注解。
重要提示：@Valid本身并不包含任何校验规则，它只是告诉校验器"这个字段需要进一步检查"
@Validated则是Spring框架对标准校验的扩展实现。它在@Valid的基础上增加了两大关键能力：
- 分组校验（Validation Groups）
- 方法级别的参数校验（包括构造器、方法参数和返回值）
2. 标准校验场景对比
2.1 基础对象校验
对于简单的DTO校验，两者表现基本一致。以用户注册接口为例：
java复制// DTO定义
public class UserDTO {
@NotBlank(message = "用户名不能为空")
private String username;
@Email(message = "邮箱格式不正确")
private String email;
}
// Controller使用
@PostMapping("/register")
public ResponseEntity register(@Valid @RequestBody UserDTO user) {
// 使用@Validated效果相同
return ResponseEntity.ok().build();
}
在这个场景下，选择@Valid更为合适，因为：
- 这是标准规范推荐的做法
- 不涉及Spring特有的功能
- 代码可移植性更好（不依赖Spring）
2.2 嵌套对象校验
当DTO包含嵌套对象时，必须使用@Valid启用级联校验：
java复制public class OrderDTO {
@NotNull
private Long orderId;
@Valid // 必须添加这个注解
private UserDTO user;
@Valid // 集合也需要级联校验
private List<OrderItem> items;
}
如果不加@Valid，即使OrderItem内部有@NotNull等约束注解，校验器也不会检查这些嵌套对象。这是新手常犯的错误。
3. Spring专属能力解析
3.1 分组校验实战
分组校验是@Validated的核心价值所在。考虑电商系统中的订单状态流转：
java复制// 定义校验组
public interface OrderChecks {
interface OnCreate {}
interface OnPay {}
}
// DTO定义
public class OrderDTO {
@NotNull(groups = {OnCreate.class, OnPay.class})
private Long id;
@Null(groups = OnCreate.class) // 创建时不应有支付时间
@NotNull(groups = OnPay.class) // 支付时必须有时间
private LocalDateTime payTime;
}
// Controller使用
@PostMapping("/create")
public void createOrder(@Validated(OrderChecks.OnCreate.class) @RequestBody OrderDTO dto) {
// 创建订单逻辑
}
@PostMapping("/pay")
public void payOrder(@Validated(OrderChecks.OnPay.class) @RequestBody OrderDTO dto) {
// 支付订单逻辑
}
分组校验的精妙之处在于：
- 同一字段在不同场景下可以有不同的校验规则
- 避免了为不同场景创建多个DTO类
- 校验规则与业务场景强绑定
3.2 方法参数校验
@Validated在类级别使用时，可以启用方法参数的校验：
java复制@Service
@Validated // 关键注解
public class OrderService {
public void updateStatus(
@NotNull Long orderId,
@Range(min = 1, max = 5) Integer status) {
// 方法参数会自动校验
}
}
这种校验方式特别适合：
- Service层方法参数校验
- Repository方法的预检查
- 工具类方法的输入验证
经验之谈：方法参数校验比在Controller层校验更靠近业务逻辑，可以捕获更早的错误
4. 高级应用技巧
4.1 自定义校验注解
结合@Validated可以实现更强大的校验逻辑。例如验证手机号格式：
java复制@Target({FIELD, PARAMETER})
@Retention(RUNTIME)
@Constraint(validatedBy = PhoneValidator.class)
public @interface ValidPhone {
String message() default "手机号格式不正确";
Class<?>[] groups() default {};
Class<? extends Payload>[] payload() default {};
}
// 实现类
public class PhoneValidator implements ConstraintValidator<ValidPhone, String> {
private static final Pattern PATTERN = Pattern.compile("^1[3-9]\\d{9}$");
@Override
public boolean isValid(String value, ConstraintValidatorContext context) {
return value != null && PATTERN.matcher(value).matches();
}
}
// 使用示例
public class UserDTO {
@ValidPhone(groups = OnCreate.class)
private String phone;
}
4.2 校验异常处理
统一处理校验异常能提升API友好度：
java复制@RestControllerAdvice
public class ValidationExceptionHandler {
@ExceptionHandler(MethodArgumentNotValidException.class)
public ResponseEntity handleValidationExceptions(MethodArgumentNotValidException ex) {
Map<String, String> errors = new HashMap<>();
ex.getBindingResult().getAllErrors().forEach(error -> {
String fieldName = ((FieldError) error).getField();
String message = error.getDefaultMessage();
errors.put(fieldName, message);
});
return ResponseEntity.badRequest().body(errors);
}
}
5. 性能优化建议
-
校验器复用：通过注入Validator实例避免重复创建
java复制@Autowired private Validator validator; public void validate(Object obj) { Set<ConstraintViolation<Object>> violations = validator.validate(obj); // 处理结果 } -
分组校验顺序：复杂对象校验时，使用@GroupSequence定义校验顺序
java复制@GroupSequence({BasicChecks.class, AdvancedChecks.class, UserDTO.class}) public interface FullValidation {} -
延迟校验：对复杂校验逻辑考虑使用@AssertTrue实现懒加载
java复制@AssertTrue(message = "密码强度不足") private boolean isPasswordStrong() { // 复杂密码强度检查 }
6. 常见问题排查
问题1：嵌套校验不生效
- 检查是否漏加@Valid注解
- 确认嵌套对象本身有约束注解
问题2：分组校验未按预期执行
- 确认@Validated指定了正确的分组
- 检查约束注解是否声明了对应分组
问题3：方法参数校验无效
- 确认类级别加了@Validated
- 检查参数是否直接使用约束注解（而非DTO）
问题4：自定义注解不生效
- 确认实现了ConstraintValidator接口
- 检查注解的@Constraint元注解配置正确
在实际项目中，我建议：
- Controller层统一使用@Valid
- 需要分组校验时使用@Validated
- 方法参数校验在Service层使用@Validated
- 复杂业务规则考虑自定义校验注解
这种分层使用策略既保持了代码的规范性，又能充分发挥两种注解的优势。