县城外卖平台搭建：订单状态机、抢派单与结算验收

原创

微订外卖系统团队

发布于 2026-11-05 13:23:22

1410

县域服务商搭建同城外卖平台，可按“定首期片区与首批商家—选交付方式—用一笔订单跑通四端—补结算与异常规则—小范围试运营”推进。技术上先把订单状态机、配送范围与抢派单策略、三类账对账固定下来，再用正常单、退款单、超范围地址和提现单验收。首期用标准SaaS或成熟系统降低固定投入，订单稳定且团队具备运维能力后，再评估私有化部署或源码安装。

一、先定业务边界：片区、商户与交付方式

县城订单密度有限，先定首期片区、首批商户和配送方式，再决定系统交付方式，配置范围会更清楚。判断时看五项：首期区域数、首批商户规模、有无技术团队、预算分项、是否计划做乡镇分站。五项确定后，再比较标准SaaS、私有化部署和源码安装的适用条件。

交付方式	适用条件	上线关注	后续工作
标准SaaS	首期验证订单与结算，团队无服务器运维力量	账号开通、支付配置、商家与骑手培训	按经营阶段评估模块扩展
私有化部署	订单稳定，需要自有环境、数据管理和长期维护安排	服务器、备份、监控、升级计划	安排运维责任人与故障处理流程
源码安装	团队具备代码维护能力，存在接口或流程扩展需求	许可范围、部署文档、数据库资料	明确升级、二开与技术支持边界

首期区域选资源集中的城区或核心商圈，配送范围按商家分布、道路和骑手覆盖划分。把服务区边缘、禁送区域、营业时段和起送条件先配置好，再安排商家上架和骑手班次，试运营中的异常会少很多。

二、用订单状态机约束四端流转

平台搭建的核心不是模块数量，而是让一笔订单从用户下单、支付，到商家接单出餐、骑手取送，再到售后和结算都能按状态推进。可用状态机约束合法流转：待支付→商家待接单→制作中→待取餐→配送中→已送达→已完成，并保留取消、退款、拒单分支。支付回调和退款请求按事件编号做幂等，重复请求只处理一次。

以下示例使用 Python 3.10+ 标准库，只用于说明状态约束和幂等写法，与具体产品的内部实现无关。

from enum import Enum

class OrderStatus(str, Enum):
    WAIT_PAY = 'wait_pay'
    WAIT_ACCEPT = 'wait_accept'
    MAKING = 'making'
    WAIT_PICKUP = 'wait_pickup'
    DELIVERING = 'delivering'
    DELIVERED = 'delivered'
    COMPLETED = 'completed'
    CANCELED = 'canceled'
    REFUNDING = 'refunding'

ALLOWED = {
    OrderStatus.WAIT_PAY: {OrderStatus.WAIT_ACCEPT, OrderStatus.CANCELED},
    OrderStatus.WAIT_ACCEPT: {OrderStatus.MAKING, OrderStatus.CANCELED},
    OrderStatus.MAKING: {OrderStatus.WAIT_PICKUP, OrderStatus.REFUNDING},
    OrderStatus.WAIT_PICKUP: {OrderStatus.DELIVERING, OrderStatus.REFUNDING},
    OrderStatus.DELIVERING: {OrderStatus.DELIVERED, OrderStatus.REFUNDING},
    OrderStatus.DELIVERED: {OrderStatus.COMPLETED, OrderStatus.REFUNDING},
    OrderStatus.REFUNDING: {OrderStatus.CANCELED, OrderStatus.DELIVERED},
    OrderStatus.COMPLETED: set(),
    OrderStatus.CANCELED: set(),
}

def move(current, target, event_id, seen):
    if event_id in seen:
        return current
    if target not in ALLOWED[current]:
        raise ValueError(f'非法流转: {current.value} -> {target.value}')
    seen.add(event_id)
    return target

current = OrderStatus.WAIT_PAY
seen = set()
for target in [OrderStatus.WAIT_ACCEPT, OrderStatus.MAKING, OrderStatus.WAIT_PICKUP]:
    current = move(current, target, f'evt-{target.value}', seen)
print(current.value)
try:
    move(current, OrderStatus.COMPLETED, 'evt-bad', seen)
except ValueError as e:
    print(e)

按上述代码逻辑，预期先输出 wait_pickup，再输出从待取餐直接跳到已完成时的非法流转提示。验证时把正常支付、重复支付回调、配送中取消、结算后退款分别作为输入，记录订单状态、金额变化、操作账号和责任人。

