上星期review代码，后端搭档写了个新增数据的接口。我点开一看，校验逻辑大概是这么个画风：

先查数据库看有没有重复记录，再校验字段格局，最终才判别必填项有没有传。

我说兄弟，用户连产品名都没填呢，你就去查库了？数据库它也是有爱情的好吧。

他愣了一下：”这有啥区别吗？横竖最终都会报错。”

区别大了。校验能不能拦住脏数据是及格线，校验的次序才是你规划水平的分界线。

这事让我想起之前踩过的一个坑。

咱们体系有个”新增周度数据”的表单——产品、企业、省份、周产值、周库存、价格、本钱、毛利，十几个字段。刚上线那会儿，校验逻辑是前端搭档”凭感觉”写的，想到哪验到哪。

成果呢，用户填了个负数的价格，体系没拦住，直接跑去做毛利核算了。算出来一个离谱的毛利率，存进了数据库。下游的价格剖析模块一读这条数据——Loss预测直接飞了，剖析师第二天跑来问咱们”这个品种是不是出bug了”。

查了半天，便是由于规模校验被放在了相关核算的后边。价格是负数这件事，本来在第三层就该拦住的，成果漏到了第四层，还引发了连锁反应。

一个校验放错方位，链路上一切下游都跟着遭殃。

这事之后我就开端揣摩：表单校验这东西，究竟有没有一套通用的、稳定的规划范式？

还真有。并且特别朴素。

五层过滤，越廉价的检查越先跑

我后来把校验逻辑梳理成了五层。不是我发明的，你去看任何一个老练结构的参数校验，底层逻辑都是这个：

L1 — 存在性：传没传？

最廉价的检查。字段是不是null、空字符串、undefined。带星号的必填项，这一层全覆盖。用户点提交，先扫一遍，没填的直接标红，后边悉数越过。

为什么放第一层？由于一个空值，你去做格局校验没含义，做规模校验更没含义。就好比你拿到一个null去调.length，不是校验失利的问题，是直接NPE给你看。

L2 — 格局类型：像不像？

字段有值了，看看这个值的”形状”对不对。周产值填了”哈哈哈”——类型不对。日期字段收到一个”2026-13-45″——格局不合法。邮箱没有@符号。手机号混进了字母。

这一层实质上是做类型转化前的门卫。过了这关，后边的逻辑才干拿到一个”至少类型是对的”的值去做进一步判别。

许多前端结构（Ant Design的Form、Element的el-form）自带的validator其实就管到这一层。但光靠这层远远不够。

L3 — 规模边界：合不合理？

格局对了不代表值是合理的。价格不能为负数。库存不能是-500万吨。年度不能填2099年。百分比字段不能呈现200%。

这一层过滤的是”格局正确但事务上离谱”的数据。我管这叫”合法的垃圾”——类型体系认它，事务逻辑不认它。

经常被忽略的一个细节：小数精度也属于这一层。价格保存两位小数，你传进来一个3.14159，后边核算会不会出精度漂移？该在这里就truncate或许round掉。

L4 — 相关逻辑：字段之间自洽吗？

单字段都合法了，但字段之间可能打架。

毛利 = (价格 – 本钱) / 价格。这三个字段之间有硬束缚。用户手动填了毛利和价格，但填的本钱算出来对不上——这便是跨字段逻辑校验该干的活。

还有一类更荫蔽的：条件必填。比如选了某个产品工艺之后，产值单位的可选规模要联动变化。选了”省份”之后，”企业”的下拉列表要跟着过滤。

这一层的本钱比前三层高不少，由于你要同时拿到多个字段的值做交叉判别。所以它排在第四。

L5 — 大局外部：跟体系里已有的数据抵触吗？

最贵的一层。要查库。

同一个”产品 + 企业 + 省份 + 周度时间”的组合，不能重复录入。这个判别必须发恳求到后端，后端去数据库里跑一条select。网络IO + 数据库查询，这是整个校验链路里本钱最高的操作。

所以放在最终。只有前面四层悉数pass了，才值得发这一趟恳求。

你想想，假如把L5放在L1前面会怎样？用户连必填项都没填全，你就发了一次数据库查询。并发高一点，这种无效查询能把你的DB连接池吃得干干净净。

实质便是个短路求值。任何一层挂了，后边不跑。这不是什么高深的规划模式，便是最朴素的本钱排序——选择性高、代价低的条件先履行。

你去看数据库查询优化器选履行计划的逻辑，一模相同的思路。MySQL决定先走哪个索引、先过滤哪个条件，背后也是这套”廉价的先来”。

这套思路不只管表单

你再想远一点。

API接口参数校验，是不是同一套？收到恳求 → 必传参数在不在 → 类型对不对 → 值域合不合理 → 参数间逻辑（start_date < end_date）→ 权限校验（查Redis/查DB）。任何一个老练的API结构，中间件链的排列次序便是按这个来的。

ETL数据清洗，也是。拿到一批CSV → 空行删掉 → 格局一致（日期转ISO、数字去逗号）→ 异常值过滤（价格为负的行剔除）→ 跨字段一致性校验 → 跟主表去重。你要是把去重放在第一步，几百万条数据先全量join一遍，跑到天荒地老。

甚至代码review的时分，你看一个PR，下意识的扫描次序也是：这个改动有没有（L1，别是个空PR）→ 改的对不对地方（L2，文件和模块对不对）→ 改动幅度合不合理（L3，是不是改了不应改的）→ 跟其他模块有没有抵触（L4）→ CI跑过没有（L5，外部验证）。

同一套模型，不同的皮肤。

落地的时分，一张表搞定

回到实际工作。我现在写PRD里的表单需求，直接用一张校验规矩矩阵表跟开发对齐：

比在PRD里写一大段”当用户输入价格时，体系应判别价格是否为空，假如为空则提示……假如不为空则持续判别格局……”清楚十倍。开发拿到这张表，每个字段每一层该干嘛，一望而知，不用反复对齐。

测验搭档也爱这张表。写测验用例的时分，每一层便是一组case。L1的case：每个必填字段分别传空。L2的case：每个字段分别传不合法格局。这么列下来，漏测的概率小许多。

前端校验和后端校验的联系

顺便说一个容易吵架的点。

前端该不应做校验？当然该做。用户体会好，即时反应，不用等网络往复。

但前端校验能不能当安全防地？不能。由于前端校验可以被绕过——随意开个Postman直接打接口，你的前端校验跟没有相同。

所以正确的做法是：前端做L1到L4，体会层面拦一道。后端L1到L5悉数重跑一遍，这是安全兜底。L5本来就要查库，只能在后端做。

别觉得后端重复跑一遍是浪费。安全领域有个原则叫”纵深防护”——不是一道墙够高就行，是多道墙叠在一同，每道都有可能拦住一类攻击。校验也是相同。

有些团队为了省劲，前端做了校验后端就不做了。我只能说，等哪天被人用脚本往你接口里灌脏数据的时分，你就知道这个偷闲有多贵了。

说究竟，校验规划这件事没有什么花活。就一条原则：

先做廉价的判别，再做贵的判别。先用本地信息，再用外部信息。先查格局，再查语义。

把这条刻进DNA里，不管是写表单、规划API、搭数据管道仍是做音讯消费，你的校验逻辑都不会太离谱。

至于那个把查库放在第一步的搭档——他后来重构了。现在那段代码的注释写着：

“L1→L5，别改次序。改了请客。”