先说结论：商城不是"能下单"就行，商品和订单模型要先设计

我们讲支付对账时，重点在"钱怎么算清"。但钱之前还有一层——商品和订单的骨架。很多商城后面越改越乱，根子在起步时没把商品、库存、购物车、订单、优惠这些模型想清楚，全靠打补丁。这篇把商城核心模块怎么梳理讲清，是需求阶段就该定的。

商品和 SKU 该怎么设计？规格、库存、价格

商品模型是商城的地基：

  • SPU 与 SKU 分开：一个商品（SPU，如"某款T恤"）下有多个规格（SKU，如"红色/L码"），价格、库存、图片都挂在 SKU 上，别混成一个"商品"；
  • 库存挂 SKU：库存要精确到规格，否则超卖、错发全是它惹的；
  • 价格分层：原价、售价、会员价、活动价分清楚，别让多个价格互相覆盖。

商品模型错了，后面下单、对账、售后全跟着错。我们做商城类项目时，会先把商品-SKU-库存模型画清楚再动手，这是后面所有功能的地基。

购物车和下单流程，有哪些容易翻车的点？

从加购到支付，几个高频坑：

  • 价格时效：加购时的价，结算时要重新校验，别让用户按旧价下单；
  • 库存锁定：下单后要锁库存、超时未付要释放，否则库存被占死；
  • 金额重算：运费、优惠都在服务端重算，不能信前端传来的总价——这和我们讲系统对接时强调的"服务端权威"是同一回事；
  • 重复提交：连点两下不能出两单，幂等要做。

下单链路是"钱相关"的链路，容不得前端说了算。我们讲支付对账、讲幂等，都是保这条链路不出错。

优惠券、满减、秒杀这些营销工具，怎么设计不打架？

营销工具一多就容易互相打架：

  • 叠加规则先说清：哪些能叠加、哪些互斥，规则要明确，别让用户凑半天发现用不了；
  • 服务端算价：优惠怎么抵、门槛怎么算，全在服务端算，前端只展示；
  • 高并发场景（秒杀）单独设计：秒杀是瞬时流量，库存、限购、防刷要单独扛，不能和普通下单混一套。

营销工具的本意是促单，规则混乱反而赶客。我们讲裂变、讲会员时强调"规则一眼看懂"，优惠叠加同理——越简单越有效。如果你要做商城、又担心商品和订单模型埋雷，把业务说给我们，方案评估免费——我们帮你先把骨架画对，再谈怎么长。