PowerDotNet平台化软件架构设计与实现系列（18）：商品管理平台

商品系统是电子商务的核心系统之一，是各种电商业务展开的基础和起点，没有调查就没有发言权，个人也深度参与设计开发和维护过商品系统，本文简单分享下PowerDotNet重写过的商品平台系统。

十多年前我刚入行，首次接触电商业务系统开发，开发重点集中在财务、库管、订单等这些需要后台强力支持的系统，反而对商品有个刻板印象，就是觉得商品系统简单，字典型应用而已，难度不大。

随着开发和填坑经验的累积以及业务知识面的扩大，从传统B2C到OTA到酒店到在线阅读再到生鲜电商，一路走来，当我真正独立设计实现过一次商品系统，才深刻意识到当初对商品的想法相当浅薄。

商品作为电商业务基础主数据，在中小公司可以抽象到基础数据平台中管理，个人工作过的公司就有这样处理的，不过大中型公司通常都会独立开发商品管理系统(CMS)，充分说明商品管理的重要性。

PowerDotNet的商品平台Power.Commodity目前已经重写完成，有时写的很挣扎，这可能和个人追求完美要从良好到更好再到更加好的自我要求有关，更可能是间隔过长看不懂自己的祖传代码，^_-。

想起代码大全里的话，大意是需求和设计文档都可能过时，而源代码往往是对软件的唯一精准描述，很多项目，程序员可以唯一得到的文档就是源代码本身。深度分析过祖传代码就能理解这话真是至理。

在实现商品系统的过程中，我也跟风热血沸腾激情澎湃用上了如日中天的AI工具，比如Cursor、Copilot、通义千问和DeepSeek等，人工智能果然厉害，因为我真有一堆祖传商品代码需要和AI交叉验证。

没有代码支撑的系统设计无异于镜花水月空中楼阁，可行性、可用性和稳定性都很可疑，Power.Commodity则建立在我个人实际工作过的商品系统代码基础之上，至少设计和实现都经受过生产环境考验。

商品系统建模相对还是比较简单的，但面对复杂的业务场景，为了满足业务需要不得不做出设计上的妥协，这种其实就是个性化需求，个人经历过的很多个性化商品需求在Power.Commodity都没有实现。

相对于传统的商品，个人也先后参与过服务商品、虚拟商品、汽车商品和生鲜商品的设计开发和维护工作，这四类商品有其不言而喻的特殊性和复杂度，一言以蔽之，通用性不足，本文只做一些概要说明。

本文介绍的商品只是个人经验中最经典和传统的商品模型，特殊商品我热血沸腾激情澎湃写了几周都不太满意就撤销了很多代码，工作量实在巨大，尽管如此，依然符合我们先写出来再说出来的务实风格。

环境准备

1、（必须）.Net Framework4.5+

2、（必须）关系型数据库MySQL或SqlServer或PostgreSQL或MariaDB四选一

3、（必须）PowerDotNet数据库管理平台

4、（必须）PowerDotNet配置中心Power.ConfigCenter

5、（必须）PowerDotNet注册中心Power.RegistryCenter

6、（必须）PowerDotNet缓存平台Power.Cache

7、（必须）PowerDotNet消息平台Power.Message

8、（必须）PowerDotNet文件平台Power.File

9、（必须）PowerDotNet人员管理平台Power.HCRM

10、（必须）PowerDotNet基础数据平台Power.BaseData

一、名词术语

商品可以认为是影响传统电商业务全局的基础数据，在供应链、仓库、门店、订单、支付、财务、结算、配送等业务端被广泛使用，对电商业务正常运营流转有举足轻重的作用。

所有的辩论，都是定义之争。作为给电商中的商品、渠道商品和货品都写过代码的资深开发，个人很熟悉不良商品设计给仓端、配端和财务等系统造成的问题，觉得有必要再明确商品的定义。

商品特别基础，但有些公司直到倒闭了，对商品概念还含糊不清，别问我怎么知道的，我就是知道，咩哈哈。本着发现问题，定义问题，解决问题的原则，本文争取把商品管理写个清楚明白。

职业生涯至今，有了些业务和技术积累，但在商品管理里经常碰到误把冯京作马凉的情况，反而是看上去盘根错节枝繁叶茂的支付、财务和CRM等系统处理起来更加得心应手融会贯通。

虽然个人有多年的电商开发经验，自认为也非常了解商品系统，什么产品、商品、货品、原料、辅料、SPU、SKU、渠道商品、属性、规格、参数、标签、包装方案、BOM等等都耳熟能详。

可是真要严格说出个所以然来，有些定义写出来真不那么让人信服，本文还是先对照着搜索引擎摘录一下，防止系统都做出来了，对基本概念还稀里糊涂的，让人觉得可靠性堪忧，咩哈哈。

1、商品

马克思主义政治经济学认为：人类劳动是最可贵的，它可以创造价值。这就是马克思主义在经济学里最出名的一个理论，即劳动价值论。

根据这个基础的理论，马克思给商品的定义是“商品是用来交换的劳动产品”。

一个物品要想成为商品必须满足两个条件：

（1）、它必须是劳动产品

一个物品要想成为商品它就必须是人类劳动的结晶，劳动创造价值，所有的商品都应该是人们劳动生产出来的，也就是说必须凝结了一定的人类劳动。

（2）、它必须是用于交换的

假如一件物品其本身只是凝结了人类劳动，但本身并没有用于交换，而只是用于自己消费，这种物品就算不上是商品，因为商品最大的外在表现形式在于交换。

商品的二重性

商品二重性是指商品具有使用价值和价值两重属性。商品是用来交换的劳动产品，具有使用价值和价值两种属性，商品是使用价值和价值的统一。