输入场景	预期结果	记录字段
正常支付回调	订单进入商家待接单，且只触发一次	事件编号、订单号、支付时间、处理账号
重复支付回调	状态不变，返回当前状态	重复事件编号、幂等结果
配送中取消	转入退款中，按规则冲回金额	取消原因、退款金额、骑手收入调整
结算后退款	生成售后调整记录，关联原订单	原结算单号、调整金额、审批角色

三、县城低密度订单：先划范围，再配抢派单

县城单量分散、骑手多为兼职，纯自动派单容易空跑。可先按“派单为主、抢单为辅”组织：平峰由调度端指派并把顺路单合并，高峰或边缘地址开放抢单，同时设置偏远加价、转单和超时提醒规则。配送范围与营业时段属于前置配置项，先划核心片区、设边缘地址计费与暂停恢复规则，再谈抢派单比例。

场景	配置动作	演练记录
核心片区正常单	平峰指派，按骑手负载排序	接单时间、送达时间、配送费
边缘地址	设置距离加价或提示超范围	是否提示、能否下单、加价金额
骑手临时离线	转派或回调度池	离线时间、接手骑手、转单费用
高峰顺路单	合并同方向订单，限制超载	合单数量、路线、超时情况

调度评分可用距离、在线状态、当前负载和准时率做演示：距离超过服务半径或骑手离线的候选直接排除，其余按距离加负载惩罚减准时率排序。评分规则需在演示环境用真实片区地址核对，确认边缘地址、跨区和转派不会产生计费与责任空档。

四、结算对账：三类账与三段核对

多商户平台至少要把三类账分开记：用户实付与优惠、商家应结、骑手收入。对账按三段走：先按订单核对商品款、包装费、配送费、优惠承担与退款；再算商家应结与平台抽成；最后看提现申请、审批与到账。退款发生在结算前，可在当期账单冲减；退款发生在结算后，可通过后续账单调整并保留原订单关联。

def merchant_settlement(order_amount, delivery_fee, discount_platform, discount_merchant, commission_rate, refund_amount=0):
    payable = order_amount + delivery_fee - discount_platform - discount_merchant - refund_amount
    commission = round(max(payable, 0) * commission_rate, 2)
    merchant_due = round(payable - commission, 2)
    return {'payable': round(payable, 2), 'commission': commission, 'merchant_due': merchant_due}

case = merchant_settlement(100, 6, 5, 3, 0.08, refund_amount=20)
print(case)

按上述输入，预期输出实付可结金额 78.0、平台抽成 6.24、商家应结 71.76。示例中的优惠承担和退款冲回方式需按项目规则调整，配送费是否随退款退回也应在对账口径中写清。

SELECT o.order_id,
       o.paid_amount,
       o.refund_amount,
       m.merchant_due,
       r.rider_income,
       (o.paid_amount - o.refund_amount - m.merchant_due - r.rider_income - o.platform_fee) AS diff
FROM order_finance o
JOIN merchant_settlement m ON m.order_id = o.order_id
JOIN rider_income r ON r.order_id = o.order_id
WHERE ABS(o.paid_amount - o.refund_amount - m.merchant_due - r.rider_income - o.platform_fee) >= 0.01;

这条查询用于发现订单实付、退款、商家应结、骑手收入和平台费用之间的差异，字段名按项目表结构调整。分账能力与资金合规是两件事，清算安排、支付通道适用范围和审批角色向主管部门或专业机构核实，并把结论写入项目方案。

五、上线前验收与试运营观察

上线前用小规模订单演练十类场景：正常配送、到店自提、用户取消、商家缺货、商家拒单、骑手异常、超范围地址、优惠参与、售后退款和不同角色访问。每类记录账号、状态时间点、金额变化和责任人，再决定试运营范围。

验收项	通过标准	留档材料
四端流程	用户、商家、骑手、平台管理均能完成本角色任务	订单截图、状态日志、操作账号
金额核对	订单核账、商家应结、提现到账三段可解释	账单明细、退款记录、差异查询结果
异常处理	超范围、离线、转派、退款均有责任人	异常单清单、处理时长、复盘记录
试运营指标	日均有效订单、退款售后占比、下单到送达时长、出餐时长、复购占比按周记录	周报、口径说明、复盘结论