基于微信小程序的同城跑腿接单助手：Python后端与订单状态机设计实践

前阵子朋友甩给我一个同城跑腿项目的需求：用户在小程序里下单，附近的骑手抢单，然后按时把东西从 A 点送到 B 点。这活儿听起来像"美团跑腿"的小型复刻，也确实是我身边不少外包团队和本地生活项目常接的单子。但真正做起来之后我发现，这类系统最磨人的不是页面设计，也不是接口数量，而是"订单从创建到送达"这条状态链路怎么走得稳。

标题里的 Python 和微信小程序，恰好是这条链路的左右手：小程序负责接触用户和骑手，Python 负责处理业务规则、距离计算和并发抢单。这篇文章就围绕"基于微信小程序的同城跑腿服务接单助手"这个项目，把技术选型、表结构设计、核心接口逻辑、联调埋点一次性写透，给同样想用 Python 做同城服务项目的同学做参考。

先提醒一句：市面上很多"同城跑腿小程序源码"交付件，本质上只是前端壳子。小程序不能像普通网页那样打开就能看，它需要开发者工具、AppID、后端接口三个条件同时具备才能完整跑通业务。想真正落地一个能接单、能派单、能结算的系统，后端业务逻辑必须自己补齐，这篇文章的重点也就在这里。

1. 跑腿接单这件事，真正要解决的是订单流转问题

1.1 原始接单方式的混乱，恰好是系统化的机会

很多三四线城市的跑腿团队，至今还是靠微信群接单：用户把发件地址、收件地址、物品照片往群里一甩，然后 @ 某个骑手。看起来没什么门槛，但跑起来全是问题：

• 订单消息被聊天记录冲掉，十分钟后再找一条单子要往上翻半天。
• 骑手有没有接单全凭口头回复，用户根本不知道谁在给自己送。
• 配送过程不透明，用户半小时后问一句"到哪了"，骑手还得停下手头的事情打字回复。
• 结算更是靠截图对账，稍一忙就漏单。

接单助手这个项目解决的不是"让用户能下单"这么简单，它真正解决的是"订单如何高效流转"：创建订单、候选骑手、接单锁定、开始配送、确认送达，每一个环节都有明确状态和操作人。用户看到结果，骑手看到任务，后台看到全量数据，这就是系统化相对口口相传的核心优势。

1.2 接单助手的三种角色视角

做这类系统前，先把角色梳理清楚。同城跑腿业务主要有三类使用对象：

• 下单用户：在小程序里发起跑腿请求，填写取送地址，支付费用，跟踪配送进度，最后确认收货。
• 跑腿骑手：在小程序里查看附近待接订单，抢单，按地址完成取送，更新配送状态。
• 平台管理员（可选）：审核骑手资质、处理客诉、查看订单流水、做结算统计。

很多教程项目只做用户端，但"接单助手"这个名字本身就说明，骑手侧的接单体验才是核心。一个骑手每天可能要抢几十张单，列表加载快不快、抢单反馈清不清晰、状态切换顺不顺，直接决定他愿不愿意用。所以文章后面会花大篇幅讲抢单接口和并发控制，这是接单助手的命门。

2. 技术选型：为什么是 Python 后端加微信小程序前端

2.1 后端用 Python，图的是开发效率和生态

同城跑腿这类项目，单量峰值可能也就几百上千，业务复杂度不算高，真正需要技术深度的点也就那么两处：距离计算和并发抢单。Python 在这两个场景下的手感非常合适。

• 框架选型：我推荐 FastAPI 或者 Flask。FastAPI 自带异步支持和接口文档，调试起来省不少事；Flask 更轻，适合想快速跑通的团队。本项目按 FastAPI 写核心逻辑，但思路在 Flask 上同样成立。
• 距离计算：直接用 geopy 库算两点间的球面距离，或者自己写一个哈弗辛公式（Haversine Formula），二三十行代码搞定，不需要引入重量级 GIS 组件。
• 并发控制：抢单场景需要"同一时刻只有一个骑手能抢成功"的保证，这个用 Redis 的原子操作或者数据库的条件更新都能做，Python 生态里 redis-py 已经封装得很顺手。
• 快速迭代：同城业务的需求变更非常频繁，比如新增"帮送文件""代买奶茶"这种子类型，Python 的动态特性让后端改动成本很低。

