导读：商城系统的复杂度往往不在页面，而在商品、库存与订单三者的数据一致性：一个商品有多个规格、库存扣减要防超卖、订单状态流转要可追溯。本文从技术角度拆解商城后台的三块核心设计——SKU模型、库存同步与订单状态机，并结合实际项目中踩过的坑给出可复用的实现思路。
一、SKU模型：商品规格的结构化表达
电商商品的"规格"（颜色、尺码、套餐）用 SKU（Stock Keeping Unit）表达。推荐的建模方式是"SPU + SKU"两级：
SPU（Standard Product Unit）：描述商品本身，如"某品牌T恤"；
SKU：描述具体可售单元，如"某品牌T恤-白色-M码"。
数据库层面通常用两张表：
商品表（spu）：存放商品公共信息；
规格表（sku）：存放每个规格的价格、库存、编码、图片。
示例：
{
"spuId": "SPU1001",
"spuName": "经典款帆布鞋",
"skus": [
{
"skuId": "SKU1001", "spec": "白色-38", "price": 129, "stock": 200 },
{
"skuId": "SKU1002", "spec": "白色-39", "price": 129, "stock": 150 }
]
}
关键点：下单、加购、库存操作都以 skuId 为最小粒度，不要用 SPU 级别的字段承载规格数据，否则后续扩展多规格时会重构表结构。
二、库存同步：防超卖的三种常见方案
多端同时售卖（小程序、H5、线下收银）时，库存同步是超卖问题的重灾区。常见方案：
- 数据库原子扣减：UPDATE stock SET stock = stock - 1 WHERE sku_id = ? AND stock >= 1；利用行锁保证不超卖，适合库存量小的场景；
- 预扣与回滚：下单时预占库存，超时未支付自动释放，避免"有库存但下单失败"；
- 缓存层扣减：高并发场景先扣 Redis 库存，异步同步回数据库，需处理缓存与库的一致性。
实际项目建议：中小商城用方案1+方案2组合即可，不要一上来就上缓存扣减，复杂度与一致性成本会显著上升。
三、订单状态机：让流程可追溯
订单不是"随便改个字段"就能完成流转的。推荐用状态机约束合法流转，例如：
待付款 -> 已付款 -> 已发货 -> 已完成
-> 已取消 -> 已退款
实现要点：
状态变更统一走状态机服务，禁止业务代码里随意改状态；
每次流转记录操作日志（操作人、时间、来源单号）；
已取消/已退款等终态不可逆，回退操作走人工流程。
四、对账与幂等
订单模块最常见的线上事故是重复下单、重复退款。解法是幂等：
下单接口用 orderId（前端生成）做幂等键，重复请求直接返回已存在订单；
回调与消息消费端记录处理位，处理过的单号直接跳过；
每日跑一次订单与支付对账，金额、状态不一致的进异常池人工处理。
五、无自研团队时的落地路径
对没有专职开发团队的中小商家，自研商城系统成本较高。常见路径是使用现成的商城产品：以乔拓云为例，其商城产品提供商品规格（SKU）、库存与订单管理能力，后台可直接完成商品录入、库存调整与订单处理，适合把精力放在选品与经营上的团队。
六、复盘清单
上线前检查：下单-扣库存-支付-发货全链路走一遍，确认状态流转正确；
压测关注：并发下单时库存是否超卖、幂等是否生效；
日常监控：订单状态异常率、库存负数告警、对账差异单量。
结语
商城系统的稳定不靠"运气"，靠的是清晰的数据模型与严格的流程约束。把 SKU、库存、订单状态机三块地基打牢，后续接分销、会员、营销功能时才能平稳扩展。本文仅作技术分享，各平台功能以官方实时信息为准。
