java部分更新校验核心是“只校验实际提交字段”，需区分“未提交”与“提交null”，推荐用jsonnode/map接收原始请求，结合@validated分组（fullupdate/patchupdate）和service层动态校验。
Java 中对部分字段更新做有选择的校验，核心不是“跳过哪些字段”，而是“只校验本次真正提交的字段”。直接复用全量校验逻辑会导致空值误报（比如只改昵称却因邮箱为 null 被拦），关键在于把校验行为和字段的实际变更意图对齐。
区分“未提交”和“提交了 null”
这是所有策略的前提。JSON 反序列化后，缺省字段和显式传 null 都变成 Java 对象里的 null，但业务语义完全不同：
- 没传字段 → 服务端应保持数据库原值，不参与本次校验
- 传了
"email": null→ 表示要清空邮箱，需走邮箱清空的校验逻辑（比如是否允许为空、是否触发关联清理）
推荐做法：用 JsonNode 或 Map<string object></string> 先接收原始请求体，再逐个判断字段是否存在、是否为 null，而不是直接反序列化成完整 DTO。
用分组校验（@Validated + Group）隔离验证场景
Spring 的 @Validated 支持分组，可为全量更新和部分更新定义不同接口：
- 定义两个空标记接口：
interface FullUpdate {}和interface PatchUpdate {} - 在 DTO 字段上标注分组，例如：
@Email(groups = FullUpdate.class)、@NotBlank(groups = PatchUpdate.class)（仅当该字段出现在 PATCH 请求中才校验） - Controller 方法参数加上
@Validated(PatchUpdate.class)，校验器就只检查属于该组的约束
这样既复用 DTO 结构，又避免规则污染，比写两套 DTO 更轻量。
结合字段级动态校验逻辑
对于需要联动或上下文判断的字段（如“修改手机号时需校验新号未被占用”），纯注解不够用。建议在 Service 层手动控制：
- 先从原始请求中提取出非空字段名列表（例如通过
BeanUtils.getPropertyDescriptors()+ 判空） - 对每个待更新字段，调用对应校验方法：
if (fieldsToUpdate.contains("email")) validateEmailUniqueness(newEmail); - 校验通过后再执行字段合并（如用
BeanUtils.copyProperties(source, target, getNullPropertyNames(source))）
这种写法清晰透明，调试方便，也便于未来接入风控或审计日志。
避免常见陷阱
几个高频踩坑点要特别注意：
- 不要为了绕过校验，把所有
@NotBlank全部删掉——这会同时破坏全量更新的安全性 - 不要依赖数据库默认值做“字段未传即用默认值”的假设，PATCH 语义是“不变即不动”，不是“不传即重置”
- 前端传空字符串
""和传null在 Java 中都是“空值”，但业务上可能代表不同意图，需按接口契约明确约定并统一处理
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
