校验规则分类：格式校验、范围校验、存在性校验、唯一性校验、业务逻辑校验

数据校验这件事，说白了就是给数据进门设几道关卡。我做了十几年数据治理，见过太多系统因为校验规则没设计好，上线后数据一团糟。今天咱们就把这五类规则掰开揉碎讲清楚。

你想想看，一个数据从录入到存储，要经过多少道检查？我习惯把这五类规则看作一个漏斗——从最基础的格式检查，到最复杂的业务逻辑验证，层层过滤。

1. 格式校验

格式校验是最基础的检查。它只关心数据长什么样，不关心数据有没有意义。

举个例子，手机号字段。你要求用户输入11位数字，结果人家填了"138-1234-5678"或者"13812345678abc"。格式校验就是干这个的——把不符合模板的数据挡在门外。

常见的格式校验手段：

• 正则表达式——最灵活，但写起来容易出错。我建议团队维护一个正则库，别让每个人自己造轮子
• 固定长度/范围长度——比如身份证号18位，银行卡号16-19位
• 字符集限制——只允许数字、只允许字母、不允许特殊字符
• 枚举值匹配——性别只能是"男""女""未知"，状态只能是"启用""禁用"

2. 范围校验

范围校验检查的是数据是否在合理区间内。格式对了，但值不对，照样要拦下来。

比如年龄字段，格式上是个正整数，但填了200岁——这明显不合理。范围校验就是干这个的。

范围校验分几种：

3. 存在性校验

存在性校验，说白了就是检查这个数据有没有。空值、null、空字符串，统统要处理。

但这里有个坑——"空"的定义在不同场景下不一样。用户注册时，手机号不能为空；但用户修改个人资料时，手机号可以不填。所以存在性校验一定要结合业务场景来设计。

我习惯把存在性校验分成三个级别：

• 强制存在——必填项，没有就不能继续。比如订单中的商品ID
• 条件存在——某些条件下必填。比如选择了"其他"选项，备注字段就必须填
• 可选存在——填了更好，不填也行。比如用户的头像

4. 唯一性校验

唯一性校验确保某个字段或字段组合的值在数据集里不重复。最常见的例子就是用户名、身份证号、订单号。

唯一性校验的实现方式：

• 数据库唯一索引——最可靠，但报错信息不友好
• 应用层查询——可以给出友好的提示，但存在并发问题
• 分布式锁+唯一索引——高并发场景下的最佳实践

这里有个经典问题：唯一性校验应该在应用层做还是数据库层做？我的建议是——两层都做。应用层做是为了用户体验，数据库层做是为了数据安全。

5. 业务逻辑校验

业务逻辑校验是最复杂的一类。它不只看单个字段，还要看字段之间的关系，甚至要结合外部数据来判断。

举个例子：请假申请。格式校验看日期格式对不对，范围校验看日期是否在合理范围内，存在性校验看必填项有没有填，唯一性校验看申请编号有没有重复——但业务逻辑校验要检查的是：请假天数是否超过年假余额、是否与已有请假日期冲突、审批人是否有权限审批。

业务逻辑校验的常见场景：

• 字段间约束——结束日期不能早于开始日期
• 状态流转校验——已取消的订单不能发货
• 权限校验——普通员工不能给自己审批
• 外部依赖校验——下单时检查库存是否充足
• 计算规则校验——订单总金额 = 商品金额 + 运费 - 优惠

五类校验规则的关系

这五类规则不是孤立的，它们之间有明确的执行顺序。我画了一张图来说明：

从这张图能看出来，校验规则是层层递进的。格式不对，后面的校验根本没必要跑。我见过有些团队把业务逻辑校验写在最前面，结果格式错误的数据把业务逻辑搞崩溃了——这就是典型的顺序搞反了。