电商后台系统，首先得有“商品”，才能开门做生意，对吧？所以这一篇，我想聊聊商品管理模块。
我手头这个项目，面临的现状是，没有统一的商品管理机制。什么意思呢？我们承接App商城的订单系统，本身具备一定的商品管理能力（上下架、管理前台库存）；订单系统将订单同步给ERP后，ERP生成自己的销售订单，ERP本身也得管理一套商品的命名、编码、库存等信息；我们还有其他对外销售入口，这些入口也有自己的商品管理后台。
这种分散管理机制会导致什么后果呢？我就举个最简单的例子吧。只要某个系统中改了一个商品名字，与ERP之间的订单同步就会出错。有时候，这种问题挺令人哭笑不得的。
为了解决上面提到的这些问题，我们决定在新的后台系统中，用一个专门的模块来管理商品。其他模块/系统凡是需要用到商品基本信息的（如商品名称编号、规格等），都从这个模块来调用即可。
我之前也没有很深入了解过电商的运行机制，借这次项目的契机，便好好调研了一番，恶补了许多基础知识。其中，就包括SPU与SKU的区别问题。
我发现，我司的电商销售模式是没有SPU概念的，纯粹是一个个的单品。虽然我司上架的商品种类不算多，不过也有典型的适合SPU/SKU模式的商品，如服装（有很多尺码）。既然是重新做一个系统，那么，现代电商的先进经验，咱们总得借鉴一番对吧。
关于SPU/SKU的概念，我这里就不多废话了，相关知识，感兴趣的可以自行Google。SKU是靠规格/属性与SPU关联起来的。至于什么是规格，什么是属性，一开始我看了很多文章，各家有各家的说法，例如有人区分为销售和非销售属性，有人区分为基础和非基础属性，看得我头都大了。静下心来对比一番后发现，叫什么名称不重要，重要的是你得能理解SKU区别于SPU的本质所在。
一句话总结：凡是能够区分和影响商品的价格和库存的指标，就是决定SKU定义的关键指标。
怎么理解？以手机这种商品为例，通常来说，颜色、运行内存和储存内存，决定了某款手机（SPU）到底有多少种型号（SKU）。例如，iPhone 8 Plus是一种SPU，其中，银色64G版本和银色256G版本，显然价格是不一样的，可以认为是两种SKU。
所以呢，我们现在可以很容易地理解各种术语了：
- 规格：决定SKU定义的指标
- 属性：“规格”之外都可以称之为属性
说个题外话，由于前端研发资源的欠缺，我们在做SKU规格的创建时，挺费劲的，最后勉强实现了。在数学上，这玩意儿叫做“笛卡尔积”。当时我在网上发现很多人提及当年淘宝UED官网的一篇文章《sku组合查询算法探索》，但是官网已经消失了，还好我通过强大的Google发现了原作者的新窝，原文可以参考这里 。
电商系统中，有个重要的概念叫做“类目”，也就是商品的分类。大的电商公司，前后台类目是有区分的，中小电商就不一定了，有可能前后台保持一致的类目。据说，这种前后台类目的管理方式，是从实体零售行业获得的灵感。以沃尔玛为例，后台仓库的商品分类肯定是在一个时期内不会有太大变动的，但是前台（超市店面内）的商品摆放分类却会经常变动。前后台类目通过人为的映射，关联起来。
在商品管理模块，可以单独控制每个SKU的上下架，以及前台库存（人为设定的可销售库存）。就我司的实际情况来说，商品类目没有那么多，除了基本的商品描述外，也没有多少需要精细控制的内容了。
商品的统一管理是基础中的基础。做好了这个模块，我们才能做采购、销售和库存的功能。