企业官网建设流程全解析

“规则”这两个字，在绝大多数团队里都是最不受待见的资产。写代码的人嫌它碍事，做产品的人嫌它拖慢上线节奏，做运营的人嫌它只会拦住正常用户。可这些年我参与过的项目里，出问题的场景大多绕不开同一个根子：某条本该存在的规则没写，或者写了却没人真正执行。规则重要不重要，平时看不出来，一旦缺位，代价往往以事故、资损、返工和团队信任的形式一次性结算。

这篇内容想聊的是“规则”这件事本身：它有哪些形态、为什么必须存在、怎么设计才不会被架空虚设、写进系统时要注意什么、失效之后怎么排查。无论你是写业务代码的开发、定流程的产品、管线上告警的运维，还是带小团队的负责人，只要手上有一摊需要多个人协作、多个系统对接的事，这些内容都能直接拿去用。我会尽量把抽象的东西落到具体的参数、表结构和操作步骤上，也把踩过的坑一并摊开说。

1. 把“规则”拆开看：它到底在替谁挡刀

很多人对规则的理解停留在“制度条款”这一层，其实在工程和业务系统里，规则至少有三种完全不同的形态，它们的强制力、维护成本、失效后果都不一样。分不清这三种形态，是规则设计一开始就跑偏的主要原因。

1.1 硬规则、软规则、隐性规则：三种形态，三种失效方式

硬规则指的是由系统强制执行、绕不过去的约束。数据库的非空约束、唯一索引、外键、类型系统、接口参数校验、权限中间件，都属于这一类。硬规则的特点是失效即报错，它是可见的、可测的、有明确边界的。你不用担心有人“忘了遵守”，因为系统根本不给他忘的机会。

软规则指的是团队约定，靠人自觉和流程约束。命名规范、提交信息格式、分支命名、评审意见的响应时限、周报模板，都属于这一类。软规则的强制力来自团队氛围和检查机制，一旦没人检查，它就会慢慢退化成摆设。我见过太多团队的代码规范文档，最后一次更新在两年前，新来的人根本不知道它存在。

隐性规则最危险，它是口口相传、文档里查不到、只有“老人”才知道的东西。比如“这个接口在每天凌晨做批处理的时候别调”、“这张表的历史数据不能直接删，要打标记”、“这个字段虽然是字符串，但里面存的其实是 JSON，解析前必须先判空”。隐性规则的特点是没有载体，人一走规则就没了，出事故的时候连排查方向都找不到。

三者的区别，我习惯用一句话概括：硬规则失效会报错，软规则失效会扯皮，隐性规则失效会出事而且没人知道为什么。一个健康的系统，应该是把关键约束尽可能地往硬规则推，把软规则压缩到最少，把隐性规则一条条挖出来写成文档或者直接代码化。

提示：判断一条规则该放在哪一层，问三个问题——违反了会不会造成数据错误或资损？如果是，必须是硬规则。违反了只是风格不统一？那可以是软规则。违反了会导致线上故障但平时没人提？那是隐性规则，优先把它显性化。

1.2 没有规则的系统一定会走向熵增，这不是玄学

我特别不喜欢用“熵增”这种词来讲道理，因为它容易变成空话。但在规则这件事上，它确实有非常具体的表现。一个系统从三个人维护变成十个人维护，从三个业务场景变成三十个，从一个字段的三个取值变成十一个，组合数量是指数级往上走的。

举个我印象很深的例子。某项目早期订单状态只有三个：待支付、已支付、已取消。后来业务扩展，加了退款中、已退款、部分退款、待发货、已发货、已签收、已关闭，一共十一个状态。因为当初没有把状态流转写成一张明确的规则表，各个模块各自判断，结果出现了“已退款但还在待发货队列里”这种不可能的组合。这种数据一旦产生，修复成本极高，因为你不确定它到底是哪一步写坏的。

状态机是规则里最典型的一种：它明确规定了“从哪个状态能到哪个状态”。有了这张表，任何一次状态变更都要先查表，非法流转直接拒绝。没有这张表，每个开发者心里都有一张自己的图，版本还不一样。规则的价值不在于它写了什么，而在于它把“大家心里的不一致”变成了“系统里的一致”。

