规范属性校验需按业务语义分层设计：明确“存在”定义（null/空串/默认值是否有效）、统一dto层预处理（如@validmobile）、处理多字段互斥（如@atleastoneof）、支持动态存在性（依订单类型等上下文触发校验）。
规范属性存在的校验，关键不是堆砌注解或写满 if 判断，而是按业务语义分层设计：哪些字段必须有值、哪些字段之间存在依赖、哪些校验需跨系统协作。下面从三个实用维度展开。
明确“存在”的定义：null、空字符串、默认值都算无效？
很多问题源于对“存在”理解模糊。比如手机号字段标记为 @NotBlank，但前端传了空格字符串或"0000000000"，业务上其实也不合法。
- 统一在 DTO 层做预处理：用
@Pattern限定格式，或自定义注解如@ValidMobile内部校验非空 + 正则 + 号段白名单 - 对数值型字段，避免仅判
!= null；应结合业务场景判断 0 是否有效（如“库存数量”允许为 0，“折扣比例”为 0 可能代表未设置） - 数据库映射时，用
@Column(nullable = false)约束物理存储，但应用层校验不能依赖这一层——它不拦截空字符串或非法默认值
多字段互斥/互补关系：用组合校验代替单字段约束
像“邮箱和手机号至少填一个”“身份证号与护照号不可同时为空”这类逻辑，单靠字段级注解无法表达。
- Lombok + Bean Validation 场景：添加私有校验方法，用
@AssertFalse标记，返回maybeEmail == null && maybePhone == null - Spring Boot 中可封装为
@AtLeastOneOf("email", "phone")自定义注解，配合 ConstraintValidator 实现复用 - 避免在 service 层写
if (obj.getEmail() == null && obj.getPhone() == null)—— 这类逻辑分散、难测试、无法被 OpenAPI 文档自动识别
动态存在性：根据上下文决定字段是否必填
同一字段在不同业务路径下要求不同。例如“发票抬头”在企业用户下单时必填，个人用户可选；“紧急联系人”在高风险操作中才校验。
- 用枚举或状态字段驱动校验开关，例如
orderType == OrderType.CORPORATE时触发发票字段非空检查 - 借助责任链模式：每个 Handler 负责一类条件校验（如
CorporateInvoiceCheckHandler），主流程只组装激活的链，不硬编码分支 - 前端同步控制：后端返回校验规则元数据（如
{"invoice_required": true}），让表单动态渲染必填星号和验证提示