对比一下其他方案：Java 技术栈写起来稳，但项目初期重；Node.js 做这类业务也完全可以，但如果你团队里 Python 是主力，没必要为了"前后端同语言"去额外引入一套生态。小步快跑的项目，选团队最熟的技术就是最好的技术。

2.2 小程序端为什么比 App 和网页更合适

这个项目核心场景是"低门槛发起请求"和"骑手在外移动时快速操作"，微信小程序在这两点上有先天优势：

• 不需要下载安装：用户和骑手都是一次性低频使用的角色，让他们为跑腿业务专门装个 App 太难了。小程序扫码即用，用完即走。
• 微信生态能力齐全：登录可以用 wx.login 静默授权，地址选择有 wx.chooseLocation，定位有 wx.getLocation，进度通知有订阅消息，这些都是直接可用的官方能力，不用自己从零造轮子。
• 打开率高：骑手端的小程序可以被置顶聊天窗口，接单通知来了直接从小程序切进去，体验比网页 H5 好一个档次。

还有一点，标题和很多热搜词都提到"小程序源码工程"和"网页"之间的差异：小程序前端代码不能直接在浏览器里跑，它必须通过微信开发者工具编译预览，发布后也要走微信审核。这和传统网页开发的调试思路完全不同，我第一次接触时也踩了坑，后面联调章节专门说。

2.3 原生开发还是 uniapp

如果这个项目只做微信小程序，我建议原生开发，也就是 WXML + WXSS + JS 那套。原因很简单：原生能和微信 API 保持零延迟同步，新功能出来马上能用，不用等跨端框架适配。而且外卖跑腿这种项目对地图组件、手机号授权这类原生能力依赖很重，绕开框架层能少踩很多坑。

但如果你未来确定要上支付宝小程序、抖音小程序，那就选 uniapp，一套代码多端发布。需要注意的是 uniapp 打包微信小程序时容易触碰主包体积 2MB 的限制，热搜词里就有关于 source size 超限的提问。解决办法是分包加载，把骑手端和用户端的页面拆成不同分包，首屏只加载用户端内容。这个坑后期很容易遇到，提前规划页面结构能省不少事。

3. 先把数据库表结构和状态机设计好，再动接口

3.1 核心表结构

写业务代码前，我习惯先设计表。跑腿接单助手至少要建三张核心表：用户表、订单表、接单日志表。下面是我在项目中实际按这个思路落地的结构，字段可以根据业务再调整。

用户表 user：

订单表 order：

接单日志表 order_grab_log：记录每个骑手的抢单行为，用于防止恶意刷单和事后追溯。字段包括 id、order_id、rider_id、action、created_at。这张表不是业务必须，但建议加上，排查并发问题的时候非常好用。

关键点我在设计时就反复确认过：

• 经纬度用 decimal 存，不要用 float，精度差异会在距离计算时被放大。
• 订单号单独一列，展示用，不用主键编号直接对外。因为主键自增容易被别人猜到平台订单量。
• status 用 tinyint 存整数状态，比字符串存状态值更省空间、查询更快，维护成本也不高。

3.2 订单状态机：先定义清楚，再写 if

接单助手最容易出 bug 的地方，就是对订单状态做了不受控的修改。比如骑手接单后订单又显示"待接单"，用户取消后骑手还能点"开始配送"。要防止这类问题，最佳实践是在写接口前把状态机画出来，明确每一个状态允许迁移到什么状态。

我的订单状态定义如下：

