SpringBoot Validation中@NotNull与@Size内部机制及底层验证逻辑问询

你克隆Jakarta Validation仓库查看@Size注解源码时，发现它的@Constraint(validatedBy = { })属性是空数组，和自定义约束注解显式指定验证类的方式不同，这是因为Jakarta Validation采用规范与实现分离的核心设计：

核心原因：规范定义与实现解耦 #

@Size、@NotNull这类注解属于Jakarta Validation规范层面定义的「约束标记」，仅负责声明约束规则（比如min/max参数、错误消息键），而具体的验证逻辑由规范的实现框架（最常用的是Hibernate Validator）来提供。规范本身不会绑定特定的验证器实现，这样可以保证不同厂商的实现都能兼容这套注解体系。

底层实现逻辑 #

1. 内置约束映射
   实现框架会通过内置的约束映射关系，将标准注解关联到对应的验证器。比如Hibernate Validator中，会通过ConstraintMapping把@Size注解分别绑定到：

   • SizeValidatorForCharSequence：处理字符串类型的长度验证
   • SizeValidatorForCollection：处理集合类型的元素数量验证
   • SizeValidatorForArray：处理数组类型的长度验证
     这些验证器都实现了ConstraintValidator<Size, T>接口，根据被验证元素的类型选择对应的实现。

2. 运行时验证器发现
   在Validator工厂初始化阶段，框架会扫描所有实现了ConstraintValidator接口的类，结合注解的元数据（比如注解类型、支持的元素类型）自动关联到对应的约束注解。对于标准约束，框架已经预先完成了这种关联，不需要在注解上显式指定validatedBy。

3. 多类型适配的灵活性
   像@Size需要支持多种数据类型（字符串、集合、数组等），如果在注解上指定单一验证器，会限制其适配能力。通过实现框架动态选择验证器的方式，能让同一个注解适配不同类型的验证场景，这也是规范注解不指定validatedBy的重要原因。

@NotNull的实现逻辑同理 #

@NotNull注解同样是规范定义的约束，其具体验证逻辑由实现框架的NotNullValidator（或对应类型的变体）完成，该验证器会检查被验证对象是否为null，不同类型的非空判断逻辑也由框架统一处理。

内容的提问来源于stack exchange，提问作者Mukund Mundhra