库存模型：扣库存的三种时机

代价不对称的两种错误

库存管理的两种错误，代价完全不对称：超卖——卖出 82 台只有 50 台货，违约、赔付、订单取消、舆情发酵，平台信用受损；少卖——本来能卖 50 台只卖了 48 台，少赚两台的利润，仅此而已。宁可少卖，不能超卖——这条不对称原则贯穿所有库存方案的设计。但少卖多了也是事故：活动结束还剩 30 台没放出来，同样是事故级别的舆情。目标态是：不超卖，尽量不少卖。

下单减库存：防超卖最强，怕占坑

下单即扣库存，订单与库存同生共死：防超卖最彻底，扣减成功才有订单；缺点是库存被"占"——下单不付款的用户会长期占着库存，恶意脚本批量下单更能把库存占空，真买家反而抢不到。适合意向强烈、下单即买定离手的场景，或者配合限购与订单超时回收使用。

支付减库存：体验最好，怕超卖

支付成功才扣库存：下单时只校验不锁定，付款瞬间才真正扣减。下单零门槛，转化率最高；但支付那一刻才发现没库存，就是支付超卖——用户付了钱没货，比下单失败恶劣十倍。适合库存宽裕的常态销售，不适合秒杀：秒杀的库存是极稀缺的确定值，支付校验拦截率会很高，体验崩塌。

预扣加超时回补：折中的主流答案

把两者折中：下单时预扣库存，生成待支付订单，限时（如 15 分钟）不支付则关单回补。防超卖接近下单减（预扣即锁定），占坑风险靠超时回补化解，转化体验接近支付减（下单顺畅）。代价是复杂度：要有关单机制、回补机制、两者的幂等与竞态处理——这三件事，正是后面几篇的内容。

秒杀的答案：预扣

秒杀场景选定预扣模式后，还有最后一个问题：预扣动作放在哪执行？数据库预扣——就是开篇事故里被打满的热点行，锁竞争扛不住；Redis 预扣——内存原子操作，单实例十万级 QPS，是数量级的跃迁。链路定型为：Redis 预扣资格 → 扣成功才发消息 → 异步落库成单 → 超时未支付关单回补。下一篇就把这条链路的核心——Lua 原子扣减的完整实现——拆开讲。