• 0：已取消。下单后用户主动取消，或者超时无人接单系统自动取消。
• 1：待接单。订单创建成功后进入，骑手可抢。
• 2：已接单。骑手抢单成功后进入，此时骑手信息已绑定到订单。
• 3：配送中。骑手已取到物品，正在送往目的地。
• 4：已完成。骑手确认送达，用户确认收货后可进入评价流程。

允许的状态迁移路线只有这些：

• 1 -> 0：用户取消或系统超时取消
• 1 -> 2：骑手抢单成功
• 2 -> 3：骑手开始配送
• 2 -> 0：骑手接单后想放弃，申请取消，平台审核后取消（这个流程要慎用，我项目里默认不允许，避免恶意占单）
• 3 -> 4：骑手确认送达
• 4：终态，不可再迁移

每个接口在做状态更新时，都必须校验"当前状态是否允许迁移到目标状态"，而不是无脑 update。比如抢单接口只能用"待接单"状态的订单，配送完成接口只能更新"配送中"的订单。这套规则写进代码之后，并发和误操作带来的脏数据会少很多。

3.3 为什么要存经纬度，而不仅仅存文字地址

同城跑腿业务里，距离是最核心的计算因子。骑手要看"这单离我多远"决定抢不抢，平台要用距离算预估费用，商家要按照配送范围决定能不能接。文字地址没法做数学运算，只有经纬度能。

所以下单接口必然要求用户通过地图选点。小程序端可以用 wx.chooseLocation 让用户在地图上选位置，把经纬度回传；后端拿到两个坐标点，用哈弗辛公式算球面距离，再叠加城市道路系数得到估算距离。这个距离在创建订单时就算好并存储，后续列表排序、费用展示都直接用存储值，避免同一张单在每次请求时重复计算，也避免骑手端和用户端展示出的距离不一致。

经纬度还有一个好处：骑手视角可以做"附近订单"的筛选。SQL 里用经纬度范围粗筛，比如用户的坐标在矩形范围内，再加距离排序，性能比全表扫描好很多。

4. 小程序端关键页面：下单、抢单、配送状态操作

4.1 登录与角色识别的实现路径

小程序端的登录依赖微信的能力。流程是：小程序调用 wx.login 获取临时 code，把这个 code 传给 Python 后端，后端调用微信接口 code2Session 换取 openid，再自己生成业务 token 返回给小程序。小程序把 token 存在本地存储，后续请求带上即可。

这里有个细节：同一套小程序如何区分用户和骑手？两种做法：

• 角色选择页。首次登录让用户选择"我是下单用户"还是"我是跑腿骑手"，提交时打上角色标签。
• 后台审核制。用户申请成为骑手时提交手机号和资质信息，管理员在后台审核通过后给 user 表的 role 字段置为 1。

我建议用第二种，更安全也更接近真实业务。骑手不是谁想当就能当的，平台要确认这个人不会拿了东西就跑。小程序端根据 role 字段决定渲染哪一套页面：普通用户看到"下单"和"我的订单"，骑手看到"接单大厅"和"配送任务"。

4.2 下单页：地图选点与费用预估

下单页是整个用户端最核心的界面，涉及的交互比较多。我的页面组成包括：取件地址选择、收件地址选择、物品类型和重量填写、备注输入、费用预估展示、提交按钮。

取件和收件地址都调用 wx.chooseLocation，这一步打完点之后把经纬度和地址名称一起回填到表单。如果用户拒绝授权定位，就让他手动输入文字地址并在地图上确认，总之经纬度必须拿到，否则后端没法算距离。

费用预估可以在前端简陋算一下，比如"起步价 + distance_km * 每公里单价"，给用户一个大致的价格参考。但真正计费一定以后端为准，前端数字只是友好提示，防止用户下单后被实际费用吓一跳。

提交订单后，页面跳转到订单详情。订单详情页展示状态流转步骤条、地图上的路线缩略、物品信息、跑腿员信息和联系按钮。

