商品中心怎么设计？一次讲清 SPU、SKU、类目、属性、上下架与索引建模

商品中心怎么设计？一次讲清 SPU、SKU、类目、属性、上下架与索引建模

大家好，我是一名有 4 年工作经验的 Java 后端开发。
商品中心几乎是电商系统的基础盘，很多后续问题其实都和商品模型有没有设计稳直接相关。
这篇文章我想系统聊一聊商品中心到底应该怎么设计。

🦅个人主页
🐼

一、商品中心到底在管什么

很多人会把商品中心理解成：

• 商品表
• 类目表

其实远不止这些。

商品中心通常要管理：

• SPU / SKU
• 类目
• 品牌
• 属性
• 销售属性
• 图文详情
• 上下架状态
• 搜索索引字段

也就是说：

商品中心不是一张商品表，而是一整套商品主数据系统。

二、SPU 和 SKU 一定要分清

2.1 SPU

更像标准商品抽象。

例如：

• iPhone 16 128G

2.2 SKU

更像具体可售卖单元。

例如：

• iPhone 16 黑色 128G 国行版

很多系统一开始不拆，后面规格一多就很痛苦。

三、推荐拆分的核心模型

至少建议有这些：

• spu
• sku
• category
• brand
• product_attr
• sku_sale_attr

这样后面：

• 搜索
• 库存
• 价格
• 购物车

才比较容易接。

四、商品状态怎么设计

商品通常建议至少拆：

• 草稿
• 待审核
• 已上架
• 已下架
• 已删除

而且：

• SPU 状态
• SKU 可售状态

有时也要分开。

五、最容易踩的坑

5.1 SPU 和 SKU 不分

后面规格、库存、价格都会乱。

5.2 属性体系没抽象

类目扩展会越来越痛苦。

5.3 搜索字段和商品字段完全耦合

后面 ES 同步和商品变更会很乱。

5.4 上下架状态设计太简单

审核、禁售、库存售罄等状态很难表达。

六、面试中怎么回答

如果面试官问你：

商品中心一般怎么设计？

你可以这样回答：

第一，我会先把商品中心理解成主数据系统，而不是一张商品表，所以至少会拆出 SPU、SKU、类目、品牌、属性和销售属性这些核心模型。

第二，SPU 和 SKU 我一定会分清，因为 SPU 更偏标准商品抽象，SKU 才是实际可售卖单元，价格、库存、购物车、订单通常都更依赖 SKU。

第三，商品状态我不会只设计成简单的上下架，而会结合草稿、待审核、已上架、已下架、已删除等业务状态一起建模，必要时 SPU 和 SKU 状态也会拆开。

七、总结

商品中心真正难的，不是表多，而是如何让：

• 模型稳定
• 后续业务好接
• 搜索库存价格都能自然接入

如果只记一句结论，我觉得可以记住这句：

商品中心最怕一开始图省事，真正稳的设计一定是先把 SPU、SKU、属性和状态边界拆清楚。

八、结尾

如果你觉得这篇文章对你有帮助，欢迎点赞、收藏、关注。
后面我会继续整理一些更偏实战的 Java 后端和电商系统设计文章，尽量少写空泛概念，多写真实项目里会踩到的坑。