不过，

拼单功能的设计往往让人误以为需要彻底改造订单和支付程序。只需在协作阶段做足准备，主要业务几乎不需要改动。下面把完整流程、数据模型和关键约束拆解成易读的 HTML 版，方便你定位痛点并解决。

拼单就是多人协作完成一笔统一订单。每个人挑选自己的商品后所有商品汇总成一笔订单，由发起人统一支付。

从痛点来看，如何让多个人同时选品又能统一下单？

业务流程拆解

1️⃣ 选品阶段

1. 发起人创建拼单组 → 选择门店、配送方式。按理说，
2. 程序生成10位唯一标识。发起人分享链接，
3. 朋友通过链接加入组，分别选品。
4. 选完后点击「确认」，等待其他人确认。
5. 发起人确认全部完成后点击「去下单」锁定组。

2️⃣ 下单支付阶段

1. 锁定后发起人进入正常下单流程，携带 uniqueId 提交订单。
2. 程序将所有人的选品合并为一笔订单，发起人统一支付。
3. 支付与普通订单一致，一笔钱对应一个订单。

3️⃣ 费用分摊阶段

1. 支付完成后程序计算每位参与者应付金额。
2. 发起人通过群收款向参与者收取各自费用。

Pain Point:

• 同一使用者多组冲突：同一使用者只能在一个进行中的拼单组内操作，否则状态混乱。方法是强制退出已有组再创建新组。
• 过期失效：48小时内未提交自动过期，避免僵尸拼单占用资源。实现通过延时任务 + Redis TTL 自动失效。

订单域 & 支付域改造

从订单域来看，加类型值 + 一张关系表

ALTER TABLE orders ADD COLUMN order_type tinyint NOT NULL DEFAULT 0;怎么说呢，

Add enum value for 拼单订单 .

Create relation table:

CREATE TABLE order_group_order (
id bigint unsigned NOT NULL AUTO_INCREMENT。group_id bigint NOT NULL COMMENT '拼单组ID',order_id bigint NOT NULL COMMENT '订单ID',created_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,PRIMARY KEY,KEY idx_group_id,KEY idx_order_id
) COMMENT='拼单组与订单关系表';

This keeps core orders table untouched;话说回来，only a tinyint flag is added.

从支付域来看。回调里加一行状态同步 + 分摊计算

// 支付成功回调
function onPaymentSuccess {
// 正常标记已支付
updateOrderPaid;// 更新拼单组状态为「已完成」
updateGroupStatus;// 执行费用分摊
calculateFeeSplit;}

No changes to payment chain,no new APIs.

拼单组表设计

CREATE TABLE order_group (
id bigint PRIMARY KEY。unique_id varchar UNIQUE,creator_id bigint,shop_id bigint,address_id bigint,status tinyint DEFAULT 0,--0:选品中,1:已提交,2:已完成,3:已取消,4:已过期
create_channel varchar,share_channel varchar,expire_at datetime
);

CREATE TABLE order_group_member (
id bigint PRIMARY KEY。group_id bigint,user_id bigint,join_channel varchar,status tinyint DEFAULT 0 --0未选品,1选品中,2已确认,...
);不过，

上面示例省略了冗长字段列表。以突出结构，实际实现请按业务需求补全字段。

• 每个使用者只能在一个进行中的组合内；若要新建需先退出旧组，
• 发起人不可退出，仅能取消整个组合；取消原因存独立表供运营分析。
• 锁定后可解锁，但只允许在未生成正式订单前；已生成则不可逆转，
• 48小时无提交自动过期；Redis TTL 与业务规则保持一致。
• 群收款人数上限100；超出会报错且不展示按钮，
• 微信小程序渠道才能使用群收款 API；非微信渠道只显示分摊明细。
• 门店/地址可在提交前修改，以应对临时变更需求。老实说，
• 'cancel_reason' 字段独立存储取消原因。用于运营分析，

  ---

  Redis 缓存方案：高频实时协作

  ts // Key patterns per day: const membersKey = `order:group:${date}:members:${uniqueId}`;// Hash – member info const goodsKey = `order:group:${date}:goods:${uniqueId}`;// Hash – per-user goods list const statusKey = `order:group:${date}:status:${uniqueId}`;// String – state snapshot
  • Why Redis?
  • 高频读写。

  • 大量废弃数据。TTL 自动清理，无需手动删除数据库。

  • 持久化时间点 Only when 发起人 clicks “去下单” do we read all data from Redis and write:

  • 合并到 orders / orders_items；
  • 写入 order_group_item；
  • 写入 order_group_order.

  ---

  成本分摊计算算法

ts function calcSplit{ const totalOrig = sum;const totalDiscount = sum;

items.forEach(it=>{ it.userdiscount = it.originprice / totalOrig * totalDiscount;})，// Round & adjust difference to initiator if any discrepancy. }

• 边界校验若某成员最终应付 <=0，需要前端提示“请检查折扣是否合理”。

群收款流程 & 条件限制

ts POST https://api.weixin.qq.com/wxa/business/groupBuy/createOrder { "openIds":。"amounts": }

再看条件，- 当前使用者必须是 发起人；- 客户端必须是 微信小程序；怎么说呢，- 拼团创建渠道 & 分享渠道均为 微信小程序；话说回来，- 人数 <=100。

如果任一步骤不满足。则仅显示“费用分摊明细”，无需群收款。不过，

撤销与退款机制

再看撤销，

从Refund来看，

• 全部退款走正常退款链路至 发起人账户。
• 若想给参与者退款。只能手动微信转账，因为群收款金额不属于程序支付链路。

状态机图示概览

align=center height=

width= 400px bgcolor=#ffffcc>