4.3 骑手端接单大厅：列表刷新与抢单反馈

骑手端打开接单大厅，核心诉求是尽快看到"周边有哪些待接订单"。这里涉及一个常见问题：列表数据怎么刷新？

• 方案A：下拉刷新。简单可靠，用户手动触发。
• 方案B：定时轮询。每 5 到 10 秒调一次列表接口，自动更新。性能上可以接受，毕竟同城订单量不大，但要处理好清理定时器的问题，否则页面退到后台还在请求，浪费流量。
• 方案C：WebSocket 推送。体验最好，但实现复杂度高，需要额外的推送服务和长连接管理，小项目不太必要。

我实际做的时候用的是 B + A 的组合：页面 onShow 时拉一次列表，同时开启定时轮询；页面 onHide 时清除定时器。这样既保证实时性，又不至于长期空跑。

列表里每张卡片要展示的信息：取件地址到收件地址的距离、预估费用、下单时间、物品描述。骑手点击卡片进入订单详情，看到更完整的路线和物品信息，确认没问题后点"抢单"按钮。

抢单按钮的点击反馈非常关键。如果抢单成功，要明确提示"抢单成功，请及时联系取件人"；如果订单已经被别人抢走，要弹"手慢了，订单已被接走"。用户最害怕的是点击抢单后页面没反应，在原地傻等，所以这个地方的交互提示宁可多写几个分支。

4.4 配送状态操作与地图导航

骑手抢单成功后，订单进入骑手的"配送任务"列表。状态操作按钮随状态切换：

• 已接单状态显示"开始配送"，点击后把订单推到配送中。
• 配送中状态显示"确认送达"，点击后走完成接口。
• 完成之后显示"订单已完成"，不可再操作。

用户端在订单详情里可以看到配送进度：待接单、已接单、配送中、已完成这四个节点的步骤条。骑手点了哪个环节，用户端进度条同步更新。

关于地图导航，一个实用小技巧：不要让小程序内嵌地图做大而全的导航功能，直接调用 wx.openLocation 把目的地经纬度传进去，系统会自动唤起微信内置的地图能力，支持路线规划和导航。这样开发成本低，体验还稳定。取件地址和收件地址分别提供"去这里"按钮，骑手一键切换导航，非常实用。

5. Python 后端核心接口与并发抢单设计

5.1 接口清单总览

后端接口不需要多，但要职责清晰。我按业务功能划分如下：

接口设计上，抢单和状态更新拆开是刻意的。抢单操作必须原子化，状态更新走统一的状态机校验逻辑，两者职责分离后，后续要加派单算法、超时自动取消之类的功能也更好扩展。

5.2 用条件更新解决抢单并发，不死锁、不超卖

抢单场景本质上是典型的并发竞争，两个骑手同时看到同一张单，点击抢单后必须保证只有一个能成功。最容易想到的方案是："先 SELECT 查一下订单状态，如果是待接单，再 UPDATE 更新骑手信息。"这个方案在并发下必出问题——两个请求同时 SELECT 都查到待接单，然后都走 UPDATE，后更新的会覆盖先更新的。

正确做法是用数据库条件更新，在一个原子操作里完成状态校验和状态变更。SQL 逻辑如下：

UPDATE `order` SET rider_id = %s, status = 2, grabbed_at = NOW() WHERE id = %s AND status = 1 AND rider_id IS NULL

执行后检查更新影响的行数。如果影响行数为 1，说明抢单成功；如果影响行数为 0，说明订单状态已经不是待接单，抢单失败。这个方案简单到不需要引入分布式锁，性能也够用，我强烈建议优先采用。

对应到 Python 代码，FastAPI 风格的核心逻辑是：

