商品分类、规格、库存和价格体系应该怎么规划？

商品还不多的时候，后台怎么填似乎都能用。一个保温杯建一条商品，颜色和容量写在详情里，库存填个总数，促销时直接改售价。等到颜色增加、两个仓库同时发货、门店与商城价格不同，问题很快就会冒出来：页面显示有货，客户选到某个颜色却下不了单；仓库有 300 件，系统不知道具体是哪种容量；活动结束后，部分商品恢复了原价，另一些还留着促销价。

这不是运营不够仔细，而是最初把分类、规格、库存和价格当成了四项后台设置。它们实际上描述的是同一笔交易：客户买了哪一件，系统按什么价格收款，哪个仓库应该扣掉多少库存。

红数科技在规划商城、品牌独立站或商品型小程序时，通常会先拿一批真实商品把这笔交易跑通，再决定后台字段。页面好不好看当然重要，但只要商品底账没理顺，筛选、搜索、促销、订单、仓储和后续数据分析都会反复返工。

先分清四种对象，很多争论会自己消失

企业内部说“一个商品”时，指的可能完全不是一回事。运营说的是一张详情页，仓库说的是货架上的一箱货，采购说的是一个供应商货号，财务关心的又是一项有成本、有税率的交易对象。

规划时可以先把对象拆开：

行业里常把商品主体称为 SPU，把具体可售版本称为 SKU，但不同系统对 SPU 的定义并不完全一致。名字不是关键，关键是企业内部能不能对同一层对象说同一种话。仓库要扣的是 SKU，价格也应能落到 SKU 或它所在渠道的销售条件上；分类本身既不存库存，也不直接代表一个成交商品。

分类按客户的寻找方式建，不照搬组织架构

分类常见的错误，一种是把公司内部产品部、品牌部、重点项目部直接搬到前台，客户根本不知道该从哪个部门找商品；另一种是分类层级越建越深，最后只有一两个商品也要单独占一层。

前台主分类应该保持稳定，名称使用客户真实会搜索和理解的商品词。一级分类承担大的选购入口，下一层再按品类本身的差异细分。到底需要两层还是四层，要看商品数量、客户的选择习惯和页面承载能力，不必追求统一深度。

一件商品通常只设一个主分类，方便确定固定路径、面包屑和数据归属。它还可以进入“新品”“适合办公室”“夏季推荐”等集合，但这些更适合作为标签、专题或动态商品集，而不是再造一套互相冲突的主分类。

分类和筛选也要分开。客户进入“保温杯”以后，可能按容量、材质、杯盖形式和是否可进洗碗机筛选。这些是属性，不一定都要成为下级分类。把每个筛选项都做成分类，导航会越来越长，商品也会散落在大量近似页面里。

开始建分类前，拿销售、客服和站内搜索中真实出现的商品叫法对一遍。内部叫“B 系列二代”，客户可能一直搜的是“车载保温杯”。前台可以保留系列名，但品类名称和页面说明要让第一次接触的人看得懂。

规格不是越多越好，要看它会不会改变成交和履约

颜色、尺寸、容量、包装数量都可以是规格选项，参数表里的额定功率、执行标准、适用温度则往往只是商品属性。判断一项信息要不要做成可选规格，可以问得很实际：客户选择它之后，SKU、价格、库存、图片、重量、条码或发货方式会不会改变？

只要其中一项会变，通常就应该建立独立的可售 SKU。反过来，只是帮助客户了解商品、不会改变实际交付物的参数，留在属性或说明中更合适。刻字内容、贺卡留言这类下单后才填写的信息，也不宜提前穷举成几百个 SKU，可以作为定制项处理，再明确它是否加价、是否延长交期。

一个商品有 5 种颜色、4 个尺寸，理论上会形成 20 个组合，但现实中未必每个组合都生产。后台只建立真实可售的组合。为了页面看起来完整而批量生成不存在的 SKU，既会出现长期零库存选项，也容易让采购和补货报表失真。

每个 SKU 至少要有稳定、唯一的内部编号。编号不要放售价、当前仓库和活动名称，因为这些信息会变；也不要让员工每次凭感觉手工拼写。已经使用商品条码的企业，还要把内部 SKU 与 GTIN、供应商货号分别保存，三者用途不同，不能把其中一个字段反复借用。GS1 对 GTIN 的定位是识别贸易项目的全球唯一标识，企业内部管理编号并不会因此被替代。

商品主表做到下面这个粒度，才比较接近可直接导入系统的状态：

库存不要只留一个“库存数量”

库存表里写着 100，不等于还能卖 100。里面可能有 12 件已经被订单占用，5 件正在质检，8 件是售后退回但尚未确认可再次销售。对客户真正有用的是可售库存，对仓库有用的则是每一种状态的数量都能对得上。

一套够用的库存口径，至少要区分：

• ‎现有库存：某个库位实际记录的数量；
• ‎已占用库存：已被订单、调拨或其他业务占住，不能再次承诺的数量；
• ‎可售库存：当前还能继续接单的数量；
• ‎在途库存：已经采购或调拨、尚未完成入库的数量；
• ‎不可售库存：待检、破损、冻结、退货待处理等暂时不能卖的数量。

有些系统会用“现有库存减去已占用和安全库存”计算可售量，有些系统还会把允许预售的数量算进去。公式可以不同，字段含义必须写进数据字典。否则商城、ERP 和仓库都显示“可用”，三边说的却不是同一个数字。

