群里两个跑腿站长吵了一晚上：一个说抢单模式骑手积极，一个说抢单把远单小单全剩在自己手里。跑腿配送小程序的调度模式怎么选，是每个站长早晚都要回答的问题，答案取决于你的订单量和骑手规模到了哪一步。
抢单：热闹，但烂单没人要
抢单模式上线快，骑手自由度高，早期用起来顺。毛病也明显：好单秒抢，远单、大件单、雨天的单挂在列表里没人碰，最后只能站长自己在群里喊人。单量小的时候还兜得住，单量一大，剩单就成了灾难。
派单：省心，但系统要立得住
系统派单按距离、骑手在线状态、当前负重自动分配，骑手没得挑，剩单问题基本消失。代价是派单逻辑必须扎实——派给离取件点三公里的骑手、派给刚点了收工的人，骑手马上就有意见。常见的折中做法是派单之后允许转出一到两次，转不出去就必须接，兼顾公平和灵活。
- 每天五十单以内：抢单为主，群里人工兜底就够了。
- 五十到三百单：派单为主，允许有限转单。
- 三百单以上：纯派单加智能调度，按网格划分运力。
模式切换不是一次性的决定
不少平台是抢单起家，做到一定规模后切派单，骑手反弹很大。提前把规则讲清楚，比如新骑手前两周抢单、之后进入派单池，过渡会平滑很多。调度模式的改动牵扯数据库和推送逻辑，选型时最好一步到位，让开发团队把两种模式的接口都留好。
异常单的处理，比派单算法更能看出水平
派单再聪明也挡不住意外：骑手电动车半路没电、商家出餐慢一小时、客户地址填错。异常单处理机制要提前设计：骑手端一键上报异常，系统自动把订单转回调度池重新派，同时给用户推送说明。转派有两次机会，两次都失败就升级到人工，站长在后台看到红色标记直接处理。别让骑手和用户互相打电话扯皮，扯皮一次，两边都掉一层信任。还有些平台吃过亏：骑手接单后摔了车，订单没人管，用户投诉到平台才发现系统里根本没有异常上报的入口。这种功能平时看着没用，出事的时候就是救命的。
调度还有个常被忽视的细节：接单半径。半径设太大，骑手空跑一半路程；设太小，边界上的订单没人抢。比较实用的做法是按骑手当前位置画圈，半径随在线骑手数量浮动，运力紧张时自动放大一档。这些参数都要做成后台可调的，上线头三个月基本每周都在微调，别把它们写死在代码里。
如果你正打算搭跑腿配送小程序，调度这块建议直接找比格网络这样有同城配送案例的团队沟通，把抢单和派单两种方案的成本、后路都问明白，比上线之后推倒重来划算。