商品的有用性，即能够用来满足人们某种需要的属性，就是商品的使用价值。

凝结在商品中的一般人类劳动就是商品的价值，各种商品的价值，只有量的差别，而无质的不同。

价值存在于商品体内，是商品的社会属性，体现着商品生产者相互交换劳动的社会关系。

（1）、使用价值

商品要能够交换就必须有用，使用价值是物品能够满足人们某种需要的属性，它是商品的自然属性，是构成社会财富的物质内容，是人类社会赖以生存和发展的物质基础。它体现了人与自然的关系。使用价值本身并不是政治经济学的研究对象。马克思政治经济学之所以要考察使用价值，是因为商品的使用价值是其交换价值的物质承担者。一种物品要成为商品，仅有使用价值是不够的，它还必须是用来交换的，即具有交换价值。商品除具有使用价值外，还具有交换价值。交换价值是一种使用价值同另一种使用价值相交换的量的关系或比例。

（2）、价值

价值是凝结在商品中的无差别的一般人类劳动，它是商品的社会属性，也是商品所特有的属性，体现了商品生产者相互比较和交换劳动的经济关系。马克思主义揭示了劳动是价值的源泉。价值是一个历史的范畴。作为商品的二因素之一，价值是商品最本质的因素。

（3）使用价值和价值的关系

价值是使用价值的基础，使用价值是价值的表现形式。 

商品是使用价值和价值的矛盾统一体，使用价值和价值之间存在着对立统一的辩证关系。

首先，使用价值与价值是统一的。二者共处于一个统一体中，缺一就不成其为商品。价值的存在要以使用价值的存在为前提，没有使用价值的东西也就不会有价值；使用价值是价值的物质承担者，价值寓于使用价值之中。

其次，使用价值与价值又是不同的、矛盾的。

因为：第一，对同一商品生产者或消费者来说，同一商品的使用价值和价值不可兼得。商品生产者向消费者让渡使用价值以换取价值，消费者为得到使用价值而支付价值。

第二，使用价值是商品的自然属性，体现人与自然的关系；而价值是商品的社会属性，体现商品生产者之间的经济关系。 使用价值是一切有用物品包括商品所共有的属性，是永恒的范畴；价值是商品所特有的属性，是商品经济的范畴，因而是历史的范畴。

商品之所以具有使用价值和价值两个因素，是由于生产商品的劳动具有二重性。劳动二重性决定商品二因素，具体劳动创造使用价值，抽象劳动形成价值。 劳动二重性是商品二重性的根源。

2、SPU和SKU

（1）、SPU

SPU = Standard Product Unit （标准化产品单元）

SPU是商品信息聚合的最小单位，是一组可复用、易检索的标准化信息的集合，该集合描述了一个产品的特性。

（2）、SKU

SKU = Stock Keeping Unit(库存量单位)

SKU即库存进出计量的单位（买家购买、商家进货、供应商备货、工厂生产等都是依据SKU进行的），SKU是物理上不可分割的最小存货单元，也就是说一款商品，可以根据SKU来确定具体的货物存量。

（3）、异同

SPU和SKU都是一组属性名值对的大集合，一组相似SKU抽象出的公共集合的统称可以认为就是SPU，下面以一个通俗易懂的示例来直观理解SPU和SKU。

华为P50 Pro手机是一种SPU；生产于中国大陆基于鸿蒙操作系统于2021年上市的黑色机身内存128GB运行内存8GB...的华为P50 Pro手机是一个SKU。

可以看到一种商品SPU包含多种SKU，SPU（SKU1、SKU2……SKU n），且SKU唯一，具有详细属性规格参数的SPU就可以唯一定义一个SKU。

因为规格（属性或参数）的不同，SKU容易产生组合爆炸难题。以华为P50 Pro为例，关键规格有颜色（黑色、白色、银色、金色）、机身内存（128G、256G、512G），可以组合出4x3=12个SKU。

从市场交易的角度来说，SPU是一种抽象集合，是无形的，无法直接定价，虽然直观理解是有价值和使用价值的，但没有价格，不能被交易；而SKU有价值和使用价值，也有价格，可以进行买卖。

通常我们口头上所说的商品，其实可以直观理解为SKU。当然我们口头上说买了一部华为P50 Pro手机是不严谨的，应该说买了一部黑色机身内存128GB运行内存8GB...（其他属性）的华为P50 Pro手机。

特别提醒，商品、SKU和SPU是完全不同的三个独立概念，SPU到SKU再到商品，是从抽象逐步到具体的过程，商品模型决定了基本定义能否被严格区分，但现实开发中常有人把它们混用而不自知。

3、产品

产品是指被人们使用和消费，并能满足人们某种需求的任何东西，包括有形的物品、无形的服务、组织、观念或它们的组合。

在经济领域中，通常也可理解为组织制造的任何制品或制品的组合。在现代汉语词典当中的解释为“生产出来的物品”。

网上有很多文章将SPU说成是产品或者等价于产品，个人认为是不太严谨的，但是绝大多数电子商务环境下这么理解也是可以接受的。

产品一般可以分为五个层次，即核心产品、基本产品、期望产品、附加产品、潜在产品。

（1）、核心产品是指整体产品提供给购买者的直接利益和效用；

（2）、基本产品是指核心产品的宏观化；

（3）、期望产品是指顾客在购买产品时，一般会期望得到的一组特性或条件；

（4）、附加产品是指超过顾客期望的产品；

（5）、潜在产品是指产品或开发物在未来可能产生的改进和变革。

简单来说就是“为了满足市场需要，而创建的用于运营的功能及服务”就是产品。

在交换的时空场景、过程中，产品可以被称为商品，也就是说产品和商品是可以互相转换的。

