商城类小程序的技术难点，多数不在界面，而在规格与库存。这部分设计错了，后续改起来要动数据，代价很高。
一、先把概念分清楚
| 概念 | 含义 | 举例 |
|---|---|---|
| 商品 SPU | 一个商品 | "纯棉T恤" |
| 规格 | 商品的可选维度 | 颜色、尺码 |
| SKU | 规格组合后的最小可售单位 | "白色 L 码" |
| 库存 | 按 SKU 计数，不是按商品 | "白色 L 码" 剩 5 件 |
二、SKU 生成的两个要点
- 不是所有组合都有效：白色可能没有 L 码，所以要有"组合是否可选"的开关
- 每个 SKU 要有独立的价格与库存：不同规格不同价是常态，不能只用一个商品价
- 建议上限：规格维度控制在 2～3 个，组合数几十个以内；组合过多会让用户挑花眼，后台也难维护
三、库存扣减的时机
| 方案 | 优点 | 风险 |
|---|---|---|
| 下单即扣 | 不会超卖 | 恶意下单会占库存，需要超时自动释放 |
| 支付后扣 | 不占库存 | 并发下单可能超卖，需额外校验 |
| 下单锁定 + 超时释放 | 兼顾两者（推荐） | 需实现超时任务，逻辑稍复杂 |
推荐第三种：下单锁定库存、15 分钟未支付自动释放。这是电商里最常见也最稳妥的做法。
四、下单时要做的一致性校验
- 下单瞬间再校验一次库存（不能只信加入购物车时的结果）
- 价格以服务端计算为准，不要信任前端传来的金额
- 同一用户同一商品限制重复提交（幂等）
- 库存不足时明确提示是哪一项缺货，并保留用户已选内容
五、常见坑
- 只在前端判断库存，并发时超卖
- 把库存记在商品上而不是 SKU 上，多规格商品必然出错
- 退款/取消后没有回补库存
- 组合商品（套装）没有拆解子商品库存
提醒：上线前做一次并发下单测试：用 10 个账号同时抢同一款最后 1 件商品。这个测试能一次性暴露绝大多数库存设计问题。