@app.post("/api/order/grab") async def grab_order(order_id: int, rider_id: int): # 执行条件更新 now = datetime.now() result = db.execute( text(""" UPDATE `order` SET rider_id = :rider_id, status = 2, grabbed_at = :now WHERE id = :order_id AND status = 1 AND rider_id IS NULL """), {"rider_id": rider_id, "order_id": order_id, "now": now} ) db.commit() # 影响行数为 1 说明抢到了 if result.rowcount == 1: return {"code": 0, "msg": "抢单成功", "rider_id": rider_id} else: return {"code": 10001, "msg": "手慢了，订单已被接走"}

如果项目已经用了 Redis 作为缓存层，也可以在 UPDATE 之前用 Lua 脚本加一个锁，但数据库条件更新已经足够解决单库场景下的全部问题，而且没有分布式锁的过期时间、误删锁等额外复杂度。

5.3 距离计算：哈弗辛公式的实现

创建订单时，后端拿到取送两个点的经纬度，用哈弗辛公式计算球面距离。公式核心思路是把经纬度转成弧度，计算球面上两点间的大圆距离。代码如下：

import math def haversine(lng1, lat1, lng2, lat2): # 经纬度转弧度 lng1, lat1, lng2, lat2 = map(math.radians, [lng1, lat1, lng2, lat2]) # 差值 dlng = lng2 - lng1 dlat = lat2 - lat1 # 哈弗辛公式 a = math.sin(dlat / 2) ** 2 + \ math.cos(lat1) * math.cos(lat2) * math.sin(dlng / 2) ** 2 c = 2 * math.asin(math.sqrt(a)) # 地球平均半径 6371 公里 distance_km = 6371 * c return round(distance_km, 2)

这个算出来的是直线距离。真实同城跑腿场景里，骑手走的路肯定比直线长，通常会给一个 1.2 到 1.5 的路径系数修正，再叠加基础起步价和重量费用，就是预估费用。要把系数留在配置里，不要写死在接口内，运营想调加价策略时后端改配置就行，不用动代码。

5.4 状态更新接口的统一校验

状态更新接口不能做成"前端传什么状态我就改成什么"，必须走状态机校验。我在实现时维护了一个允许的状态迁移映射表：

# 允许的状态迁移 STATUS_TRANSITIONS = { 1: [0, 2], # 待接单 -> 已取消 / 已接单 2: [3], # 已接单 -> 配送中 3: [4], # 配送中 -> 已完成 } @app.post("/api/order/update_status") async def update_order_status(order_id: int, from_status: int, to_status: int): # 校验迁移合法性 if to_status not in STATUS_TRANSITIONS.get(from_status, []): return {"code": 10002, "msg": "非法的状态流转"} # 条件更新，防止并发下状态被重复推进 if to_status == 4: sql = "UPDATE `order` SET status = 4, delivered_at = NOW() WHERE id = :id AND status = 3" else: sql = "UPDATE `order` SET status = :status WHERE id = :id AND status = :from_status" result = db.execute(text(sql), {...}) db.commit() return {"code": 0, "msg": "状态更新成功"}

这里有一个看似多余但很重要的细节：状态更新也要用 where 条件带旧状态去更新。比如骑手点了两次"确认送达"，第一次已经把状态改成已完成，第二次再更新时因为 where status = 3 不成立，影响行数为 0，前端可以根据返回值提示"订单已完成，不要重复操作"。既杜绝了重复提交，又防止了脏数据。

6. 前后端联调时绕不开的几个坑

6.1 开发者工具能跑，真机一测就废

小程序开发里最典型的问题：在微信开发者工具里一切正常，真机打开就白屏或者接口全部超时。原因基本出在域名校验和 HTTPS 上。

开发环境下，开发者工具可以勾选"不校验合法域名、TLS 版本以及 HTTPS 证书"，这样 localhost 或者局域网 IP 都能直接访问后端。但手机真机预览时，微信强制要求请求地址必须是配置在后台的合法域名，而且必须是 HTTPS。解决办法：