产品和商品的主要区别：产品不论是交换前与交换后都可称为产品。而当一种产品经过买卖交换进入使用过程后，如果不存在交换场景中就不能再称之为商品，只能称为产品。当这个产品又在交换的场景中的时候，那么在这段即将发生买卖交换的时间空间内，它又能被称之为商品。商品是用于买卖交换前的产品，产品经过买卖交换进入使用阶段后就不能称为商品了，只能称为产品。

4、货品

货品，汉语词语，读音是huò pǐn，意思是货物；也指货物的品种。

百度百科里的这个2025年之前的（旧）解释真是坑爹，简直就和没解释一样。我们再来看看几个流行AI工具对货品的定义是什么样的。

（1）、通义千问

（2）、字节豆包

（3）、DeepSeek

（4）、文心一言

（5）、腾讯混元

（6）、Kimi

根据AI工具给出的解释，我们能够得到如下结论：

（1）、商品，更强调经济属性，是指为交换而生产的劳动产品，具有价值和使用价值。商品的核心在于“交换”。

（2）、货品，更强调物理属性，是指具体的物品或货物，通常指库存、仓储或运输中的物品。货品的核心在于“物品本身”。

个人认为货品这个名词本身就是很抽象的定义，对抽象本身再进行抽象，实现的结果就可能挺抽象的。

曾经某电商公司以货品来重写商品系统，从设计之初到上线再到日常运营甚至公司关门大吉前都问题不断，尤其是货品表的一把梭设计，一张表一百几十个字段，让人大开眼界，咩哈哈。

货品看上去是一种合理的抽象定义，但实践证明不宜用于商品系统设计，遗憾的是个人投入再多精力也无济于事。抽象和设计糟糕造成业务系统写不好，不比刻骨铭心爱而不得好受多少。

5、原料

用于进一步加工的材料即为原料，可以是其它加工过程的产物，也可以是自然界生长或自然形成的产物。

原料可以进行采购，可以交换和买卖，其价格往往是标准价格或按质论价，典型示例如铁矿石等。

原料在采购和买卖的过程中，有使用价值和价值，有价格，这样就自动转换为了商品。

6、辅料

对产品生产起辅助作用的材料。示例：服装的辅料，有拉链，纽扣，兜标等附属物；生鲜类产品的辅料有塑料箱、胶带等。

辅料也可以进行采购，可以交换和买卖，在采购和买卖的过程中，有使用价值和价值，有价格，这样就自动转换为了商品。

7、BOM

BOM = Bill of Material，叫做物料清单，也叫产品结构表、物料表等。

将产品的原材料、零配件、组合件予以拆解，并将各单项物料按物料代码、品名、规格、单位用量、损耗等依制造流程的顺序记录下来，排列为一个清单，这就是物料清单，也就是BOM。

BOM是：

(1) 、物资需求计划（Material Requirement Planning，MRP）的基础。

(2) 、制造令发料的计算依据。

(3) 、本质上是一项工程文件，不但是产品的规范说明，而且是制造流程的依据。

(4) 、用来核算产品成本的基础。

由以上知道BOM的重要性及其影响范围很大，故其内容必须随时保持正确及时。 

8、渠道商品

发布到某个销售渠道的商品集合，例如线下实体店、线上商城、自助售货机、无人售货商店等渠道。渠道商品在业务系统处理过程中往往会增加很多额外工作量以适配不同渠道。

渠道商品的架构设计和实现非常考验开发者的水平和经验，设计不好，除了增加工作量和系统复杂度，每次看到和维护不可描述的业务代码更是让人头疼，这也是个人经验之谈。

9、商品规格

商品规格（Goods specifications），是指一些足以反映商品品质的主要指标，如化学成分、含量、纯度、性能、容量、长短、粗细等。

例如：买衣服的商品规格指的是尺寸的大小，一般的均码分大、中、小号；有的较细，上衣依据衣长、胸围、领长分大小，下裤依据裤长短、腰围分大小等等。

10、商品属性

商品属性，平常也叫商品参数，是指商品本身所固有的性质，是商品在不同领域差异性（不同于其他商品的性质）的集合。也就是说，商品属性是商品性质的集合，是商品差异性的集合。

简单来说，商品属性是描述商品维度的字段，也就是商品的基本信息。

属性或参数或规格，它们其实非常相似，当然商品属性、商品参数、商品规格的严格定义和区分一直有争议，本文不做过多讨论。

二、商品基础

任何系统都会或多或少用到些字典型的基础数据，商品系统当然也不例外。商品基础数据管理是主数据管理中非常重要的环节，在电商活动中商品基础数据出现频率极高。

本文简单介绍几种最常见的查询检索用到的基础数据，包括品牌、分类、厂商等。

1、品牌

各种各样电子商务活动中出现频率最高的词汇之一就是品牌。

2、厂商

商品的厂商和品牌息息相关。

品牌和厂商通过关系表进行连接查询，品牌和厂商通常是一对一或一对多的关系。

3、分类

商品分类是商品分组聚合最常用到的技术和业务手段，分类通常支持层级管理，最多二到三级为宜，很多电商公司分类层级都最多精确到三级分类。

PowerDotNet实现的商品平台目前支持通用的三级商品分类，满足绝大多数电商业务需求，复杂度可控，可扩展性也适中。

4、分类分组

商品分类自身也支持分组管理，比如商品分类可以分为前台分类、后台分类、营销分类、手机分类等等，按照业务需要进行扩展。

当然商品分类分组不是必须，如果分类设计的好，可扩展性优秀，完全可以适配多种场景，不需要再独立进行分组管理。

5、其他

其他如商品标签、单位、产地、价保等基础数据本文不再列出。

