1、数据校验概述
数据校验，说白了就是给数据「把个关」。你想想看，系统每天要处理成千上万条数据——用户注册填的表单、API 接口传过来的 JSON、Excel 导入的批量记录……这些数据里有没有空值？格式对不对？业务逻辑上合不合理？
我刚开始做开发那会儿，觉得数据校验就是个「if-else 堆砌」的体力活。直到有一次线上事故——用户生日字段传了个「2025-02-30」，下游系统直接崩了。嗯，从那以后我再也不敢轻视校验了。
什么是数据校验
数据校验，就是在数据进入系统之前或之后，按照预先定义的规则，检查它是否满足要求。它回答三个问题：
- 数据存在吗？——非空校验
- 数据长对了吗？——格式校验
- 数据合理吗？——业务逻辑校验
核心定义：数据校验是数据质量的第一道防线。它确保进入系统的数据是完整、准确、一致的。
举个例子。用户注册时填手机号：
- 非空校验：手机号不能为空
- 格式校验：必须是 11 位数字，以 1 开头
- 业务校验：不能是已注销的号码段
这三层校验层层递进。缺一层，都可能出问题。
为什么需要数据校验
这个问题我问过不少新人。有人答「防止报错」，有人答「规范数据」。都对，但不够全面。
我个人习惯从三个维度来看：
| 维度 | 不校验的后果 | 校验的价值 |
|---|---|---|
| 系统稳定性 | 空指针、类型转换异常、SQL 注入 | 拦截异常数据，保护下游服务 |
| 数据质量 | 脏数据堆积，报表不准，分析失效 | 保证数据一致性，提升可信度 |
| 业务合规 | 违反监管要求，产生法律风险 | 满足行业规范，规避审计问题 |
我在项目中遇到过最典型的案例：一个金融系统没有对交易金额做上限校验，结果某次批量导入时，一条「999999999.99」的记录直接导致日终对账不平。排查花了整整两天。你说，一个简单的 max(amount) <= 1000000 能省多少事？
我曾经踩过的坑：只做前端校验，不做后端校验。用户通过 Postman 直接调接口，绕过了前端限制，脏数据照样进了数据库。记住——前端校验是用户体验，后端校验才是安全底线。
数据校验的常见场景
数据校验无处不在。我把它归纳为四大类场景：
1. 用户输入校验
这是最直观的场景。注册、登录、下单、填写资料……用户每次提交表单，都需要校验。
- 必填字段：用户名、密码、邮箱
- 格式校验：邮箱格式、身份证号、银行卡号
- 长度校验：密码 6-20 位，备注不超过 500 字
- 范围校验：年龄 0-150，金额大于 0
2. 接口数据校验
系统间调用时，数据格式和内容必须对齐。我见过太多因为接口字段类型不匹配导致的故障。
- JSON 结构校验：字段是否存在、类型是否正确
- 枚举值校验：状态字段是否在允许范围内
- 签名校验：防止数据被篡改
- 幂等校验：防止重复提交
3. 批量数据校验
ETL 导入、Excel 上传、数据库迁移……批量场景下，数据量巨大，问题也隐蔽。
- 行级校验：每行数据是否完整
- 关联校验：外键是否存在、父子数据是否一致
- 重复校验：主键是否唯一
- 统计校验：总数、合计是否匹配
4. 实时流数据校验
物联网、日志采集、交易流水……数据源源不断流进来，校验必须低延迟。
- 时间戳校验：数据是否过期
- 阈值校验：传感器数值是否在正常范围
- 序列校验：数据顺序是否错乱
- 频率校验：单位时间内数据量是否异常
我的建议：不同场景的校验策略差别很大。用户输入可以给友好提示，批量导入需要错误汇总报告，流数据则要快速丢弃异常。别想着「一套校验打天下」。
下面这张图，是我梳理的数据校验知识体系。它把校验的核心要素串在了一起：
这张图把校验场景和校验项对应起来了。你会发现，不同场景的校验重点差异很大。用户输入侧重格式和必填，接口校验强调结构和签名，批量导入关注关联和重复，流数据则更看重时效和阈值。
说到这儿，我想强调一点：数据校验不是「一次性」的工作。业务在变，数据在变，校验规则也得跟着迭代。我见过不少团队，上线时校验规则写得挺全，半年后业务改了，校验还停在原地——结果就是脏数据悄悄溜进来。
一句话总结：数据校验是数据治理的基石。它不复杂，但容易被忽视。把校验做好，能省掉后面 80% 的数据清洗和故障排查时间。