• 正式环境：把后端 API 部署到一台有域名的服务器上，配好 HTTPS 证书，然后在微信公众平台的小程序后台配置 request 合法域名。
• 联调阶段：可以先申请一个测试域名，配 HTTPS 后再把后端代理过去，或者用本地调试隧道工具把本地端口映射到公网临时地址。需要注意，如果本地开发用 HTTP，还是要先保证调试工具的域名校验关闭，隧道映射出来的地址通常也要求 HTTPS 才能在小程序里跑通。

这个坑几乎每个小程序项目都会遇到，建议项目一开始就把域名和证书准备好，别等到真机测试时再手忙脚乱。

6.2 手机号获取：个人主体小程序没法直接用

热词里有很多人在搜"微信小程序登录获取手机号"，这里单独说明一下：wx.getPhoneNumber 能力和小程序主体的认证状态强相关，个人开发者注册的小程序默认拿不到用户手机号，需要企业主体并且在小程序后台开通相应的接口权限。即便开通了，2023 年之后微信也调整了授权逻辑，不再支持 wx.getUserInfo 直接弹窗授权昵称头像。

实际项目里我是这样做的：注册登录阶段不强制拿真实手机号，用户用微信登录后先分配临时身份，等需要骑手入驻时，再要求骑手填写手机号用于审核联系。用户端下单不需要手机号场景硬绑定，收货电话放在订单备注里由用户填写即可。这样既绕开了微信的能力限制，又符合业务需要。

6.3 模拟器定位不准，导致测试数据混乱

小程序开发者工具里的定位默认是模拟的，很多教程环境会固定返回一个地点（经常是深圳或者北京某处），这和真机定位完全是两码事。我第一次测试时，用开发者工具下了好几张单，全部集中在模拟点附近，距离算出来都是 0 点几公里，我还以为接口算错了。

排查了很久才反应过来是模拟器定位的问题。真机上 wx.getLocation 返回的是当前设备定位，和模拟器结果差异很大。建议测试联调阶段尽量用真机，特别是涉及距离排序、费用计算的场景，模拟器数据不能作为判断依据。另外，wx.getLocation 需要在 app.json 里声明 permission 描述，否则部分用户授权时会提示信息不完整。

6.4 时间格式和距离单位的约定

前后端联调最容易出"各说各话"的隐藏 bug。比如后端返回的 datetime 字段，在 JSON 序列化后会变成 "2024-06-01T12:00:00" 这种字符串，小程序端直接用 Date 处理倒还好，但如果有的接口返回时间戳、有的返回字符串，前端就得写兼容逻辑。我后来统一约定：所有接口时间字段一律传秒级时间戳，前端需要展示再自行格式化。

距离单位更要注意。接口里 distance_km 用的是数字，前端列表里要显示"1.2km"，有的页面想按米精度显示"1200m"。如果没有约定好，就会出现列表显示 1.2km，详情页却显示 0.0012km 的尴尬。我的做法是：接口一律返回公里数保留两位小数，前端展示时判断，小于 1 公里就显示"约 850 米"，大于 1 公里显示"1.2 公里"。展示逻辑统一收敛在一个前端工具函数里，不要散落在各页面。

6.5 订阅消息不适合做全流程实时通知

小程序端有一个天然的短板：后台状态下没法长期保持 WebSocket，所以"骑手抢单成功后实时通知用户"不能靠长连接推送实现。微信提供的方案是订阅消息，但要注意它有个限制：一次订阅授权只能推送一次消息。用户下单时要提示"允许发送订单进度提醒"，他点一次授权，平台才能在订单状态变化时推一条通知。想让用户在整个流程中收到多次通知，就得设计多次授权引导，比如下单页的订阅授权弹窗让用户多点几下。

实际做下来，最稳的通知方案是：骑手接单后，小程序端用订阅消息发一次"骑手已接单"；配送中状态就靠用户自己在订单详情页刷新查看。非要全程实时的话，建议引入厂商的小程序推送服务或者自建 WebSocket 网关，但这属于大工程，小项目没必要。

6.6 抢单后立刻查订单，可能查不到？

