Sku在电商产品里指的是商品的最小贩卖单位，例如一件衣服，选择颜色和尺码后就确定的商品的唯一性（平台型产品还需要和店铺属性关联）。在产品框架中，sku功能模块不算小，需要产品分类和属性库等功能支持，所以在产品初期，很多情况，我们并没有做sku功能。而当商品的数量增加，业务上需要扩展大量商家（供应商）时，sku功能便变的不可或缺了。
Sku功能设计，需要Sku（销售）属性的支持，例如前面提到的衣服，颜色和尺码就是衣服的Sku属性，这些属性对用户的购买商品的唯一性和商品价格起着重要的作用，而不同种类的商品，确定唯一性的属性不同，如果Sku属性直接和商品关联，会带来两个结果：添加Sku属性的同学会把PM的全家问候个遍，后端的开发同学会让PM看不到第二天的太阳。和单个商品关联不仅操作繁琐而且数据冗余，简单解释下后者，Sku属性直接和商品关联，会造成衣服A和衣服B本来仅用颜色和尺码两个属性就可以满足需求，实际上却需要A的颜色，A的尺码和B的颜色，B的尺码四个属性才满足需求。所以属性和（叶子）类别挂钩，实际上就是把衣服A和衣服B都用到的颜色和尺码属性挂靠在叶子类别上，以实现属性的简洁。
先谈商品的类别模块，再谈Sku模块和类别模块的关系。商品的类别模块是电商产品中的重要一环，商品需要被条理清晰地分类，然后被管理，被展示，和属性关联优化搜索等。由此可见，分类模块是电商产品的基石之一。通常我们从业务的角度去划分，把商品划分为2-3级，以三级分类结构为例，一级分类下有二级分类，二级分类下有属于自己的三级分类，而三级分类就属于整个分类体系中不可再划分的类别，称之为叶子类别。属性挂靠在类别上，低级别的分类继承父级分类的属性。在一二级分类中，设置的属性通常为扩展属性，我们也可以认为是基本属性，通常为不影响产品价格，不确定产品唯一性的属性，例如产地，功效等属性，而sku属性挂靠叶子类别而不是其他类别，从两个角度思考，业务上，这个级别分类“颗粒度”正好，平衡了sku属性的简洁和灵活性，sku属性本来就是采纳笛卡尔积的形式，如果sku属性下又有sku属性，那么整个sku体系会显得臃肿。
以上，我们了解了什么是sku，sku该如何设计，那么原本是单品模式切换至sku模式时，我们该留意什么呢？
1，和商品相关的都会有变动，首当其冲的就是购物流程，我们从以前的购买单品转变为选择sku后再购买单品，从购买开始，到提交订单，到订单列表还有购物车，都会添加sku属性。
2，sku其实对价格体系影响很大，例如，商品有特卖价时，其实特卖价格数量也是程笛卡尔积的形式上升。所有的商品列表由展示单品转换为展示商品，以前可能一个价格就够用了，现在一个商品有多个sku，就有了价格区间。库存也没那么容易显示“已抢光”了，库存是和sku关联的，所以以前展示单品的时候，库存为零，很好展示“已抢光”图标，现在多个sku库存为0，商品列表的商品才算真正的“已抢光”，所以这时候要和开发同学，好好沟通下，“已抢光”好不好实现。
3，处理新老数据是个问题，以前的数据都是没有sku属性的，那么sku属性上线后，数据不做抽离等处理，那么老的数据基本作废，所以在开发过程中，先做好类别体系，再做属性，再处理数据，这样一步步来，才能保证业务正常运转。
4，版本发布是个大问题，客户端，后台，Api，像iOS上线需要7天审核，如果这7天审核的时间，Api和后台不上线，待审核的版本，将无法正常使用，肯定审核不过，如果Api和后台上线了，那么老版本的App将无法使用商品相关的功能，7天的时间不能下单，想想都是公司不能接受的，所以面对这样的情况，“切换”处理，是较好的方式，在某一个时间段内，老版本的App依旧用老接口，由老后台控制，使用老的数据，新版本的App，使用新的接口和新的后台，平滑使用一段时间后，在对后台和商品数据进行切换，达到最小损失。
