商品系統是電子商務的核心繫統之一，是各種電商業務展開的基礎和起點，沒有調查就沒有發言權，個人也深度參與設計開發和維護過商品系統，本文簡單分享下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可輕鬆解決數據同步問題。