SKU编码规则怎么设计？三种方案与常见错误
在ERP里，库存、订单、采购、成本全都挂在SKU编码上。编码规则设计得是否合理，直接决定了三五年后你的数据还能不能看得懂。这篇讲清三种常见方案和它们各自的代价。
一、编码需要承载哪些信息
一个常见的误区是”编码里塞的信息越多越好”。实际上编码只需要满足三个要求：唯一（不重复）、稳定（不随意修改）、可扩展（新增品类不需要推翻规则）。
至于”哪些信息更适合写在编码里”，取决于你会不会经常用它来筛选。如果你经常要按品类查库存，品类信息放在编码里会方便；如果只是偶尔查一次，放在商品属性字段里更好，因为属性可以修改，编码最好不要改。
二、三种常见编码方案
| 方案 | 形式举例 | 优点 | 代价 |
|---|---|---|---|
| 无意义流水号 | SP000123 | 绝对唯一，规则简单，永不需要重构 | 看编码无法判断是什么商品 |
| 语义分段编码 | TS-RED-M-001 | 可读性强，便于人工识别与Рубрика筛选 | 品类增加时容易规则冲突，成本高 |
| 沿用平台原始编号 | 平台 item_id 或变体 ID | 零改造成本，与平台一一对应 | 多平台时同一商品会有多个编号，无法作为主键 |
多数中小团队的合理选择是折中方案：用一段简短的品类前缀加上流水号，例如 TS-00123。既能大致判断品类，又不会因为新增规格而需要重构规则。
О проекте规格的处理：把颜色、尺码这类规格做成独立的SKU，而不是在同一SKU下用文字说明。否则库存无法分规格统计，拣货时也容易拿错。
三、建立SKU与平台商品的映射
多平台卖家会遇到一个现实问题：同一个实物商品，在A平台是一个商品，在B平台可能被拆成两个链接，在C平台又被合并。这个差异必须有一层映射来吸收。
- 一对一：最常见，一个SKU对应一个平台链接。
- 一对多：一个SKU对应多个平台链接，例如同一商品在不同平台分别上架。库存变动时，需要同时推送给所有关联链接。
- 多对一：多个SKU对应一个平台链接，常见于组合装或套装销售。这类结构必须记录组成关系，否则发货时会拆错。
建议用一张独立的映射表维护这层关系：SKU编码、平台名称、平台商品ID、平台变体ID、关联类型。这张表看起来不起眼，但它是库存同步和订单回写的依据。
四、四个常见错误
- 频繁修改编码。编码一旦被订单、库存流水引用，改动就会造成历史数据断裂。确需调整时，建议新建SKU并做新旧关联，而不是原地改名。
- 一码多品。不同实物共用一个SKU编码，库存永远对不上，成本也无法核算。
- 多码一品。同一实物因为不同批次、不同供应商而建了多个SKU，导致需要合并分析时无法汇总。
- 规则里包含可变信息。例如把供应商名或年份写进编码，一旦更换供应商或跨年，编码就失去了稳定性。
结论：SKU编码的设计目标不是”看起来专业”，而是唯一、稳定、可扩展。中小团队可采用”短品类前缀 + 流水号”的折中方案，规格独立成SKU，并单独维护一张SKU与各平台商品ID的映射表。避免改编码、一码多品、多码一品与可变信息入码这四类错误，数据的长期可维护性就有保障。