还有一个我自己踩过的小坑：骑手抢单成功后，前端立刻跳转到订单详情页，结果页面调用详情接口时提示"订单不存在"。原因是抢单接口提交的订单 ID 是字符串，前端在小程序 JS 里用的是 Number 类型比较，ID 后面多了个 ".0"，或者后端返回给前端的类型是 string 导致比较出错。

这类问题特别隐蔽，建议所有跨端接口统一把 ID 字段类型约定为 number 或者统一为 string，避免 123 和 "123" 在比较时出现隐式转换问题。前后端联调前先约定接口协议，字段名、类型、单位都列出来，能省很多排查时间。

7. 部署上线与后续扩展思路

7.1 服务器部署的起步配置

跑腿接单助手这种地方性业务，初期用一台 2 核 4G 的云服务器完全够了。部署架构可以很简单：

• 后端：Python 3.10 以上，pip 装依赖，用 uvicorn 拉起 FastAPI 服务。
• 进程守护：用 systemd 配一个服务，保证进程挂了能自动拉起，或者直接用 gunicorn 配多 worker。
• 反向代理：Nginx 做 HTTPS 终结，把 API 路径代理到 uvicorn 监听的本地端口。
• 数据库：MySQL 或者 PostgreSQL，初期单机实例足够。
• 缓存（可选）：如果上线后骑手量涨起来了，可以加 Redis 存 token 和每次拉取列表的临时缓存，减少数据库压力，但这一阶段不是必须。

上线前千万别忘了一件事：把小程序后台上传的代码提交审核。审核期间后端域名必须是公网 HTTPS 可访问的，否则审核员打开小程序时接口报错，会被打回。第一次审核建议选择本地生活或者跑腿配送相关类目，提前准备好相应的服务类目资质材料。

7.2 从"能接单"到"好用"，可以往这几个方向扩展

项目跑通基础闭环之后，真正投入运营前一般还要补几块拼图：

• 自动派单而不是全靠抢单：系统可以根据骑手当前位置、在途订单数、评分，自动把订单推给最合适的骑手，设定 30 秒响应超时后再释放给所有人抢。
• 钱包与结算：跑腿业务的履约保证金、订单分成、骑手提现，建议直接对接微信支付的分账能力，订单完成后自动把跑腿费和平台佣金分账到各自账户。
• 骑手入驻审核：从简单的角色标记升级为骑手提交身份证、健康证、电动车照片，管理员后端逐条审核。
• 多城市支持：订单表加大区字段，接单大厅按城市隔离，避免跨城骑手接到不合理的远单。
• 评价体系：订单完成后双向评价，骑手评分影响后续派单权重。

7.3 代码分层的小建议

项目如果只有几个接口文件，怎么都行，但一旦加了骑手入驻、结算、客服这些功能，代码就开始乱了。我的习惯是后端按模块分层：路由层只做参数接收和响应封装，业务层写状态机、距离计算、并发控制这些逻辑，数据访问层单独抽出来，避免在路由函数里直接拼 SQL。这样的结构在项目后期维护时省心很多。小程序端的代码也一样，公共请求封装、登录态检查、角色判断这些抽成公共模块，页面里只写页面逻辑。

这个项目做完之后，我最大的体会是：跑腿系统的难点基本不在"能下单、能接单"这个主流程，而在各种边界状态的处理。比如用户下单后十分钟没人接，要不要提醒；骑手接单后原地不动，平台要不要干预；用户顺路把单取消了，骑手已经在取货路上，损失怎么算。这些小问题在设计状态机的时候如果没想清楚，写代码时就会不停打补丁。

所以我给准备做同城跑腿项目的朋友一个最真诚的建议：别着急写代码，先花上半天时间，把订单从创建到完成、从取消到异常处理的所有状态流转图一张一张画出来，把每个节点的操作人和条件都写清楚。状态机定稿了，剩下的接口实现就是"照着图填代码"，效率反而最高。