تسجيل الدخول الآن 做电商后台，不管从哪个模块切入，最后一定会回到商品上。之前聊过类目体系和属性库的搭建，但那更像是“基础设施”，真正的主角始终是商品。没有商品，交易就无从谈起。商品系统可以说是整个电商平台的底盘，几乎所有的业务都跑在商品数据上——从采购、入库、上架、前台展示，到下单、发货、签收、售后，每一步都绕不开它。
通常我们说的后台商品系统，至少包含类目管理、属性库、品牌管理，以及最核心的商品管理。商品管理本身又覆盖了发布商品、编辑、上下架、审核、价格库存设置、运费模板等一系列操作。这篇文章，就把商品管理这块彻底讲清楚。
做电商产品，有两个概念是绕不过去的：SPU和SKU。虽然前面文章里提过，但这里还是有必要掰开揉碎再说一遍。
SPU，标准产品单元，可以理解成“某一款商品”的抽象集合。它由一组关键属性来确定，能让人知道这是什么东西，但还没到具体能买到的那个颗粒。比如“iPhone X”就是一个SPU，品牌加型号就锁定了。
SKU则是库存量单位，是真正能出入库、能标价、能卖的最小单元。它需要用销售属性来进一步锁定，比如“iPhone X 128G 黑色”，就是一个SKU。用户在前台选规格，选完后才会看到对应的价格和库存，背后就是SKU在起作用。
大多数情况下，一个SPU下面会挂多个SKU，是一对多的关系。比如一款工装男鞋，SPU是“森马工装男鞋”，颜色和尺码就是销售属性，组合出“黄色 41码”这样的SKU。反过来，少数场景中也可能出现一个SKU对应多个SPU，比如同一双鞋，商家用两个不同的商品标题挂在店里，前台看是两个商品，后台其实对应同一个SKU编码。这种操作虽然少见，但确实存在。
还有一种更复杂的场景——组合商品。比如运动健身套装，有两件套、三件套，前台是一个商品，用户一单拍下，后台其实是用多个SKU虚拟组合成一个套装SKU，传到仓库再拆解成对应的实物SKU去扣减库存，最后打包发出去。这种逻辑听起来有点绕，但实际业务中挺常见。
把这些概念理清了，再去看商品管理，很多东西就顺了。可以说，前面做的所有类目和属性设计，都是在为商品管理铺路。商品管理本身，就是对这些商品做日常维护：新增、编辑、上下架、查库存、设运费等等。
发布商品时，第一步就是选择所属类目，系统会根据类目调用对应的属性模板，通过关键属性和销售属性自动生成SPU和SKU结构。不同平台对商品维度的管理思路不太一样，京东倾向于以SKU维度管理，切换规格时标题和详情会变；淘宝和天猫则更多以SPU维度管理，切换规格时标题和详情不变。这个设计差异会直接影响用户前台体验，没有绝对的好坏，主要看业务侧重点。
新发布的商品通常需要审核，尤其是平台型电商。为了控制商品质量，运营人员会介入审核流程，审核通过后才允许上架。审核流程一般包括提交、待审、通过或驳回、修改再提交这些环节，具体可以根据业务需要灵活调整。
商品信息拆开来看，涉及的内容挺多。首先是基本信息，比如类目、标题、品牌、商品条码、广告语等，这些是用户浏览时最先接触到的信息。其次是商品属性，前面文章里详细讲过，这里再概括一下：关键属性用来定SPU，销售属性（也叫规格属性）用来生成SKU，另外还有普通属性做补充描述，比如适用场景、材质等。有的团队还会根据业务拆出特殊属性、绑定属性，但核心逻辑就这几类。
然后是图文描述，主图、轮播图、活动图，再加上文字说明，这部分直接决定转化率，重要性不用多说。库存设置是针对每一个SKU的，需要分别填写价格和库存量。库存数据一般会同步WMS的实物库存，或者由运营手动设置活动库存。当某个SKU库存卖到零时，通常会自动下架，避免超卖。
支付信息这块，主要涉及付款方式和库存计数方式。付款方式有一次性付款、预售、货到付款等。预售就是先付定金，到时间再付尾款，这两年大促用得特别多。库存计数方式则分拍下减库存和付款减库存两种。拍下减库存能防止超卖，但容易被恶意占库存；付款减库存对用户更友好，但万一短时间内大量下单，商家可能发不出货，超卖风险就上来了。很多平台会针对不同活动或商品类型混合使用这两种策略，没有一种能包治百病。
物流信息一般直接关联运费模板，发布商品时选一个已经配置好的模板就行。运费模板通常按件数、重量或体积来计算，如果没合适的，就得先去物流系统里新建。售后服务也是一样，比如七天无理由退换、假一赔十这类承诺，在发布商品时就要勾选清楚，不同类目可选的服务项可能不同。
商品上架后，就会进入在售状态，没上架的就是待售商品。运营过程中，下架的情况五花八门，有系统自动下架的，比如违规、品牌授权到期、店铺迁移等；也有商家自己主动下架的，比如换季、调价、临时缺货。设计系统时，最好能把各种下架原因都枚举出来，这样运营就能根据原因快速定位问题，通知商家整改。
商品编辑和新增差不多，改完信息后系统会判断有没有触发重新审核的条件，如果触发了，就得再来一遍审核流程。至于删除，只能删还没卖过的商品，已经在售的商品不能直接删，这是基本的数据安全逻辑。
运费模板的设置入口，一般会直接放在商品管理模块里，方便操作。设置好之后，发布商品时直接调用，订单生成时自动计算运费，整个链条就串起来了。
商品状态流转，从新建开始，到待审核、审核通过、审核不通过，再到上架、下架，有些平台还会区分有效和无效状态。这些状态之间怎么跳转，最好一开始就画清楚，否则后面运营会乱，数据统计也会乱。
说到底，商品管理系统是电商平台的地基，所有上层业务都依赖它。刚开始做系统的时候，就要把每个模块的可扩展性规划好，尽量降低耦合度。如果前期图省事，把逻辑写死，等业务规模上来再想改，成本会高得吓人。地基打牢了，后面盖楼才稳。