潮玩小程序订单模型：商城单、抽盒单、一番赏单，怎么用一张表装下
摘要：潮玩小程序里有商城、抽盒机、一番赏、会员赏等多种玩法，每种都要下单。如果每个玩法建一套订单表，库存、对账、售后全乱套。本文讲怎么用一张 order_tbl + 订单类型枚举 + 两段式支付状态机，把所有玩法的订单统一成一个模型，并讲清订单状态机设计与后续 ERP 对接的接口。
痛点：玩法可以很多，订单表不能很多
一个潮玩小程序，玩法往往不止一种：
- 商城：用户直接买 IP 周边、手办
- 抽盒机：抽一盒，先买后拆
- 一番赏：排队抽赏，奖池制
- 还有会员赏、新人赏、社区奖励......
每种玩法都要下单、支付、发货、退款。如果图省事，每个玩法建一套订单表，会出三个问题：
1. 库存对不上。
商城卖一个手办、抽盒机抽到同一个手办、一番赏赏出同一个手办------三个玩法都动库存，但三张订单表互相看不见，超卖了你都不知道是哪个玩法卖超的。
2. 对账想死。
微信支付每天对账，你拿着支付流水，却要在好几张订单表里分别找"这笔钱对应哪笔订单"。对账脚本越写越长，还容易漏。
3. 售后各搞一套。
退款、发货、查物流，每个玩法一套逻辑。用户问"我那个退款到哪了"，客服要翻三四个后台。
结论：玩法可以多，订单模型必须是一个。 这篇讲一套真实跑在潮玩小程序里的统一订单模型。
方案选型：多表各管各，还是单表 + 类型区分？
结论先行：用一张订单主表 + 一个"订单类型"字段，把不同玩法的订单统一装进去。
| 维度 | 每玩法一套表 | 单表 + 类型枚举（本方案） |
|---|---|---|
| 库存联动 | 各表独立，容易超卖 | 同一套商品/库存，天然一致 |
| 支付对账 | 多个表分别找 | 一张表，按时间/类型筛 |
| 售后 | 每个玩法一套 | 一套售后链路复用 |
| 新增玩法 | 又建一张表 | 加一个枚举值就行 |
| 订单查询 | 联表复杂 | 一张表直接查 |
关键设计 ：订单表里加一个 type 字段，用一个枚举标记订单来自哪个玩法。
这套代码里，订单类型长这样：
PRODUCT：实物商品GOODS：线上商城LOTTERY：一番赏LOTTERY_VIP：会员赏LOTTERY_NEWER：新人赏SHOW_AWARD：社区/内容奖励
好处：以后要加新玩法（比如新的活动抽奖），不需要动订单表结构，加一个枚举值、复用下单链路就行。订单表永远是那一张，越跑越稳。
架构：一张订单表 + 两段式支付状态机
结论先行：订单模型的核心是"一张订单主表承载所有玩法 + 一个状态机管好两段支付"。
┌──────────────────────────────────┐
│ order_tbl │
│ orderId / openId / drawId │
│ productName / productPrice │
│ 收货信息 / 状态 / 运费单号 │
└───────────────┬──────────────────┘
│ type 区分玩法
┌──────────────┬─────────┴────────┬──────────────┐
▼ ▼ ▼ ▼
商城订单 抽盒订单 一番赏订单 会员赏订单
(GOODS) (PRODUCT+drawId) (LOTTERY) (LOTTERY_VIP)几个关键设计点：
1. drawId 把订单和盒绑定。
抽盒机的订单，通过 drawId 直接关联到"抽中的那一盒"。用户付款后，系统查这个 drawId 对应的盒子，就知道他抽到了什么，然后发货。订单和玩法数据通过关联字段打通，而不是各存各的。
2. 两段式支付：先付产品款，再付运费。
潮玩小程序的支付是分两段的，状态机也对应两段：
产品款： 待支付 → 已支付 / 支付失败 / 支付超时
运费款： 待支付 → 已支付 / 支付失败 / 支付超时
最终态： 已退款为什么拆两段？因为盲盒玩法里，用户可能抽完先只付产品款，后面确认要收货地址了再付运费（或者凑单免邮）。两段各自独立状态，用户体验灵活，状态也清晰。
3. 状态全部落库，字符串枚举。
订单状态用枚举字符串存（如 PAY_PRODUCT_SUCCESS），可读、可查、可对接微信支付回调。用户在小程序里看到"待发货/已发货/已退款"，后台就是这些状态的直观映射。
4. 关联表补齐闭环。
一张主表之外，订单的周边信息拆到关联表：
- 回收表：盲盒特有的"单件回收"（抽到不想要的可以回收）
- 退款表：退款记录、退款状态
- 合并包裹表：一个订单多个商品合并发货
- 物流记录表：每次发货的物流轨迹
主表管"这笔订单是什么、现在什么状态"，关联表管"这个订单的售后/物流细节"。不把一张表塞成万能表。
实现思路：四条核心链路
1. 下单------不同玩法，同一条链路
结论先行：所有玩法的下单，最终都汇入同一套"建订单 → 调支付"链路，区别只在订单类型。
- 商城：用户点购买 → 建一条
GOODS订单 - 抽盒机：用户抽一盒 → 建一条
PRODUCT订单，带上drawId - 一番赏：玩家抽中赏品 → 建一条
LOTTERY订单
每个玩法入口不同，但都调用同一套下单逻辑，只是传的 type 不同。这就是统一模型的价值：玩法是插件，订单是地基。
2. 支付------微信支付回调驱动状态流转
结论先行：支付状态不靠轮询，靠微信支付回调精确驱动。
用户拉起支付 → 微信扣款 → 微信回调你的服务器 → 回调里按订单号找到订单 → 把状态从"待支付"改成"已支付" → 触发后续（发货/揭晓/抽奖结算）。
两段式也一样：产品款回调驱动产品款状态，运费款回调驱动运费款状态。回调是状态机的唯一驱动力，这样不会出现"钱扣了但状态没更新"的错位。
3. 发货与合并------状态推进到可发货
产品款已付、运费款已付（或免邮）后，订单进入可发货状态。后台可以：
- 单个发货，录入快递单号
- 批量发货，一次处理多个订单
- 一个订单多个包裹，合并/拆分发货（合并包裹表记录）
物流记录落到物流表，用户端随时能查"到哪了"。
4. 售后------退款、回收各走各的闭环
- 退款 ：用户申请 → 后台审核 → 微信退款 → 退款表记录 → 订单状态置
已退款 - 盲盒回收：抽盒机特有的------用户抽到不想要的，可以走"单件回收"，回收审核通过后按规则处理
售后是订单模型的延伸，都挂在同一张主表下，按订单号就能查全生命周期。
验证：这套订单模型靠不靠谱
结论先行：统一表 + 类型枚举 + 回调驱动状态机，订单全生命周期可查、可对账、可扩展。
- 可对账：所有订单在一张表里，微信支付流水的每一笔都能定位到具体订单（按订单号/时间/类型筛），日结对账一把梭
- 可扩展：加新玩法 = 加枚举 + 复用链路，不动表结构，不动支付，不动售后
- 可追溯：从下单 → 支付 → 发货 → 售后，全程一张表 + 关联表，任何一笔订单都能回溯到具体玩法、具体盒、具体支付流水
- 可对接：统一模型给后续对接 ERP（旺店通，见 C 系列）铺好了路------ERP 要的就是一张干净的订单主表，按类型区分，推过去就是标准结构
常见问题（FAQ）
Q1：为什么商城单和抽盒单不用两张表？
因为库存、支付、对账、售后都要打通。两张表意味着两套逻辑，超卖、漏对账、售后分裂是必然结果。单表 + type 区分，一套逻辑管所有玩法。
Q2：订单类型怎么区分？
一个 type 字段 + 枚举。下单时按玩法传入（商品/商城/一番赏/会员赏/新人赏/社区奖励），查询、对账、报表按 type 分组即可。
Q3：为什么支付要分两段？
盲盒玩法里，用户可能先只付产品款、之后再付运费（或凑单免邮）。两段独立状态，用户灵活、状态清晰，也方便做"包邮门槛"这类运营逻辑。
Q4：支付状态靠什么更新？
微信支付回调，不靠轮询。回调里验签、按订单号定位、更新状态、触发后续，保证"钱到账"和"状态更新"严格一致。
Q5：抽盒机的订单怎么知道用户抽到了啥？
订单表带 drawId，关联到抽盒记录。用户付款后，按 drawId 查到对应的盒子/赏品，就知道发什么货。
Q6：统一订单模型怎么和 ERP 对接？
统一模型正是 ERP 对接的前提。一张干净的订单主表 + type 区分，推给 ERP（如旺店通）时就是标准结构：按订单号推、按类型分、状态字段一一映射。库存、物流、退款也都能在统一模型上做同步。这一块在系列的 C 篇（旺店通对接）详细展开。
总结：这套订单模型的可复用要点
- 一张订单主表装下所有玩法：type 枚举区分，库存/支付/对账/售后全打通
- 抽盒单用 drawId 关联玩法：订单和"抽到哪盒"通过关联字段绑定，不各存各的
- 两段式支付状态机：产品款、运费款各自独立状态，回调驱动，清晰可靠
- 周边信息拆关联表：回收、退款、合并包裹、物流各一张表，主表不臃肿
- 为 ERP 铺路：统一订单模型，后面对接旺店通（C 系列）就是标准结构直接推
下一篇：盲盒特有的售后链路------拆盒确认、回收审核与退款资金流（B4）。
本文基于真实生产代码撰写。关注我，潮玩盲盒电商的从0到1。