1.3 一条规则也是有成本账的，别只顾着加

规则不是免费的。它的成本至少有五项：开发成本、维护成本、误杀成本、绕过成本和沟通成本。开发成本最好理解，写下这条规则要花人力；维护成本是随着业务变化要不断调整它；误杀成本最容易被忽略，一条过严的规则会把正常用户挡在外面，损失的是转化和口碑；绕过成本是当规则不合理时，大家为了干活想出的各种变通办法，这些办法往往比规则本身更危险；沟通成本则是每次规则变更都要通知一圈人。

所以判断一条规则该不该加，我会算一笔很粗的账：规则收益 = 它能拦住的错误数量 × 单次错误的平均代价，规则成本 = 上面五项之和。这个账算不精确，但能帮你想清楚方向。比如一条 10 行代码的金额校验，拦住的可能是几十万的资损，那答案很清楚；而一条为了统一某个内部字段命名而增加的强制校验，如果没有配套的迁移方案，可能给十几个调用方都带来改动，收益远小于成本。

我个人的经验是：涉及资金、权限、数据一致性的规则，宁严勿松；涉及展示、排序、文案的规则，宁松勿严。这个原则能帮你在一堆“要不要加校验”的争论里快速收敛。

2. 规则设计：怎么写一条不会被绕过去的规则

规则写出来没人执行，比不写更糟糕，因为它会给团队一种“我们有规范”的错觉。这一章聊的就是怎么让规则真正立得住，从位置上、从冲突处理上、从可验证性上三个角度切入。

2.1 规则要放在离错误最近的地方，而且不止放一层

同一条业务约束，可以放在前端、后端、数据库、流程审批四个位置，效果完全不同。前端校验体验最好，用户提交前就能看到提示，但它天然可以被绕过，抓个包改个参数就没了。后端校验是正确性的主战场，只要请求进来就必须过这一关。数据库约束是最后一道防线，它能保证即使代码有 bug、即使有人手工执行 SQL，数据本身也不会脏。流程审批最重，它解决的是“该不该做”而不是“能不能做”。

我的建议是分层布防：前端放体验型规则，后端放正确性规则，数据库放底线规则，审批流程放高风险操作规则。以金额为例，前端限制输入框只能填数字、最多两位小数；后端校验金额大于 0、不超过单笔上限、与订单明细汇总一致；数据库字段用定点数类型并加非负约束。四层各司其职，任何一层出问题，后面还有兜底。

这里有个很常见的误区：有人觉得后端已经校验了，前端就不用管，或者数据库约束是“冗余”。实际上这三层解决的根本不是同一个问题。前端处理的是可用性，后端处理的是业务正确性，数据库处理的是数据完整性。去年我参与排查过一个对账差异问题，最后定位到是某次数据修复脚本直接改了库，绕过了所有应用层校验。如果当时金额字段上有非负约束和范围约束，脚本会直接执行失败，问题当场就能暴露。

2.2 优先级与冲突：规则表设计里最容易翻车的地方

规则一多，冲突就来了。最典型的场景是营销：满减规则、折扣规则、优惠券规则、会员价规则同时命中一笔订单，到底按哪个算？如果没有明确的冲突处理机制，结果就是随代码执行顺序变化，今天算出来是这样，明天重构一下算法变了，用户看到的价格都不一样。

处理冲突通常有三种思路。显式优先级，给每条规则一个数字，数字小的先执行或者后执行，取决于你的语义定义，关键是要全局统一。特异性优先，越具体的规则优先级越高，比如“指定品类满 200 减 30”比“全场满 200 减 20”更具体，应该优先。互斥分组，把不能同时生效的规则放进同一个组，一组内只允许命中一条，命中多条直接拒绝并报警。

实际项目里我会把三种混着用，规则表大概长这样：

有了这张表，冲突处理就有了明确的抓手：同组内按 priority 排序，只取第一条命中的规则；如果业务上允许叠加，就在 action 里声明可叠加，并在结算时校验叠加后的总优惠不超过订单金额的某个比例。这个比例上限本身就是一条兜底规则，防止出现零元购这种极端情况。

