Java数据校验必须在入口主动结构化检查，而非依赖try-catch；DTO用@Valid+BindingResult配合JSR-303注解，自定义校验需实现ConstraintValidator，全局异常应分层处理。

Java 数据校验模块不能只靠 try-catch 捕获异常来实现，它必须在业务逻辑入口就做主动、结构化、可复用的约束检查；否则异常会穿透到上层，导致错误定位难、响应不明确、API 可信度低。

用 @Valid + BindingResult 做 Spring Web 层参数校验

这是最常见也最容易出错的场景：前端传参格式不对，后端直接 500 或空指针。关键不是“能不能捕异常”，而是“要不要让请求进到 Controller 方法体里”。

• 必须在 DTO 字段上加 @NotBlank、@Min(1)、@Email 等 JSR-303 注解，而不是等进方法后再手写 if (x == null)
• Controller 方法参数前必须加 @Valid，且紧随其后声明 BindingResult result —— 顺序不能错，否则校验失效
• 校验失败不会抛 MethodArgumentNotValidException（除非没接 BindingResult），而是由 result.hasErrors() 主动判断
• 不要在 BindingResult 后再写其他非 @Valid 参数，Spring 会跳过校验

@PostMapping("/user")
public Result createUser(@Valid @RequestBody UserDTO dto, BindingResult result) {
    if (result.hasErrors()) {
        String msg = result.getFieldError().getDefaultMessage();
        return Result.fail("参数错误：" + msg);
    }
    // 正常业务逻辑
}

自定义校验注解要实现 ConstraintValidator

内置注解覆盖不了业务规则时（比如“密码不能包含用户名”、“结束时间不能早于开始时间”），硬塞在 service 里做 if 判断会导致校验逻辑分散、无法复用、测试困难。

• 先定义注解，如 @PasswordNotContainUsername，记得加 @Constraint(validatedBy = PasswordNotContainUsernameValidator.class)
• 实现类必须继承 ConstraintValidator，泛型类型必须匹配被校验对象
• initialize() 方法通常留空；isValid() 返回 false 才触发校验失败
• 注意：自定义注解默认不级联校验嵌套对象，需手动加 @Valid 到字段上

手写校验工具类时避免吞掉原始错误上下文

有些老项目习惯封装一个 ValidateUtils.checkNotNull(x, "用户ID不能为空")，但这类工具一旦滥用，会让错误堆栈丢失、字段路径模糊、国际化困难。

• 不要用 IllegalArgumentException 包装所有校验失败——它语义太宽，下游难区分是参数错还是流程错
• 建议统一用自定义异常，如 ValidationException，构造时带 field、value、reason 字段，方便日志采集和前端提示
• 避免在循环里反复调用校验方法却不中断，应提前收集所有错误再批量返回（参考 javax.validation.ConstraintViolation 的设计思路）
• 性能敏感场景慎用反射校验（如遍历所有 @NotBlank 字段），优先走编译期注解处理或 AOP 增强

全局异常处理器别把校验异常和系统异常混为一谈

很多人写一个 @ExceptionHandler(Exception.class) 拦住所有异常，结果 ValidationException 和 NullPointerException 返回同样的 HTTP 状态码和错误结构，前端无法区分是填错了表单，还是服务崩了。

• 至少分三类处理：ValidationException → 400 + 字段级错误信息；BusinessException → 409 或 422 + 业务码；RuntimeException → 500 + 运维告警
• MethodArgumentNotValidException 是 Spring 自动抛的，对应未接 BindingResult 的情况，需单独捕获并转成标准错误格式
• 不要在异常处理器里打印完整堆栈到响应体——敏感路径、内部类名可能泄露架构细节

@RestControllerAdvice
public class GlobalExceptionHandler {
    @ExceptionHandler(MethodArgumentNotValidException.class)
    public Result handleValidException(MethodArgumentNotValidException e) {
        String msg = e.getBindingResult().getFieldError().getDefaultMessage();
        return Result.fail("参数校验失败：" + msg);
    }
}

真正难的不是写几个 if 或配几个注解，而是校验边界划在哪：DTO 层负责格式与必填，Service 层负责业务规则与状态一致性，DAO 层负责唯一性与外键约束。跨层重复校验浪费性能，缺位校验埋下隐患。