直接答案：同城跑腿小程序按用户端、骑手端、商家发单端、平台后台四端组织，首期先跑通“下单—计价—抢单或派单—取送凭证—送达—结算—售后”一条闭环，营销功能后置。多数开发坑不在页面，而在订单状态定义不全、计价口径含糊、送达凭证缺失和结算账目混在一起；下面用一个具体工程故障“订单金额与状态在转单后对不上”展开模型、SQL和验证方法。
一、先定四端和最小闭环，再谈功能堆叠
同城跑腿平台通常按四类角色拆分：用户端选服务、填地址、下单支付、看进度和售后；骑手端接单、取送、上传凭证、看收益；商家发单端录单、批量发单、看配送；平台后台管调度、区域价格、人员权限、结算和售后。首期把这几段跑成闭环，比先做会员、积分、社区更划算。
微订同城平台统计后台与移动页面组合。
| 端 | 首期必备功能 | 验收观察点 |
|---|---|---|
| 用户端 | 服务类型、取送地址、物品说明、即时/预约、费用明细、取消退款 | 下单前能否看到完整费用明细，退款后金额是否冲回 |
| 商家发单端 | 手动录单、批量发单、订单跟踪、配送费账单 | 同一批订单能否一次发出并在后台正确分组 |
| 骑手端 | 抢单/派单、取件拍照、送达凭证、导航、收益明细 | 正常单和转单在骑手、商家、后台三端状态是否一致 |
| 平台后台 | 调度看板、改派、区域价格、抽成配置、结算提现、售后 | 改派后责任人、金额和结算归属是否同步变化 |
微订商家手机订单页，展示订单筛选、配送状态与订单详情入口。
这份清单的用途是写需求文档和跟供应商对功能，避免只问“有没有”而不问“怎么串”。四端清单本身不是技术产出，真正决定上线质量的是下面两层的字段约束和状态流转。
二、具体工程故障：转单后订单金额与状态对不上
设一个试运营场景：用户在中午下一笔帮送单，商家另发一笔批量配送单，平台用“抢单为主、派单兜底”调度。骑手A接单后取件，途中因车辆故障转给骑手B；用户随后申请取消其中一件物品。上线前演练时出现三个现象：后台显示订单仍为“配送中”，骑手B的待结算金额为零，商家账单里却已扣了配送费。把问题拆开看，是订单主表没有独立的状态字段与金额快照，转单只改了骑手归属，没有写状态流水和账务分录。
这个故障对应两个最容易漏的工程点：一是订单状态必须由状态机约束，不能散落在各端页面判断；二是计价与结算要用同一份金额快照，不能在下单、送达、结算三个阶段各算一次。
三、数据模型与字段约束
以下模型按关系型数据库设计，订单主表保存业务快照，订单状态流水保存每次变更，订单金额明细保存费用组成，骑手任务表保存转单前后的责任人。字段约束直接写进建表语句，便于在评审和验收时逐条核对。
-- 订单主表：一行对应一笔跑腿订单
CREATE TABLE errand_order (
order_no VARCHAR(32) PRIMARY KEY, -- 业务单号
user_id BIGINT NOT NULL,
merchant_id BIGINT NULL, -- 个人下单时为空
task_type VARCHAR(16) NOT NULL, -- send/pick/buy/express
status VARCHAR(16) NOT NULL, -- 见状态机
pay_amount DECIMAL(10,2) NOT NULL DEFAULT 0, -- 用户实付
fee_snapshot JSON NOT NULL, -- 下单时计价快照
pickup_addr VARCHAR(255) NOT NULL,
delivery_addr VARCHAR(255) NOT NULL,
receiver_phone VARCHAR(32) NOT NULL,
receive_code CHAR(4) NULL, -- 收货码，送达前生成
created_at DATETIME NOT NULL,
updated_at DATETIME NOT NULL,
CONSTRAINT chk_status CHECK (status IN (
'CREATED','PAID','ACCEPTED','PICKED','DELIVERING',
'DELIVERED','SETTLED','CANCELED','REFUNDING','REFUNDED'))
);
-- 状态流水：每次状态变化都写一行，禁止只改主表
CREATE TABLE errand_order_status_log (
id BIGINT AUTO_INCREMENT PRIMARY KEY,
order_no VARCHAR(32) NOT NULL,
from_status VARCHAR(16) NOT NULL,
to_status VARCHAR(16) NOT NULL,
operator VARCHAR(32) NOT NULL, -- user/merchant/rider/platform
remark VARCHAR(255) NULL,
created_at DATETIME NOT NULL,
INDEX idx_order (order_no, created_at)
);
-- 金额明细：费用组成逐项落库，退款冲回也写在这里
CREATE TABLE errand_order_fee (
id BIGINT AUTO_INCREMENT PRIMARY KEY,
order_no VARCHAR(32) NOT NULL,
fee_type VARCHAR(24) NOT NULL, -- delivery/distance/weight/time/extra/coupon
amount DECIMAL(10,2) NOT NULL,
bearer VARCHAR(16) NOT NULL, -- platform/merchant/rider/user
created_at DATETIME NOT NULL
);
-- 骑手任务：转单新增一行，不复用原记录
CREATE TABLE errand_rider_task (
id BIGINT AUTO_INCREMENT PRIMARY KEY,
order_no VARCHAR(32) NOT NULL,
rider_id BIGINT NOT NULL,
assigned_by VARCHAR(16) NOT NULL, -- grab/dispatch/manual
accepted_at DATETIME NULL,
finished_at DATETIME NULL,
transfer_fee DECIMAL(10,2) NOT NULL DEFAULT 0,
status VARCHAR(16) NOT NULL DEFAULT 'OFFERED'
);
字段约束里有三个关键点：status 用 CHECK 限定枚举，避免出现前端自己拼出来的临时状态；fee_snapshot 保存下单时计价结果，配送中改价只能新增费用行并写原因，不能覆盖快照；收货码只在骑手取件后生成并绑定订单，送达时由骑手核验，防止未送达提前结算。
四、状态机与核心实现
订单状态只允许沿固定方向流转，取消与退款作为分支处理。状态机用一张转换表约束，任何一端发起变更都要服务端校验，不能由小程序页面直接改库。
| 当前状态 | 允许流转 | 触发方 | 必要校验 |
|---|---|---|---|
| CREATED | PAID / CANCELED | 支付回调 / 用户 | 支付单号唯一，取消需未取件 |
| PAID | ACCEPTED / REFUNDING | 骑手 / 用户 | 骑手在线且未超接单上限 |
| ACCEPTED | PICKED / ACCEPTED（转单） | 骑手 / 调度 | 转单写新任务行并记录转单费 |
| PICKED | DELIVERING / REFUNDING | 骑手 / 用户 | 取件照片已上传 |
| DELIVERING | DELIVERED / REFUNDING | 骑手 / 用户 | 收货码核验通过 |
| DELIVERED | SETTLED | 平台 | 账期到达，商家与骑手金额已生成 |
| SETTLED | REFUNDING / 终态 | 用户 / 平台 | 售后工单关联原订单 |
下面用一段核心服务代码演示转单与送达两个动作，包含事务和幂等校验。代码为伪工程实现，依赖订单表、状态流水表和骑手任务表，运行前需按上文建表。
def transfer_order(conn, order_no, from_rider, to_rider, transfer_fee):
with conn.cursor() as cur:
# 幂等：同一订单同一时刻只允许一条未完成的新任务
cur.execute("""SELECT status FROM errand_order WHERE order_no=%s FOR UPDATE""", (order_no,))
row = cur.fetchone()
if row is None or row[0] != 'ACCEPTED':
raise ValueError('当前状态不允许转单')
cur.execute("""UPDATE errand_rider_task SET status='TRANSFERRED', finished_at=NOW()
WHERE order_no=%s AND rider_id=%s AND status='OFFERED'""", (order_no, from_rider))
if cur.rowcount != 1:
raise ValueError('原骑手任务不存在或已转出')
cur.execute("""INSERT INTO errand_rider_task
(order_no, rider_id, assigned_by, transfer_fee, status)
VALUES (%s,%s,'manual',%s,'OFFERED')""", (order_no, to_rider, transfer_fee))
cur.execute("""INSERT INTO errand_order_status_log
(order_no, from_status, to_status, operator, remark, created_at)
VALUES (%s,'ACCEPTED','ACCEPTED','platform','转单',NOW())""", (order_no,))
conn.commit()
def deliver_order(conn, order_no, rider_id, receive_code):
with conn.cursor() as cur:
cur.execute("""SELECT status, receive_code FROM errand_order
WHERE order_no=%s FOR UPDATE""", (order_no,))
status, code = cur.fetchone()
if status != 'DELIVERING':
raise ValueError('非配送中状态不能送达')
if receive_code != code:
raise ValueError('收货码不匹配')
cur.execute("""UPDATE errand_rider_task SET status='FINISHED', finished_at=NOW()
WHERE order_no=%s AND rider_id=%s AND status='OFFERED'""", (order_no, rider_id))
cur.execute("""UPDATE errand_order SET status='DELIVERED', updated_at=NOW()
WHERE order_no=%s""", (order_no,))
cur.execute("""INSERT INTO errand_order_status_log
(order_no, from_status, to_status, operator, created_at)
VALUES (%s,'DELIVERING','DELIVERED','rider',NOW())""", (order_no,))
conn.commit()
五、正常输入输出与异常反例
用两笔测试订单逐步核对。以下输入为构造示例，用于说明字段和状态变化，不代表任何真实客户或系统运行记录。
订单A：帮送，起步3公里内8元，距离加价2元，无优惠，收货码4821
1 用户支付10元 -> status=PAID, pay_amount=10.00
2 骑手A抢单 -> status=ACCEPTED, 任务行rider=A
3 骑手A取件拍照 -> status=PICKED
4 转单给骑手B -> 新增任务行rider=B, transfer_fee=0
5 骑手B送达，输入4821 -> status=DELIVERED
6 账期到达 -> status=SETTLED，骑手B收益入账
订单B：帮买，预约次日，下单时费用12元
1 用户支付12元 -> status=PAID
2 骑手接单后用户申请取消未取件 -> status=REFUNDING
3 退款回调成功 -> status=REFUNDED，金额冲回
用户支付经分账规则和区域节点分配至商家、骑手与平台的流程示意。
异常反例一：转单时原骑手任务已经是 TRANSFERRED，再次调用转单接口。预期抛出“原骑手任务不存在或已转出”，订单状态保持 ACCEPTED，不产生第二条新任务。若接口没有 FOR UPDATE 与 rowcount 校验，会生成两个骑手同时配送，结算时重复计收益。
异常反例二：骑手在 DELIVERING 状态直接点送达，未输入收货码或输入错误码。预期抛出“收货码不匹配”，订单仍为 DELIVERING，且不写结算金额。若前端只做按钮隐藏而服务端不校验，兼职骑手可在未送达时提前结算，这是试运营阶段最常见的漏项。
异常反例三：用户在下单后商家调高区域配送费。预期是把差额写入 errand_order_fee 并标明承担方，pay_amount 不变；若直接更新 fee_snapshot，同一订单在退款时按新价冲回，用户实付和账目就会对不上。
六、业务验收：一笔测试订单走完四端
把上面的模型转成验收动作，比只核对功能列表更可靠。约演示或验收时，带一笔正常单、一笔转单、一笔部分退款，按下表记录结果。
用户端：下单前费用明细完整，取消后金额按规则冲回，订单进度与后台一致。
骑手端：接单后能看到取件地址和收货码输入入口，转单后原骑手不再持有任务，新骑手收益正确。
商家发单端：批量发单中某一笔转单或退款，不影响同批其他订单的状态和账单。
平台后台：改派、抽成、结算金额都由同一份订单快照生成，售后工单能关联原订单和状态流水。
选型时可以用这份模型和验收单去问供应商：订单状态是否由服务端状态机约束、转单是否新增任务行、金额快照是否在下单时固定、收货码是否强制、退款冲回是否写明细。若对方只能用“有按钮”回答，说明四端协同还需用真实订单演示核对。计价维度、抢派单规则、转单收费、分账开通条件和许可办理范围，以演示和项目方案确认；订单量、性能与上线效果需结合试运营观察，不在本文给出未经核实的结论。
作者：微订（上海逊柯计算机科技有限公司）。
