一个做潮玩盲盒的客户在新品首发日出了事故：一百二十件的限量款卖出一百五十七单，平台赔付加口碑损失，一个首发日的利润全搭进去还倒贴。商城小程序开发的库存模块，平时看着人畜无害，并发一来全靠之前布的防线。
扣库存的时机，三种选法三种命
下单减库存、支付减库存、预占减库存，三种方式的坑各不相同。下单即减，占着不付款会憋死库存；支付才减，并发时必超卖；稳的是预占方案——下单先锁库存，十五分钟未付款自动释放。锁定的窗口期别设太长，三十分钟以上的预占在大促等于敞开大门让人占坑。所有库存变动走同一个入口，禁止不同模块各改各的数，见过客服后台和商城前台两边扣减打架的，库存永远对不上账。
并发场景的几道闸门
真到几百人同时抢一件商品，靠数据库慢慢排队是来不及的：
- 热点商品库存放进缓存，读写走内存，数据库只做最终落账
- 请求进队列依次处理，多出来的请求明确返回稍后再试，别让它们全砸到数据库上
- 扣减操作加锁或用原子指令，同一件商品不会算出两个可售数
- 前端按钮点击后置灰，防止手抖连点生成多张订单
这些话对非技术出身的人偏硬，翻译一下：上线前让开发方做一次模拟抢购测试，两百个虚拟账号同时下单一件库存一百的商品，最终成交数必须等于一百，多一单都不行，少一单也是事故。这个测试通不过，别的都白谈。
退款回补和对账兜底
超卖防线的后半段常被忽略：退款订单的库存要不要自动回补、什么时候回补，规则要在后台定清楚，尤其是预售和换货场景，回补时机错了照样出乱子。库存数字每天固定时间核对一次，核对的人别和操作的人是同一个，自己查自己，错永远看不出来。每日对账是最后一道网——后台可售数、数据库库存数、实际发货数三方核对，差异单当天查清。商城小程序开发交付时把对账报表列为标配，比出事后再人工拉Excel强十倍。那个潮玩客户后来加了每日对账，第二个月就抓出一批刷单占用库存的异常单，堵的都是钱。
两条建议：限量款和爆款首发，宁可少放两成库存也别顶格放，留出容错空间；每次大活动前把抢购模拟测试跑一遍，通过报告留档。比格网络给商城项目交付，超卖模拟测试是验收必过项，库存数字对不上，别的功能做得再漂亮都是空谈。
