一、规则检查概述
什么是规则检查
规则检查，说白了就是一套自动化的校验机制。
我在项目中遇到过不少新人，一上来就问：「规则检查不就是写几个 if-else 吗？」
嗯，这么说也对，但格局小了。
规则检查的核心，是把业务约束、技术规范、安全策略这些「隐性知识」，变成可执行的代码逻辑。它不关心你的数据怎么流转，只关心你的数据对不对、合不合规。
举个例子：
用户注册时，手机号必须是 11 位数字。这不是业务逻辑，这是规则。
订单金额不能为负数。这也不是业务逻辑，这是规则。
你想想看，如果没有规则检查，这些约束就得散落在各个业务代码里。改一个规则，得翻遍整个项目。我见过最夸张的一次，一个简单的「密码长度从 6 位改成 8 位」，改了 7 个服务、12 个文件。为什么？因为规则和业务逻辑混在一起了。
规则检查的本质：将「判断」从「执行」中剥离出来，形成独立的校验层。
为什么需要规则检查
这个问题我问过很多团队。答案五花八门，但核心就三点：
- 防止脏数据进入核心流程
数据一旦进入数据库，再想清洗就难了。我曾经接手过一个老系统，里面存了几十万条「手机号为空」的订单。为什么？因为早期没有规则检查，前端传什么就存什么。后来光修数据就花了两个星期。 - 降低维护成本
规则集中管理，改一处生效全局。我习惯把规则定义放在独立的配置中心或规则引擎里。业务方改规则，不需要动代码，改个配置就行。 - 提升系统健壮性
规则检查就像系统的「免疫系统」。你想想看，一个没有规则检查的系统，就像一个人没有痛觉。受伤了也不知道，等发现时已经晚了。
避坑指南：我曾经犯过一个错误——把规则检查放在业务代码的最后一步。结果呢？前面已经做了大量计算、调用了多个外部服务，最后一步发现参数不合法，全部回滚。浪费资源不说，还容易引发分布式事务问题。
正确做法：规则检查一定要前置，越早越好。
正确做法：规则检查一定要前置，越早越好。
规则检查在业务流程中的位置
这个问题很关键。很多架构图里，规则检查被画在「入口处」或者「网关层」。但实际项目中，规则检查应该出现在每一个关键节点。
我画了一张图，帮你理解规则检查在整个流程中的位置：
从这张图你能看到：
- 入口处：做基础校验，比如参数格式、必填项。这是第一道防线。
- 业务处理中：做状态校验、权限校验。比如「已取消的订单不能再次发货」。
- 数据持久化前：做数据一致性校验。比如「库存扣减后不能为负数」。
我个人的习惯是，在每一个「状态变更」和「数据写入」之前，都加一道规则检查。宁可多查一次，也不要漏查一次。
小技巧：规则检查的结果不要只返回「成功/失败」。我建议返回一个结构化的结果对象，包含：
这样调用方可以根据不同级别做不同处理。
isValid: boolean — 是否通过errors: string[] — 错误列表warnings: string[] — 警告信息（不影响流程，但需要关注）这样调用方可以根据不同级别做不同处理。
规则检查的分类
在实际项目中，规则检查大致可以分为三类：
| 分类 | 说明 | 示例 |
|---|---|---|
| 语法规则 | 检查数据格式是否正确 | 手机号格式、邮箱格式、JSON 结构 |
| 业务规则 | 检查数据是否符合业务约束 | 订单金额不能为负、库存不能超卖 |
| 安全规则 | 检查操作是否合规 | 权限校验、频率限制、敏感操作二次确认 |
这三种规则，在代码中的实现方式完全不同。语法规则可以用正则或 JSON Schema，业务规则需要查数据库或调用外部服务，安全规则则依赖权限系统。我建议你不要混在一起写，分开处理，各自独立。
核心原则：规则检查要「早检查、快失败、细粒度」。早检查避免浪费资源，快失败让调用方及时感知，细粒度让错误信息更精准。
好了，这一章就到这里。规则检查听起来简单，但真正做好并不容易。后面的章节我会带你深入每个细节，包括如何设计规则引擎、如何做性能优化、如何应对复杂业务场景。
可可精品资料库