有些电商公司还会把尺码、颜色等抽象出来放在基础数据表里，PowerDotNet实现的商品平台没有采用这种做法。

三、SPU管理

SPU的抽象能够大大简化商品管理。让我们再来复习一遍SPU的定义。

SPU = Standard Product Unit （标准化产品单元），SPU是商品信息聚合的最小单位，是一组可复用、易检索的标准化信息的集合，该集合描述了一个产品的特性。

1、SPU档案

SPU包含的标准化的信息主要包括品牌、分类、厂商、区域、助记码等公共信息，个性化的信息不适合抽象到SPU中，可以在商品属性中独立添加或修改。

SPU抽象的粒度非常考验业务或运营人员的经验和需求，缺少经验的业务运营人员经常会需要不断变更SPU的定义。

比如，华为P40 Pro和华为P50 Pro可以定义成两个SPU，也可以直接定义成华为手机Pn系列一个SPU，这个就看实际运营需求，通常情况下SPU管理宜细不宜粗，越具体越好。

SPU的管理对商品系统的稳定非常重要，如果系统里SPU需要经常变动，我们很可能需要重新抽象定义新的SPU。

SPU字段较多，新增SPU比较考验业务和运营人员的耐心，当然对于相似的SPU，商品平台提供了快速复制生成SPU的工具，几个必填参数改改或者留空后台自动生成，很容易就能添加一个SPU。

2、审核SPU

SPU的管理对商品系统的稳定是如此重要，所以SPU所有新增或修改操作都需要人员审核，所有关于SPU的操作都要添加审计日志，特定环境或场景下可以依赖日志快速恢复或还原。

3、生成商品

SPU不是商品，但是可以通过SPU工具自动批量快速生成最终售卖的商品，有差异性的商品属性单独修改即可，这样就可以大大简化商品的添加操作。

四、属性管理

商品属性是对我们通常所说的商品规格、商品属性和商品参数的通用抽象。

PowerDotNet重写的商品平台，对规格、属性和参数经过慎重考虑后进行了裁剪和取舍，直接按照商品属性来定义商品元数据，不延用规格而使用属性仅仅是因为作者的个人喜好，咩哈哈。

商品属性的表设计采用了经典的元数据设计大法，按照属性名和属性值进行独立建表，可扩展性非常好，虽然查询检索可能会比较复杂，但是有成熟的技术手段如Lucene、ES等全文检索技术优化查询。

属性名值对支持文本、单选和多选设计，这种设计方法对于电商系统中常见的单规格商品和多规格商品可以完美支持。

有了元数据设计法，品牌、分类等商品基础属性通过名值对字典表也能完美适配，但很多电商都独立设计这几张数据表，一个原因是查询频繁，另一个可能是品牌有图片，分类有前台、APP显示名称等，业务字段较多。

1、属性名

属性名支持分组管理，这个抽象通常都是后台管理用到，前端逻辑不需要过分关注。

属性名也支持层级管理，通常不那么复杂的电商场景，只设计一级属性名即可。

 2、属性值

根据属性名定义不同的属性值，对于单规格商品就设置一个值，多规格商品就设置多个属性值。

 3、商品属性

属性名和属性值定义好了，最终是要作用于商品上的，否则单独设计属性名和属性值也没有意义。

商品、属性名和属性值可以通过传统的中间关系表产生关联，这样可以达到属性名值对作用于商品上的效果。

PowerDotNet实现的商品平台更进一步，设计了商品属性表，这张表对属性名和属性值进行了大量冗余。这样设计的优点是属性名或者属性值变更时不会影响到现有的商品属性；缺点也比较明显，某些查询场景下需要行转列处理，冗余数据略多，如果相同的改动就需要作用于大部分商品，可能不得不改动大量的冗余数据。

PowerDotNet开发的商品平台有商品属性名和商品属性值自动同步功能，可以按照商品、SPU、分类、品牌等不同维度和粒度进行批量同步数据操作，大大减少属性数据变更导致的业务和运营人员的工作量。

当然这个中间商品属性表的维护还是需要人员花费大量精力和时间，毕竟商品属性很多，幸好有模板设计法，PowerDotNet内置了很多模板工具和方法，可以进行批量增删改操作，同样能大大减少工作量。

不得不说，元数据大法好，模板大法好，PowerDotNet大法好，咩哈哈。

五、模板管理

电商平台的商品琳琅满目，属性成千上万，如果我们对商品属性管理按照商品一个一个进行录入，工作量巨大，而且容易出错。

通过模板设计大法，我们完全没有必要按照商品进行一个一个管理，可以先定义好属性模板，按照SPU、分类、品牌等进行模板管理，只需要录入必须的基本的属性名和属性值就可以按照模板批量管理。

当然，模板生成的商品属性通常都是通用的没有明显差异化的，需要个性化的商品属性我们可以按照商品一个一个进行补充，这种操作通常很少，工作量完全可以接受。

1、模板信息

可以按照SPU、分类、品牌等分组命名模板，望文知义，所见即所得，便于运营和管理。

2、模板属性

定义模板是为了解决属性繁多易错的问题，所以模板就要和属性名、属性值产生关联关系。

3、复制模板

对于相似SPU、分类或品牌，PowerDotNet商品平台提供了快捷复制工具，可以按照已有模板批量复制模板和模板关联属性，大大减少业务工作量。

4、同步模板

模板的改动相对而言比较少，但是如果有变更，比如属性名值的增删改，我们可以通过同步工具自动批量将变更数据同步到各个商品中，业务要做的事情就是点下按钮而已。

5、SPU模板

一种SPU可以包含多种商品，定义好SPU模板，可以一键生成相同SPU下的一组商品的商品属性，差异化的属性再到商品属性管理页面下独立设置修改即可。

