同城配送小程序开发避坑指南

过去两年我参与过三个同城配送小程序的从 0 到 1，有跑通的，也有上线三个月就下线的。踩过的坑比写过的代码还多。这篇文章不讲空泛的方法论，只聊开发过程中真正会让你返工、烧钱、甚至项目失败的关键点。

一、先想清楚：你到底做的是哪种配送

很多团队一上来就写代码，结果做到一半发现业务模型选错了。同城配送至少分三类，技术架构差别很大：

• 店配（B2C）：商家发货给消费者，比如鲜花、蛋糕、文件。订单由商家发起，重点是商家端和骑手端的衔接。
• 跑腿（C2C）：用户发单，骑手接单代买代送。用户端体验是核心，价格计算复杂。
• 平台聚合（B2B2C）：多商家入驻，平台派单。要处理商家结算、骑手分润、区域划分。

这三类的订单状态机、计价规则、结算逻辑完全不同。开工前把业务类型定死，能省掉至少两周的重构。

二、订单状态机是整个系统的骨架

配送系统最怕状态混乱。用户看到“已接单”，骑手看到“待取货”，商家看到“待发货”，后端其实是一个状态在不同角色下的投影。

我的建议是：后端只维护一套主状态，前端按角色做映射。主状态大致如下：

待支付 → 待接单 → 已接单 → 已到店 → 已取货 → 配送中 → 已送达 → 已完成
                              ↓
                           已取消 / 异常

关键点：

• 状态流转必须由后端校验，前端只做展示，绝不信任客户端传来的状态。
• 每个状态变更都要写日志，出问题时能追溯是谁在什么时间改的。
• 超时未接单要有自动取消或重新派单机制，否则订单会烂在池子里。

三、骑手调度：别一开始就追求智能算法

新手最容易犯的错，是花大力气做“智能派单算法”。实际上单量没到日均几百单之前，抢单模式 + 简单的距离排序完全够用。

真正要提前设计的是：

• 地理位置上报：骑手端定期上报坐标，注意小程序后台定位权限和频率限制，太频繁会被系统限制。
• 接单范围：用圆形或行政区域圈定骑手可见订单，避免跨城接单。
• 防刷单：同一骑手短时间内大量接单、同一设备多账号，都要有风控标记。

调度算法可以后补，但订单分配的数据结构一开始就要设计成可扩展的，否则后期接入算法要重写。

四、计价与结算，钱的事不能含糊

同城配送的计价通常由基础运费 + 距离费 + 重量/体积费 + 时段加价 + 小费组成。开发时注意：

• 计价规则做成配置化，不要硬编码在代码里，运营随时会改。
• 下单时预估价格和实际结算价格可能不一致（比如实际距离变长），要明确以哪个为准，并给用户确认环节。
• 骑手分润、平台抽成、商家结算三条账要分开记，任何一条对不上都会引发纠纷。

五、小程序特有的坑

1. 实时位置与地图

小程序的地图组件在部分安卓机型上刷新有延迟，骑手位置建议用 WebSocket 推送坐标，前端只负责渲染，不要依赖地图组件的自动定位。

2. 消息通知

小程序没有常驻后台，订单状态变更必须靠订阅消息或短信通知用户和骑手。订阅消息要用户主动授权，一次性订阅只能推一条，长期订阅有类目限制，这些都要在产品设计阶段考虑进去。

3. 后台定位权限

骑手端需要持续上报位置，但小程序在切到后台后定位会被暂停。纯小程序方案很难做到真正的实时追踪，如果对骑手轨迹要求高，建议骑手端用原生 App 或小程序 + 蓝牙设备辅助。

六、上线前必须验证的几件事

1. 弱网环境下订单能否正常提交和同步。
2. 骑手长时间不操作，订单是否会卡在中间状态。
3. 并发抢单时，同一订单是否会被两个骑手同时接到（用数据库乐观锁或分布式锁解决）。
4. 用户取消订单后，骑手端和商家端是否同步收到通知。
5. 支付回调丢失时的补偿机制。

七、总结

同城配送小程序的难点不在小程序本身，而在订单状态、调度逻辑、资金结算这三块后端设计。技术选型上，小程序适合做用户端和商家端的轻量入口，骑手端如果对实时性要求高，要有原生方案的心理准备。先把业务模型和状态机想清楚，代码只是水到渠成的事。