同城配送小程序：我踩过的坑和最终方案

去年接了本地一个跑腿团队的活，要做同城配送小程序。需求不复杂：用户下单、骑手接单、实时看位置、后台派单。我一开始觉得两周能搞定，结果前后拖了一个多月。这篇文章把过程和踩过的坑写下来，给准备做同类项目的朋友一个参考。

先说结论：别急着写代码

我犯的第一个错误是先动手。拿到需求就建项目、画页面，做到第三天发现订单状态流转逻辑没想清楚，骑手端和用户端的状态对不上，返工一大片。

同城配送的核心不是页面，是订单状态机。我最后定的状态是：

• 待支付 → 已支付待接单 → 已接单 → 取货中 → 配送中 → 已送达 → 已完成
• 分支：已取消、超时未接单、异常/退款

每个状态谁能操作、超时怎么处理、要不要推送通知，都在纸上画清楚再写代码。这一步花半天，后面省好几天。

技术选型：云开发还是自建后端

这个项目我用了微信云开发。原因很实际：客户预算有限，团队就我一个人，自建服务器加运维成本扛不住。云开发的数据库、云函数、存储一套下来，前期基本够用。

但云开发也有坑，得提前知道：

• 云函数冷启动，第一次调用可能慢一两秒，下单这种关键路径要预热或做 loading 兜底
• 数据库查询有单次返回条数限制，骑手列表、订单列表要分页
• 实时位置推送用云开发的 watch 不太稳，我最后走的是定时拉取 + 骑手端主动上报

如果单量预期大、需要和已有 ERP 打通，还是老老实实自建后端。云开发适合验证期和中小规模。

骑手端的位置上报

这是同城配送小程序最容易被低估的部分。用户要看到骑手在地图上动，就得持续拿位置。

我的做法是骑手端在配送中状态下，每 5 秒调一次 wx.getLocation，把经纬度写进云数据库，用户端每 5 秒拉一次。听着土，但稳定、省事、流量可控。

// 骑手端：配送中定时上报位置
let timer = null
function startReport(orderId) {
  timer = setInterval(async () => {
    const res = await wx.getLocation({ type: 'gcj02' })
    await db.collection('rider_location').doc(orderId).update({
      data: {
        lat: res.latitude,
        lng: res.longitude,
        updatedAt: Date.now()
      }
    })
  }, 5000)
}

// 页面隐藏或订单结束时一定要清掉
function stopReport() {
  if (timer) {
    clearInterval(timer)
    timer = null
  }
}

注意两点：一是 onHide 和 onUnload 里必须停掉定时器，不然骑手切后台还在耗电；二是位置权限被拒绝要有引导，很多骑手第一次用会点“拒绝”。

派单逻辑别做太复杂

客户一开始想要“智能派单”，按距离、评分、当前单量加权。我劝住了，第一版就做抢单 + 后台手动指派。原因很简单：单量没起来之前，算法派单反而容易出错，骑手抱怨，客服天天救火。

抢单模式实现简单：新订单进池子，骑手端轮询或订阅到新单，先到先得，数据库用事务或乐观锁防重复接单。

// 云函数：抢单，用状态字段做乐观锁
const order = await db.collection('orders').doc(orderId).get()
if (order.data.status !== 'paid') {
  return { ok: false, msg: '手慢了，单已被接' }
}
const res = await db.collection('orders')
  .where({ _id: orderId, status: 'paid' })
  .update({ data: { status: 'accepted', riderId: openid } })
return { ok: res.stats.updated === 1 }

这段 where 里带上 status: 'paid' 是关键，两个骑手同时点，只有一个能更新成功。

几个上线后才发现的细节

• 距离和价格：直线距离和实际骑行距离差很多，我用了腾讯位置服务的路线规划接口，按骑行距离算配送费，用户投诉少了一大半。
• 手机号：骑手和用户之间要能联系，但直接暴露手机号有隐私风险。我用了虚拟号中间号，成本不高，体验好很多。
• 超时提醒：订单超时没接单要自动通知后台，这个用云开发的定时触发器做，别指望人工盯。
• 审核：同城配送类目要选对，涉及地理位置和交易，提交时把业务说明写清楚，我第一次因为类目选错被打回。

关于成本和周期

这个同城配送小程序从开发到上线大概五周，云开发费用前期每月几十块，加上地图和虚拟号接口，成本可控。如果找外包做类似的，报价差别很大，从一两万到五六万都有，主要差在实时定位、派单调度这些细节上。建议谈的时候把订单状态、派单规则、位置刷新频率这些写进需求文档，不然做出来和想的不一样，扯皮最费时间。

总的来说，同城配送小程序的技术门槛不高，难的是把业务流程想透。状态机、位置上报、抢单并发这三块处理好了，剩下的都是体力活。希望这篇能帮你少走点弯路。