举例：SPU为华为P50 Pro，主要差异属性有颜色（黑色、白色、银色、金色）和机身内存（128G、256G、512G），定义好模板，可以一键生成4x3=12个商品的所有商品属性。

根据SPU自动生成商品的过程，其实也是自动生成SKU的过程，但这个过程在PowerDotNet商品管理里可以弱化，后续介绍SKU的时候再介绍下为什么要弱化这个过程。

6、分类模板

如果某些分类下的商品属性非常相似，可以定义比SPU更粗力度的模板，批量生成相同分类下的商品属性，差异化的属性再到商品属性下独立设置修改即可。

举例：三级分类为手机，定义好分类下的模板，可以一键批量生成手机分类下的商品属性。

7、分类品牌模板

和分类模板的主要功能和作用类似，只不过分类品牌模板是在分类相同的情况下再找到相同品牌的商品，商品范围被缩小，差异化的属性再到商品属性下独立设置修改即可。

举例：三级分类为手机，品牌为华为，定义好分类品牌下的模板，可以一键批量生成手机分类下华为手机的商品属性。

六、商品管理

商品管理模块主要包括商品信息、商品属性、商品条码、商品价保、商品图片、商品视频等常用功能。

有些公司的商品管理代码，对很多基础概念那叫一个不讲究，尤其是SPU和SKU，规格、属性和参数等容易混淆的内容，有经验的人看过就知道，不出意外的话，总有一天会出意外。

1、SKU

SKU = Stock Keeping Unit(库存量单位)，严格按照定义来看，显而易见，SKU肯定不完全等于商品，实际情况也确实是这样的，商品定义远远比SKU要复杂的多，商品要应对的变化也远比SKU复杂。

在传统的商品管理体系设计和实现中，商品管理一般都会包含SPU、SKU和商品信息三层管理逻辑，商品ID(GoodsId)、SkuId和SpuId之间有关联关系，抽象程度越高，定义越明确，商品更容易管理。

个人经验中，SKU主要基于商品的销售属性生成，常用于库存和价格管理，后台控制更多；而商品的整体定义，除了销售属性，还有条码、图片、视频和营销等等各种元素，前后台都有复杂控制逻辑。

SPU可以根据模板自动生成SKU和商品，SKU属于商品和SPU之间的过渡角色，如果你开发过的WMS、MES和商品管理系统CMS都是以商品为准，SKU的地位就很尴尬，让人几乎感觉不到它的存在。

PowerDotNet的SKU设计参考了前厂的商品管理，商品和SKU仅有简单的关联关系，实际商品管理都是以商品为准，弱化了SKU的存在，WMS和MES中的商品库存也是商品为准，这就是理论和实践的区别。

2、商品档案

支持商品信息的增删改查，支持快捷生成商品。通过模板可以批量生成商品属性，通过SPU可以一键批量生成商品。

PowerDotNet实现的商品信息管理兼具易用性和可扩展性，查询也比较方便，对于中小公司，甚至不需要上全文检索，直接创建宽表根据RDBMS的查询功能即可实现基本业务需求。

商品信息字段比较多，商品管理后台提供了完善的偷懒工具，只要点击复制按钮，必填参数改一下或者不填由后台自动生成，可以大大提高录入数据速度和准确性，对于同品类或相同SPU的商品有奇效。

3、商品属性

商品信息里的字段主要是常用检索字段和通用信息字段，商品属性定义更丰富的商品维度描述。

字典表属性名和属性值修改后可以批量同步到商品属性中，这是一个比较危险的操作，尤其是销售属性的批量同步变更，需要业务反复查询对比确认后才能操作。

前面属性管理处我们已经说过，PowerDotNet实现的商品平台对商品属性表做了大量冗余，支持自定义，支持修改特定商品属性名值对而不影响全局。

4、商品条码

条码的应用非常广泛，PowerDotNet实现的商品条码支持商品普通条码和二维码的生成。

某些商品还需要按渠道不同生成特定渠道的条码和二维码，PowerDotNet预留了扩展用以后续支持。

商品条码和商品库存有一定的关系，通常情况下，相同商品SKU的有效条码可以重复，重复个数和库存数相等，当然不严格的情况下条码也可以重复生成或作废，并不强求条码和库存数一定相等。

5、商品价保

价保基础表定义价保信息，商品再根据商品和价保关系表构成商品价保，这样设计的好处是价保信息可以复用。

其中价保关系表还特别设计了价保开始和结束时间，满足绝大多数电商促销活动的需求。当然有些电商的活动规则引擎会把价保自动放到规则中去，不需要在商品系统中进行价保维护。

6、商品图片

商品图片主要利用文件平台Power.File实现图片的管理，本文不再赘述。

7、商品视频

和商品图片类似，目前短视频极其流行，视频文件大小较大，对文件服务器有较高要求。

8、商品统计

电商系统中商品众多，排序在商品展示中有重要作用，常见的排序指标比如评论数、收藏数、销量等等，这些数据主要由统计计算而来，直接设计存储在商品系统中非常合理，当然这些数据存储在其他系统（如CRM、订单等）中进行汇总定时通知到商品系统或者商品系统主动调用接口查询也是常见的可行方案。

9、其他

其他如商品买家秀等个性化数据没有设计在商品平台里，个人认为这些模块功能属于商品系统的可扩展设计，对于中小电商系统它们完全可以划归到Power.PCRM中去。

商品库存则很明显需要开发库存或者进销存系统进行商品库存管理，复杂点的库存管理系统还需要包括原料、辅料、生产加工等等功能模块，这些正是WMS和MES系统的长项。

