凌晨两点，业务我盯着屏幕上那串订单号，逻辑漏洞后背发凉。业务一个价值1999元的逻辑漏洞商品，被同一个账号用同一张优惠券买了47次。业务优惠券规则写得清清楚楚：每人限用一次。逻辑漏洞系统也确实只发了一张券。业务但没人想到，逻辑漏洞用户把商品加入购物车，业务结算时用券，逻辑漏洞支付前取消订单——再结算，业务券又回来了。逻辑漏洞

这不是业务bug，是逻辑漏洞业务逻辑的漏洞。代码没报错，业务数据库没异常，安全扫描器也检测不到。它藏在规则与规则的缝隙里，像水渗过砖墙的细缝，悄无声息。

我见过最蠢的漏洞，是某电商平台的积分兑换。规则是“消费1元积1分，100分换1元红包”。精明的用户发现，买100元的商品退货，积分不退；再用积分换红包，红包能提现。一来一回，净赚100。平台亏了三个月才反应过来，但那时候，羊毛党已经用脚本刷了上万次。

这类漏洞有个共同点：它们不攻击系统，而是攻击“信任”。系统信任“取消订单会回滚优惠券”，所以没做次数限制；系统信任“退货会撤销积分”，所以没做逆向校验。程序员写代码时，默认用户是守规矩的，但现实里总有人把规则翻来覆去地揉搓，直到揉出油来。

有个朋友做支付接口，他讲过更邪门的——转账金额填负数。银行系统校验了金额是否大于零，但没校验“负数是否被允许”。有人试着转了-1元，结果账户余额反而增加了1元。这听起来像段子，但2018年某银行真的出过类似事故，虽然很快被修复，可那笔“负转账”的记录到现在还挂在内部审计的档案里。

为什么这类漏洞防不胜防？因为安全团队盯着“攻击面”，而业务逻辑漏洞藏在“业务流”里。攻击面是墙上的门，业务流是墙里的管道。门焊死了，管道却七拐八绕，总有一截没包好。

我后来复盘那个优惠券漏洞，发现根因特别简单：系统把“领取”和“使用”当成两个独立事件，忽略了它们之间的状态流转。领取时校验了用户资格，使用时却只校验券的有效性。取消订单把券退回“可用”状态，但没重新校验“是否已超过使用次数”。

修复也容易——给每张券加个“已使用次数”字段，超过1次就作废。但难的是发现它。那晚我盯着订单列表，突然意识到：47次下单，每次都走完了完整的支付流程，只是最后一步取消。这行为模式太规律了，规律到像机器在操作。但机器不会累，人也不会觉得“取消47次”有什么问题——毕竟每次都是合法操作。

业务逻辑漏洞的可怕之处就在这：它不触发任何警报，因为每一步都合规。它像慢性毒药，等发现时，账户里的钱早被搬空了。我见过最狠的案例，是某P2P平台的“邀请返利”——邀请好友注册，双方各得50元。有人注册了5000个虚拟账号，用接码平台收验证码，一天赚了25万。平台发现时，活动已经上线两周。

技术能解决“能不能”的问题，但“该不该”得靠业务规则补。可惜很多团队把规则写在PRD里，没写进代码里。PRD说“每人限一次”，代码只实现了“每账号限一次”。人和账号之间，隔着一层“身份认证”的信任，而这层信任，恰恰是最容易撕破的纸。

那晚之后，我养成了个习惯：每次上线新功能，先问自己三个问题——如果用户重复操作会怎样？如果用户跳过某一步会怎样？如果用户同时操作两个账号会怎样？这些问题听着傻，但真能逼出漏洞。毕竟，代码不会撒谎，撒谎的永远是人对规则的想象。