注意：规则表里的 condition 一定要做语法校验和空值保护。我见过因为条件表达式里某个字段为空导致整个求值抛异常，进而让整笔订单优惠失效的案例。表达式求值必须包在 try 里，异常时走默认策略，而不是让流程中断。

2.3 一条不能被验证的规则，等于没有规则

规则写进文档只是第一步，写进测试用例才算数。我判断一条规则是否合格，标准很简单：能不能被写成“给定输入，期望输出”的用例。如果写不出来，说明这条规则本身是模糊的。

状态流转规则最好测，列一张二维表，行是当前状态，列是目标状态，合法的填 1，非法的填 0，每个格子一个用例。条件组合类的规则用决策表最合适，把条件列出来，穷举关键组合，每条组合对应一个期望结果。比如一条风控规则有三个条件：金额是否超过阈值、是否新用户、是否异地登录，三个布尔值组合出八种情况，逐个定义处置动作，这张表就是规则本身，也是测试用例。

我自己维护规则时有个习惯：每条规则在代码里都有一个固定的 rule_id，测试用例的命名里带上这个 id。这样当某条规则变更时，通过 id 就能快速搜出所有相关用例，回归范围一目了然。这个小习惯在规则数量超过五十条之后，能省下大量排查时间。

另外提醒一句，规则的测试要覆盖“边界值”。阈值是 200，那 199、200、201 三个值都要有用例。这条听起来像常识，但我在评审里见过的规则用例，十有八九只测了中间值，边界反而漏了。

3. 落地实现：把规则从文档搬进系统

规则设计得再好，最终要落到代码和配置上。这一章讲三个实操层面的事：规则该用什么形式承载、阈值这类参数怎么算出来、规则变更怎么安全上线。

3.1 规则引擎选型：先想清楚你到底需不需要

一说规则，很多人第一反应是上规则引擎。我的观点是：不要为了规则引擎而规则引擎。选型的核心变量只有三个——规则条数、变更频率、变更人是谁。

规则少于二十条、变更不频繁、只有开发改，那就老老实实写 if-else，可读性最好、调试最方便。规则在二十到两百条之间、每月都有变更、开发改为主，那就做配置化的规则表，用数据库或配置文件承载，代码里只保留一个通用的求值器。规则超过两百条、变更非常频繁、需要业务人员自己维护，这时候才值得引入通用规则引擎或者表达式引擎，代价是学习成本和调试难度都会上升。

下面这个最小实现，是我在很多项目里用过的思路，规则存在表里，求值器统一处理，代码量不大但足够应付大多数场景：

import operator OPS = { ">=": operator.ge, "<=": operator.le, ">": operator.gt, "<": operator.lt, "==": operator.eq, "!=": operator.ne, } def eval_condition(cond, ctx): # cond 形如 [["amount", ">=", 200], ["category", "==", "digital"]] try: for field, op, value in cond: actual = ctx.get(field) if actual is None: return False # 字段缺失视为不命中，而不是抛异常 if not OPS[op](actual, value): return False return True except Exception: return False # 任何求值异常都走不命中，保证主流程不中断 def pick_rule(rules, ctx): # 同组内按 priority 升序，取第一条命中的规则 for rule in sorted(rules, key=lambda r: r["priority"]): if rule["status"] != "active": continue if eval_condition(rule["condition"], ctx): return rule return None

这段代码有两个刻意的设计。一是字段缺失返回不命中而不是报错，因为上游数据不完整是常态，规则系统不应该成为故障源。二是排序取第一条，保证结果确定，同样的输入永远得到同样的输出。规则系统最怕的就是不确定性，一旦结果不可复现，排查成本会高得离谱。

如果你的规则需要支持更复杂的表达式，比如嵌套逻辑、函数调用，可以换成表达式引擎，但一定要注意沙箱隔离和求值超时。规则是人写的，人就会写错，写错的规则不能把主流程拖死。

3.2 阈值这类参数怎么定：拿一个具体例子算一遍

规则里最难定的是数字。超时阈值的规则、限流阈值的规则、告警阈值的规则，定高了没用，定低了天天误报。我拿接口超时阈值举个完整的计算过程，其他阈值可以照这个思路套。

