SpringBoot校验：@Valid与HibernateValidator使用

Spring Boot中@Valid参数校验失效？别急着怀疑代码逻辑——90%的问题源于未手动引入spring-boot-starter-validation依赖（2.3+版本已移除默认支持），或忽略BindingResult必须紧随@Valid参数之后的关键顺序；更需厘清@Valid与@Validated的本质差异：前者支持嵌套校验但不支持分组，后者专为分组场景设计却无法用于字段级级联；自定义注解失效往往卡在泛型类型不匹配或Jakarta命名空间迁移（javax→jakarta）的细节陷阱里——掌握这些核心要点，才能真正让校验“看得见、接得住、控得准”。

Spring Boot里@Valid不生效？先检查是否引入了starter

很多人加了@Valid和@NotNull，接口调用却完全不校验——最常见原因是没引入校验依赖。Spring Boot 2.3+ 默认移除了spring-boot-starter-validation的自动依赖，必须手动加。

• Maven里确认有：org.springframework.bootspring-boot-starter-validation
• Gradle对应：implementation 'org.springframework.boot:spring-boot-starter-validation'
• 没有这个依赖，@Valid只是个空注解，连MethodValidationPostProcessor都不会注册

Controller层校验对象时，@Valid必须写在参数前，且不能漏掉BindingResult

校验失败默认抛MethodArgumentNotValidException，但你想自定义返回格式，就得显式接住错误。关键不是“要不要@Valid”，而是“怎么接住它”。

• @Valid必须直接修饰方法参数，比如：public ResponseEntity create(@Valid @RequestBody UserDTO user, BindingResult result)
• BindingResult必须紧跟@Valid参数之后，顺序错（比如中间插了个@RequestParam）会导致注入失败
• 如果没写BindingResult又没全局异常处理器，请求会直接500，日志里只有ConstraintViolationException或MethodArgumentNotValidException

@Validated和@Valid的区别：分组校验和嵌套校验场景下不能混用

单纯非空校验用@Valid够了，但涉及“新增时校验手机号、编辑时校验ID”这类逻辑，就得用@Validated配合分组接口。

• @Validated支持分组：@Validated(User.Create.class)，而@Valid不支持
• @Valid能用在字段上做嵌套校验（比如User类里有个@Valid Address address），@Validated不行
• Controller方法参数只能用@Validated或@Valid之一，同时写两个不会叠加生效，后者会被忽略

自定义校验注解失效？注意ConstraintValidator的泛型类型必须严格匹配

写了个@Phone注解，实现ConstraintValidator，但校验始终跳过——大概率是泛型声明和字段类型对不上。

• 如果字段是private Long phone，ConstraintValidator得写成ConstraintValidator，不能写String
• 自定义注解类上必须有@Constraint(validatedBy = PhoneValidator.class)
• Spring Boot 3+ 使用Jakarta EE命名空间，注解包名要是jakarta.validation.constraints，旧的javax.*会静默失效

复杂点在于嵌套对象的级联校验和分组传播——比如@Valid List里的Item想用不同分组，光靠@Validated搞不定，得用@Validated({Default.class, Item.Create.class})再配合@ConvertGroup，这个细节多数人第一次踩坑时根本想不到。

今天关于《SpringBoot校验：@Valid与HibernateValidator使用》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！