为了查漏补缺，我试着问国内几个主流AI工具相同的问题“提供一份电子商务商品系统主要的数据库表设计”，最终比较满意的竟然是字节豆包，而我预料中最可能接近答案的通义千问还不如DeepSeek给的结果靠谱。

七、日志管理

商品平台是电商系统最基础最重要最敏感的业务系统之一，所以对商品的增删改操作都要有业务操作日志，某些核心查询操作也需要按需记录审计日志。

1、商品日志

主要用于记录并管理商品的核心操作日志，特殊情况下还可根据这些日志进行业务数据还原和恢复。

根据个人经验，所有基础数据表的修改，自定义商品属性、销售属性、价格等敏感参数都需要重点记录日志，防止修改错误需要紧急修复。

2、系统日志

系统日志相对商品日志，重要性就不那么突出，主要记录一些日常操作日志、对外提供接口日志、业务不敏感日志等。

系统日志可通过定时任务自动归档或者清理。

八、特殊商品

上面列举的一系列商品功能只是最通用最基础的电商商品抽象，还有一些特殊商品，正是我实现过程中痛苦和挣扎的主要来源，可能还需要按需进行额外扩展设计和管理。

Power.Commodity一开始只是我没事写点代码让自己高兴高兴的临时作品，目的也只是单纯总结和提取个人工作过的商品代码，但写着写着就发现越来越深不见底，尤其是特殊商品实在难以全部覆盖。

本文不探讨特殊商品的具体管理设计开发和建设细节，因为这是另外一个漫长的故事了，对于体力活我也是有追求的，所谓识时务者为俊杰^_^，只简单说说个人实际参与设计开发过的几种特殊商品。

1、汽车商品

汽车商品是一种特殊商品，区别于一般商品的主要特点包括：

（1）、零件多，技术含量高，属性多且复杂

（2）、金额较大

（3）、耐用品

（4）、涉及重大安全问题

（5）、有专属的交通法规，管理人员，道路辅助等

（6）、大件，重量较大，不易快递或转运，配合门店或4S店销售

（7）、是高档金融消费品，和金融保险联系紧密

（8）、其他，如税费较多，汽车商品常见的5种税：车辆购置税、车船税、增值税、消费税、关税，除车款外其他费用包括上牌费、保险（交强险、商业险）等

多层级属性是汽车商品的一个显著特点，汽车商品常见的一级属性包括品牌、厂商、车系、车款、车身、发动机、电动机、变速箱、底盘转向、车轮制动、安全装备、操控配置、外部配置、内部配置、座椅配置、多媒体配置、灯光配置、玻璃/后视镜、空调/冰箱、高科技配置等，每一个属性下又可以继续拆分出不同的子属性，比如多媒体配置，我们可以继续拆分出GPS导航、定位互动服务、中控台彩色大屏、蓝牙/车载电话、车载电视、后排液晶屏、外接音源接口、CD支持MP3/WMA、多媒体系统、扬声器品牌、扬声器数量、220V/230V电源系统等子属性。

相比普通商品，汽车商品查询检索有较多的多规格设计，常见的除了分类和品牌外，还包括价格、排量（如1.1-1.6L、1.7-2.0L）、能源（如汽油、新能源）、结构（如两厢、三厢）、国别（如中国、欧系）、配置（如全景天窗、电动天窗）、驱动、变速箱、座位、进气形式、生产方式等。

个人开发经验中，和汽车这种巨多规格和属性的商品类似的还包括药品和生鲜类商品，对于这种繁多而复杂的商品，一张宽表一把梭的设计特别容易造成开发和维护灾难。

PowerDotNet的商品属性设计和模板方法完全可以应对汽车商品的多规格属性配置，只是属性层级多，属性字段也很多，查询逻辑略微复杂。

2、生鲜商品

生鲜商品的最大特点是任意性和随意性，正是因为这两个特性导致生鲜商品的标准化远远滞后于一般商品，而标准化在商品平台设计与实现中至关重要。

我们还是以前面提到的华为手机举例，通过一个简单示例对比，看一下标准化生鲜商品为什么会比较困难：

华为P50 Pro手机是一种SPU；生产于中国大陆基于鸿蒙操作系统于2021年上市的黑色机身内存128GB运行内存8GB...的华为P50 Pro手机是一个SKU。

相对应的，生鲜类标准化商品会有如下描述：

南汇8424西瓜是一种SPU；产于中国上海的于2021年上市的重量为XX公斤到YY公斤...的南汇8848西瓜是一个SKU。

"人不能两次踏进同一条河流"，这是古希腊哲学家赫拉克利特说的。西瓜不能两次长出同一种重量，我们也可以说的富有哲理，咩哈哈。

假如标准化不加约定和限制，仅仅根据生鲜类商品的重量就能组合出很多种商品，造成SKU组合爆炸难题。

有人可能会有疑问，为什么不按照单位重量或体积进行商品定义，比如产于中国上海的于2021年上市的每公斤5元的南汇8848西瓜是一个SKU，然后用户下订单，直接按照实际购买重量乘以单价即可。

这种方案看上去非常完美，但是有一个先天缺陷，重量是需要人力称出来的，生鲜电商由于是大规模线上经营，通常都是预先通过生产加工系统进行称重，然后更新库存，不可能像实体店那样当面现称现卖。

这个问题的解决方案就是针对特定生鲜产品进行评估，对相同SPU的商品给出一个大致模糊的重量（或体积）范围以满足生产加工的需要，商定出一个用户能接受的价格，达到一种买和卖的平衡。

在一些电商站点上，生鲜商品比普通售卖的商品看上去没有更加复杂，有些行业特点比如储运条件（常温、恒温、冷冻、冷藏等）通过属性名值对或者扩展表也能很好支持，之所以拿出来单独说，主要是因为生鲜商品标准化背后隐藏的复杂性。

