简介这是一份基于微信小程序的校园跑腿服务项目完整源码前端涵盖小程序页面与后台管理界面后端以PHP处理核心业务适合用于毕业设计、课程项目或小程序与PHP开发学习。包内共1715个文件约20.83MB其中611个PHP负责接口与业务逻辑182个JavaScript、133个Vue、90个WXML与92个WXSS构成小程序和后台前端100个JSON用于配置另含SQL数据库脚本、图片素材及便于一键安装运行的bat脚本整体结构清晰。项目包含用户认证、订单处理、任务分配、支付接口等核心功能模块源码经过可运行验证可直接部署测试。已有73人学习浏览对有答辩演示或快速搭建同类跑腿平台需求的开发者来说是一份兼具参考与复用价值的实践案例。1. 把 .bak 文件当成线索一个校园跑腿项目的真实结构拿到weixin164校园跑腿php.rar这个压缩包第一眼扫过去里面躺着大量.bak备份文件和三个.bat脚本而不是一个规整的 src 目录这种草莽感恰恰暴露了项目的演进过程前端改过样式、后端调过接口备份是为了随时回滚。这不是坏事对想学微信小程序和 PHP 后端协作的开发者和毕业生来说反而是一份难得的完整样本——它同时包含了微信小程序前端、PHP 后端接口、构建脚本和环境初始化流程。整个系统要解决的是校园内即时跑腿需求用户在小程序下单后台 PHP 处理订单分发、状态流转和支付回调管理员或抢单者接手执行。从文件列表里的IndexMain.vue.bak、IndexAsideStatic.vue.bak能看出前端不是原生小程序而是用 Vue 语法编写的最终被打包成app.94b62048.css这样的静态资源后端则是典型的 PHP 接口服务。下面我按后端接口设计 → 小程序端对接 → 环境初始化 → 排错优化的顺序拆每个环节都给到能直接抄走的代码和参数说明。2. PHP 后端接口设计与订单状态机2.1 数据表结构跑腿系统的核心表拆分解压后你会看到一个Users目录这不是用户表而是后端存放用户数据模块的文件夹。跑腿系统最少需要四张核心表用户表、订单表、接单记录表、订单状态日志表。用户表不做详细展开重点是订单表的设计——它是整个系统的中枢。订单表常见做法是包含订单号、下单用户 ID、配送地址、收货人、物品描述、配送费、状态字段、创建时间和超时时间。状态字段我建议用 tinyint 而不是字符串原因有两个一是省存储二是后续写状态机判断时整数比较比字符串匹配快得多。订单表结构大致如下CREATE TABLE errand_order ( order_id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL COMMENT 业务订单号全局唯一, user_id INT UNSIGNED NOT NULL COMMENT 下单用户, pickup_address VARCHAR(255) NOT NULL COMMENT 取件地址, delivery_address VARCHAR(255) NOT NULL COMMENT 送达地址, goods_desc VARCHAR(500) DEFAULT COMMENT 物品描述, fee DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT 配送费, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待接单 1已接单 2配送中 3已完成 4已取消, timeout_at INT NOT NULL COMMENT 超时自动取消时间戳, created_at INT NOT NULL, KEY idx_status (status), KEY idx_user (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里有个值得注意的点order_no和自增order_id是两套编号。自增 ID 主键用于内部关联业务订单号对外暴露。生成订单号时不要用 time() 加随机数并发下会撞车常用做法是date(YmdHis) . sprintf(%04d, mt_rand(1000, 9999))再拼上用户 ID 末尾两位基本能保证单日不重复。配送费字段用 DECIMAL(10,2) 而不是 float因为浮点数在支付场景下会有精度丢失PHP 里用 bcadd 做金额计算更稳妥。2.2 微信登录与用户身份绑定小程序端拿到微信的 code 后需要后端调用微信接口换 openid。这里有一个所有 PHP 开发者都要记住的细节jscode2session接口返回的数据里openid是用户唯一标识session_key是会话密钥但这玩意儿千万不能返回给前端否则有心人可以直接解密用户手机号等敏感数据。正确流程是后端拿 code 换 openid 后生成自己的 token 返还给小程序。核心代码大致是这个样子public function login($code) { $appid 你的appid; $secret 你的appsecret; $url https://api.weixin.qq.com/sns/jscode2session?appid{$appid}secret{$secret}js_code{$code}grant_typeauthorization_code; $resp file_get_contents($url); $data json_decode($resp, true); if (!isset($data[openid])) { // 记录错误日志不要直接把微信返回的 errmsg 抛给前端 return $this-error(登录失败,请重试); } // 查表或创建用户然后生成自己的 token $user $this-findOrCreateUser($data[openid]); $token md5($user[id] . time() . mt_rand(1000, 9999)); // 存 token 到缓存或数据库设置 7 天有效期 return $this-success([token $token, user_info $user]); }这里用了file_get_contents请求微信接口在低并发场景下够用但正式上线建议换成 cURL 并设置超时时间否则微信接口慢时 PHP 进程会一直阻塞。token 的生成用了简单的 md5讲实话安全性一般好一点的方案是hash(sha256, $user[id] . time() . random_bytes(16))。另外注意 code 一次性有效五分钟内没换到结果就会失效所以前端必须在wx.login成功后立刻调这个接口。PHP 接口返回给前端的统一格式我也建议固定下来不要有的接口返回数组、有的返回对象我一般用[code 0, msg ok, data [...]]这个结构前端封装 request 时统一判断 code。2.3 订单状态机的流转与超时处理跑腿订单不是简单的新增和修改它有一个明确的生命周期待接单 → 已接单 → 配送中 → 已完成中间还能跳转到已取消。如果在代码里直接写update order set status 2时间长了必然出现状态错乱比如已取消的订单被接单了。所以要用状态机约束流转代码里显式定义允许的跃迁关系private $transitions [ 0 [1, 4], // 待接单可以接单或取消 1 [2, 4], // 已接单可以配送或取消 2 [3], // 配送中只能完成 ]; public function changeStatus($orderId, $newStatus) { $order $this-find($orderId); if (!in_array($newStatus, $this-transitions[$order[status]])) { throw new \Exception(非法状态流转); } // 更新订单状态,同时写状态日志表 $this-db-update(errand_order, [status $newStatus], [order_id $orderId]); $this-db-insert(order_status_log, [ order_id $orderId, old_status $order[status], new_status $newStatus, operator $this-userId, created_at time(), ]); }状态日志表非常关键出了纠纷时它是唯一的追溯依据。再加一个 PHP 队列的思路用户下单后不是立即派单而是先进入待接单池同时把订单号推入 Redis 队列或直接存到errand_task_queue表里由后台的轮询脚本或抢单页面去消费。订单超时未接单时常见做法是写一个定时任务每分钟扫一次timeout_at time() and status 0的订单自动置为取消。这里要注意索引timeout_at和status必须建联合索引否则订单量大了以后这个扫表 SQL 能把数据库拖垮。3. 小程序端对接登录态、构建产物与 API 映射3.1 从 app.94b62048.css 反推前端技术栈先看文件app.94b62048.css文件名里的 hash 值是 Webpack 构建时生成的。这说明前端不是直接用微信开发者工具写原生 WXML而是用 Vue 语法通过 uni-app 或 mpvue 编译成小程序代码。这也解释了为什么压缩包里会有IndexMain.vue.bak、IndexHeader.vue.bak这样的文件——.vue单文件组件是源码构建后才生成小程序能跑的wxss和js。理解这一点很重要修改前端代码后必须重新构建不能直接改dist目录里的产物。前端页面与后端 PHP 接口的映射关系大致是下面这样这也能帮你快速定位代码文件小程序页面对应接口接口职责登录页POST /api/user/logincode 换 token首页GET /api/order/list?status0待接单列表下单页POST /api/order/create创建订单订单详情GET /api/order/detail?idxx订单信息与状态个人中心GET /api/user/profile用户信息与历史记录3.2 request 封装与 token 注入小程序端的wx.request每次都得手动写header、success、fail很繁琐。我在实际项目里会统一封装一个request.js把 baseURL、token 注入、错误码拦截都收拢到一个文件里。这样后面接 PHP 接口时只需要改一个变量就能切换测试服和正式服不会出现全局搜索替换域名的情况。参考实现如下const BASE_URL https://your-php-server.com/api; function request(path, method GET, data {}) { return new Promise((resolve, reject) { const token wx.getStorageSync(token) || ; wx.request({ url: BASE_URL path, method: method, data: data, header: { Content-Type: application/json, Authorization: Bearer token }, success: (res) { if (res.statusCode 200 res.data.code 0) { resolve(res.data.data); } else if (res.statusCode 401) { // token 过期跳回登录页 wx.removeStorageSync(token); wx.navigateTo({ url: /pages/login/login }); reject(res.data); } else { wx.showToast({ title: res.data.msg || 请求失败, icon: none }); reject(res.data); } }, fail: (err) { // 网络错误提示用户检查网络 wx.showToast({ title: 网络异常, icon: none }); reject(err); } }); }); } module.exports { request, BASE_URL };登录跳转这里有个坑wx.navigateTo跳转会累积页面栈用户反复登录几次后栈就满了页面卡住不动。正确做法是登录页用wx.redirectTo或者在 tabBar 页面登录时直接wx.switchTab。另外res.data.code 0这个判断依赖后端统一返回结构如果后端某个接口忘了包一层直接返回了裸数据前端这里会静默失败。我调试时会先在success里打印完整res.data而不是只看拦截后的结果。3.3 下单流程的完整链路小程序端下单是整个项目最复杂的交互涉及地址选择、配送费计算、备注填写和支付。配送费的计算放在前端还是后端这是个值得考虑的问题如果放在前端用户可以篡改费用直接提交低价订单如果放在后端前端展示的价格和实际扣费可能不一致。我的建议是前端只展示预估费用、真实费用必须由 PHP 后端根据距离重新计算。前端下单时提交的是起点终点坐标或地址 ID后端拿到后再算距离和费用。这样即使用户伪造请求参数后端也能兜住。下单页提交的代码大致是这个流程const data { pickup_address: this.pickupAddress, delivery_address: this.deliveryAddress, goods_desc: this.goodsDesc.trim(), receiver_name: this.receiverName, receiver_phone: this.receiverPhone }; const order await request(/order/create, POST, data); if (order.order_no) { // 生成订单成功,跳转支付页 wx.navigateTo({ url: /pages/pay/pay?order_no order.order_no }); }这里的order_no是整个支付流程的关键标识后端生成后返回给前端。注意不要拿着自增order_id去支付因为 ID 是连续的竞争对手或者恶意用户可以通过遍历 ID 看到所有订单数据。所有对外暴露的业务标识一律用order_no。4. 三个 bat 脚本背后的环境变量与构建流程4.1 1-install.bat依赖安装的自动化压缩包里的1-install.bat、2-run.bat、3-build.bat是 Windows 下的一键脚本这种形式在毕业设计和课程设计里很常见但对刚接触的人其实隐藏了不少信息。逐个拆开看第一个安装脚本的核心逻辑通常是检查 PHP 和 Composer 是否在 PATH 里然后执行依赖安装echo off chcp 65001 nul echo [1/3] 检查 PHP 环境... php -v nul 21 if errorlevel 1 ( echo 未检测到 PHP请先安装 PHP 并加入系统 PATH pause exit /b ) echo [2/3] 检查 Composer... composer -V nul 21 if errorlevel 1 ( echo 未检测到 Composer请先安装 Composer pause exit /b ) echo [3/3] 安装后端依赖... composer install --no-dev --optimize-autoloader echo 安装完成 pause这段脚本里chcp 65001是个隐藏深坑。Windows 的 cmd 默认代码页是 GBK如果 bat 文件里包含中文注释和 echo 输出文件保存编码又是 UTF-8执行时就会乱码或直接报错。chcp 65001把代码页切到 UTF-8 能解决显示乱码但前提是 bat 文件本身保存为 UTF-8 编码。如果保存成了 ANSI切到 UTF-8 后反而乱得更狠。建议用 VS Code 打开 bat 文件右下角确认编码再保存为 UTF-8。Composer 依赖安装慢是国内网络环境的老问题可以修改composer.json里的仓库源为国内镜像阿里云镜像或腾讯云镜像或者在项目根目录放一个composer.json的config字段声明仓库 URL。这一步不做composer install可能卡十几分钟做了一分钟完事。4.2 2-run.batPHP 内置服务器启动后端第二个脚本负责启动后端服务。PHP 开发环境最省事的方式是直接用内置服务器php -S不需要装 Nginx 或 Apache。运行脚本大致是这样echo off chcp 65001 nul cd /d %~dp0 set PORT8080 echo 启动 PHP 内置服务器, 监听端口 %PORT% ... php -S 0.0.0.0:%PORT% -t public pause这里cd /d %~dp0是切换到 bat 文件所在目录%~dp0是 bat 脚本所在的完整路径。如果少了这行你在其它目录双击这个 batPHP 会因为找不到public目录直接报错。-t public指定了 web 根目录这是 PHP 项目里常见的入口设计public/下放index.php作为前端控制器其它代码文件通过 Composer 的 autoload 加载不在 web 根目录内这样用户无法直接通过 URL 访问敏感文件。0.0.0.0表示监听所有网卡局域网内其他设备可以访问。如果只想本机调试改成127.0.0.1更安全。另外注意 PHP 内置服务器是单进程的一次只能处理一个请求如果前端页面同时发多个请求就会出现请求排队、页面转圈的情况。并发测试时还是要上 Nginx PHP-FPM但本地跑通功能没问题。4.3 3-build.bat前端资源构建第三个脚本是前端构建。从app.94b62048.css这个文件名可以断定前端用的打包器是基于 Webpack 的构建命令一般是npm run build。构建脚本内容和安装脚本类似先检查 Node 环境再安装 npm 依赖最后执行构建echo off set NODE_ENVproduction cd /d %~dp0\frontend if not exist node_modules ( echo 安装前端依赖... call npm install --registryhttps://registry.npmmirror.com ) echo 开始构建小程序/前端资源... call npm run build echo 构建完成产物在 dist 目录 pausenpm install时指定--registry参数可以临时切换镜像源不用改.npmrc文件适合在不对项目做额外改动的情况下跑通构建。call npm run build里的call也很关键bat 里直接写npm run build会把控制权完全转交给 npmnpm 执行完退出后bat 脚本后续的echo不会执行窗口直接关闭你根本来不及看构建结果。加了call才保证控制流回到 bat 继续执行。还有一个常见坑是 node_modules 目录被杀毒软件误删或权限受限。Windows 下如果npm install报了 EPERM 错误先检查是不是杀毒软件在后台扫描 node_modules。可以把前端目录加入杀毒软件白名单或者临时关闭实时防护再执行一次。5. 备份文件回滚、错误排查与上线前的三件事前缀带.bak的文件main.css.bak、IndexHeader.vue.bak等是开发者在修改核心样式和组件前手动复制的备份目的是出问题时能快速回退。这个习惯在单人开发时很有效但多人协作时就不行了容易覆盖别人的改动。接手项目后建议把.bak文件统一移动到_backup_2024这样的目录里不要留在源码目录中否则 PHP 或构建工具扫目录时可能把.bak文件也当资源处理导致报错。排错时要分清前后端错误。小程序端报错先打开微信开发者工具的 Network 面板看请求的状态码和响应体401是 token 问题500是 PHP 代码异常404要看是路由没定义还是 Nginx 配置没有 rewrite。PHP 端的错误日志默认写到 PHP 安装目录的logs/php_error.logWindows 下经常因为目录权限不足写不进去导致代码报错但页面空白。我一般会在public/index.php顶部加一段临时调试代码把错误输出到浏览器error_reporting(E_ALL); ini_set(display_errors, 1);这样能看到具体的错误行号定位完再删掉。上线前必须关掉display_errors改到error_log里否则 SQL 报错信息会直接暴露给用户连表名和字段名都泄露了。上线做支付功能时要特别留意回调的幂等性——微信支付回调可能因为网络重试触发多次PHP 接口里必须判断订单状态如果已经是已支付就不要再改否则会出现订单金额和状态不一致的情况。给微信回调的 URL 处理函数里加一个前置检查就是先查一次status再决定是否更新能省掉后续对账时的大量麻烦。最后是订单超时扫描和消息推送。这类跑腿项目在 Linux 服务器上可以用 crontab 定时跑 PHP 脚本来实现订单状态扫描但 Windows 服务器上建议写一个 PHP CLI 脚本配合任务计划程序。脚本注意设内存限制和超时防止长时间执行被系统杀掉。跑腿平台的体验核心是有人接单所以订单无人接时要推送通知给候选骑手先做好这一个推送场景整个项目的可用性会提升一个档次。本文还有配套的精品资源点击获取
