从SKU穷举到可组合交易：客制化属性商品模型的领域建模与工程落地

目录一、问题的本质：定制化商品不是“更多SKU”，而是“可组合交易”（一）从消费体验反推商品模型1、线下的自由组合与线上的固定规格存在天然张力2、判断一个字段应不应该进入SKU，要看它是否具有独立经营语义（二）把“商品”和“成交结果”分开，是模型稳定性的起点二、为什么“把配料做成销售属性”会必然失控（一）组合爆炸不是实现细节，而是模型选错后的数学结果1、传统SKU模型的增长方式是乘法1.1 组合数量增长快于业务人员的理解能力1.2 组合模型无法自然表达“默认值”和“份数”2、动态上下文会让静态SKU穷举进一步失效（二）SKU的库存语义被稀释，会反过来伤害供应链和数据体系1、SKU本来应该代表可独立识别的库存或经营单元2、原材料库存和成品SKU库存应当分层处理（三）当模型语义错误时，系统会出现一连串“补丁式复杂度”三、建模转向：用“SKU + 客制化属性”构造最终交易单元（一）职责分离比新增一个字段更重要1、SKU继续负责稳定的商品身份2、客制化属性负责成交时的可选内容3、客制化规则负责“在什么条件下可以怎么选”（二）一个可落地的核心对象集合1、目录层对象1.1 Product：聚合展示和经营信息1.2 SKU：可售变体和基础价格2、配置层对象2.1 CustomizationGroup：客制化组2.2 CustomizationOption：具体选项2.3 CustomizationRule：上下文规则3、交易层对象3.1 Selection：用户本次选择3.2 PriceSnapshot：价格快照3.3 OrderItemSnapshot：订单商品快照四、规则模型：从“字段开关”升级为可解释的约束系统（一）规则的本质是把配置空间裁剪到业务允许的范围1、先定义可选空间，再定义条件变化2、规则需要明确优先级，否则“覆盖”会变成不可预测2.1 默认规则2.2 SKU覆盖规则2.3 门店/渠道规则2.4 交易上下文规则（二）规则不是越通用越好，而要围绕高频业务模式收敛1、优先使用结构化规则表达80%的需求2、复杂表达式只能作为受控扩展五、价格模型：从“SKU有一个价格”升级为“交易价格可分解、可复现”（一）实时计价必须先确定价格责任边界1、基础价属于SKU，增量价属于客制化项2、默认份数与“已包含份数”必须区分（二）复杂价格需要从“固定加价”逐步演进，而不是一次做成万能引擎1、固定单价与阶梯价2、SKU相关价格3、组合价格与套餐价格（三）购物车、下单、退款必须共享同一套计价口径六、库存与履约：弱库存场景不等于可以忽略资源约束（一）成品SKU库存、门店产能和原材料库存是三类不同约束1、成品SKU库存2、原材料库存3、产能与设备约束（二）“客制化属性不进入SKU”并不意味着它脱离供给体系七、前台交互：一个好模型应该直接生成正确的选择体验（一）商品模型不只是后台数据结构，它应该驱动前台状态1、前端不应硬编码某个品牌或品类的选择规则2、禁用比报错更好的前提，是规则能够提前计算3、默认选择要可解释，不能偷偷改变成交价（二）前台选择状态应被视为一个受约束状态机八、接口与数据结构：让配置、选择和快照在协议层有清晰边界（一）商品详情接口应返回“可配置视图”，而不是数据库表的直出1、一个建议的读取模型2、写入接口只提交“事实”，不要提交客户端计算结果（二）规则版本是分布式一致性的关键抓手1、为什么需要configVersion2、版本不要只靠updatedAt九、性能与缓存：实时计算不意味着每次都去拼接几十张表（一）运行时应该消费“编译后的商品配置”，而不是原始运营数据1、配置态与运行态分离2、缓存键必须包含影响结果的上下文（二）规则引擎的性能优化重点不是“算得快”，而是“少算和可预测”1、建立依赖索引2、将静态规则提前折叠3、报价接口要幂等十、订单快照与可审计性：今天卖出的商品，半年后仍要解释得清（一）订单不能只保存ID引用1、商品名称和选项名称都需要快照2、价格必须保存逐项明细3、关键规则结果也应快照（二）修改商品配置时，要明确“新单”和“历史单”的边界十一、迁移路线：从“配料SKU”平滑切换到客制化属性（一）第一步不是删SKU，而是识别哪些维度被误建模1、按业务语义给现有属性分类2、优先迁移组合爆炸最严重的维度（二）双轨期要保证老链路可回退1、建立旧SKU到“基础SKU + Selection”的映射2、灰度发布时同时比对价格3、等订单、库存、履约、报表都完成适配后再下线旧SKU十二、测试体系：定制化模型最需要验证“组合边界”，而不是只测几个样例（一）规则测试要覆盖边界值和组合关系1、数量边界2、联动边界3、互斥与依赖（二）价格测试应采用“金丝雀案例 + 属性测试”结合1、金丝雀案例2、属性测试（三）性能测试要贴近用户连续点击的真实节奏十三、治理与扩展：把“客制化属性”做成能力，而不是新的万能垃圾桶（一）何时适合使用客制化属性1、餐饮和现制商品2、轻定制零售3、服务型商品（二）哪些内容仍然应该坚持使用SKU1、需要独立库存的变体2、具有长期编码和财务身份的变体（三）客制化属性必须设置能力边界1、不要把搜索筛选属性混入客制化2、不要把营销规则全部塞进客制化规则3、不要把后厨工艺全文当作前台选项十四、常见误区：模型重构最容易在这些地方再次走回老路（一）误区一：只是把“销售属性”改名成“客制化属性”（二）误区二：客制化属性可以无限嵌套、无限联动（三）误区三：既然实时计价，就不需要价格版本（四）误区四：只改商品中心，不改订单和履约（五）误区五：为了减少SKU，反而把真正的库存变体也客制化十五、落地方法论：用六个问题判断模型是否健康（一）面向架构评审的检查框架1、这个选择是否需要形成长期独立经营单元2、这个选择是否允许多选、重复或数量变化3、这个选择是否会被SKU、门店、渠道或时间改变约束4、价格是否能够逐项解释并在历史订单中复现5、供给约束究竟属于成品库存、材料库存还是产能6、前端能否仅依靠服务端元数据完成正确交互十六、结语：把SKU从“所有选择的容器”还原为稳定的商业身份可参考文章与文档干货分享，感谢您的阅读！在茶饮、咖啡、餐食、烘焙、礼赠等行业里，“商品”正在从一个固定成品，演化为一个可以在交易时被用户重新配置的组合体。杯型、温度、糖度、加料、份数、酱料、制作方式等信息，表面上都像商品属性，但它们的业务语义并不相同：有些决定可独立管理的库存单元，有些只是成交时的个性化选择；有些改变基础价格，有些只产生加价；有些需要控制必选、默认、最大份数，有些还会随着SKU、门店、渠道和时间发生联动。如果把这些差异全部压进传统“销售属性 → SKU”的组合模型，就会快速遭遇SKU数量爆炸、库存语义错位、运营配置困难、价格难以解释、订单历史不可复现等问题。本文以“客制化属性”这一思路为起点，对原方案进行重新抽象与工程化扩展：保留SKU作为真正可销售、可库存、可履约的核心单元，把加料、做法等交易时选择拆分为独立的客制化属性；再通过规则层、定价层、库存/履约层和交易快照层建立稳定边界。文章进一步给出领域模型、规则建模、实时计价、接口结构、缓存与性能、订单审计、迁移方案和测试体系，目标不是为茶饮单一场景“打补丁”，而是构建一套能够延伸到餐饮、