第一步，采集数据。取最近两周的正常时段调用耗时，剔除已经明确异常的时间段，样本量至少几万条，太少没有统计意义。第二步，看分布。不要只看平均值，平均值会被少量慢请求拉偏，要看分位数，P50、P90、P99、P999 都拉出来看一遍。第三步，定基线。一般的做法是取 P99 作为基线，因为它已经覆盖了绝大多数正常请求。第四步，留余量。基线乘以一个系数，我通常取 1.5 到 2，具体看业务对延迟的敏感度，交互型接口取 1.5，后台批处理可以取 2 甚至 3。第五步，设下限。如果算出来的值太小，比如只有 50 毫秒，那要抬到一个合理下限，因为网络抖动和 GC 停顿本身就可能有几十毫秒的波动，阈值太紧会导致大量误判。第六步，灰度验证。新阈值先只告警不阻断，观察一周的触发次数，如果每天触发几十次，说明阈值定低了，要么调高，要么先解决那些慢请求的根因。

限流阈值同理。压测出单机在可接受错误率下的最大 QPS，乘以 0.7 作为单机限流值，集群总限流值是单机值乘以实例数再打个折，因为你不可能保证流量完全均匀分布。这个 0.7 的系数不是拍脑袋，它留出了突发流量、实例重启、依赖抖动三类情况的缓冲，具体数值可以根据压测曲线的拐点位置微调。

我要强调的一点是：阈值一定要写进规则表并且带上计算依据和计算日期。我见过太多阈值，问是谁定的、为什么是这个数，没人答得上来。半年后业务量翻了三倍，阈值还是老样子，规则早就失效了，但因为没人报错，它就那么一直挂着。

3.3 规则变更也是发布，要走灰度、观察、回滚三步

规则改错导致的故障，和代码发布导致的故障没有本质区别，所以规则变更必须走发布流程。我要求团队里的规则变更至少做到三件事：版本化、灰度、可回滚。

版本化指的是每次变更都生成新版本，旧版本保留，规则表里 version 字段递增。灰度指的是新规则先只对一小部分流量生效，比如按用户 ID 取模，只对 5% 的请求应用新规则，同时把命中新规则和命中旧规则的结果都记录下来做对比。这个做法叫影子模式，新规则只记录不生效，跑一段时间看两边差异，差异可解释再切正式。可回滚指的是出问题时能一条命令切回旧版本，而不是现场改代码。

这里有个细节容易漏：规则的灰度要能精确到规则级别，而不是系统级别。如果一次改了五条规则，灰度时应该是这五条一起灰度，观察它们的综合效果，而不是每条规则独立灰度。因为规则之间可能有依赖关系，单独灰度一条可能反而制造出不一致的中间状态。

提示：规则变更记录里建议加一栏“变更原因”。看起来是形式主义，但在半年后有人问“这条规则为什么这么写”的时候，这一栏能救命。我现在的做法是变更原因必须写到可复现的程度，比如“因某次对账差异，新增金额上限校验，上限取近三个月单笔最大值的 1.2 倍”。

4. 规则失效的六种典型现场与排查路径

规则失效很少以“报错”的形式出现，它更多时候是静悄悄地不生效，直到某个事故把它掀出来。这一章把我在实际项目里遇到过的典型情况整理一下，配一张速查表，方便你在出问题时快速定位方向。

4.1 规则膨胀：当规则多到没人看得懂

第一个失效原因是数量失控。规则从十条涨到一百条，再涨到五百条，每条看起来都合理，但没人知道整体是什么样。这种情况下，规则之间开始互相干扰，新加一条规则可能导致老规则永远不命中。更糟的是没人敢删规则，因为不知道删了会影响什么。

判断是否已经膨胀，看三个数：规则总数、近三个月新增数、近三个月删除数。如果新增远大于删除，而且总数超过某个你团队能维护的量级，比如人均超过三十条，那就是膨胀了。我的处理办法是给规则打标签，按业务域分组，每个业务域指定一个 owner，owner 对本域的规则数量和规则效果负责。同时强制要求每条规则必须有关联的监控指标，没有指标说明它从来没被验证过，直接标记为待清理。

4.2 规则腐化：环境变了，规则没变

