校园外卖与跑腿“一套系统两用”，技术上的成立条件并不在功能菜单数量，而在于数据层能否同时做到两件事：共用同一批用户、地址、骑手和运营后台，同时让外卖订单与跑腿任务的类型、计价、履约状态和结算账目彼此隔离。下面以一张统一订单表和一套分账 SQL 为例，说明共用与分开的边界怎么落到字段和约束上，再用跨业务退款这个高频工程故障做反例验证。
一、问题拆解：二合一系统到底该共用什么
把“两用”拆成四层，选型时逐层对照，比看功能截图更容易判断一套系统是否真的能分业务核算。
| 层级 | 可共用的内容 | 必须分业务记录的内容 |
|---|---|---|
| 资源层 | 用户账号、收货地址、服务区域、管理后台入口、骑手池 | 各业务的任务池与接单权限范围 |
| 规则层 | 品牌入口、登录体系、消息通道 | 订单类型、计价模板、履约状态机、售后规则 |
| 账务层 | 统一对账入口与统计口径 | 商家货款、骑手收益、平台服务费、退款冲回 |
| 实施层 | 账号主体、骑手培训、客服流程 | 校区通行规定、分拣点位、班次与演练订单 |
资源层共用能省掉重复注册和重复装端；规则层与账务层分开，才能让外卖按订单计商家货款、跑腿按任务收服务费，在共用骑手时仍能算清每笔收益归属。工程上最常见的故障就发生在账务层：外卖与跑腿共用订单表后，退款逻辑没有按业务类型分支，导致退款金额冲回错误的账目。
微订配送调度电脑后台与手机管理页。
二、数据模型：统一订单表与业务分表
一个可落地的做法是主表统一、明细分表。主表只放两类业务共有的字段，业务差异放进各自的扩展表，避免为一半订单留大量空列。
-- 统一订单主表：只保留外卖与跑腿共有的字段
CREATE TABLE biz_order (
order_id BIGINT PRIMARY KEY,
order_no VARCHAR(32) NOT NULL UNIQUE,
biz_type VARCHAR(8) NOT NULL, -- TAKEOUT 外卖 / ERRAND 跑腿
user_id BIGINT NOT NULL, -- 与跑腿共用同一账号体系
address_id BIGINT NOT NULL, -- 共用地址簿
campus_id BIGINT NOT NULL, -- 校区，用于分站权限
rider_id BIGINT, -- 共用骑手池，未接单为 NULL
status VARCHAR(16) NOT NULL, -- 见第三节状态机
pay_amount DECIMAL(10,2) NOT NULL, -- 用户实付
created_at DATETIME NOT NULL,
CONSTRAINT ck_biz_type CHECK (biz_type IN ('TAKEOUT','ERRAND')),
CONSTRAINT ck_amount CHECK (pay_amount >= 0)
);
-- 外卖明细：商家与商品侧信息
CREATE TABLE takeout_detail (
order_id BIGINT PRIMARY KEY REFERENCES biz_order(order_id),
merchant_id BIGINT NOT NULL,
pack_fee DECIMAL(10,2) NOT NULL DEFAULT 0
);
-- 跑腿明细：任务侧信息，无商家概念
CREATE TABLE errand_detail (
order_id BIGINT PRIMARY KEY REFERENCES biz_order(order_id),
task_type VARCHAR(16) NOT NULL, -- 帮买/帮送/帮取/代取快递
pickup_addr VARCHAR(255) NOT NULL,
item_desc VARCHAR(255)
);
-- 分账流水：一笔订单可产生多条，按业务描述归属
CREATE TABLE settle_flow (
flow_id BIGINT PRIMARY KEY,
order_id BIGINT NOT NULL REFERENCES biz_order(order_id),
account_type VARCHAR(8) NOT NULL, -- MERCHANT 商家 / RIDER 骑手 / PLATFORM 平台
direction VARCHAR(8) NOT NULL, -- IN 收入 / OUT 退款冲回
amount DECIMAL(10,2) NOT NULL,
biz_type VARCHAR(8) NOT NULL, -- 冗余业务类型，便于按业务对账
created_at DATETIME NOT NULL,
CONSTRAINT ck_account CHECK (account_type IN ('MERCHANT','RIDER','PLATFORM')),
CONSTRAINT ck_direction CHECK (direction IN ('IN','OUT'))
);
关键约束有三条。其一，biz_type 在订单表和分账流水里都出现，流水冗余业务类型是为了对账时不必回表联查，也避免主表被误改后账目失去业务标识。其二，跑腿订单没有商家，takeout_detail 不允许出现对应行，分账时也不得生成 MERCHANT 流水。其三，pay_amount 只记用户实付，商品款、配送费、平台抽成的拆解全部落到 settle_flow，保证一次退款能定位到具体科目。
三、状态转换：共用骑手，分开状态机
外卖与跑腿共用骑手池，但两者的履约节点不同。外卖是“商家出餐—骑手取餐—送达”，跑腿是“接单—到取件点—取件—送达”。若强行合并成一套状态，骑手端展示的任务节点会与业务语义错位，客服也难以判断卡点。
| 业务 | 状态序列 | 允许的终止状态 |
|---|---|---|
| 外卖 | 待支付→待接单→待出餐→待取餐→配送中→已送达 | 已取消、已退款 |
| 跑腿 | 待支付→待接单→待取件→配送中→已送达 | 已取消、已退款 |
两个约定的转换约束需要写进代码：配送中不允许直接跳已退款，必须先回到已取消再退款；骑手转派只允许发生在待取餐或待取件之后、送达之前，转派时 rider_id 更新但订单号和计价不变。
微订骑手任务列表与校园宿舍配送组合。
四、核心实现：按业务类型计价与分账
下面的 SQL 用于生成外卖订单的分账流水：用户实付拆成商家货款、平台抽成和骑手配送费。跑腿订单不经过这一段，走单独的任务服务费分支。
-- 外卖订单结算：实付 = 商品款 + 包装费 + 配送费 - 优惠
-- 平台抽成按商家货款比例计算，骑手收益按配送费计算
INSERT INTO settle_flow (flow_id, order_id, account_type, direction, amount, biz_type, created_at)
SELECT 1001, o.order_id, 'MERCHANT', 'IN',
ROUND((o.pay_amount - d.pack_fee - (o.pay_amount - d.pack_fee) * 0.30), 2),
o.biz_type, NOW()
FROM biz_order o JOIN takeout_detail d ON d.order_id = o.order_id
WHERE o.order_id = 20001 AND o.biz_type = 'TAKEOUT';
INSERT INTO settle_flow (flow_id, order_id, account_type, direction, amount, biz_type, created_at)
VALUES (1002, 20001, 'PLATFORM', 'IN', 6.00, 'TAKEOUT', NOW());
INSERT INTO settle_flow (flow_id, order_id, account_type, direction, amount, biz_type, created_at)
VALUES (1003, 20001, 'RIDER', 'IN', 3.50, 'TAKEOUT', NOW());
跨业务退款是事故高发点。正确做法是先按 biz_type 判断走哪条冲回路径，再按原流水逐条生成反向记录，而不是简单按比例全额回滚。
-- 跨业务退款冲回：外卖退款冲商家货款+平台抽成，跑腿退款冲平台服务费
INSERT INTO settle_flow (flow_id, order_id, account_type, direction, amount, biz_type, created_at)
SELECT 2001 + ROW_NUMBER() OVER (ORDER BY f.flow_id), f.order_id, f.account_type, 'OUT', f.amount, f.biz_type, NOW()
FROM settle_flow f
JOIN biz_order o ON o.order_id = f.order_id
WHERE f.order_id = 20001
AND o.biz_type = 'TAKEOUT'
AND f.account_type IN ('MERCHANT','PLATFORM')
AND f.direction = 'IN';
五、异常反例：跑腿退款误冲商家账
反例场景：订单 20002 是一笔跑腿代取快递任务，用户实付 8.00 元，其中平台服务费 2.00 元、骑手收益 6.00 元，没有商家参与。如果退款 SQL 只按“account_type IN ('MERCHANT','PLATFORM')”冲回而漏掉 biz_type 判断，系统会向 MERCHANT 账户写入一条反向流水，造成两个后果：商家账上出现一笔无来源的减项，月底对账与提现申请对不上；跑腿应退的 2.00 元平台服务费反而没有冲回。
-- 错误写法：没有限制 biz_type，跑腿单也会命中 MERCHANT 分支
SELECT f.order_id, f.account_type, f.amount
FROM settle_flow f
WHERE f.order_id = 20002
AND f.account_type = 'MERCHANT' -- 跑腿单本应无此行
AND f.direction = 'IN';
-- 期望输出：0 行
-- 实际输出（故障时）：1 行，account_type = MERCHANT, amount = 0.00 的占位流水
修复方式有两层：写入侧在生成分账流水时按 biz_type 选择账户集合，跑腿单只允许 RIDER 与 PLATFORM；读取侧对账查询统一加上 biz_type 过滤，并在 settle_flow 上增加组合索引 (order_id, biz_type, direction)，让两类业务的退款走不同扫描路径。
-- 核对：按业务类型汇总冲回金额，两者应互不串账
SELECT biz_type, account_type, SUM(CASE WHEN direction='OUT' THEN amount ELSE 0 END) AS refund_amount
FROM settle_flow
WHERE order_id IN (20001, 20002)
GROUP BY biz_type, account_type
ORDER BY biz_type, account_type;
-- 预期：TAKEOUT 组出现 MERCHANT/PLATFORM 退款行；ERRAND 组只出现 PLATFORM 退款行
六、复现与验证步骤
准备 MySQL 8.0 环境，依次执行第二、四节的建表与分账语句，插入订单 20001（外卖）与 20002（跑腿）各一条主表记录及对应明细。
运行正常分账，检查
settle_flow中 20001 之行包含 MERCHANT、PLATFORM、RIDER 三类账户，20002 之行只包含 PLATFORM 与 RIDER。运行第五节错误写法，观察 20002 是否出现 MERCHANT 占位行，记录实际输出与期望输出的差异。
替换为带
biz_type过滤的修复版本，重跑退款与汇总查询，确认跑腿单的 MERCHANT 组为空、PLATFORM 组出现对应冲回金额。
上述语句为结构示例与预期输出说明，可在本地 MySQL 环境自行执行核对；真实支付通道的分账、提现还需要商户主体资质与通道开通，本地演示不涉及资金实际流转。
七、业务验收：三笔订单走完再上线
把技术核对转回经营问题，验收用三笔订单最直观：一笔外卖正常单核对商家货款与平台抽成，一笔跑腿帮买单核对任务服务费与骑手收益，一笔跨业务退款单核对两类账目是否互不串账。每笔都从用户端下单开始，依次查看商家端、骑手端和后台的订单状态与金额变化，再把账单与提现记录逐条对应。校园场景还要补两条前置条件：校门中转点位置与分拣班次须与校方通行规定一致；共用骑手的派单规则、转派收费需在目标版本实测，学生骑手的用工与保险安排按项目实际落实。部署层面，本地演示使用单机数据库即可复现上述逻辑；若迁移到云上，还需考虑订单高峰期的连接池、读写分离与流水表归档策略，这些与本地单机环境存在差异，不应把本地结果直接当作生产性能结论。
作者：微订（上海逊柯计算机科技有限公司）。
