做过电商后台开发的朋友应该都清楚商品多规格设置这个功能看上去就是个“给商品加几个选项”但真到自己动手设计时才发现这里面的门道比想象中多得多。从规格项怎么组织、规格值怎么组合、SKU怎么自动生成到库存价格如何联动、下单时如何锁库存每个环节都有不少容易踩坑的地方。尤其是当商品规格特别复杂——比如一件衣服同时有颜色、尺码、版型三个维度每个维度下面还有七八个选项时如果底层数据结构设计得不好后面做商品列表筛选、购物车合并、订单拆单时会非常难受。这篇文章把我自己做多规格功能时的完整设计思路、表结构、核心算法和前后端交互逻辑都梳理了一遍同时也整理了几个我实际项目中遇到的比较典型的坑和解决办法。不管你现在是用原生PHP做商城还是用Vue加Node写后台这套思路都是通用的希望能给正准备做这个功能的同学一些参考。1. 商品多规格功能的设计思路拆解1.1 多规格到底解决的是什么问题先把这个基础问题理清楚。一个商品为什么需要多规格本质上是因为同一个商品在某些属性上存在多个可选项而不同选项组合起来会直接影响价格、库存、图片甚至商品编码。举一个最简单的例子一个充电宝有“黑色”和“白色”两个颜色价格一样库存分别是50台和30台。这种情况下没有规格功能也能做无非就是建两个商品而已。但如果是卖T恤颜色有黑、白、灰三种尺码有S、M、L、XL四个组合起来就是12个售卖单元。如果每个组合都单独建一个商品后台管理会变成灾难——图片、详情、标题都要维护12遍买家在前台也看不出来它们是同一个款式。所以多规格的核心价值有两点把“可变的部分”从商品主体中抽离出来让商品基础信息只维护一次规格维度独立管理。用规格值的组合确定唯一售卖单元SKU每个SKU拥有独立的库存、价格、编码、图片从而支撑精确的售卖和库存管理。搞清楚这一点很重要因为很多设计跑偏都是因为把“规格”当成了“参数”。参数是描述性的比如材质、产地它不影响买卖规格是决策性的颜色、尺寸买家必须选择之后才能下单。这两种东西在数据结构上必须分开建模。1.2 SPU与SKU的关系模型在做多规格之前建议先把SPU和SKU这两个概念理清了。SPUStandard Product Unit是标准化产品单元我们可以理解成商品详情页上展示的那个“商品”SKUStock Keeping Unit是库存量单位是具体到某个规格组合的那一项。拿刚才那件T恤来说SPU这件T恤本身包含标题、主图、详情描述、品牌等基础信息。SKU黑色S码、黑色M码、白色S码、白色M码……每一个具体的组合都是一个SKU。SPU和SKU是一对多的关系。多规格功能实际上就是围绕这两个模型做文章后台录入SPU信息时同时维护它的规格方案系统根据规格方案自动生成SKU列表运营人员再对每个SKU分别填写价格、库存、编码等信息。设计表结构时我一直坚持下面的拆法一张SPU主表存商品通用信息。一张SKU表存每个具体规格组合的价格、库存、编码。一张规格项表或者叫规格名表存“颜色”“尺码”这类维度。一张规格值表存“黑色”“M码”这类具体选项。一张SKU和规格值的关联表存具体某个SKU都含哪些规格值。有些团队喜欢把规格项和规格值存在一张表里用父子关系表示也能跑但如果后续要做“规格模板”复用比如服装类商品都用“颜色尺码”模板拆开更灵活。这个问题没有绝对的对错团队规模和项目复杂度不同选择也不同但核心原则是不要让SKU表里出现逗号拼接的规格值字符串那样做查询和筛选的时候会非常痛苦。1.3 数据建模需要提前想清楚的关键点多规格的数据建模有几个关键点必须提前想清楚否则后期返工成本很高。第一个是规格值的顺序问题。用户在后台录入规格值时是有顺序的比如颜色黑、白、灰尺码S、M、L、XL。这个顺序会直接影响前端规格选择器里选项的展示顺序。如果数据结构里没有“排序字段”后面连调个顺序都要改代码。所以每一张规格值表都建议加一个sort字段默认按录入顺序排列。第二个是SKU的规格值组合key怎么生成。常规做法是把规格值ID排序后拼接成一个字符串比如“3_15_28”作为SKU的唯一标识。为什么必须排序因为“黑_M”和“M_黑”在数学上是同一个组合如果不做排序同一个组合可能会被当成两个SKU这就是数据混乱的根源。第三个是规格图片怎么关联。用户在前台切换规格时商品主图会跟着变这算多规格功能的高频需求。实现方案有两种简单一点的在SKU表上加一个image字段存规格组合对应的图片URL复杂一点的在规格值级别存图片比如选了“黑色”不管尺码是什么都展示黑色款图片然后前台根据当前选中的规格值动态匹配。建议从SKU级别开始做因为它最灵活只是录入时稍微麻烦一点。2. 规格方案与SKU生成的核心算法2.1 规格维度的录入与校验逻辑后台的规格录入界面现在主流做法是动态交互式的选择规格项名称颜色、尺码、版本等然后逐项添加规格值。比如颜色黑、白、灰尺码S、M、L保存时前端会把这组数据组装成一个JSON提交给后端。这个JSON的数据结构非常重要建议用这种格式{ 规格项: [ { name: 颜色, values: [ { value: 黑色, image: }, { value: 白色, image: } ] }, { name: 尺码, values: [ { value: S, image: }, { value: M, image: } ] } ] }后端收到这个JSON后需要做两步校验。第一步是规格项去重同一种商品不允许出现两个同名规格项第二步是规格值去重同一个规格项下的规格值不能重复。这两步不做好后面生成SKU时会出现歧义。提交后系统需要把规格项、规格值分别落库然后根据“规格方案”自动生成一组初始SKU等待运营人员补充价格和库存。注意这里说的“生成初始SKU”到底生成多少个取决于规格值的笛卡尔积数量。2.2 笛卡尔积实现SKU自动生成这里就进入多规格功能最核心的算法了——笛卡尔积。所谓笛卡尔积简单说就是多个集合之间所有可能的组合。颜色的集合是{黑白}尺码的集合是{SM}它们的笛卡尔积就是{黑S黑M白S白M}这四种组合。总SKU数量的计算公式很好理解SKU总数 规格项1的值数量 x 规格项2的值数量 x ... x 规格项n的值数量比如一个商品有“颜色3个值、尺码4个值、版型2个值”三个规格维度那么它的SKU总数就是3 x 4 x 2 24个。这个公式在做“一键生成SKU列表”功能时非常有用前端可以先计算出来给运营人员一个预期。生成笛卡尔积的代码有好几种写法我推荐用递归或者reduce来实现。下面这段代码用reduce生成笛卡尔积逻辑清晰且容易维护虽然不是性能最优但规格值的数量级一般在两位数以内性能完全够用function cartesianProduct(groups) { return groups.reduce((accumulator, current) { const result []; accumulator.forEach(item { current.forEach(value { result.push([...item, value]); }); }); return result; }, [[]]); } // 示例用法 const groups [ [黑色, 白色], [S, M, L] ]; const skus cartesianProduct(groups); console.log(skus); // 输出: [ // [黑色, S], [黑色, M], [黑色, L], // [白色, S], [白色, M], [白色, L] // ]这段代码的本质是初始值是一个“空组合”每遍历到一个规格项就把当前已有的所有组合和该规格项下的每一个值做一次拼接形成新的组合列表。循环结束后得到的就是所有组合。生成组合后接下来要给每个SKU计算一个唯一标识key。我的做法是把每个组合里的规格值按ID排序后用下划线拼接。比如上面的组合“黑色、S”假设黑色值是3S值是8那key就是“3_8”。用这个key去判断某个SKU在数据库里是否已存在就可以做到“规格方案变了自动增删SKU”。2.3 无效组合如何处理实际业务中并不是所有规格值组合都是有效的。举个例子一款女装的连衣裙颜色有红色、藏青色尺码有S、M、L、XL。但红色款只生产到L码XL码根本没有货。如果按照笛卡尔积全量生成SKU就会多出“红色_XL”这样一个无效组合。处理无效组合有两条路全量生成运营人员手动把无效SKU删掉或下架。优点是实现简单缺点是多了一点录入工作量。录入时支持“排除某组组合”。前端界面里提供“按规格值过滤”的功能比如选了颜色为红色时尺码下拉框自动去掉XL。这样从源头就不会生成无效SKU。我个人建议先做全量生成再在SKU列表中允许“停用”某些组合。因为“排除组合”的交互逻辑相对复杂而且要动态计算剩余SKU初期开发成本高收益却没有想象中那么大。等业务侧真正提出需求后再迭代这个能力也不迟。3. 前后端联动从选择规格到提交订单3.1 前端规格选择器的交互逻辑前端规格选择器就是商品详情页里那组按钮或下拉框。买家能否顺畅地完成选择很大程度上取决于这个交互做得好不好。这里有一个高频需求当某个规格组合无效时对应选项应该自动置灰不可点选。比如某件T恤没有“白色_XL”买家选了“白色”后XL这个尺码按钮就应该灰掉。实现这个逻辑的思路是这样的先把所有SKU数据一次性加载到前端数据结构是一个映射规格组合key - SKU信息。用户点击某个规格值时实时去判断在当前已选规格值的前提下这个值是否还能与其他未选的规格值组成有效SKU。如果不能就置灰。判断是否有效的核心函数大概是这样的function isOptionValid(skuList, selectedSpecs, specName, specValue) { const nextSelected { ...selectedSpecs, [specName]: specValue }; return skuList.some(sku { return Object.entries(nextSelected).every( ([name, value]) sku.specs[name] value ); }); }这段代码的意思是当用户选择了某个新的规格值后判断全量SKU列表里是否存在至少一个SKU它的所有已选规格值都匹配当前选择。如果存在说明这个选项有效否则置灰。这里有个交互细节要格外注意用户选择规格值的顺序是不固定的。可能先选尺码再选颜色也可能反过来。所以判断有效性的逻辑必须基于“已选集合 当前值”而不是硬编码依赖某个规格项的选取顺序。用上面的函数天然就支持任意顺序点选。另外每一档规格选择后价格区间、库存总量也应该联动更新。比如一件T恤不同SKU价格不同用户选了黑色后发现只剩黑白两个SKU可选了界面上的价格范围应该自动变为“99 - 129”实时反馈。3.2 后端接口设计SKU查询与详情前端的规格选择器需要足够的数据支撑。我的做法是提供两个接口获取商品详情返回SPU基本信息包括规格方案规格项和规格值以及所有SKU的概要信息。获取SKU详情根据商品ID和规格组合key返回某个SKU的完整信息包括价格、库存、SKU编码、图片等。第一个接口的数据量会比较大尤其当SKU数量很多时比如60个一次性返回所有SKU的信息也能接受因为这些数据结构本身不复杂。但如果SKU数量爆炸几百上千个就应该改成懒加载详情页先只返回规格方案和每个SKU的“存在性”当用户选中完整组合后再调第二个接口拿具体价格和库存。这里我还想提醒一下库存字段的返回问题。很多后台系统会把真实库存整数原样返回给前端但前台详情页通常不需要展示精确库存只需要展示是否有货。所以我习惯用库存的多个档位来判断状态比如库存 0有货库存 0无货按钮置灰如果要做“仅剩X件”这类效果再单独返回一个库存档位字段避免把真实库存裸奔给前端也算是一种保护。3.3 下单时的库存扣减与并发安全多规格真正考验功底的地方在下单环节。用户选好规格后请求下单后端必须确保这个SKU的库存是足够且安全的。所谓安全就是并发情况下不能超卖。我推荐的方案是在SQL层面做原子扣减用条件更新代替“先查再改”。UPDATE sku SET stock stock - #{quantity} WHERE sku_id #{skuId} AND stock #{quantity};这个UPDATE语句的效果是只有当当前库存大于等于本次购买数量时才执行扣减。通过受影响行数affected rows判断是否扣减成功。如果影响行数为0说明库存不足直接提示买家“库存不足”即可。这是解决超卖问题最简单有效的方案。相比先SELECT再UPDATE的方式它避免了并发场景下的竞态条件相比加锁SELECT FOR UPDATE它不会锁表导致性能下降。如果项目里用了Redis也可以先走一层Redis缓存做库存预扣再异步同步到数据库但那属于进阶方案需要对缓存一致性有充分的把控。普通业务场景下直接打数据库做原子扣减完全够用而且不会出现“缓存里有库存、数据库没库存”这类麻烦问题。4. 多规格场景下的常见问题与避坑技巧4.1 SKU数量爆炸前台加载卡顿怎么解决前面提到过SKU总数是规格值数量的乘积。当规格项和规格值都很多时SKU数量会呈指数级增长。比如一个定制类商品颜色5种、尺码6种、图案3种、面料2种SKU总数就是180个。这还只是4个规格维度如果加到6个维度轻松破千。SKU多了之后首当其冲的是前端页面性能。一次性渲染上千个SKU的选项状态判断会明显感到卡顿。我整理了几条缓解方案按性价比排序规格JSON拆分成“元信息”和“SKU列表”两部分SKU列表按需加载。详情页先渲染规格选择器结构用户完整选定后再请求SKU详情。有效组合状态用Set而不是数组存。判断一个规格值是否有效时只需检查组合key是否在Set里时间复杂度是O(1)比遍历数组快得多。后端接口做缓存。SKU列表数据可以缓存到Redis设置几秒钟过期时间避免每次刷新页面都打数据库。实际操作中如果你的SKU数量控制在100以内第一点基本不用考虑做好第二和第三点就行了。4.2 规格数据一致性被破坏的典型场景多规格功能最常见的脏数据场景是“SKU引用的规格值已经不存在了”。比如运营在删规格值时没有同步处理已有SKU的数据导致SKU表里关联到一个空值。规避这个问题我常用的办法是删规格值之前先查一遍有没有SKU在用。如果有就拦截删除操作提示运营“该规格值已存在于12个SKU中请先处理这些SKU再删除”。这个校验逻辑听起来很简单但实际操作中很容易被忽略。我见过有的系统在删除规格值时后端直接执行DELETE等买家在前台报错“商品参数不完整”时才慌慌张张去排查。做后台功能开发时一定要把“引用完整性”放在心里不管是外键约束还是逻辑校验必须有一道防线。另一个典型场景是修改规格名或规格值文本。比如原来尺码项叫“大小”后来想改成“尺码”。如果改的是规格名问题不大但如果改的是规格值比如把“全码”改成“均码”那么所有引用过这个值的SKU在前台的展示文本也会自动改变。这里需要谨慎因为SKU编码、套餐名等业务数据如果是基于旧规格值生成的就会出现不一致。4.3 SKU编码规则怎么设计SKU编码是多规格功能里很容易被忽视、但后期极为重要的字段。它对外是售后沟通的凭证对内是库存管理的抓手。设计SKU编码时我建议遵循三个原则唯一性一个SKU一个编码全局唯一。可读性编码中最好能看出商品和规格信息方便人工识别。稳定性编码一旦生成尽量不要改变否则会牵动订单、库存、采购等多个系统。一个可以参考的编码规则是SPU编码如10086 规格值缩写如BKXL 序号。其中规格值缩写可以在后台设置规格值的时候一并维护比如“黑色”缩写为BK、“XL”缩写为XL。当然这套规则不是绝对的关键是要全公司上下统一使用做到“拿一个编码能反查是哪个商品的哪个规格”。4.4 历史商品数据的兼容迁移很多做多规格功能的项目都不是从零开始的而是原来“一个商品一个价格库存”现在要升级成多规格。这就涉及历史数据的迁移。迁移方案通常是这样旧商品没有规格方案我们把它当作一个“默认规格”的商品处理。在建表时给没有规格的商品自动生成一个默认规格方案比如规格项叫“默认”规格值叫“默认”并生成唯一一个SKU。这样旧数据也能统一走SKU逻辑不需要写两套下单代码。迁移过程中有个坑要特别提醒旧商品的价格、库存可能存在SPU表里也可能在另外一张price表里。做迁移脚本之前一定要先做数据盘点确认每一个字段的来源表避免迁移后价格对不上。我踩过这个坑当时有一个字段在库存表里叫inventory在价格表里叫stock_num两个都是“库存”的意思但数值对不上最后逐行比对才发现有一批商品的库存数据早就不同步了。4.5 多规格联动的“规格图片”方案前面说过SKU表上的image字段可以解决多规格图片联动的问题。但这里有个细节是当商品只有颜色影响图片、尺码不影响时让运营在每个SKU上都重复填相同图片体验非常差。所以现在的后台系统一般提供两种图片设置方式SKU级别直接在某一个SKU上设置独立图片。规格值级别给某个规格值设置图片比如颜色的“黑色”设置一张黑色产品图所有包含“黑色”的SKU都默认展示这张图。技术实现上优先展示SKU级别的图片如果没有就回溯到规格值级别的图片。这个“继承”策略实现起来很简单function getSkuImage(sku, specValueImageMap) { return sku.image || specValueImageMap[sku.specs[颜色]] || sku.skuImage; }前台代码先查SKU自己的图片再查规格值图片最后回退到SPU主图。这样做既照顾了精细化运营的需求又不会给运营增加太多工作负担。5. 多规格功能上线后的运维心得功能上线只是开始真正考验的是上线后的长期运营和数据质量。我做了几个多规格项目之后最大的感悟是这个功能本身不算难难的是在“灵活”和“可控”之间找平衡。太灵活了运营可以随便建规格、填值、配SKU结果平台上的数据五花八门——“颜色”这一项有人填“颜色”有人填“色彩”有人填“COLOR”同一个SPU池子里的商品数据就乱了。太可控了比如只能从平台预设的规格模板里选灵活性又不够无法满足各种品类的差异化需求。我比较推荐的折中方案是后台提供一套规格模板功能运营创建商品时可以复用模板。服装类目有“颜色尺码”模板手机类目有“颜色存储版本”模板。模板除了预设规格项和规格值还能预设SKU的默认价格、默认库存。运营只需要微调少数SKU即可。这套方案既能保证数据相对规范又不需要强制所有商品都用同一套规格是目前电商系统里比较成熟的解法。顺便说一句如果你的系统里已经积累了大量“一规格一SKU”的历史数据切到新多规格模型时要注意新老数据的筛选和导出的权限配置不要在切换接口时就让人手忙脚乱。备好回滚方案先灰度后全量才是稳妥之道。这个功能做做容易做精做稳不简单。希望上面这些内容能帮你绕过我在这个功能上踩过的那些坑。