做电商的老板基本都想上秒杀。限时、限量、低价，这三个词一摆出来，流量和订单确实能往上冲一冲。但秒杀这个功能看着简单，真做出来问题一大堆：库存超卖、重复下单、服务器卡死、有人用脚本刷单……今天左左就跟你聊聊，商城小程序里的秒杀功能，底层到底是怎么实现的，哪些地方容易踩坑。

秒杀的本质是什么

秒杀不是普通的下单。普通下单是用户看中了，慢慢填地址、选规格、付款，整个过程可能持续几分钟。秒杀是几千人同时盯着同一个商品，在某一秒同时点购买。这个并发量，是普通订单的几十倍甚至上百倍。

如果你的小程序后台还是普通的数据库更新逻辑，大概率会出两个问题：一是库存扣减不及时，卖完了还有人能下单，导致超卖；二是数据库连接被打满，整个系统卡死，连正常订单都下不了。

倒计时的技术实现

秒杀页面头上那个倒计时，看着就是一个数字在跳，但里面有几个细节要注意。

首先是时间同步。用户手机的时间可能不准，快个几分钟慢个几分钟很常见。如果你用用户本地时间来算倒计时，可能活动还没开始他就看到可以买了，或者活动结束了他还在等。正确的做法是以服务器时间为准，页面加载时从后端取一个服务器时间戳，然后用本地计时器来渲染，但基准是服务器时间。

其次是页面可见性。用户切到别的应用再切回来，倒计时要继续走，不能暂停。这里要用到 Page Visibility API，页面重新可见时重新校准一下时间。

还有一个体验细节：倒计时结束前，购买按钮应该是置灰的，不能点。但有些人会尝试在倒计时结束前疯狂点按钮，这时候前端要做好防抖，不要发无效请求到服务器。

库存扣减是核心难点

秒杀核心的技术挑战就是库存扣减。常见有三类方案，难度和效果逐级递增。

首先，数据库直接更新。用户下单时，UPDATE 库存表 SET 数量 = 数量 - 1 WHERE 数量 > 0。这种方案在并发量小的时候没问题，但人一多就会出现"幻读"，两个人同时读到库存还有1，都扣减成功，结果卖出去了2件，实际只有1件。这就是超卖。

其次，数据库加乐观锁。在库存记录上加一个版本号，每次扣减时检查版本号是否变化。如果变了，说明被别人先改了，这次扣减失败，返回给用户"已抢完"。这种方案能解决超卖，但大量请求会失败重试，数据库压力还是很大。

再者，用 Redis 做预扣库存。这是目前主流的方案。活动开始前，把库存数量写到 Redis 里。用户点击购买时，先走 Redis 的 DECR 命令扣减库存。Redis 是单线程的，天然不会有并发问题，扣减结果是原子性的。如果 Redis 返回库存已经小于0，直接告诉用户抢完了，根本不用走到数据库。

只有 Redis 扣减成功的那部分用户，才进入下一步：创建订单、锁定商品、引导支付。如果用户10分钟内没付款，再把库存回退到 Redis。这样既保证了不超卖，又大幅减轻了数据库压力。

防刷和限流

秒杀活动很容易招来羊毛党和脚本刷单人。你的秒杀商品如果利润率不错，一定会有人写脚本自动抢购。

基础的防护有几层。一是限流，对单个用户、单个IP在单位时间内的请求次数做限制。比如限制单个用户1秒内只能请求3次，超过就返回"操作频繁"。

二是验证码。在点击购买前弹出图形验证码或滑块验证，脚本很难自动过掉。不过验证码太复杂又会影响正常用户体验，所以要把握好度。

三是风控策略。比如新注册账号不能参加秒杀、同一收货地址短时间内多次下单要人工审核、异常IP段直接拉黑等。这些策略可以根据业务情况灵活配置。

支付超时回退

用户抢到商品后进支付页面，但可能一直不付款。这时候库存是被锁定的，别人买不了。如果锁太久，活动结束了还有大量库存被占用，就亏了。

一般的做法是设置支付超时时间，比如10分钟或15分钟。超时后自动取消订单，把库存回退。这个回退逻辑要和Redis预扣库存联动：数据库里订单状态改为"已取消"，同时 Redis 里的库存数量加回去。

这里要注意，回退操作也可能有并发问题。如果用户刚好在超时那一刻点击了付款，两边同时操作，可能出现钱付了但订单被取消的情况。解决办法是给订单加一个状态机：待支付、支付中、已支付、已取消。只有"待支付"状态才能被超时取消，进入"支付中"状态后就不能取消了。

给商家的建议

如果你的小程序日订单量不到100单，其实没必要做太复杂的秒杀系统，数据库乐观锁基本够用。但如果你经常搞活动，一次有几百人同时在线抢，那就必须把Redis预扣库存这套上了。

另外，秒杀商品的定价要算清楚账。很多商家把秒杀当成引流手段，价格压得很低，结果引来一堆羊毛党，真正有价值的客户没几个。建议秒杀商品选利润款而不是引流款，或者设置参与门槛，比如仅限会员购买、满多少金额才能参加。

秒杀功能做好了是利器，做不好就是给自己挖坑。先把底层逻辑搞明白，再决定上不上这个功能。

关注左左，你需要一个懂技术的朋友。