很多客户在选型时都会问：同样跑在平易客底座上的外卖与跑腿模块，技术架构到底差在哪？我们从订单模型、调度引擎、端侧交互三个维度拆开看。

一、订单状态机与履约链路差异

外卖系统的订单状态高度依赖商家接单、备餐、骑手取餐三段式，状态流转强耦合。而跑腿系统更接近即时物流：下单即派单，取件与送达之间没有商家节点。平易客在底层做了状态机隔离，外卖走“商家-骑手-用户”三角校验，跑腿则走“发件人-骑手-收件人”直线校验，数据库表结构也分属不同schema。

二、调度引擎的并发策略

外卖午高峰的并发压力集中在微信外卖订餐小程序入口，订单密度高、配送范围小，平易客采用“网格化抢单+超时兜底”策略。跑腿则跨区长距离多，我们用的是“路径预测+动态定价”调度，骑手接单半径可放宽到5公里。实测数据显示，跑腿订单的调度计算耗时比外卖高出约40%，但平易客通过Redis GEO和预计算路网做了有效压制。

• 外卖系统：3秒内完成骑手匹配，超时转人工调度
• 跑腿系统：支持预约单与实时单混排，路径规划优先

三、端侧技术选型对比

两者共用微信外卖订餐小程序的登录与支付能力，但跑腿端额外集成了地图选点、重量预估和保价模块。平易客的跑腿小程序包体积比外卖端大约1.8MB，主要消耗在路径渲染上。我们建议跑腿客户开启分包加载，首屏时间可控制在1.2秒内。

某连锁品牌同时上线平易客外卖与跑腿后，午高峰外卖单均配送时长28分钟，跑腿单均42分钟，但跑腿客单价高出67%。架构选型没有优劣，关键看业务场景。

平易客在双系统共用账户、骑手池和结算中心的基础上，保留了各自独立的调度与状态机，这是目前比较务实的做法。