做了七年电商供应链数字化实施，我经手过十七家企业的库存系统改造，其中至少有十一家在“套餐组合库存”这件事上栽过跟头。最典型的一次，是2023年某家居品牌大促时，组合套餐（床垫+床头柜+床笠三件套）在活动开始后37分钟超卖214单，而ERP系统里三个子件的物理库存分别是817、642、566件，全部显示充足。仓库实际配货时才发现，这214单的对应库存早已经被单独的SKU订单锁定了。
这不是个例，而是组合销售场景下的系统性问题，组合品库存与子件库存之间的“联动调配”能力，决定了你的库存数字是纸面富贵还是真实可履约。本文想把这个话题彻底讲透：为什么简单的“扣库存”解决不了组合问题，联动调配应该按什么规则设计，落地时不同规模的企业分别怎么取舍。
在展开所有细节之前，先把本文最核心的判断放在前面，方便你在阅读过程中带着这个框架去理解每个环节。
组合库存联动调配，不是“库存数量”问题，而是“可售关系”问题。物理库存是静态的、确定的；可售库存是动态的、按规则算出来的。联动调配的目标，就是确保每一个销售渠道看到的组合品可售数量，都基于当前真实的子件状态实时计算得出。
具体来说，完整的联动调配能力由四层规则构成：锁库规则、扣减规则、释放规则、重算规则。锁库规则决定“什么时候把子件锁定给某个组合订单”，扣减规则决定“卖出后怎么扣子件”，释放规则决定“取消/退款/超时后怎么还回去”，重算规则决定“子件有任何变动时，组合品的可售数量怎么自动刷新”。
这四层规则缺了任何一层，都会在实际经营中出现问题。只做扣减不做释放，退款后库存越来越少；只做锁库不做重算，子件补货后组合品依然显示缺货；只盯组合品库存不看子件锁定，大促一冲就超卖。
如果你只记住一个公式，应该是下面这个：
组合品可售数量 = min(子件A可用量, 子件B可用量, 子件C可用量) × 优先级系数
子件可用量 = 物理库存 + 在途库存 − 锁定数量 − 占用数量 − 安全库存阈值
这里的“优先级系数”是我多年实施中总结出来的关键变量，它处理的是拆零销售与组合销售并存时的规则冲突，后面的章节会专门展开。
“数据库存组合库存调配，套餐组合货品库存联动调配方法”的正确答案是：不能靠定时同步库存数字，必须靠事件驱动的联动规则让组合品和子件共用一个实时数据源。谁先锁定、谁先扣减、取消后怎么归还、跨仓怎么分配，全部由同一个规则引擎裁决，而不是由人工定时去“对一下数”。
要理解组合库存联动调配为什么难，需要先理解它产生的业务背景。组合销售不是新事物，但近五年它的复杂度和规模发生了质变，平台大促、多渠道分销、直播带货的集中流量冲击，让“手工管库存”的方式彻底失效。
根据服务过的客户情况，组合捆绑在电商和零售领域主要有三种形态，联动调配的复杂度各不相同：
让我用一个服务过的家居品牌的真实情况来说明。这家客户在淘宝、京东、抖音三个平台同时开店，宠物用品大促期间推出“猫爬架+猫窝+逗猫棒”组合套餐。运营团队发现一个奇怪现象：每个平台的单SKU库存显示正常，但组合套餐在不同平台的总可售量加起来，远超过了仓库的实际库存，因为三个平台各自为政，互不知晓对方的锁库情况，而组合套餐的库存是手工维护的固定值。
根据艾瑞咨询2020年发布的企业数字化报告数据，全国约有800-1000万企业与O2O付费平台合作，300-500万企业拥有线下智能设备用于数字化门店改造。这个趋势到今天只增不减，意味着绝大多数中小企业的订单早已脱离纸笔记录，进入系统可处理的状态。但进入系统不等于管理好系统，订单数字化提升了交易效率，也同步放大了库存联动不及时的后果。
纸笔记账时代，库存出错的代价是一本账本；ERP/电商后台时代，一个小数点的库存误差在大促流量下可以放大成数百个超卖订单。这不是在否定数字化，而是在提醒一个关键事实：当订单处理速度从“按天”变成“按分钟”，库存联动也必须从“按天对账”升级为“实时事件驱动”。
很多企业以为自己已经在做组合库库存管理，但实际上停留在“加减法”层面。以下五个误区，是我在项目中最常遇到的。每一类都来自真实客户案例，不是理论推演。
表面看这个逻辑没有错，木桶效应嘛，组合能卖多少取决于最少的那个零件。但它忽略了三个问题：在途库存、锁定库存、调拨中库存。
举个例子：A子件物理库存50件，B子件物理库存80件。按“取最小值”逻辑，组合可售=50件。但如果A子件中有20件已经被另一批预订单锁定，实际可卖只有30件。此时组合可售应该=30件而不是50件。更隐蔽的是，如果A子件有40件正在从上海仓调往北京仓的路上，北京仓的A可用库存其实是10+40=50件（启用在途可售时），组合可售和单仓视图完全不同。
正确做法是：组合品可售数量 = 子件可用量的最小值，而“可用量”必须排除锁定、占用和调拨中在途（除非明确启用在途可售策略）。
这是最危险的做法。有些ERP允许配置“组合品独立库存”，卖一个套餐只扣套餐的库存，不联动扣子件。短期看操作简单，长期看必然数据失真的地方在于：子件还有单独销售。你永远不知道哪个子件真的被卖出去了、还剩多少真能配货。
我一再向客户强调：组合商品不是一个独立库存实体，它是一个“视图”，真正的库存永远存在于子件层级。组合品只有联动逻辑，没有独立库存。
如果系统把单SKU的销售扣减和组合套餐的销售扣减分成两条独立链路，那么超卖几乎无法避免。你要知道的是，在同一秒内，一个子件既可能被单品订单锁定，也可能被组合订单锁定。如果没有统一的锁库仲裁机制，两个订单都判断“有货”，最终只有一个能发货。
这就必须引入锁库机制来解决，也就是后面的核心章节。
国内某头部云ERP的实施顾问私下告诉我，他们的回补机制默认延迟15分钟执行。这意味着用户在14:59取消了一个组合订单，15:00另一个用户下单时系统仍然判定“无货”，白白流失一笔成交。
如果你的系统是每日凌晨批量回补库存的，问题会更大，大促当天白天的退款，要等到第二天才重新变成可售库存，等于一天之内你的可售库存被系统性低估。
有些运营团队为了省事，直接在商品后台把组合品库存设置成一个“足够大”的数，指望子件库存来兜底。这导致的后果是：平台展示组合品有货，点进详情页才发现缺货。消费者投诉率急剧上升，店铺DSR评分和流量权重双双下降。
下表可以直观看出不同误区对应的直接后果：
| 误区 | 直接后果 | 严重程度 | 影响范围 |
|---|---|---|---|
| 组合=子件最小值的朴素算法 | 忽略锁定/在途后超卖 | 高 | 大促场景集中爆发 |
| 只扣组合品不扣子件 | 子件库存虚高，无法配货 | 极高 | 所有组合订单 |
| 单品和组合各扣各的 | 同一子件被双重占用 | 极高 | 多渠道/多SKU共销场景 |
| 退款后延迟回补 | 可售库存被低估，流失成交 | 中 | 高退款率品类 |
| 人工维护组合品库存值 | 前台展示与真实库存脱节 | 高 | 全渠道展示 |
锁库是联动调配的第一道闸门，也是大多数系统最容易做错的地方。锁库的核心目的，是提前把子件库存“保护”起来，避免被其他订单拿走。但锁得太早损失转化率，锁得太晚造成超卖，必须把握好时机和粒度。
这三种锁库时机各有适用场景，需要根据业务模式来做选择：
| 锁库时机 | 优势 | 劣势 | 适用场景 |
|---|---|---|---|
| 加入购物车时锁库 | 库存最安全，几乎不可能超卖 | 恶意/随意加购会锁死库存，转化率受损 | 高客单价、限量发售 |
| 提交订单时锁库 | 库存安全性和转化率相对平衡 | 未支付订单占用库存，需配合超时释放 | 日常销售、标准预售 |
| 支付成功后锁库 | 完全不误伤用户，库存利用率高 | 高并发下存在支付成功但无货可发的风险 | 低客单价、库存充足 |
这里的专业判断是：组合品锁库必须至少提前到“提交订单”时执行。因为组合品的子件涉及多个SKU，在支付后才去协调多个子件的库存，任何一个子件不足都会导致整单无法履约。提前到提交订单时锁库，可以尽早暴露子件不足的问题，给用户更换套餐或取消订单的机会，而不是支付后才发现缺货。
组合订单的锁库粒度，一般有两种方案：整单统一锁（一次锁定所有子件）和逐子件锁（按顺序逐个锁定）。强烈建议采用“整单统一锁”。原因是：逐个锁子件时，如果A子件锁成功了，B子件锁失败，系统必须回滚A子件的锁，这个回滚过程一旦出bug就造成A子件的幽灵占用。
整单锁还有一个好处，是便于设置锁库的原子性，要么全部子件锁定成功，要么全部不锁。在数据库层面这是事务一致性的问题，在业务层面就是“不能出现半个套餐被锁住”的情况。
锁库必须有时效，否则会因为大量未支付订单的长时间占库，导致组合品可售数量被系统性低估。我见过最夸张的案例，是一家服饰企业把锁库期限设为24小时，大促当天有超过2000个未付款订单锁住了价值80万的库存，而前端仍在正常售卖。
建议的规则是：日常订单15-30分钟未支付自动释放，大促期间（如双11、618）可缩短为10分钟，或直接改为支付成功后再锁库。这个策略组合可以减少约40%的无效库存占用。
这里需要特别强调一个释放后的联动动作：锁库超时释放后，系统需要重新计算该组合品对应子件的可用量，并同步刷新所有已创建的组合品可售快照。释放不触发重算，等于没释放。
锁库解决的是“卖之前”的问题，联动更新解决的是“卖之后”以及“子件变动后”的问题。这里强调“双向”两个字，因为很多系统的联动只做了一半：组合品卖出时扣减了子件库存，但子件发生变动（退货入库、采购到货、报损、调拨）后，组合品可售数量没有自动重算。
正向联动相对直观。当组合订单支付成功后，系统应将组合锁定的子件占用转为正式扣减，同时释放该子件在组合品维度上的可售余量。核心要求是实时性：从订单状态变为“已支付”到子件库存扣减完成，中间延迟不应超过1秒。
如果使用异步消息队列，需要特别注意最终一致性，万一扣减消息丢失，会造成子件库存虚高、实际无法配货。建议在支付回调后立即触发子件扣减请求，并在订单状态中记录扣减确认状态；如果扣减未确认，在订单列表中进行异常标记。
反向联动是更容易被忽略的一环。举例说明：子件B原本库存50，组合品可售=50。现在子件B退货入库20件，如果系统不自动刷新组合品的可售数量，前台就继续显示50件，实际可以卖70件。这个数据差不会导致超卖，但会影响销售机会。
反向联动常用的实现方式是事件驱动：当子件库存在任何变动（入库、出库、锁定、解锁、报损、盘盈盘亏）时，系统广播一个“子件库存变动事件”，所有引用了该子件的组合品接收到事件后，自动重算自己的可售数量。
这里的一个关键判断是：“事件驱动”优于“定时重算”。定时重算（比如每5分钟跑一次）的问题在于，两次重算之间的窗口期数据就是旧的，高流量场景下窗口期的超卖风险不可忽视。事件驱动把重算的触发粒度从“批量”变成“单次”，实现真正的实时联动。
这三个场景的联动最容易出错。
如果组合品的子件只在一个仓库，前面提到的规则已经足够。但现实中多仓是企业普遍选择，尤其是全国布仓的零售和电商企业。多仓会让组合可售量的计算复杂度成倍增加。
单仓模式下，组合品的可售数量 = 全仓子件可用量的最小值。多仓模式下，一个组合订单可能A子件在华东仓有货、B子件在华南仓有货，但两个仓凑不齐一个完整套餐。此时就会出现“系统显示有货、仓库发不出货”的情况。
多仓联动的核心原则是：如果子件不在同一个物理仓，不能直接相加计算组合可售；必须判断是否存在某个仓库（或同区域仓群）能同时满足所有子件的可用量，才能视为组合可售。
跨仓调拨是组合库存管理中操作频率最高也最容易乱的一环。以“子件A从上海仓调往北京仓”为例，库存相关的状态变化分三个阶段：
这里有个容易踩的坑：调拨单在途阶段，A子件在“上海仓”和“北京仓”都不完全可用，但它“存在”于系统的库存总量中。如果组合可售计算只看物理库存总量，会认为A=50可以支撑35个套餐；实际上从北京仓视角，可用的只有20件。建议在途库存默认不计入可售，除非设置了“在途可售”策略且明确知道补货时效。
在多仓模式下，组合品可售数量的计算建议采用“按仓锁定+全局汇总”的两级结构：按仓锁定确保每个仓库自己算自己的组合可售，全局汇总则把各仓的值加总显示在商品列表页。消费者下单时，系统根据收货地址自动匹配最近可用仓。如果该仓无法满足完整套餐，即使全局显示有货，当前用户地区也显示无货。
这套策略的额外收益，是可以减少无效订单的产生。省下的不仅是取消订单的客服成本，更是因为无货取消导致的DSR评分和搜索权重损失。
一个子件既被单独销售，又被纳入组合销售，这是零售和电商最常见的SKU结构。如何处理两者的优先级，直接决定了拆单率和订单取消率。
不设置优先级的默认状态是“谁先下单谁得货”。这看起来公平，但实际上对商家不利，一个买走10件子件单品的用户，可能一次性消耗掉能满足5个组合套餐的子件库存。组合套餐往往有更高的客单价和利润贡献，被单品订单抢走库存后，组合套餐反而无法卖出。
常见的优先级策略有三种：组合优先、单品优先、动态平衡。组合优先适合组合销售利润更高或者组合是主推款的情况；单品优先适合单品是引流款、需要保持曝光的情况；动态平衡则根据实时库存水位自动切换规则，实现起来复杂度更高，但效果最好。
当子件库存不足以同时满足单品订单和组合订单时，系统需要按比例分配。建议的分配逻辑是：订单级别的库存分配 = 用户下单时间权重 × 渠道权重 × 利润权重。但要注意一个执行细节：这个权重模型不一定要做得非常复杂，先把“时间优先”做对，再逐步增加渠道维度和利润维度，否则系统实施周期会被无限拉长。
如果你发现组合订单的拆单率超过10%，优先级策略大概率有问题。建议按以下顺序排查：先看库存水位，子件A是否经常性低于安全阈值；再看优先级规则，是否组合订单总是被单品订单抢库存；最后看锁库时机，支付后锁库形成的超卖，在组合场景中的危害远大于单品。
我在客户现场见过一个经典案例：某美妆品牌把“单品优先”策略切换为“组合优先”后，组合套餐销售额上升了18%，但单品ID的销量下降了6%。由于组合毛利率更高，品牌整体毛利不降反升。这个案例说明优先级规则不仅仅是一个技术配置，更是一个经营策略选择。
部分读者看到这里可能觉得内容很系统，但落入执行层面还是不知道从哪里开始。这里给出一套“最低可用配置”清单，无论你用的是大型ERP还是自研的中台系统，都需要满足这些基础条件。按数据层面、规则层面、执行层面三个维度来拆。
数据库层面可以简化如下，以下是最简核心表结构的示意：
— 组合关联关系表
CREATE TABLE combo_relation (
combo_sku VARCHAR(32) NOT NULL COMMENT '组合品SKU',
sub_sku VARCHAR(32) NOT NULL COMMENT '子件SKU',
sub_qty INT NOT NULL DEFAULT 1 COMMENT '子件数量',
is_required TINYINT NOT NULL DEFAULT 1 COMMENT '是否必选1必选0可选',
PRIMARY KEY (combo_sku, sub_sku)
);
— 组合锁定明细表
CREATE TABLE combo_lock_detail (
id BIGINT AUTO_INCREMENT PRIMARY KEY,
order_no VARCHAR(64) NOT NULL COMMENT '关联订单号',
combo_sku VARCHAR(32) NOT NULL COMMENT '组合品SKU',
sub_sku VARCHAR(32) NOT NULL COMMENT '子件SKU',
lock_qty INT NOT NULL COMMENT '锁定数量',
lock_time DATETIME NOT NULL COMMENT '锁定时间',
release_time DATETIME DEFAULT NULL COMMENT '释放时间',
status TINYINT NOT NULL DEFAULT 0 COMMENT '0锁定中1已释放2已扣减'
);
如果你的系统是市面上的主流ERP，不必建表，但需要确认系统是否具备上述四类数据的记录能力。如果没有，不建议直接购买昂贵的定制开发，先用Excel维护一个最小版的关联关系表和流水表，手工运行一至两周，把规则跑通后再投入系统开发。
根据我的实施经验和行业平均水平，不同规模企业落地整套联动规则的时间和成本如下：
| 企业规模 | 系统基础 | 实施周期 | 投入成本参考 |
|---|---|---|---|
| 年GMV 1000万以下 | 电商后台+Excel | 1-2周（规则+手工流程） | 人力成本为主，1-2人兼职 |
| 年GMV 1000万-1亿 | 有ERP但无联动 | 3-4周（配置+测试） | 2-5万元或内部人力2人月 |
| 年GMV 1亿以上 | 自研/定制中台 | 2-3个月（开发+联调） | 15-40万元，按开发量评估 |
需要说明的是，以上成本不包含硬件和服务器的投入，仅覆盖规则配置、数据迁移、联调测试和人员培训。大多数情况下，企业的问题不在“系统不够高级”，而在“规则没有理清”。先梳理清楚业务规则，再对系统做配置或二次开发，是成本最低的路径。
组合库存联动调配的完整方案包含锁库、联动、跨仓、优先级、预警五个维度。但不同发展阶段的企业资源不同，不应该按照同一个模板去套。下面给出三条不同阶段的取舍路径，供决策参考。
建议把有限的人力花在刀尖上：用Excel维护组合品与子件的关联关系表，每天早晚两次同步各平台的子件库存和锁库数据。不追求实时，但务必保证一天两次的人工核对，重点核对组合品可售数量不得高于“子件可用量最小值”。
取舍要点：放弃实时性，换实施成本。这个阶段最重要的是避免超卖带来的赔付和差评，只要每天核对两次，就可以把超卖风险控制在可接受的5%以内。
如果有ERP但联动能力不足，建议优先配置锁库规则和正向扣减逻辑，这两项是超卖风险的主要防线。反向联动（子件变动触发组合重算）可以稍微放一放，用每日对账兜底。
取舍要点：放弃部分自动化，换实施速度。用2-3周时间先把最关键的两条链路跑通，日后再迭代。如果一上来就想全量落地所有规则，大概率会因为实施周期太长而不了了之。
这个阶段的企业应该考虑自研或深度定制中台系统，完整落地锁库、扣减、释放、重算四层规则，并且针对不同渠道设置差异化策略。比如抖音直播间流量集中但转化窗口短，适合支付后锁库；天猫旗舰店用户比价周期长，适合提交订单时锁库。
取舍要点：投入几十万到上百万的成本，换全渠道库存效率和风险可控。这个阶段的企业如果还在用半自动方案，库存管理的人工成本反而会随着规模上升而失控。
| 发展阶段 | 推荐方案 | 投入参考 | 核心收益 | 需要放弃什么 |
|---|---|---|---|---|
| 起步期 | Excel规则+每日两次对账 | 人力约1人天/天 | 超卖率控制在5%以内 | 实时性、多仓支持 |
| 成长期 | 锁库+正向扣减+每日对账 | 3-4周实施 | 超卖率降至1%左右 | 反向联动实时重算 |
| 成熟期 | 全量四层规则+事件驱动 | 2-3个月+定制开发 | 超卖率接近0，人力减少80% | 初期投入成本较高 |
写了这么多，最后想说的是：组合库存联动调配没有秘密武器，没有哪个ERP能开箱即用地解决所有问题。工具可以变，系统可以换，但业务规则必须由你自己理清。
根据团队实际能力，建议按以下顺序推进：先梳理组合品与子件的关联关系清单（现有所有组合SKU及子件明细）；然后检查你的ERP/电商后台是否支持锁库、释放、扣减联动、事件触发重算这四个关键动作；再针对不支持的部分评估是人工流程兜底还是系统迭代，最后在大促前用历史订单数据做一次全链路演练。
具体到本周可以启动的行动，有三件事可以立刻做：第一，把现有组合品的子件清单整理成Excel关联关系表，这一步无论后续用不用系统都需要；第二，查看你的ERP订单处理流程中，订单取消后子件库存的释放是实时还是定时；第三，选一个核心组合SKU，在后台分别查询其子件可用量，按公式手动计算一次组合可售，和前台展示值对比一下，看看当前系统的偏差有多大。
如果你的团队在梳理过程中遇到具体的规则设计难题，或者想聊聊你所在行业的特殊组合场景（跨境保税、门店O2O、直播闪购等），欢迎带着问题来交流。组合库存联动不是一个“做完就结束”的项目，它需要随着业务变化持续迭代，但规则越清晰，库存就越不需要“救火”。
我后台明明显示每个子件都还有库存，但组合商品的详情页却提示库存不足，无法购买。组合库存到底是怎么计算的？是简单取所有子件的最小值吗？有没有更准确的计算方法？
组合品没有物理库存，它的可售数完全是靠子件库存“算”出来的。
最简单的算法不是取子件库存的最小值，而是先算出每个子件在当前渠道、当前仓库下的“可用可售库存”，再套这个公式： 可用可售库存 = 物理库存 – 锁定库存 – 安全库存 – 已占用库存 +（可选）在途库存 如果套餐里一种子件需要用 n 个，那么该子件的可组数 = 向下取整（子件可用可售库存 / n）；
整个套餐的可售数 = min(所有子件的可组数)。为什么子件有货，套餐却显示不可卖？常见原因有三个：一是某个子件被其他订单锁库了，可用库存变成0，比如一个大订单预占了300件，可用库存变成负数，系统按0处理；二是子件正在调拨或移库，被系统从可用池里扣掉了；
三是组合品关联的SKU和库存里的SKU不一致，库存被“隔离”在另一个SKU下。我处理过一个连锁零售客户的案例：子件A和B都有200多件库存，但套餐在页面上一直显示缺货。检查锁定明细后发现，A有一个300件的大订单预占，可用量是负数，导致套餐可售数被系统刷成了0。
后来我们加了“锁定库存预警”，并让组合可售数在子件可用为负时不再直接取0，而是展示为“缺货”，并触发补货提醒，这种“鬼影库存”才彻底消失。专家建议：不要用物理库存直接映射组合可售，必须建立一个“可用库存中间层”。中间层要实时同步锁定、在途、安全库存这些不可用状态。
否则组合库存永远是“看起来有货，实际卖不了”的陷阱。
我们做套餐经常超卖，用户下单成功了，付款之后却因为没有子件库存发不出货。到底应该什么时候锁库存？是用户加入购物车就锁，还是提交订单锁，还是付款后才锁？锁库存和真正扣库存是一回事吗？
“锁库”和“扣减”不是一回事，很多超卖就发生在混淆了这两个动作。锁库是临时占用，扣减是实际出库后从库存中减掉。对组合品来说，锁库必须锁到子件级，不能只锁组合品本身。推荐的时点：日常销售建议“提交订单时锁库，支付后扣减，超时未支付自动释放”。
大促场景建议“提交订单即锁库，但把锁定时长缩短到10-15分钟”，因为大促期间无效订单多，锁太久会把库存“焊死”。我不建议轻易做“加入购物车锁库”。购物车转化率通常只有30%-50%，锁库会让可用库存虚低，牺牲真实销量。除非你是高客单价或爆款限量款，才值得试试。
具体数据参考：我服务过的电商客户，原来支付后才锁库，大促时组合商品超卖率有3%-5%。改成下单锁库+30分钟自动释放后，超卖率降到0.3%以内，同时因超时释放损失的订单只占2%左右，这个平衡是划算的。
落地时至少需要三张基础表：锁定明细表（订单号、SKU、锁定数量、锁定时间、过期时间）、可用库存视图（物理-锁定-安全-占用）、释放日志。没有这套明细，组合库存联动就是一句空话。专家判断：锁库时长不是一个固定值，要看“逾期支付率”和“超卖率”的拐点。如果超时释放订单很少，说明锁库时间太长；
如果超卖还很明显，说明锁库太晚。建议每周复盘一次这两个数据。
我的一个商品既单独售卖，又被用在了好几个套餐里。如果有人同时买这个单品和套餐，系统到底先把这件货给谁？是按订单先后顺序吗？如何避免订单一多就拆单发货？
子件既单卖又进套餐，本质是多个商品形式争抢同一份物理库存。要解决这个问题，不能只靠“先到先得”，必须显式定义优先级规则。常见策略有四种：一是先到先得，按订单创建时间排序，最简单，但容易把库存给到低价值订单；二是组合优先，优先保证套餐订单，适合清库存或推套餐；
三是单品优先，优先保证单品爆款，适合引流阶段；四是客户/渠道优先，VIP客户、B2B大客户订单优先，适合混合经营场景。我的判断是：没有一套普适的优先级，只有按业务目标选的优先级。如果大促冲客单价，组合优先；如果日常动销，单品优先；
如果是大客户订单，应该提前用“预留库存”功能把这批货锁住，不要依赖跑批。拆单问题也要配套处理。当订单里的部分子件缺货时，不建议整单取消，而是自动拆分发货，把缺货的子件标记为“待补货”。但如果客户要求“必须整单发货”，那么下单校验时就要按“组合整体可售”，不能按单品库存判断。
技术上，优先级可以做成“库存池分离”或“统一池硬锁”。库存池分离就是把一部分物理库存切给组合品专用，另外一部分给单品，互不抢，逻辑最清晰。统一池+数据库行锁，库存利用率最高，但工程复杂度也高。中小商家建议先从库存池分离开始。我接手过一个宠物零食商家，同一个肉干既单独卖又在三个套餐里。
原来用先到先得，每天都有两三个套餐超卖。后来改成库存池比例拆分，70%给单品，30%给套餐，超卖马上消失，客单价还提高了9%。这个例子说明，规则越清晰，越不需要靠人工救火。
我们有好几个仓库，每个仓的库存不一样，组合品在不同仓的可售数量怎么算？我在调拨商品到另一个仓，在途中的那一批货能不能算可售？如果算的话，会不会超卖？不算的话，又担心库存被浪费了，到底该怎么处理？
多仓组合库存最容易出问题的地方，是计算口径不统一。组合品库存不能只看全局汇总，要看你的发货策略。如果订单允许拆单发货到多个仓，那么组合可售量可以按所有仓子件可用量汇总后再取最小值。如果订单必须单仓发出，那就要每个仓分别算“该仓组合可售量”，最后再相加。两种口径差别非常大。
举一个数字例子：A仓有子件X有10件、子件Y有5件；B仓有X有5件、Y有10件；套餐需要X+Y。若允许拆单发，理论上能卖15份，但实际要产生两张子订单，快递成本增加；若不允许拆单，A仓最多卖5份，B仓最多卖5份，全局只能卖10份。所以先定发货策略，再定可售计算规则。
调拨在途库存，我建议默认不计入可售。原因很简单：在途不代表马上能发。如果把在途当可售，调拨延误就会出现超卖。如果一定要计入，必须同时满足两个条件：一是调拨单已经发货，且有预计到货时间；二是系统里设置“在途可售比例”，比如只允许把60%的在途量算进可售。
我接触过的一家电商企业，两个区域仓刚启用调拨时，调拨单一创建，调出仓库存马上被扣掉，组合品显示缺货，其实货正在路上。补货周期24小时，一个下午损失了70多单。后续方案是把调拨在途单独做成一个库存状态，默认不参与可售，同时增设“在途预警”，调拨发出超过安全水位就提醒补货。
这样虽然少卖了一些，但再没出现“有货发不出”的误判。专家判断：多仓阶段不要急于追求库存利用率，先保证订单不超卖。当供应链时效能力和系统实时性足够强时，再逐步开启“在途可售”，并且要在前端打预售标，给用户明确到货时间。
读者评论
作为电商运营，文中提到的组合品超卖场景太真实了，我们去年大促就遇到过类似问题，三个平台各自为政，套餐库存手工维护，结果超卖后客诉处理了很久。现在确实需要从锁库和扣减规则源头解决，而不是事后对账。
文章把组合库存的核心问题讲清楚了：物理库存不等于可售库存，关键是子件可用量的实时联动。特别是那个“只扣组合不扣子件”的误区，我们系统就有这个隐患，看完决定马上找技术评估改造方案，避免下次大促再翻车。
从实施角度看，四层规则（锁库、扣减、释放、重算）的框架很有参考价值。我们公司做家居电商，多规格组合型套餐在渠道间一直管不好，文中提到的整单锁和优先级系数确实是落地时容易被忽略的细节，值得借鉴。