spring boot参数校验需规避五大坑：①注解必须加在字段而非getter；②嵌套对象需显式加@valid；③bindingresult须紧跟被校验参数；④list校验需封装容器类或自定义校验器；⑤全局异常须单独捕获methodargumentnotvalidexception。
Spring Boot 参数校验不是加个 @Valid 就万事大吉的事。很多团队踩过坑才明白：校验失效、嵌套不触发、异常没捕获、分组乱套、列表校验静默失败……这些问题往往上线后才暴露，修复成本高。关键不在“会不会用”，而在“怎么避开执行路径里的断点”。
校验注解位置错误：字段上写，别在 getter 上
校验注解必须直接标注在实体类的字段（field）上，而不是 getter 方法或 setter 方法。Hibernate Validator 通过反射读取字段上的注解，若写在 getter 上，框架根本看不到。
- ❌ 错误写法：
@NotBlank放在getEmail()方法上 - ✅ 正确写法：
@NotBlank private String email; - 补充：Lombok 的
@Data不影响字段级注解，但需确认生成的字段名与注解目标一致
嵌套对象校验失效：里层必须显式加 @Valid
外层 DTO 加了 @Valid，不代表内部对象自动递归校验。只有被 @Valid 显式标注的字段，其内部约束才会被触发。
- 例如：
UserDTO中有个AddressDTO address字段，必须写成@Valid @NotNull private AddressDTO address; -
@Validated本身不支持嵌套校验，它不能替代@Valid在字段上的作用 - 如果嵌套的是集合（如
List<item></item>），每个Item类型字段也需加@Valid，且集合本身建议配合@NotEmpty或@Size
校验失败却不抛异常：BindingResult 必须紧跟参数声明
当使用 @Valid + @RequestBody 时，校验失败默认不会中断执行，而是把错误塞进 BindingResult。若不显式接收并检查，业务逻辑照常运行——等于没校验。
- ✅ 正确写法：
public Result save(@RequestBody @Valid UserDTO dto, BindingResult result) - 紧接着判断：
if (result.hasErrors()) { return Result.fail(result.getAllErrors()); } - ⚠️ 注意：
BindingResult参数必须紧挨着被校验参数，顺序不能错，否则 Spring 找不到对应关系
列表参数校验静默失败：@Valid 不能直接加在 List 上
直接对 List<userdto></userdto> 加 @Valid 是无效的。Spring 不会遍历列表元素逐个触发校验，因为 List 本身不是 Bean，没有字段约束可读取。
- ✅ 解决方案一（推荐）：封装一层容器类，如
class BatchRequest { @Valid @NotEmpty private List<userdto> users; }</userdto> - ✅ 解决方案二：用自定义校验器，实现
ConstraintValidator<validlist list>></validlist>，手动遍历并调用validator.validate(item) - 避免写：
@RequestBody @Valid List<userdto> users</userdto>—— 这行代码看起来合理，实际完全不生效
全局异常未覆盖：MethodArgumentNotValidException 要单独捕获
当校验失败且未配 BindingResult 时，Spring 会抛出 MethodArgumentNotValidException（@RequestBody 场景）或 BindException（表单提交场景）。若全局异常处理器没明确处理这两个类型，就会退到默认 500 页面。
- 在
@RestControllerAdvice类中添加：@ExceptionHandler(MethodArgumentNotValidException.class) - 提取错误信息建议用：
ex.getBindingResult().getAllErrors().stream()... - 别只 catch
RuntimeException：太宽泛，无法精准响应校验失败的结构化错误
