★ FEATURED ARTICLE 简介这是一套面向同城跑腿业务的全开源技术解决方案基于FastadminThinkPHP与Uniapp开发包含用户端、骑手端与运营后台适合跑腿团队、独立开发者及有意搭建校园或小区配送平台的技术人员。系统覆盖帮取、帮送两种核心模式按距离/重量自动计价支持预约取件、临时加价、跑腿小费、物品保价地图精确定位后计算距离并规划导航路线提升配送体验。派单侧提供一键抢单、接单大厅按距离显示待抢订单、自由开工开关以及依据骑手距离、送货地址与等级进行智能推送的派单机制同时支持兼职/全职佣金结算运营后台可灵活切换抢单或派单模式并管理接单规则。资源压缩包约64.82MB代码无加密、可私有化部署便于快速二次开发或投入生产。目前已有94人学习下载适合需要完整前后端实现、想快速落地同城配送平台的开发者。1. 校园跑腿最需要的不是“能下单”而是“这一单该派给谁”午间取件高峰学生在宿舍楼、快递点同时下单骑手在几栋楼之间来回空跑——这是校园跑腿小程序里最典型的混乱场景也是智能派单要解决的核心问题不是把下单页面做得好看而是当订单进来后系统能根据骑手位置、手上单量、取件时间窗自动决定这一单派给谁。基于“跑腿小程序智能派单系统派单同城配送校园跑腿预约取件用户端骑手端全开源.zip”这类全开源工程本文会拆开它的用户端、骑手端和派单引擎讲清楚本地跑通的最小命令、派单评分里最值得调的 5 个参数以及从抢单切换到自动派单时最容易踩的坑。适合想快速验证派单策略、做毕业设计或准备把同城配送流程产品化的开发者目标是让你拿到源码后一周内跑出第一笔测试订单而不是在工程目录里迷路。2. 开源跑腿项目的四层架构用户端、骑手端、管理端与派单引擎2.1 用户端的关键链路预约取件与订单状态机先看用户端。校园跑腿和普通同城配送最大的差异体现在“预约取件”。用户不是实时叫车而是先指定一个时间窗口让骑手在某段时间内到宿舍楼下、图书馆或快递点取件之后再做配送。这就要求订单核心字段不只是起点、终点和价格还必须包含“期望取件开始时间”“期望取件结束时间”“期望送达时间”三类字段否则预约单和即时单在派单逻辑里无法区分。很多初版工程把预约做成了用户在备注里写一行字这种做法在派单引擎里完全没有意义因为系统只能看见字符串无法参与时间计算。一个典型跑腿订单的状态机一般包含待支付、已支付待接单、已接单待取件、骑手已取件、配送中、已送达、已完成。被取消的单子走待支付取消或已支付取消已支付取消时后端要触发退款回调。常见实现里状态流转不靠前端按钮而是后端维护订单状态表每次变更写入一张订单操作流水表。跑腿项目的调试难点就在这里用户说“我没收到货”骑手说“我早送到了”两边都有界面证据但后台对不上账往往是因为状态变更没有流水记录没办法定位到底是哪一步漏了。所以拿到源码后不要只看订单表优先看有没有 order_log 或 order_track 这类流水表没有的话建议自己补一张后续分析派单超时和骑手滞留都靠它。预约取件的下单表单通常长这样取件地址通过地图选点或地址库选择取件时间窗用两个时间选择器分别定开始和结束收货地址、物品类型和备注都是普通字段。前端把这些组合成一个 JSON 提交到后端后端落库时把时间窗存成 pickup_start_time 和 pickup_end_time 两个字段而不是只存一个“预计取件时间”。这两个字段会直接参与第 4 章的派单评分这也是预约单和即时单在调度层最大的差异点即时单没有时间窗评分只看距离和负载预约单必须保证骑手在时间窗内能到达取件点否则优先度要下降。2.2 骑手端的接单模式抢单与派单两种节奏如何共存骑手端面向的是两类完全不同的角色。全职骑手熟悉校园地形希望系统直接派单省去刷单兼职学生只在自己没课时跑希望看到订单列表自己挑单。所以成熟工程里通常不是二选一而是把订单的接单方式做成一个字段常见命名是 assign_mode取值可以是 manual管理员手动指派、auto智能派单、grab抢单。三种模式共存并不会增加多少开发量但能给运营方一个灰度切换的余地后面第 6 章还会用到这个设计。抢单模式的实现比较直接骑手端通过 WebSocket 或定时轮询拉取待抢单列表看到订单后点击抢单后端用条件更新保证同一订单不会被两个骑手同时抢到。这里最常见的翻车点是前端点击抢单到后端完成校验之间有几百毫秒的窗口两个骑手几乎同时请求结果双双提示“抢单成功”订单却被分配给了其中一人。解决做法是抢单接口里先执行一句条件更新例如把订单状态从“已支付待接单”改成“已接单”并同时写入抢到者的骑手 ID然后根据受影响行数判断是否成功受影响行数为 1 才算抢到否则直接返回“手慢了”。不要先查一次状态再更新查询与更新之间的空档就是并发问题产生的根源。派单模式则完全不一样。它不依赖骑手主动而是由派单引擎在订单进入“待派单”队列后按评分规则选出一个最合适的骑手然后向骑手端推送一个确认请求。骑手端收到的是“系统派单请确认”而不是一个可抢的订单列表。常见做法是给骑手 30 到 60 秒的接收窗口超时未确认自动改派下一个骑手。这个改派超时时间非常值得单独拎出来看因为在校园午高峰30 秒没人接就意味着订单堆积而在平峰期60 秒没接可能只是骑手正在骑车看不了手机。很多开源工程把这个值写在配置表里目的就是让你按时间段动态调整而不是在代码里写死。2.3 管理后台与派单引擎的分工边界管理后台不是做一个花哨的订单列表就完了它要承担三块职责基础数据维护、异常干预、规则配置。基础数据包括骑手资料与审核状态、服务区域划分、配送费模板、用户和骑手的黑名单异常干预包括订单改派、取消退款、骑手封禁规则配置包括派单算法开启/关闭、评分权重、接单模式切换。凡是运营过程中要改的东西都应该做成配置而不是让运维去改代码。比如临时把某个楼的配送费调高如果只能改代码再发版运营基本不会愿意用你的系统。派单引擎在开源工程里通常是一个独立服务或独立模块不和用户端的 CRUD 代码混在一起。它的输入是“待派单订单”和“可用骑手快照”输出是一串派单建议或者直接执行派单动作。为了压测和回放常见设计是引擎只输出评分结果和推荐骑手而不直接写库真正写库的动作由调度模块完成。这样做的好处是你可以把线上的历史订单数据重新喂给引擎对比新旧算法的评分结果而不需要真的把订单再派一次。选型时优先看派单引擎是否独立成模块如果看到派单逻辑直接写在订单 Controller 里后续改算法会非常痛苦每次调参都要动核心接口风险很大。3. 把全开源源码跑通的最小路径从 zip 到第一笔测试订单这一章直接进入落地路径。这类工程的典型结构是一个后端服务、一个管理后台前端、一套用户端小程序、一套骑手端小程序外加一份 SQL 初始化脚本。不考虑业务复杂度按依赖关系顺序启动即可先数据层再后端最后前端。3.1 技术栈选型为什么原生小程序和 uniapp 会同时出现看标题里的“全开源”最常见的工程有两种前端形态原生微信小程序或 uniapp 工程。两者经常共存用户端用 uniapp 方便跨端和二次开发骑手端用原生微信小程序追求更可靠的定位和更直接的原生能力调用也有相反的做法用户端原生、骑手端 uniapp。这没有绝对标准但建议你先在工程根目录看有没有 pages.json有就是 uniapp没有就是原生小程序这样能快速确定用哪条编译工具链。从跑通速度来说我建议优先把 uniapp 端跑起来因为 uniapp 可以先在 HBuilderX 里运行到浏览器把界面和接口先点通再打包到微信开发者工具。原生小程序则必须一开始就配 appid、处理 request 合法域名对只想看系统效果的人来说链路长一些。但要注意跑腿业务强依赖微信登录、手机号、地图和定位浏览器预览只能看到骨架和部分列表真实数据链路最后还是得回到微信开发者工具里验证。所以可以这么计划第一天先让 uniapp 端在浏览器里跑起来第二天再导入微信开发者工具联调登录与定位。3.2 本地启动的最小命令集后端、管理端、小程序端各干什么假设工程结构是常见的 Spring Boot 后端 Vue 管理后台 uniapp 小程序端本地跑通的顺序通常是先启动 MySQL 和 Redis再导入 SQL再启动后端接着启动管理端最后跑小程序端。前端和后端不要同时启动否则接口报错时你分不清是依赖没起来还是代码问题。先在 MySQL 里建库并导入初始化脚本常见做法是命令行直接导入mysql -uroot -p sql/init.sql这段命令会把建表语句、初始管理员账号、服务区域和配送费模板一起写入数据库。如果初始化脚本里有存储过程或自定义函数导入时要注意 MySQL 版本兼容5.7 和 8.0 对默认字符集、排序规则的默认值处理不同有时候报 1067 或 1273 错多半是字符集或 SQL mode 导致把数据库字符集统一成 utf8mb4 再试一次通常能解决。后端如果是 Spring Boot常见启动方式是cd server mvn spring-boot:run -Dspring-boot.run.profilesdev这里的 profilesdev 指定开发环境配置工程里一般会区分 dev 和 proddev 配置指向本地 MySQL、Redis并且通常关闭了微信支付真实回调。启动后看控制台日志出现类似“Started Application”的字样才算成功。如果你的机器上没装 Maven直接敲 mvn 会提示 command not found要么先安装 Maven要么用 IDEA 自带 Maven 面板启动不要在这里硬卡太久。管理端一般是 Vue 工程启动命令是cd admin npm install npm run devnpm install 首次安装会比较久还可能遇到 node 版本不兼容。常见的是 node-sass 在 Node 18 以上安装失败这类工程如果依赖比较老建议直接用 nvm 把 Node 切到 14 或 16而不是反复删除 node_modules 重试。启动后浏览器打开管理端地址能看到登录页说明前端起来了接着用初始化脚本里的管理员账号登录查看订单和骑手列表是否正常加载。小程序端如果是 uniapp先安装依赖再编译到微信开发者工具cd miniapp npm install npm run dev:mp-weixin编译产物通常会生成到 dist/dev/mp-weixin 目录然后打开微信开发者工具选择“导入项目”指向这个目录。这里有个高频坑小程序端代码里的 request 地址如果写的是 http://localhost:8080在开发者工具里必须勾选“不校验合法域名、web-view业务域名、TLS 版本以及 HTTPS 证书”否则请求全部报 fail页面看起来就像后端没启动。这个开关只是本地开发时用上线前必须在微信公众平台配置正式的 HTTPS 域名。3.3 微信小程序登录获取手机号与预约取件的关键配置跑腿系统的用户端和骑手端都依赖微信登录而“微信小程序登录获取手机号”现在的标准流程不是前端直接拿手机号。前端先调 wx.login 拿到 code后端用 code 换 openid 并返回自定义 token手机号则是用户点击“获取手机号”按钮通过 open-type 能力拿到加密数据再由后端解密和绑定。代码上常见是这样的顺序// 用户端登录并获取手机号 wx.login({ success: async (res) { const code res.code; // 后端 /api/login 使用 code 换取 openid并返回自定义 token const loginRes await request(/api/login, { code }); wx.setStorageSync(token, loginRes.token); } });逻辑说明wx.login 拿到的 code 有效期只有 5 分钟且只能用一次所以后端换取 openid 的接口如果失败要提示用户重新触发登录而不是静默重试。openid 是用户身份标识但它不是手机号跑腿系统里用户连接以 openid 为根手机号是后续下单联系骑手或骑手联系用户时的补充信息。预约取件的下单接口字段层面要确认后端接收的是时间戳还是日期字符串。常见做法是前端传 ISO 日期字符串后端转成 LocalDateTime数据库存 datetime。这里最容易出问题时区前端传的 2025-06-01T12:00:00 到了后端如果没有统一时区可能被当成 UTC 存成 20:00派单引擎再读出来就成了晚上直接把预约单派给了错误的时段。我的经验是前后端统一传 Unix 毫秒时间戳数据库用 bigint 存储彻底绕开时区解析。虽然数据库里看起来是一串数字可读性差但比半夜查“为什么预约单被提前派走”要省心。如果改不动数据库字段至少要在后端启动参数里加上时区设置并在数据库连接串里指定 serverTimezone。4. 智能派单的核心评分逻辑与 5 个必调参数派单引擎是这个系统里最值得研究的部分。前面已经讲清了状态机和跑通流程这一章进入算法选型、评分公式和调参方法。4.1 派单算法选型从 FCFS 到评分制贪心派单全开源项目里出现的派单算法大致有三档先到先得FCFS、就近派单、评分制贪心派单。FCFS 严格按订单进入队列的顺序分配不考虑骑手位置适合单量很小的场景做演示可以上线不行就近派单只看距离容易把离得近的那一两个骑手累到爆其他人闲着评分制贪心派单是当前最常见的落地形态因为它把距离、负载、时间窗、骑手效率等因素统一折算成分数再选最高分。评分制的核心思路是对每个待派单订单 O 和每一个可用骑手 R计算一个分数 S(O,R)。分数由几部分组成距离分、负载分、时间窗匹配分以及可选的骑手评级分。派单时按分数从高到低选择骑手如果该骑手超时未确认就顺延给下一位。这个逻辑在开源工程里通常写成一个独立方法参数放进配置文件或配置表目的就是不修改代码就能调权重。一个常见的最小评分伪代码如下def score(order, rider): dist_score -distance(order.pickup, rider.position) # 距离越近分数越高 load_score -rider.active_orders * load_weight # 手上单越多扣分越多 time_ok 1 if order.pickup_start rider.free_at order.pickup_end else -10 return dist_score * w_distance load_score time_ok * w_time逻辑说明这里输出的是相对分数而不是概率所以权重 w_distance 和 w_time 的绝对值大小直接决定距离和时间窗哪个优先级更高。如果出现“全都派给最近骑手”的现象问题往往不是公式不对而是距离分的数值量级远大于负载分把后者的贡献压没了。解决思路是先对各分项做归一化再乘权重避免单个分项主导结果。参数说明load_weight 通常从 0.5 起步w_distance 建议 0.8 到 1.2w_time 建议 1.5 到 2.5具体数值结合第 4.2 节的表再定。4.2 需要调参并观察的 5 个派单参数调参不是拍脑袋要有一个最小的参数集合。最常动的参数如下参数常见初始值作用调整经验距离权重 w_distance1.0控制“就近优先”的程度校园场景建议 0.8-1.2太高会让顺路带单失去价值负载权重 load_weight0.5控制骑手手上单量对评分的影响兼职骑手偏多时调到 0.8 以上避免某一两个人被塞满改派超时时间30-60 秒骑手未确认时多久换下一个午高峰短一点平峰长一点建议做成按时间段生效的配置时间窗权重 w_time2.0预约取件时间窗的严格程度预约单占比高时再调高否则骑手会优先接低峰即时单最小派单间隔5 秒同一骑手连续被派单的最小间隔高峰调到 10 秒防止骑手端一口气弹多个订单调参有一个基本原则一次只改一个参数改完至少看半天数据。观察指标主要有三个订单从支付完成到骑手接单的平均耗时、骑手空驶率、订单超时率。接单耗时太长优先调短改派超时空驶率高优先调大距离权重超时集中在某个时间窗优先调高时间窗权重。不要三个指标一起优化那样你根本说不清是哪次改动起作用。开源工程里的参数一般放在配置表而非配置文件就是为了让你能在管理后台直接改、马上生效。注意任何参数改动都要记录在案包括修改时间、原值、新值、观察指标变化方便回滚和复盘。4.3 抢单模式下的人工兜底与调度回滚智能派单不是百发百中空转的情况很常见骑手端网络断开、GPS 定位没更新、骑手手动关闭派单模式、高峰期没有可用骑手。所以成熟项目里几乎都会保留管理后台的人工派单页面管理员看到订单卡在“待派单”超过阈值直接在后台指定一个骑手。这个兜底的价值不只是处理几单而是让你敢把自动派单打开——你知道即使派单引擎出问题也不会真的没人管。调度回滚则是另一个容易被忽视的功能。假设派单引擎在 10:00 把一单派给了骑手 A但 10:01 发现 A 已经离线或者主观拒绝了系统要能自动改派给骑手 B并记录改派原因。实现上常见做法是维护一张派单流水表每条记录包含订单 ID、骑手 ID、动作派单、确认、超时、拒绝、改派和时间。后面分析“为什么这单超时了”查流水表的动作序列就知道卡在哪一步。注意改派不是改一下订单表的 rider_id 就完事必须同时给 A 推送“订单已取消”提醒、给 B 推送新的派单提醒否则 A 还在去取件的路上B 也去了用户会被两个骑手同时联系这是最容易引发投诉的场景。拿到源码以后优先确认工程里有没有这张流水表没有的话建议尽快补上。5. 从源码到上线的避坑手册5 个实测踩坑现象开源源码能运行是一回事在自己环境里可靠跑起来是另一回事。以下五个现象来自同类项目的常见问题按“现象→原因→解决”记录。5.1 现象微信小程序抓包看不到请求或所有请求都报 fail现象用微信开发者工具打开页面接口全部报 fail后端日志却没有收到任何请求或者用抓包工具想看小程序请求发现根本抓不到。原因小程序 request 的域名校验默认开启代码里请求的是 http://localhost 或局域网地址而小程序要求 https 且域名已备案。另外开发者工具没有正确配置外部工具也看不到请求不代表后端没启动。解决先在开发者工具“详情 → 本地设置”里勾选“不校验合法域名、web-view业务域名、TLS 版本以及 HTTPS 证书”再确认后端接口允许跨域。小程序抓包的排查顺序应该是先看开发者工具 Network 面板有没有请求发出再看后端日志有没有收到请求最后才看数据库是否有数据。如果 Network 面板里根本没有请求问题在前端地址配置或编译产物没更新有请求但后端没日志问题在域名校验或网络连通后端有日志但数据不对才需要继续排查业务逻辑。5.2 现象派单引擎把所有订单都派给最近骑手其他人空闲现象打开自动派单后某一个骑手的待处理订单堆积其他骑手长时间空闲用户等待时间没有明显下降。原因评分公式里距离分没有归一化数值范围在 0-1000 米这个量级而负载分只有个位数负载权重再大也压不过距离分最终变成纯就近派单。解决给评分的各个分项做归一化让距离、负载、时间窗都在同一个量级例如 0 到 1再乘各自权重。如果工程里没有归一化函数可以临时把负载分乘以一个放大系数观察效果但这只是临时验证不能作为长期配置。改完后对比同一时段内各骑手接单量的标准差如果明显下降说明负载均衡开始生效。5.3 现象预约取件单的时间窗显示正常派单引擎却提前几小时派出去现象用户预约的是下午 14:00-14:30 取件系统上午 11:00 就把单派给了骑手骑手到了取件点却没人。原因这是典型的时区问题。前端传的“2025-06-01 14:00:00”字符串在后端解析时被当成 UTC转成本地时间后变成 22:00而派单引擎用当前时间与 pickup_start_time 比较时看到的时间窗已经错位误认为时间窗即将到来或已过期于是提前派单。解决全链路统一使用 Unix 毫秒时间戳。前端下单时用 Date.now()后端直接存 bigint派单引擎比较时全部用毫秒数。如果数据库字段已固定为 datetime就在后端统一时区并保证数据库连接参数里带 serverTimezoneAsia/Shanghai。这个问题的排查成本远高于改造成本属于典型的早改早省心。5.4 现象uniapp 打包时提示 source size 2612kb exceed max limit 2mb现象微信开发者工具导入 uniapp 编译产物后提示主包体积超过 2MB小程序编译失败。原因微信小程序主包体积限制 2MB工程把页面的路由、静态图片、第三方 UI 组件全部打进了主包。跑腿项目里用户端的图片资源多加上组件库很容易超限。解决按页面路由拆分包。主包保留首页、订单详情、登录骑手端相关页面和用户个人中心拆进分包。pages.json 里增加 subPackages 节点并把相关页面路径从 pages 数组移入 subpackages 数组示意如下{ pages: [ { path: pages/index/index } ], subPackages: [ { root: subpkg/rider, pages: [ pages/list/list ] } ] }逻辑说明分包根目录和页面路径必须写完整跨包跳转时路径要带 /subpkg/rider/ 前缀否则运行时报找不到页面。另外把骑手证照片、商品图等大图片资源放到图床或对象存储不要放在本地 static。分包之后及时查看主包大小目标控制在 1.5MB 以内留出余量。5.5 现象骑手端定位偶尔漂移系统把单派到几百米外现象骑手实际在 A 栋派单引擎却按 B 栋附近的坐标计算距离导致订单被派给更远的人或者骑手接到单后找不到取件点。原因骑手端用的是模拟器定位或上一次缓存的 GPS 坐标没有持续更新楼内 GPS 信号弱时返回的坐标精度差引擎拿旧坐标或低精度坐标直接计算。解决骑手端在进入“配送中”状态后调用 wx.onLocationChange 持续监听位置每 10-15 秒上报一次坐标并过滤掉精度值大于 50 米的定位回调。派单引擎侧设置“骑手位置新鲜度上限”比如超过 3 分钟未更新的骑手评分时标记为不可用避免用旧坐标参与派单。这个新鲜度阈值要放进配置表因为不同校园的网络和楼宇遮挡情况差别很大固定值容易误伤。6. 上线前值得多花一周做的事压测、可视化与灰度智能派单这类系统真正决定成败的不是功能而是你能否看见调度过程并提前验证。最后讲三个进阶动作。6.1 用回放脚本压测派单引擎先做数据回放。把一份真实订单数据包含下单时间、取件点、配送点在测试环境按原时间顺序重新喂给派单引擎观察平均派单耗时和超时率。脚本可以用 Python 直接请求派单接口模拟 50 个骑手在线、并发 200 单的负载# 回放压测模拟 200 单并发进入派单队列 import time, requests orders load_orders(test_orders.json) for i in range(0, len(orders), 50): batch orders[i:i50] t0 time.time() for o in batch: requests.post(http://localhost:8080/api/dispatch, jsono) print(fbatch {i//50}, total {time.time()-t0:.2f}s) time.sleep(1)逻辑说明这里按 50 单一批发送是为了观察派单引擎在批量请求下是否出现阻塞。如果总耗时随批次数量线性增长说明存在串行瓶颈优先查 Redis 连接池和订单表索引如果每一批基本稳定在相近耗时说明吞吐正常。压测只针对测试库不要用线上全量订单避免把真实订单重复派发。调参的对照也要用同一份回放数据否则两次结果差异可能是数据不同而不是参数不同。6.2 把派单结果画成调度热力地图调参最怕一通改完不知道效果如何。我一般会把派单结果映射到校园地图每个订单的取件点画一个圆骑手轨迹用线段表示颜色标记空驶和超时。这样看一个下午的调度数据就能发现算法是不是总往某个楼群塞单。实现不复杂把订单表和派单流水导出成 GeoJSON再用 Leaflet 或高德 JS API 渲染。这一步在项目里看起来不是必做项但实际价值很高因为你把派单调度从黑匣子变成了可观察的图形后续调每个参数都有了一个直观的参照系也能拿给运营看效果沟通成本低很多。6.3 先抢单后派单的灰度方案最后说上线节奏。不要第一天就打开全量自动派单。常见做法分三步第一周关闭派单引擎所有订单走抢单加管理员手动指派后台同步收集骑手位置上报间隔、订单配送路径第二周开启派单引擎但只对 10% 的低峰订单启用其余仍然抢单人工对比派单和抢单的配送时长第三周再全量开启自动派单同时保留管理后台的人工改派兜底。整个过程本质上是在积累“这个校园的骑手习惯、楼宇距离和高峰期流量”没有这些数据评分公式里的权重只能靠猜。经历过一次把订单派给已经逆风骑到另一栋楼的骑手之后我的习惯就变成改任何调度参数之前先导出三天派单流水看一眼距离分布和骑手负载分布再动配置项。希望这个方法能帮到你少走一点弯路。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