第二个原因是规则与环境脱节。业务规则里的阈值是按当时的业务量定的，用户分层是按当时的数据分布分的，过了一年这些前提全变了，规则还在原地。这种腐化最隐蔽，因为规则看起来在正常工作，只是它保护的东西已经不对了。

我会定期做一件事：把每条规则近三个月的命中次数拉出来。命中次数为零的规则，要么是它保护的问题已经不存在了，要么是它的条件写错了永远不会命中，两种情况都需要处理。命中次数异常高的规则也要看，可能是阈值定得太松，也可能是上游出了问题导致大量请求落进这个规则。这两个极端都是信号。

4.3 常见问题速查表

这张表我建议直接放进团队的排查手册里。规则类问题的排查思路和普通代码 bug 不太一样，普通 bug 看堆栈就能定位，规则问题往往没有堆栈，只有“结果不对”这个现象，所以排查顺序很重要：先确认规则是否被加载，再确认条件是否求值为真，再确认动作是否执行，最后确认执行结果有没有被后续逻辑覆盖。四步走下来，绝大多数问题都能定位。

5. 规则的度量、退役与长期维护

规则加上去容易，让它长期有效很难。这一章聊两个容易被忽略的环节：怎么用指标衡量规则的质量，怎么让规则有序退役。

5.1 三个核心指标：命中率、误杀率、覆盖率

规则的质量不能靠感觉判断，得看数。我一般盯三个指标。命中率是规则触发次数除以进入规则的请求总数，它反映规则的活跃程度，太低说明规则可能失效，太高说明规则可能过宽。误杀率需要人工抽检被规则拦下的样本，估算其中有百分之多少是本该放行的，这个指标最难拿但最有价值，它直接对应业务损失。覆盖率是指规则覆盖的业务场景占全部场景的比例，它回答的是“还有多少场景是裸奔的”。

这三个指标的组合能说明很多问题。命中率高但误杀率也高，说明阈值定得太激进，需要放宽。命中率低但覆盖率也低，说明规则设计偏了，保护的不是关键路径。理想状态是覆盖率逐步上升，命中率保持在一个合理区间，误杀率持续下降。这个趋势比单点数值更重要。

实际操作上，误杀率不可能天天人工抽检，我会做成抽样机制：每天随机抽 50 条被拦截样本，推给对应的业务 owner 标注，标注结果汇总成周报。这个机制刚开始推行会有点阻力，但坚持两个月之后，团队对规则的信心会明显不一样，因为大家知道规则是有人在看着的。

5.2 退役机制：规则要有保质期

一条规则如果没有明确的退役条件，它就会永远留在系统里。我的做法是给每条规则加两个字段：复核日期和退役条件。复核日期到了，owner 必须确认这条规则是否还有效，无效就停用，有效就延到下一个周期。退役条件写清楚什么情况下这条规则可以下线，比如“该业务线下线后同步停用”、“当某指标连续三个月为零时停用”。

这个机制看起来增加了管理成本，但它换来的是规则集合的整洁。我见过一个规则表，三年没人清理，五百多条规则里有近一半从来没命中过，但因为没人敢删，它们就一直占着位置，让真正重要的规则淹没在里面。规则系统的价值不取决于它有多少条规则，而取决于它有多少条正在有效工作的规则。

注意：停用规则和删除规则要分开。停用是可逆的，保留历史记录和版本；删除是不可逆的，只在确认规则完全无用且不占资源的情况下才做。大部分情况下停用就够了，没必要追求物理删除。

最后分享一个我自己的做法。我在每个项目的规则模块里放了一个“规则清单”文件，用最简单的表格维护，每条规则一行，包含 id、作用一句话、owner、复核日期、近三个月命中数。这个文件不追求格式漂亮，但要求每次改规则必须同步更新。它的作用不是给别人看，而是逼自己在加规则之前想清楚：这条规则到底解决什么问题，半年后还有没有人记得它为什么存在。

踩过几次坑之后我越来越确信一件事：规则的价值不在于写得多全，而在于每一条都有人负责、有据可查、有数可验。写一条能被执行、能被测试、能被度量、能被退役的规则，比写十条挂在文档里没人看的规范，有用得多。