生鲜商品非标准化的物品很难用标准化的商品软件来管控，很多生鲜电商公司都只能按需自研信息化服务，比如供应链、生产加工、仓储管理、质检、运输、配送等等，难度可想而知。

个人曾经参与开发维护过一套生鲜系统，业务逻辑之恶劣，实现之奇葩，单据之多样，软件流程之长，使用之不友好，每看一遍代码都差点灵魂出窍，业务系统做成这种效果也是常人所不能及也。咩哈哈。

我尝试过用PowerDotNet新的商品设计思路重构一个生鲜商品系统，但是难度和工作量极大，还会影响其他系统，最后只能撤销改动放弃努力，曾经有过美好，但有些事物失去了就是失去了，不可强求。

假如商品平台要支持生鲜商品的主要特性，可能原料、辅料、包装方案、BOM、计划单、提货单、加工单、反加工单、损益单、尾料、原料顶替等名词都要再温故知新一遍，往事历历在目却遥不可及也。

通用性、标准性和普适性的公共服务系统才是PowerDotNet努力的方向，而任意性和随意性天生就是公共服务的天敌，抽象和实现的难度肉眼可见成倍剧增，所以最新商品平台设计暂不支持生鲜类商品。

3、虚拟商品

最典型而常见的几种虚拟商品如下：

（1）、网络游戏卡，是按服务公司的规定以现金兑换虚拟点(积分)的形式，通过消耗虚拟点(积分)来享受服务的一种支付形式。

（2）、移动/联通/电信/充值，包括话费充值，流量充值等。

（3）、网络软件，一般是指系统的操作系统、协议和应用级的提供服务功能的专用软件。

（4）、网站产品，以产品的眼光看待网站是网站产品的精髓所在。网站产品不同于软件产品、服务产品、工业产品等。网站产品是一类信息产品，以网站的形式提供信息、服务或二者的结合是它的主要表现形式。

我个人最熟悉的虚拟商品，包括网文（按章节收费）和电子书以及游戏点卡，某些公司的虚拟货币充值也可以抽象成一种商品，只要让用户下订单花钱支付购买同时又没有直接拿到实物产品，就可以认为用户购买的是虚拟商品。

4、服务商品

服务型商品也是日常生产生活中经常碰到的一种商品类型。最典型的如火车票、汽车票、酒店、机票、旅游度假等商品。

以我个人比较熟悉的某OTA（Online Travel Agency，在线旅行社）机票产品为例，服务型商品也非常考验开发人员的设计和架构水平。

机票系统涉及到很多业务数据表，常见的比如区域、二字码、三字码、机场、航站楼、航线、航司、飞机机型、中转地、行程总时长、仓位、常旅客、机票、机票库存、报价信息等表。

机票、火车票、汽车票、船票和邮轮等非常相似，看上去都是一个“占座”的商品形式，完全可以抽象出公共部分。而酒店则有一个间夜的概念，外加酒店内的附属商品管理，复杂度更胜一筹。

我们可以将机票航线、航班号、起降时间和具体飞机及仓位的组合（也就是一张飞机票）直观理解为商品，常见的机票商品包括单程和往返机票，还可以根据不同航线组合出联程/多程机票。

对于机票，大家还应该听说过中航信（含eTerm 或IBE+，两者都知道的，我只想说吾道不孤矣），机票查询和预定基本离不开它。

注：IBE+（Internet Booking Engine），即中国航信互联网订座引擎，是基于因特网的开放平台技术，它为各种用户应用系统提供访问中国航信传统订座业务系统的途径，是采用API方式的接口。

据我所知，机票库存可以通过中航信的eTerm软件来查询，行业内的一般做法是将eTerm软件功能封装成接口，供内部系统使用，当然除了eTerm，现在还有IBE+以API接口的形式提供查询和预定功能。

机票的库存信息一般称为AV信息，这个称呼的来源主要源于eTerm（黑屏）查库存指令。由于库存信息非常重要，因此每家OTA都会花费很多的流量在获取航班的AV信息上。

由于eTerm和IBE+的接口响应时间较慢，因此OTA采用的方法基本都是主动去获取AV信息，然后缓存起来，绝大多数用户查询时直接拿缓存数据即可，当然有些情况下还是会出现查询缓存失败，再去实时获取AV信息的情况。

相较于汽车、生鲜和虚拟商品，PowerDotNet的商品系统可能只需要加一些业务扩展表就可以完美支持，而服务类商品通常业务复杂，不容易做成通用设计，所以PowerDotNet已完成的商品设计将服务商品排除在外。

我尝试着使用国内流行的人工智能服务（通义千问、字节豆包、DeepSeek、文心一言和腾讯混元），实现机票预定功能，给出的代码真是一言难尽，AI目前还无法给出超过预期的方案，祖传代码暂时还是安全的^_^。

假如后续仍然需要加入机票、酒店、火车票、汽车票等服务商品功能，最好按照服务商品的特殊规范进行抽象设计，独立出来服务商品平台未尝不是一个好方法，元数据和模板设计大法同样有用武之地。

当然，目前看来PowerDotNet实现的商品管理系统还是比较基础的传统的商品管理，想做到大一统的支持各种形态的商品，还需要做很多设计和实现工作，虽然我个人手头有现成的业务代码和解决方案可参考，咩哈哈。

九、商品搜索

1、实现功能

商品搜索实现的功能主要包括按关键字搜索、中文分词、历史搜索、热门搜索、推荐搜索、联想关键词等等，绝大多数大中型电商公司的全站搜索服务就包括商品搜索功能。

