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<passwordnotcontainusername userdto></passwordnotcontainusername>，泛型类型必须匹配被校验对象 -
initialize()方法通常留空；isValid()返回false才触发校验失败 - 注意：自定义注解默认不级联校验嵌套对象，需手动加
@Valid到字段上
手写校验工具类时避免吞掉原始错误上下文
有些老项目习惯封装一个 ValidateUtils.checkNotNull(x, "用户ID不能为空")，但这类工具一旦滥用，会让错误堆栈丢失、字段路径模糊、国际化困难。
立即学习“Java免费学习笔记（深入）”；
- 不要用
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 层负责唯一性与外键约束。跨层重复校验浪费性能，缺位校验埋下隐患。
