优惠券打码可以跳数

去年秋天，优惠我在一个做本地生活的券打朋友那里喝茶。他手机响了，跳数看了一眼，优惠骂了句脏话。券打我问怎么了，跳数他把屏幕翻过来——后台显示，优惠一张满100减30的券打券，在凌晨两点被连续核销了47次。跳数同一个账号，优惠同一家店，券打间隔不到三秒。跳数

这就是优惠“打码跳数”。

说白了，券打优惠券的跳数核销码本来应该是一一对应的。你领了券，到店消费，商家扫你的码，系统确认，券失效，钱结算。但有人发现，在核销请求发出去和系统回写状态之间，有个时间差。这个窗口很短，几十毫秒到几百毫秒不等。如果在这个窗口里，把同一个码同时发给多个核销终端，或者用脚本高频轮询，系统就可能重复计数。券只领了一张，但后台显示的核销次数可以跳到几十甚至上百。

我后来专门找做风控的人聊过。他说这事不新鲜，早年电商大促的满减券就有类似漏洞。原理不复杂：核销接口没有做幂等，或者幂等键设计有缺陷。幂等这个词听着技术，翻译成人话就是——同一个请求发一百遍，系统只认一遍。没做这个，就等于门没锁。

但真正让我觉得离谱的，是另一件事。

有个做餐饮的老板，店不大，上了某平台的外卖。平台业务员让他参加“满50减20”的活动，说能拉新。他参加了。头一个星期，订单涨了不少，他挺高兴。月底对账，发现平台补贴的钱对不上。一查，有十几张券的核销记录集中在同一天，但那天他店里根本没那么多单。他打电话给平台客服，客服说系统显示正常核销。他让客服调监控时间戳，客服说调不了。

他后来自己琢磨明白了。有人领了券，把核销码截图发到群里，群里有“代下单”的人，用脚本批量核销。商家看到的订单是假的，但平台按核销记录结算补贴。钱进了谁的口袋？不知道。商家没拿到，平台说已经出了，那钱去哪了？

这事最麻烦的地方在于，它不像盗刷银行卡那样有明确的受害者报警。商家觉得没损失——反正券是平台补贴的。平台觉得没损失——补贴预算本来就是花出去的。但整个池子里的钱，被跳出来的那些“数”稀释了。真正该拿到补贴的消费者，可能因为预算提前耗尽，后面领不到券了。

我见过一个技术方案，说是在核销接口加分布式锁，再配合Redis的原子操作。听起来能解决。但问题是，很多中小平台的技术栈根本撑不住高并发下的锁竞争，加锁之后核销超时率飙升，商家扫半天没反应，体验直接崩了。所以有些团队明知道有漏洞，也选择先扛着——等量级上来了再重构。

这就成了一个死循环。量小的时候不值得修，量大的时候修不动。

还有个细节。那些打码跳数的脚本，很多不是黑客写的。就是普通运营人员，用按键精灵或者Python的requests库，几十行代码。他们甚至不觉得自己在攻击系统，只觉得是在“薅羊毛”。有个被抓的，审讯时说自己只是“测试一下平台的技术水平”。

平台后来怎么处理的？我朋友那家店，最后平台把异常核销的补贴扣回去了，还罚了商家一笔“违规操作”的钱。商家不服，说我是受害者。平台说，你的核销终端没有做设备绑定，也有责任。

扯皮到现在还没结束。

所以你看，优惠券打码跳数这件事，表面是技术漏洞，底下是利益分配。修接口容易，修人心难。只要补贴还在发，就总有人盯着那个时间差。几十毫秒，够干很多事了。

(责任编辑：休闲)