一次线上事故让我印象特别深某个后台系统接收批量导入的数据第137行的手机号少了一位数字结果整批订单全部进了下游的计费服务。按说这种问题不该出现源头就有一个“手机号校验”的逻辑挂在表单页面上可那次导入走的是内部管理接口绕过了页面接口侧只做了“非空判断”。一个字段漏校验半天的数据全废复盘会开了两小时。“常见的数据校验方法”这个话题看起来简单真正做起来坑都在细节里。数据校验不是写几个if判断就完事它是从用户输入、接口传输、业务处理到最终落库的一条完整链路。我做了多年开发前后端涉及的项目也杂今天把这几年沉淀下来的校验思路和方法整理一遍包含具体步骤、设计取舍还有踩过的坑希望能帮你把校验这件事做扎实。1. 拆解一下数据校验到底在防什么1.1 三类最常见的脏数据想设计好校验方案先要弄清楚校验要挡住的到底是什么东西。我习惯把脏数据分成三类分别对应三个不同层次的缺口。第一类是缺失型数据字段该有值但没值比如注册接口里没有传用户名或者订单号字段传了空字符串。这类问题最直观也最容易漏因为很多接口在联调阶段用数据构造工具生成数据根本不走真实输入场景。第二类是畸形数据字段有值但格式不对。邮箱没有符号手机号只有10位日期写成2024-13-40JSON字段里塞进了一段HTML。这类问题通常是客户端校验和服务端校验口径不一致导致的客户端通过了服务端一验就挂。第三类是越界数据格式没问题但内容超出了业务允许的范围。年龄填了200岁库存数量填了-5状态字段传了一个流程里根本不存在的枚举值。这类数据最阴险字段级别完全合法进了业务层才会炸而且炸的时间往往在半夜跑批的时候。1.2 分层防护的思路校验必须分层做但不是每层都做同样的检查。我的经验是前端校验负责体验后端校验负责安全数据库约束负责底线三者各管一段缺一不可。前端校验最快用户输入完立刻能给反馈不需要等网络请求。但前端校验不能作为安全边界因为请求可以被直接构造页面规则可以被绕过。后端校验是真正的防线所有外部输入进入服务端时都默认不可信要做完整的合法性检查。数据库约束是最后一道兜底就算应用层有漏洞数据库也不会让明显非法的数据落库。三个位置各有取舍用一张表看更清楚校验位置核心职责响应速度被绕过的风险前端即时提示、减少无效请求毫秒级高可直接构造请求绕过后端业务合法性、防止脏数据进入核心链路随接口耗时低是真正的防线数据库约束兜底保证落库数据基本合法写入时检查极低但能做的检查有限2. 常见校验方法的五大流派2.1 手写条件判断最朴素但永远不会过时最直接的方式就是写if、switch这类条件判断一个字段一个字段地验。这种方式的优点是完全可控逻辑写在明面上出了问题能直接定位缺点是重复代码多字段一多校验代码会膨胀得很难维护。我见过很多老项目一个保存接口的校验逻辑堆了几百行各种if嵌套改一个规则要上下翻找半天稍不留神就漏改。举一个典型的手写校验片段function validateUser(input) { if (input null) { return { valid: false, message: 入参不能为空 }; } if (!input.name || input.name.trim().length 0) { return { valid: false, message: 姓名不能为空 }; } if (input.name.trim().length 20) { return { valid: false, message: 姓名长度不能超过20个字符 }; } if (!input.age || input.age 1 || input.age 120) { return { valid: false, message: 年龄必须在1到120之间 }; } return { valid: true }; }手写校验的要点在于尽早返回错误不要把所有判断堆在一起最后统一报错那样反而会让错误信息失去针对性。我的习惯是每个函数开头先处理空值和类型再处理业务规则层层递进。2.2 基于正则的格式校验能解决问题也能制造问题格式类字段的校验主流方案是正则表达式。邮箱、手机号、身份证号、URL、IP地址都有对应的通用正则可用。但正则也是一把双刃剑写复杂了性能会崩写简单了又拦不住非法输入。先给几组我经常用的正则经过了多轮调整// 邮箱基础但足够的版本 /^[^\s][^\s]\.[^\s]$/ // 中国大陆手机号以1开头的11位数字 /^1\d{10}$/ // URL支持http/https /^https?:\/\/[\w\-](\.[\w\-])[/#?]?.*$/ // 数字支持整数和小数不允许科学计数法 /^-?\d(\.\d)?$/用正则必须记住一个原则宁可宽松不要过度严格。很多同学喜欢在网上找“完美版手机号正则”带号段校验结果运营商一推出新号段旧正则就把新号码拦在了门外。尤其邮箱校验RFC里合法邮箱的范围比大多数人想象中宽得多过于严格的正则只是给自己找麻烦。2.3 字典与枚举校验状态类字段的守护者业务系统里有一类字段取值范围是固定的比如订单状态、用户类型、审批结果。这类字段最怕的是库里出现一个谁都不认识的值导致前端下拉框显示空白或者判断逻辑走入else分支。枚举校验的正确做法不是在前端下拉框里限制就完了后端一定要对枚举值做白名单校验。拿订单状态举例// 合法的订单状态集合 private static final SetString VALID_ORDER_STATUS Set.of( CREATED, PAID, SHIPPED, COMPLETED, CANCELLED ); public void checkOrderStatus(String status) { if (!VALID_ORDER_STATUS.contains(status)) { throw new IllegalArgumentException(非法订单状态: status); } }更复杂一点的状态流转建议把“哪些状态可以流转到哪些状态”也约束起来。比如已取消的订单不允许再变更为已支付这种跨字段校验规则后面会专门讲。2.4 用校验框架和声明式规则解放双手业务字段一多手写if就开始力不从心。这时候很多团队会引入校验框架把校验规则以注解或Schema的方式声明在模型上框架自动在请求进入时执行。Java生态里最典型的就是Bean Validation那一套注解NotNull、Size、Min、Max、Pattern这些挂在实体字段上就行public class CreateUserRequest { NotNull(message 用户名不能为空) Size(min 2, max 20, message 用户名长度必须在2到20之间) private String username; NotNull(message 邮箱不能为空) Email(message 邮箱格式不正确) private String email; Min(value 1, message 年龄不能小于1) Max(value 120, message 年龄不能大于120) private Integer age; }前端工程也有对应的声明式校验方案把规则定义在Schema对象里校验库负责逐项执行并组装错误消息。这种方式的核心优势是规则与业务代码分离规则放在数据模型旁边改规则时不用在业务方法里翻找if判断。声明式校验并不适合所有场景。它擅长的是字段级规则而跨字段逻辑和依赖外部服务的校验还是得写自定义校验器。后面我会结合实操讲怎么补这一块。2.5 数据库约束最容易被忽视的最后一关数据库自带的约束能力经常被人低估。NOT NULL、UNIQUE、CHECK、外键约束这些在建表时顺手就定义了但对数据质量的保障作用非常大。举几个例子用户表里用户名加了UNIQUE约束就算应用层并发判断漏了数据库也会用唯一索引兜底阻止重复用户名落库。年龄字段加CHECK约束应用层校验被绕过时数据库直接拒绝写入。外键约束能阻止引用不存在的关联记录。不过数据库约束也有局限它做不了复杂格式校验错误提示极度不友好而且在建表结构变更时很痛苦。所以数据库约束适合作为底线存在不该依赖它去反馈业务错误。3. 校验规则设计与组合的实践经验3.1 规则按数据维度拆开我把校验规则拆成几个维度每个维度独立设计后组合使用这样既不容易漏也方便维护必填规则这个字段能不能为空空字符串算不算空类型规则字段类型对不对能不能安全转换格式规则类型没问题但格式是否符合规范范围规则数值大小、集合长度、时间范围是否在业务允许区间唯一性规则是否和已存储数据冲突比如用户名、订单号业务一致性规则字段之间的关系是否成立比如开始时间不能晚于结束时间这个顺序也很重要。先验必填再验类型然后格式接着范围最后业务规则。顺序错乱会导致报错信息莫名其妙。比如年龄字段传了abc如果先验范围直接提示“年龄必须在1到120之间”用户会一头雾水正确做法是先提示“年龄必须是数字”。3.2 组合校验的执行顺序多个校验规则同时落在同一批数据上的时候要决定是“遇到第一个错误就停”还是“收集所有错误一起返回”。这两种策略各有适用场景。单条数据提交类的接口适合遇到错误立即返回用户改完一轮再来一遍响应快、逻辑简单。批量导入类的场景适合收集所有错误一次性返回比如导入1000条数据第3条和第500条都有问题如果只提示第3条用户改完又发现第500条来回折腾的体验很糟糕。批量校验的伪代码大致是这样function validateBatch(items) { const errors []; for (const [index, item] of items.entries()) { const result validateItem(item); if (!result.valid) { errors.push({ row: index 1, field: result.field, message: result.message }); } } return errors; }3.3 空值的三种形态实战里最容易被忽略的细节是空值至少有三种形态null、空字符串、纯空格字符串 。很多校验只判断了null和结果一个 就让规则漏过去了。处理这类问题统一策略比逐个处理更省心。我的做法是字符串字段在校验前先做一次规范化处理trim掉首尾空格然后null、、 统一视为空。但要注意有些场景空格不能乱trim比如用户填写的密码前端trim会影响实际密码内容这种需要特殊标注。3.4 自定义业务校验跨字段与外部依赖字段级校验再完善也覆盖不了一些业务规则。比如活动开始时间必须早于结束时间发货地址和收货地址不能完全一致新用户注册时用户名不能和已有用户重复。跨字段校验通常需要把整个请求对象传进去统一判断public class ActivityTimeValidator { public void validate(ActivityRequest request) { if (request.getStartTime() ! null request.getEndTime() ! null request.getStartTime().isAfter(request.getEndTime())) { throw new ValidationException(活动开始时间不能晚于结束时间); } } }依赖外部数据的校验比如用户名查重需要访问数据库或远程服务。这种校验有一个性能陷阱如果在循环里逐条查库接口响应时间直接爆炸。正确做法是批量查询把一批待校验的数据收集起来一次查完再比对。4. 一套可落地的校验流程设计4.1 校验应该放在哪一层后端开发里经常有争议校验逻辑该放在Controller层还是Service层我的习惯是简单字段级校验放Controller入口处业务规则校验放Service层开头两层都用各管一摊。Controller层负责检查“请求数据本身是否合法”不涉及业务状态。Service层负责检查“这个合法请求在当前业务状态下是否可执行”。比如下订单接口字段级校验在Controller层做而“库存是否足够”“用户是否有购买权限”属于业务校验必须在Service层执行。这种分层的好处是Controller层校验可以完全复用框架能力而Service层校验与业务事务绑定保证了校验和真正写库在同一个事务内避免校验通过后、写库前数据被其他并发请求改了。4.2 统一错误返回格式校验失败的响应格式最好全团队统一。我推荐一种三元组结构错误码 字段名 用户可读的提示信息。错误码给前端程序判断用字段名用来定位输入框提示信息直接展示给用户看。{ code: 400102, message: 参数校验失败, errors: [ { field: email, message: 邮箱格式不正确 }, { field: age, message: 年龄必须在1到120之间 } ] }统一格式最大的收益是前端处理逻辑可以复用。不管哪个接口返回校验错误前端都能用同一段代码解析并定位到表单字段。如果每个接口返回格式都不一样前端就要针对每个接口写一套错误处理逻辑维护成本直接翻倍。4.3 错误消息的国际化问题很多团队在项目初期不做国际化错误消息直接写在代码里比如“用户名不能为空”。等公司业务发展到海外所有写死的提示都要翻出来改一遍工作量巨大。我建议把错误消息统一放在资源文件或配置中心里代码里只引用消息键。这样即使当前只有一个语言环境未来扩展也很方便。消息键的命名按“字段.规则”的规范来比如user.name.not_blank一看就明白是哪个字段的哪条规则。4.4 校验规则的可维护性设计随着业务迭代校验规则一定会变。我踩过的坑是规则散落在各种工具类和业务代码里改一处漏三处。后来我把校验规则集中管理一个业务模块对应一个校验规则文件规则变更时只改一处测试也只盯这一处。规则文件里可以直接用注释说明变更原因。这段规则是什么时候加的为什么这样限制下一任维护者看到注释能快速理解来龙去脉不至于对着奇怪的规则瞎猜。5. 高频问题排查实录5.1 只做前端校验的导入接口真实发生过的事故前面说过数据从管理后台导入不走正常的前端表单流程接口侧又只做了非空判断结果脏数据长驱直入。修复方案是给导入接口补上同等的后端校验并增加一条自动化测试专门用伪造请求绕过前端直接打接口。凡是接收外部输入的接口不管有没有前端页面后端校验都要做。前端校验是体验保障后端校验才是数据安全的根。5.2 数字类型校验被字符串绕过有个接口接收JSON格式的数据年龄字段前端传的是数字但有人手工构造请求传了字符串18。应用层用类型判断没拦住因为JSON解析时字符串18被自动转换成了数字看似没问题。可到了另一个消费方直接用18去拼接字符串出线了“18岁”和“18天”的歧义。处理这类问题的关键是前端传进来的类型后端必须显式声明和强校验不要依赖JSON解析器的隐式类型转换。字段类型是数字就坚决要求JSON里是数字字符串就要求字符串两边不一致直接报错。5.3 时间格式校验的时区陷阱接口校验收到一个时间字符串2024-11-03 08:00:00按格式校验通过了存进数据库后却发现时间变成2024-11-03 00:00:00或者多出了8小时。问题出在时区客户端和服务端的时区配置不一致或者显示层做了时区转换。处理时间的校验不能只验格式还要约定时区规范。我建议服务端统一使用UTC存储出参时按客户端时区转换校验逻辑里要明确时区是UTC的避免两套时间标准互相混用。5.4 正则灾难性回溯有一次线上接口突然大量超时排查了半天发现是邮箱正则太复杂在特定字符串输入下触发了灾难性回溯CPU被打满。正则表达式在匹配失败时如果存在大量可回退的分支可能产生指数级的时间消耗。从那以后我对正则的性能约束非常严格能用简单字符类解决的不堆叠复杂嵌套所有正则都要本地跑一遍边界测试包括超长字符串、大量连续重复字符、极端符号的组合。这类问题不遇到一次很难有切身体会遇到之后就再也不敢随手抄网上的大正则了。5.5 唯一性校验的并发漏洞“用户名查重”这个逻辑很简单但并发场景下有个经典漏洞两个请求同时查数据库都没查到“张三”于是同时插入数据库唯一索引直接让一条插入失败。如果数据库没有唯一索引两条“张三”就都进去了。解决并发下的唯一性校验不能依赖“先查后插”这种应用层判断真正的兜底是数据库唯一约束。应用层可以提前给用户友好提示但最终防线必须落在约束上。问题典型原因解决思路导入接口脏数据只做前端校验后端疏漏后端做完整校验补自动化测试类型被隐式转换依赖JSON解析器宽松处理显式声明类型强校验时间差8小时时区约定不一致统一UTC存储显示层转换接口超时正则灾难性回溯简化正则跑边界性能测试并发重复数据应用层查重不兜底数据库唯一索引兜底校验这件事做多了代码会显得啰嗦做少了线上事故会教你做人。我的体会是校验代码不该追求“少”而该追求“清晰可审计”每个校验规则都要能说清楚为什么存在。条件允许的话把常用的校验规则抽成团队内部的标准清单新项目直接套用老项目定期对着清单查漏补缺。另外再分享一个小技巧每次上线后关注校验错误日志的分布哪类错误被触发得最多就说明用户最容易在哪里犯错产品侧可以针对性做输入引导。这既是校验的延伸也是提升数据质量的另一种思路。