不懂技术搭建校园生活平台，落到工程上不是先写代码，而是先把“一笔订单如何变成商家账、骑手账和平台账”定义清楚，再用成熟系统配置验证。只要这四类数据——订单、结算单、退款单、分账明细——的字段约束和状态转换明确，即使由标准产品承载，也能在试用账号里走通正常单、部分退款和结算后退款；反过来，字段缺失或状态随意跳转，就是后期人工对账的根源。本文给出可直接建表的核心模型、正常与异常输入输出，并解释它如何用于系统选型和上线验收。
一、业务问题：为什么“跑通一笔订单”比“功能清单长”更重要
校园生活平台通常同时有校园外卖、代取快递和跑腿。三者的共同点是：一个用户下单、一个商家（或取件点）履约、一个骑手配送、平台按规则抽成。真正容易出问题的地方集中在两处：一是订单状态被重复事件推动，例如支付回调重复到达导致重复生成结算；二是资金账在退款时没有按原订单冲减，导致商家应结、骑手收入和平台抽成对不上。
微订校园外卖、代取快递、校园商城、信息发布、二手交易与跑腿配送业务矩阵。
因此搭建时的技术验收目标可以归纳为：同一订单事件只产生一次有效业务结果；每笔资金变动都能追溯到原订单和原分账明细；退款、结算和提现的状态不能跳步。下面用一套最小数据模型说明如何约束这三点。
二、数据模型：订单、结算、退款、分账明细的字段与约束
表结构按“订单主表 + 分账明细 + 结算单 + 退款单”组织。金额统一用“分”为单位的整数，避免浮点误差；状态字段用短字符串枚举，并由应用层和数据库约束共同限制。以下SQL以通用语法书写，本地演示使用SQLite，生产环境可迁移到MySQL或云数据库。
-- 订单主表：一笔订单对应一次用户支付
CREATE TABLE orders (
order_no TEXT PRIMARY KEY, -- 业务单号，全局唯一
campus_id TEXT NOT NULL, -- 校区/站点，多校区隔离键
user_id TEXT NOT NULL,
merchant_id TEXT NOT NULL,
rider_id TEXT, -- 未派单时为空
amount_total INTEGER NOT NULL CHECK (amount_total >= 0), -- 用户实付，单位分
amount_goods INTEGER NOT NULL CHECK (amount_goods >= 0), -- 商品款
amount_delivery INTEGER NOT NULL CHECK (amount_delivery >= 0),
amount_discount INTEGER NOT NULL DEFAULT 0 CHECK (amount_discount >= 0),
status TEXT NOT NULL CHECK (status IN ('created','paid','accepted','delivering','completed','refunding','refunded','closed')),
paid_at TEXT,
completed_at TEXT,
created_at TEXT NOT NULL,
UNIQUE (campus_id, order_no)
);
-- 分账明细：订单完成时按规则生成，一行代表一个收款方
CREATE TABLE split_items (
id INTEGER PRIMARY KEY AUTOINCREMENT,
order_no TEXT NOT NULL,
payee_type TEXT NOT NULL CHECK (payee_type IN ('merchant','rider','platform')),
payee_id TEXT NOT NULL,
amount INTEGER NOT NULL CHECK (amount >= 0),
reversed INTEGER NOT NULL DEFAULT 0 CHECK (reversed IN (0,1)), -- 是否已被退款冲减
settle_id TEXT, -- 归属结算单，未结算为空
created_at TEXT NOT NULL,
UNIQUE (order_no, payee_type, payee_id), -- 同一订单同一收款方只允许一条
FOREIGN KEY (order_no) REFERENCES orders(order_no)
);
-- 结算单：按账期把若干分账明细打包，提现以其为对象
CREATE TABLE settlements (
settle_id TEXT PRIMARY KEY,
payee_type TEXT NOT NULL,
payee_id TEXT NOT NULL,
amount INTEGER NOT NULL CHECK (amount >= 0),
status TEXT NOT NULL CHECK (status IN ('pending','confirmed','withdrawn')),
period_start TEXT NOT NULL,
period_end TEXT NOT NULL
);
-- 退款单：记录原订单、退款金额和退款时订单所处阶段
CREATE TABLE refunds (
refund_no TEXT PRIMARY KEY,
order_no TEXT NOT NULL,
amount INTEGER NOT NULL CHECK (amount > 0 AND amount <= (SELECT amount_total FROM orders WHERE order_no = refunds.order_no)),
stage TEXT NOT NULL CHECK (stage IN ('before_settle','after_settle')),
status TEXT NOT NULL CHECK (status IN ('created','succeeded','failed')),
created_at TEXT NOT NULL,
FOREIGN KEY (order_no) REFERENCES orders(order_no)
);
关键约束说明：order_no 在同一校区内唯一，便于分站各自出账；split_items 对同一订单同一收款方设唯一键，这是防止重复回调生成重复分账的第一道闸；refunds.amount 的 CHECK 子查询限定单笔退款不超过订单实付；stage 区分退款发生在结算前还是结算后，决定账务是冲减待结算还是调整已结算账单。
三、状态转换：订单与退款不能跳步
订单状态按 created → paid → accepted → delivering → completed 单向推进；closed 只能从 created 或 paid 进入；refunding / refunded 由 completed 之后的售后触发，且必须存在对应的 refunds 记录。退款单状态为 created → succeeded 或 created → failed，失败后可重试但不改变原订单号。
微订商家手机订单页，展示订单筛选、配送状态与订单详情入口。
| 当前状态 | 允许事件 | 下一步 | 资金动作 |
|---|---|---|---|
| created | 支付成功回调 | paid | 记录 paid_at，不生成分账 |
| paid | 商家接单 | accepted | 无 |
| accepted | 骑手取货 | delivering | 无 |
| delivering | 送达确认 | completed | 生成 split_items 三条明细 |
| completed | 发起退款 | refunding | 生成 refunds，stage 按是否已结算取值 |
| refunding | 退款成功 | refunded | 对应 split_items.reversed=1 或生成调整记录 |
这里的技术要点是：状态推进由“带条件的更新语句”完成，而不是先查再改。例如接单操作写成 UPDATE orders SET status='accepted' WHERE order_no=? AND status='paid'，依据受影响行数判断是否成功，可避免并发下重复接单。
四、核心实现：分账计算与可重复执行的退款冲减
以下 Python 示例只使用标准库 sqlite3，在本地内存库中执行。它模拟订单完成后按比例生成分账，并在退款时做冲减，重点演示幂等处理。
import sqlite3
DDL = open('schema.sql', encoding='utf-8').read()
def init_db():
conn = sqlite3.connect(':memory:')
conn.executescript(DDL)
return conn
def settle_order(conn, order_no, total, goods, delivery, discount, platform_rate=0.05):
"""订单完成：状态推进 + 生成分账，可重复调用。"""
cur = conn.execute(
"UPDATE orders SET status='completed', completed_at=datetime('now') "
"WHERE order_no=? AND status='delivering'", (order_no,))
if cur.rowcount != 1:
return {
"ok": False, "reason": "状态不允许完成或订单不存在"}
platform_fee = int((goods - discount) * platform_rate)
merchant_amt = goods - discount - platform_fee
rows = [('merchant', 'M001', merchant_amt),
('rider', 'R001', delivery),
('platform', 'P001', platform_fee)]
for payee_type, payee_id, amt in rows:
conn.execute(
"INSERT INTO split_items(order_no,payee_type,payee_id,amount,created_at) "
"VALUES(?,?,?,?,datetime('now')) "
"ON CONFLICT(order_no,payee_type,payee_id) DO NOTHING",
(order_no, payee_type, payee_id, amt))
conn.commit()
return {
"ok": True, "platform_fee": platform_fee, "merchant_amt": merchant_amt}
def refund(conn, refund_no, order_no, amount, stage):
"""退款：写退款单并冲减分账，同一退款单号重复提交不重复冲减。"""
try:
conn.execute(
"INSERT INTO refunds(refund_no,order_no,amount,stage,status,created_at) "
"VALUES(?,?,?,?, 'created', datetime('now'))",
(refund_no, order_no, amount, stage))
except sqlite3.IntegrityError:
return {
"ok": False, "reason": "退款单已存在"}
conn.execute("UPDATE orders SET status='refunded' WHERE order_no=?", (order_no,))
if stage == 'before_settle':
conn.execute("UPDATE split_items SET reversed=1 WHERE order_no=?", (order_no,))
else:
# 结算后退款：保留原分账，另记调整（此处简化为标记 reversed）
conn.execute("UPDATE split_items SET reversed=1 WHERE order_no=?", (order_no,))
conn.execute("UPDATE refunds SET status='succeeded' WHERE refund_no=?", (refund_no,))
conn.commit()
return {
"ok": True}
运行步骤：把第二节SQL保存为 schema.sql，与上述代码放在同一目录，使用 Python 3.9 及以上版本执行。预期输出：正常订单完成时返回平台抽成与商家应结金额，split_items 恰好三行；同一订单再次调用 settle_order 返回 {'ok': False, 'reason': '状态不允许完成或订单不存在'}；重复退款单号返回 {'ok': False, 'reason': '退款单已存在'}。
需要说明：以上为本地内存库演示，未连接真实支付通道或云资源，也未在客户环境执行；真实开通分账还取决于支付机构规则、经营主体资质和版本配置。若部署到云上，云数据库只承担存储与备份职责，业务幂等仍需在应用层实现，本地与云环境在事务隔离和网络超时行为上会有差异，测试需分别覆盖。
五、反例与验证：两类最容易被忽略的资金异常
反例一：重复支付回调
支付平台可能对同一笔订单多次回调。若处理逻辑是“回调即插入分账”，第二笔回调会因唯一键冲突报错，但若代码吞掉异常并继续改状态，就会出现订单完成而分账缺失。正确做法是先按状态条件更新订单，只有受影响行数为 1 时才生成分账；生成时使用 ON CONFLICT DO NOTHING，使重复调用无副作用。验收时可在本地连续调用两次 settle_order，观察第二次返回失败、split_items 仍为三行。
反例二：结算后退款未调整已结算账单
若商家已提现后再发生退款，仅将 split_items.reversed 置 1 并不够，还需要在下一账期生成负数调整或在结算单中记录冲减，否则商家账余额虚高。验收清单应包含：退款单必须写明 stage；结算单金额 = 未冲减分账合计 ± 调整项；提现申请只能针对 confirmed 状态的结算单。以下为可执行的核对SQL：
-- 核对：已完成订单是否都有三条分账，且金额合计等于可分配金额
SELECT o.order_no,
COUNT(s.id) AS split_count,
SUM(s.amount) AS split_sum,
o.amount_goods - o.amount_discount + o.amount_delivery AS expect_sum
FROM orders o
LEFT JOIN split_items s ON s.order_no = o.order_no
WHERE o.status = 'completed'
GROUP BY o.order_no
HAVING split_count != 3 OR split_sum != expect_sum;
-- 核对：结算后退款是否留下调整记录（应返回0行）
SELECT r.refund_no, r.order_no
FROM refunds r
LEFT JOIN split_items s ON s.order_no = r.order_no AND s.reversed = 1
WHERE r.stage = 'after_settle' AND s.id IS NULL;
第一条查询在数据正常时返回空结果；若某订单只有两条分账或合计不符，会被列出，可直接作为上线前数据自检项。第二条查询用于发现“标记了退款但未冲减分账”的漏单。这类SQL不依赖具体产品，任何系统迁移前后都可以运行。
六、回到选型：用这套模型验收成熟系统
不懂技术时，不必自己维护这套代码，但可以把上述约束转成向服务商演示的核对项：一问系统是否记录订单、分账、结算、退款四类数据，且分账明细能关联原订单；二问支付回调重复到达时是否幂等处理；三问部分退款和结算后退款分别如何冲减商家账、骑手账和平台账；四问多校区时订单和分账是否带校区归属，导出能否按子账号控制列。能现场跑通正常单、重复回调、部分退款和结算后退款四组场景，就比只看功能菜单可靠。
如果考察标准SaaS交付的产品，可要求对方演示中逐条对上这些字段和状态。校园场景还需额外确认校门交接、楼栋分拣和批量送达是否与订单状态联动，以及退款是否影响已生成的骑手收入。演示记录建议保留订单号、各端金额截图和导出表，作为后续合同附件或实施清单的一部分。
七、上线验收清单
数据层：确认订单表含校区、状态、四类金额字段，分账明细对同一订单同一收款方唯一。
状态层：订单从支付到完成不可跳步，退款单必须关联原订单并标注结算前后阶段。
资金层：正常单金额合计等于商品款减优惠加配送费；部分退款后各收款方金额可追溯冲减。
异常层：重复支付回调、重复退款请求、结算后售后三类场景各演练一次，记录系统返回和账务结果。
权限层：多校区账号互看订单和导出列，总部可单独控制提现与改价权限。
这套模型不绑定具体技术栈，也不替代真实支付通道测试；它解决的是“先想清楚账再选系统”的问题。按此准备需求，再结合演示与报价确认模块和交付范围，搭建校园生活平台的第一步就算落地了。
作者：微订（上海逊柯计算机科技有限公司）。