多仓经营时，库存要记录到“SKU + 地点”，不能只给 SKU 一个公司总数。华东仓有货，不代表西南地区的订单一定应该从华东仓发；门店的展示样品也不一定能直接用于线上订单。系统需要明确分仓优先级、拆单规则、调拨条件，以及某个仓库断货后是否允许其他仓承接。

套装商品还要看组成关系。一个礼盒包含 1 个杯子和 2 个滤芯，可卖礼盒数受库存最少的那项限制。若套装有自己的预包装库存，就按独立 SKU 管；若下单后才临时组合，就要由组件可售量实时计算，不能另外手填一个长期不更新的礼盒库存。

缺货也不是只有“显示”与“隐藏”两种处理。可以停售，可以接受预订，也可以保留页面并说明预计补货时间。选哪种方式，要和真实供应能力、支付规则及页面承诺一致。平台后台允许超卖，不代表企业就适合开启超卖。

价格要有层次，更要有明确的优先顺序

同一个 SKU 可能同时出现建议零售价、官网售价、门店价、会员价、批发阶梯价和限时活动价。问题不在价格数量多，而在结账时系统不知道该听哪一个。

价格表不能只有“价格名称”和“金额”，至少要带上适用范围：

价格优先级最好写成一张能执行的决策表。比如某 SKU 同时满足会员价和活动价，是取更低价，还是活动商品不再享受会员折扣；优惠券能不能叠加；满减是在单品折后计算，还是按订单原价计算。规则没有提前定，活动上线后只能靠客服逐单解释。

跨渠道、跨地区销售时，还要把币种、税费、四舍五入、最低毛利限制和汇率更新时间单独管理。不能用当天汇率直接把人民币价格机械换算后长期不动，也不能把含税价与未税价放进同一列。页面、购物车和结账页显示的价格口径应该一致，确有运费、税费或定制费后置计算时，要在客户作出购买决定前说明。

Google 的商品结构化数据和 Merchant Center 商品数据规范都把价格、币种、库存状态与具体商品或商品款式关联起来。对网站来说，页面可见价格、结账价格、结构化数据和提交给商品平台的数据如果不一致，不只是体验问题，也可能影响商品信息的展示资格。

真正落地时，先用代表性商品跑一遍

一开始就整理几千个 SKU，效率通常不高。更实际的做法，是挑 10 到 20 个最能暴露问题的商品：单规格商品、多颜色多尺寸商品、组合套装、预售商品、多仓商品、批发阶梯价商品和参加促销的商品都放进去。先让这批商品从导入、展示、下单、扣库存到退款完整走一遍。

试跑时，几种容易被忽略的情况值得单独检查：

• 客户切换规格后，图片、价格、库存和网址状态是否一起变化；
• 最后一个库存被两笔订单同时提交时，系统怎样处理；
• 订单取消、部分退款和退货入库后，库存回到哪个状态；
• 活动到期后，价格是否自动恢复，页面缓存是否仍显示旧价；
• 一个仓库缺货时，订单是换仓、拆单、预售还是停止购买；
• 商品停售后，旧链接、收藏、文章和广告入口怎样承接。

这批商品跑顺以后，再确定全量导入模板、字段字典和命名规则。哪些字段必填，谁维护，修改是否需要审核，数据从商城回写 ERP 还是由 ERP 下发商城，也要在这一步定下来。接口能传数据，不等于双方字段天然一致；同步前必须确认哪一套系统是商品、库存和价格各自的最终数据源。

商品页能被搜索和引用，靠的是稳定、可核对

一个包含多个规格的商品，可以共用商品主体内容，但每个可售款式仍要让系统识别。Google 当前的商品款式/规格结构化数据支持用 ProductGroup 表达商品组，再用不同的 Product 表达颜色、尺寸等款式；每个款式应当能够通过独立网址直接选中，单页与多页结构都可以采用。

这不意味着要给每个颜色机械复制一篇近似详情页。更重要的是：商品名称、规格、SKU 或 GTIN、图片、价格和库存状态在页面上真实可见，结构化数据与可见内容一致，款式链接长期稳定。商品下架、价格变化和库存变化后，页面与机器可读数据也要同步更新。

分类页负责帮助寻找和比较，商品页负责说明共同信息，SKU 负责确认具体交易对象。三者边界清楚，搜索系统更容易判断页面在说什么，智能问答引用时也更不容易把一个规格的价格和另一个规格的参数拼在一起。结构化数据能帮助理解，却不能替代准确的商品资料，也不保证一定获得特殊搜索展示或固定排名。

商品体系上线后还需要有人持续管。新品由谁建立主数据，规格改动由谁确认，仓库差异由谁处理，价格政策由谁批准，旧 SKU 在什么条件下停用，这些责任最好跟字段一起定下来。半年后再打开商品主表，仍能查到一个价格为什么生效、一批库存为什么冻结、一个规格为什么停售，这套体系才算真正可维护。

参考资料

以下公开资料核验于 2026 年 7 月 24 日。平台字段、展示规则和功能会继续调整，实际配置应以企业现行业务和平台当时的正式文档为准。

[1]: Google 搜索中心，《商品款式/规格结构化数据（ProductGroup、Product）》，页面最后更新时间为 2026 年 5 月 26 日。 [2]: Google 搜索中心，《Google 上的商品结构化数据简介》，页面最后更新时间为 2025 年 12 月 18 日。 [3]: Shopify 帮助中心，《Variants》。 [4]: Shopify 帮助中心，《Managing inventory quantities》。 [5]: GS1，《Global Trade Item Number (GTIN)》。 [6]: Google Merchant Center 帮助，《商品数据规范》。