社区团购在下沉市场持续运转的核心是三件事:开团节奏、自提点履约、团长分佣。它的技术复杂度不在流量峰值——团购是计划性购买,流量是可预期的——而在订单归集与履约单据的转换链路:用户订单怎么归集成向供应商的采购单,采购单怎么拆成每个自提点的分拣单。本文给出可落地的模型,基于 MySQL 8 + Redis,部署可用云托管。
社区团购不是"随时下单",而是"某个团长在某段时间开的某次团"。所有交易围绕团次(group_buy)展开:
CREATE TABLE leader (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(30) NOT NULL,
phone CHAR(64) NOT NULL COMMENT '加密存储',
station_id BIGINT NOT NULL COMMENT '绑定自提点',
commission_rate INT NOT NULL DEFAULT 800 COMMENT '佣金比例,万分比',
status TINYINT NOT NULL DEFAULT 1,
UNIQUE KEY uk_station_phone (station_id, phone)
);
CREATE TABLE station (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(60) NOT NULL,
addr VARCHAR(200) NOT NULL,
lat DECIMAL(10,6), lng DECIMAL(10,6),
capacity INT NOT NULL DEFAULT 200 COMMENT '日均自提承载',
status TINYINT NOT NULL DEFAULT 1
);
CREATE TABLE group_buy (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
leader_id BIGINT NOT NULL,
title VARCHAR(80) NOT NULL,
start_at DATETIME NOT NULL,
end_at DATETIME NOT NULL,
delivery_at DATE NOT NULL COMMENT '预计到货日',
status TINYINT NOT NULL DEFAULT 1
COMMENT '1开团中 2已截团 3已到货 4自提中 5已结束 6已取消',
KEY idx_leader (leader_id, start_at)
);
CREATE TABLE gb_sku (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
group_id BIGINT NOT NULL,
sku_name VARCHAR(80) NOT NULL,
spec VARCHAR(60) NULL,
price INT NOT NULL COMMENT '团购价,单位分',
stock INT NOT NULL DEFAULT 0 COMMENT '本次团限量',
sold INT NOT NULL DEFAULT 0,
sort INT NOT NULL DEFAULT 0,
KEY idx_group (group_id, sort)
);设计要点:团次到截团时间是硬边界。截团后订单锁定、进入采购,SKU 不可再改;用户下单在 end_at 之前,用服务端时间校验,别信客户端。gb_sku.stock 用条件更新防超卖(WHERE stock - sold >= qty),团购限量是刻意的稀缺运营,超卖会直接打脸运营策略。
用户订单和团长佣金是两个账本,混在一起必然出错:
CREATE TABLE gb_order (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
order_no VARCHAR(32) NOT NULL,
group_id BIGINT NOT NULL,
leader_id BIGINT NOT NULL,
user_id BIGINT NOT NULL,
total INT NOT NULL,
commission INT NOT NULL COMMENT '本单佣金,下单时锁定',
status TINYINT NOT NULL DEFAULT 1
COMMENT '1已支付 2截团 3已到货 4已自提 5售后中 6已退款',
picked_at DATETIME NULL,
UNIQUE KEY uk_no (order_no),
KEY idx_group_status (group_id, status),
KEY idx_leader (leader_id, status)
);佣金在下单时按当期比例锁定,而不是结算时再算——团长改级别、活动期比例变化,都不影响历史订单。佣金入账条件是订单走到"已自提"(用户提走),退款单要同步冲减佣金。账目规则一句话:商品的钱跟订单走,佣金的钱跟履约走。
截团那一刻,系统要把几千笔用户订单转换成三种单据:
async function closeGroup(groupId) {
const orders = await db.query(
`SELECT * FROM gb_order WHERE group_id = ? AND status = 1`, [groupId]);
// 1. 汇总为采购单:按 SKU 聚合
const purchase = groupBy(orders.map(o => o.items))
.map(([skuId, qty]) => ({ skuId, qty: sum(qty) }));
// 2. 拆分为自提点分拣单:按 leader 归组
const picking = groupBy(orders, o => o.leader_id)
.map(([leaderId, os]) => ({
leaderId,
lines: groupBy(os.map(o => o.items)) // 每个自提点的拣货明细
}));
// 3. 生成售后责任快照:每个 SKU 在截团时的供应商
// (供应商换批次后,售后归属要按截团时点判断)
await savePurchaseSheet(groupId, purchase);
await savePickingSheets(groupId, picking);
}三种单据的用途:采购单给供应商,按 SKU 汇总数量;分拣单给每个自提点,到货后按单分货;售后快照记录截团时的采购归属,因为生鲜售后常在到货两三天后才发生,那时供应商可能已经换了批次,没有快照就说不清责任。
分拣单打印格式值得花心思:团长不是仓库管理员,单据要按"谁订的什么、几份、电话尾号"排,到货时团长按单喊人取货。这是打印模板的问题,不是架构问题,但直接影响履约效率。
到货后,货从供应商到自提点,用户来提。状态推进的准确率决定体验:
- 到货登记:团长在小程序端确认"本团已到货",缺货 SKU 单独登记,触发该 SKU 订单的自动退款流程;- 自提核销:用户出示取货码,团长扫码核销,订单置为已自提、佣金入账;- 超时未取:到货 N 天未取的订单提醒用户,再超时按规则处理(生鲜类通常电话催提后销毁,损耗记账)。
缺货处理要单独建模。生鲜团购缺货是常态,缺一个 SKU 不能整单退款,要按行退款:
CREATE TABLE gb_refund_item (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
order_id BIGINT NOT NULL,
sku_id BIGINT NOT NULL,
qty INT NOT NULL,
amount INT NOT NULL,
reason VARCHAR(100) NOT NULL COMMENT '缺货/质量/少称',
status TINYINT NOT NULL DEFAULT 1 COMMENT '1待退 2已退',
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
KEY idx_order (order_id)
);行级退款同步冲减对应佣金,两本账的联动要在同一个事务里完成。
生鲜的称重差异也要单独处理。团购按份卖,但水果蔬菜按斤进货,每份实际重量有出入。做法是下单时按份计价,到货后允许团长登记"少称"记录,平台按规则补差或者下次发货加量,小额差异免报处理。把"每单必须分毫不差"的执念放下,换成小额差异的批量化处理,履约成本和客诉都会下降。
团长提现和风控别做成事后补丁。佣金入账有 T+N 的确认期(覆盖售后窗口),提现走小程序内转账,单日限额和异常提现(新团长大额提现、多账号同设备)要有拦截。团购平台的资金安全事件,几乎都出在"佣金规则改了但历史订单没锁定"和"提现无风控"这两件事上,前面讲的"佣金下单时锁定"就是为这里埋的伏笔。
生鲜的称重差异也要单独处理。团购按份卖,但水果蔬菜按斤进货,每份实际重量有出入。做法是下单时按份计价,到货后允许团长登记"少称"记录,平台按规则补差或者下次发货加量,小额差异免报处理。把"每单必须分毫不差"的执念放下,换成小额差异的批量化处理,履约成本和客诉都会下降。
团长提现和风控别做成事后补丁。佣金入账有 T+N 的确认期(覆盖售后窗口),提现走小程序内转账,单日限额和异常提现(新团长大额提现、多账号同设备)要有拦截。团购平台的资金安全事件,几乎都出在"佣金规则改了但历史订单没锁定"和"提现无风控"这两件事上,前面讲的"佣金下单时锁定"就是为这里埋的伏笔。
团长的留存决定平台生死,而团长最关心的是"我这个月挣了多少、哪个品好卖"。给团长的小程序端要有:佣金明细(逐单可查、提现记录)、本团销量排行、好货推荐(平台按区域动销数据推送)。技术实现不难,一个聚合查询加图表,但它让团长从"帮平台转发链接的人"变成"经营自己社群的老板",这个心态差别就是流失率差别。
社区团购的工程主线:团次是一等公民、截团单据转换是骨架(采购单 + 分拣单 + 售后快照)、佣金下单锁定且跟履约入账、缺货走行级退款、团长端数据透明。青海青帝信息科技有限公司在本地团购类项目里,会先做"截团到分拣"这条链路的全流程演练再上线——这条链路断一环,到货那天几十个自提点同时乱掉,补不回来。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。