2、解决方案

商品搜索在商品管理上算是常用而又有点技术难度的功能了，曾经有一种简单直接高效的暴力设计方法，就是添加一张商品关键词表，不过随着NoSQL和NewSQL的兴起，这种设计方案已显得非常落后。

个人早年有幸独立实现过一个典型而朴素的商品搜索功能，按照商品分类、标签以及任意关键字，通过MySQL的查询功能，模糊或精确匹配，按权重分页展示，现在想来依然十分好笑，咩哈哈。

搜索有很多现成的解决方案，比如基于Lucene或者ElasticSearch全文检索实现的搜索服务，按不同数据源（比如商品）建立索引，通过分词优化匹配查询索引，可按需实现对应系统（如商品）查询服务。

Lucene和ElasticSearch在实践中极易一不小心踩到很多坑，尤其是ElasticSearch，个人印象最深的是看上去简单常用的分页查询，在数据量很大或者有较多分片的情况下，越往后分页查询性能越拉跨。

个人曾经所在电商公司使用ES实现基本搜索功能，外加Redis和SqlServer配合实现搜索服务兜底方案，性能恶劣的sql语句like模糊匹配是最差的选择，like查询默认选择可以使用索引的左匹配。

搜索服务的设计与实现比较有技术挑战，尤其是全站搜索和商品搜索结合，值得再开一篇文章详细介绍，不过这就是更偏重于分词索引实现搜索服务的另一个话题了，本文不再展开详细说明。

十、商品排序

商品搜索和商品排序是密不可分的，对于商品搜索结果，我们总是要根据一定的排序规则展示给用户。下面列举电商中常见的几种商品排序：

1、直接根据商品属性排序

比如商品价格、上架时间、商品序号、自定义排序序号等

2、根据商品相关统计进行排序

比如商品销量、好评数、关注数、浏览次数、回购率等

3、根据商家相关统计进行排序

比如商家信用、商家门店数等

4、根据距离排序

最常见最典型的就是在线外卖订餐平台，根据消费者当前位置，按照距离排序

5、综合排序

在实际电商业务场景中，系统默认推荐排序不是简单的根据单一字段进行排序，而是综合排序。

通常来说，综合排序是先按商品和搜索关键词的相关性过滤，然后按上下架时间做预选，最后在预选结果里根据商品人气及质量等方面进行排序。

十一、系统交互

商品系统是电商最核心的组成部分之一，是电商平台的基础数据服务系统，和很多内部业务系统保持互通关系，整理下个人开发和对接过的几种常见互联系统。

1、订单系统

毫无疑问，订单的生成离不开商品，企业在正常的经营过程中，必须有销售商品、产品、提供劳务等业务，订单系统主要提供商品售卖服务。

2、库存系统

库存系统主要用于管理商品库存，主要包括商品入库、商品出库，商品调拨和商品盘点等操作。我们熟知的仓储WMS系统就包括库存管理。

3、采购系统

电商中的商品一般来说主要由供应商提供，我们常见的采销系统或进销存系统或供应链系统等都和商品及库存紧密相关。

某些特殊电商场景除了商品，还要考虑辅料、原料（物料）等，商品管理系统的设计直接关系到采销业务系统的复杂度。

4、门店系统

门店系统主要经营企业线下业务，门店系统的经营活动也离不开商品管理系统。

5、财务系统

财务系统是电商系统中最复杂的复合型公共服务型系统，财务单据经常和商品管理有千丝万缕的联系。

十多年前在帝都某电商公司做财务开发，竟然要自己写SQL访问商品表的积分字段，写windows服务计算和统计用户积分，这么普通而自信的业务逻辑放在今天你敢信？这些其实都是要规避的不合理设计。

6、票券系统

票券系统是电商中常见的营销系统，针对商品分类、SPU甚至SKU的票券设计很常见。

7、广告系统

广告系统也是电商中常见的营销系统，针对商品的广告宣传层出不穷。

8、推荐系统

电商里的推荐系统不会孤立存在，往往和商品、CRM、订单等系统配合完成业务需求。

9、CRM

主要包括针对个人用户或会员的商品偏好收集和购买统计、积分赠送等等

10、其他系统

其他如活动等电商业务系统也和商品管理有些联系。

十二、其他

个人参与设计与开发的商品系统还涉及到以下功能：

1、商品详情

一个好的商品详情页，可以有效的提升单品的转化率，对于不同终端（比如PC、APP、H5等）的商品详情页设计侧重点也会有很多不同。

商品详情页的接口设计也非常考验开发人员的编程经验，是采用大而全接口还是小而美接口，这需要开发人员根据实际情况做出合适的选择。

2、多语言

商品的多语言设计和实现也很普遍，对数据表的设计有更多更高要求，虽然多语言的工作绝大多数在我看来都是体力活。

3、组合商品

为了促进销售，很多商家在售卖时会利用“捆绑销售”的策略，这样就自然而然发明出了组合商品：人为将几个单独售卖的商品组合在一起进行合并售卖的商品。

SKU(组合)=m*SKU1+n*SKU2+...p*SKUx

组合商品的设计可能会对商品库存管理和订单拆单逻辑造成直接的负面影响，曾经在某电商公司做过一段时间开发，没少被组合商品搞得晕头转向，尤其是某些单据的业务逻辑那是相当炸裂。

4、商品数据同步

不同系统对商品主数据的要求是不一样的，有些业务系统仅仅提供商品接口即可满足业务需求，比如订单系统。

但一些后台业务系统（如WMS、MES等），往往牵涉到商品的复杂SQL查询，商品数据同步至对应业务系统也是必要的，PowerDotNet数据同步平台Power.DataX可轻松解决数据同步问题。