简介这是一套面向计算机专业本科生课程设计与毕业实践的校园跑腿小程序全栈开发资源基于Spring Boot Vue3 微信小程序技术栈实现前后端分离架构解决高校场景下学生间即时跑腿服务的线上化需求。资源包共1109个文件涵盖82个Java后端接口与实体类、112个Vue3前端组件、39个WXML页面与45个WXSS样式文件、220个JS逻辑脚本以及SQL建表脚本、项目配置文件与多套静态资源整体压缩后仅9.49MB轻量易部署。已有57人学习下载适合初学者快速掌握微信小程序对接Spring Boot后端的完整链路。资源提供可直接运行的完整前后端代码、配套MySQL初始化脚本、清晰的模块划分含任务管理、菜单排序、资讯发布、文件上传下载及客服投诉等核心功能并附带实操演示视频便于理解业务流程与接口调用逻辑。从零搭建校园跑腿小程序Spring Boot Vue3 微信小程序全栈实录先聊点实际的。校园跑腿这个需求几乎每所大学都有——代取快递、代买饭、代打印、代排队高峰期的时候单子多到接不过来。但市面上通用跑腿平台在校园场景里其实很别扭校内配送距离短、单价低、接单员基本都是同校学生需要一个轻量、灵活、能快速上线的方案。我一直在做前后端分离类的项目这次干脆用Spring Boot Vue3 微信小程序这套组合把校园跑腿小程序从零到一完整搭了出来包含完整前后端代码、SQL脚本、前后端分离架构和全套软件部署方案本文把我整个实现过程和踩过的坑都整理出来。这个项目主要面向三类读者一是计算机相关专业的学生需要一个能写进简历、能演示、能二次开发的全栈项目二是想接校园外包或创业试水的开发者需要一套能快速部署上线的代码基底三是已经在做跑腿类业务、想用技术手段替代手工派单的运营者。整个过程我会从业务拆解、数据库设计、后端接口、小程序端、管理后台、部署上线这几个维度讲清楚最后附上我在实操中遇到的典型问题和解决方案帮大家少走弯路。1. 校园跑腿业务拆解这个项目到底解决了什么问题1.1 校园跑腿的核心业务链路先别急着写代码。我见过太多人一上来就建表写接口结果做到一半发现业务逻辑对不上回头重构。做这类项目第一步一定是把业务链路画清楚。校园跑腿的核心链路其实就一句话用户下单骑手接单跑腿完成双方结算。但展开来看这里面的角色有三个不是两个——除了发单的用户和接单的骑手之外还有一个管理方。管理方负责审核骑手资质、处理纠纷、查看平台运营数据。这三者的诉求完全不同用户要的是下单方便、进度透明骑手要的是单量充足、结算及时管理方要的是流程可控、数据可查。这个项目把这三条线都做了用户端微信小程序发布跑腿需求、查看订单状态、确认收货、在线支付或线下支付。骑手端微信小程序内嵌接单大厅抢单、查看任务详情、标记送达、查看收益。管理后台Vue3 Web端用户管理、骑手审核、订单监管、数据统计。这三个角色其实可以做成三个独立App但对于校园场景把用户端和骑手端放在同一个微信小程序里通过登录角色区分是更务实的做法——学生下载一个App成本太高小程序扫码即用用完即走完全贴合校园场景。1.2 用户、骑手、管理员三类角色的权限设计角色权限是这类项目的命脉设计不好后面全是坑。我沿用了经典的RBAC模型但在实现上做了精简。用户表user里除了基本信息外加了role字段取值为USER普通用户、COURIER骑手、ADMIN管理员。用户可以在小程序里申请成为骑手申请后需要管理员在后台审核审核通过后role才变为COURIER同时会在骑手表courier里插入一条关联记录记录接单状态和累计收益。这里有一个关键设计为什么不直接把role改了就行还要单独建一张骑手表因为骑手有额外属性——接单状态空闲/忙碌、接单数、完成数、总收益、评分。这些字段放在用户表里会显得很冗余而且用户表和骑手表是一对一关系拆开更清晰。后端接口层面用Spring Boot拦截器统一校验JWT Token再从Token里解析出用户ID和角色通过自定义注解RequireRole做角色校验。比如发布订单的接口只需要登录即可但接单接口必须校验当前用户角色是COURIER审核骑手申请的接口必须是ADMIN。这个逻辑在拦截器里统一处理业务代码里只需要加一行注解非常干净。1.3 为什么选前后端分离而不是单体架构有人可能会问一个跑腿小程序单体架构不就行了吗前端模板渲染后端返回页面部署一个Tomcat搞定。确实可以但我会选前后端分离有三个实际考虑。第一开发和联调效率。小程序端、管理后台、后端服务可以三线并行开发。前端只用Mock数据调界面后端专心写接口最后联调时统一对接整个开发周期能压缩至少三分之一。第二部署灵活。前端静态文件可以直接扔到Nginx里后端独立部署数据库单独一台。小程序端不用部署微信开发者工具上传后等审核即可。任意一层挂了不影响其他层出问题也容易排查。第三团队协作模式。哪怕是个人开发前后端分离也能让你在不同时间段用不同心态工作——上午专心写Java接口下午切到Vue页面晚上调小程序样式切换工作内容本身就是一种休息而且每块都能做得很专注。2. 后端Spring Boot核心模块与数据库设计思路2.1 用户、订单、接单三张核心表的字段设计数据库设计是这类项目最不能糊弄的部分。我花了整整一个晚上梳理字段改了三次才定稿。下面我把核心表结构的关键字段列出来并标注为什么这样设计。用户表user字段类型说明idBIGINT主键自增openidVARCHAR(64)微信openid唯一索引nicknameVARCHAR(64)微信昵称avatarVARCHAR(255)头像URLphoneVARCHAR(20)手机号下单联系用roleVARCHAR(20)USER/COURIER/ADMIN默认USERstatusTINYINT0正常 1禁用create_timeDATETIME注册时间注意openid必须加唯一索引。微信开放平台的规范是同一用户在同一小程序下的openid唯一这个字段是整个登录体系的核心不加唯一索引的话万一并发注册会出现同一用户两条记录后面所有关联数据都会错乱。订单表order表名避开orders的保留字问题字段类型说明idBIGINT主键order_noVARCHAR(32)业务订单号展示给用户看user_idBIGINT下单用户IDcourier_idBIGINT接单骑手ID初始NULLtypeTINYINT订单类型1取快递 2代买 3代排队 4其他pickup_addressVARCHAR(255)取件地址delivery_addressVARCHAR(255)送达地址rewardDECIMAL(10,2)跑腿费悬赏金额goods_amountDECIMAL(10,2)物品费用代买时预填remarkVARCHAR(500)备注statusTINYINT0待接单 1已接单 2配送中 3已完成 4已取消create_timeDATETIME下单时间accept_timeDATETIME接单时间finish_timeDATETIME完成时间订单表是整个系统数据量增长最快的表也是后续统计报表的数据来源。order_no我选择在Java里生成而不是用数据库自增ID格式是yyyyMMddHHmmss 4位随机数。为什么不用自增ID直接当订单号因为订单号会展示给用户自增ID会暴露平台单量这是安全风险而且多表关联时用自增ID做业务标识容易被人遍历抓数据。骑手表courier字段类型说明idBIGINT主键user_idBIGINT关联用户IDstudent_noVARCHAR(32)学号real_nameVARCHAR(32)真实姓名id_cardVARCHAR(32)身份证号脱敏存储statusTINYINT0待审核 1审核通过 2禁用total_ordersINT累计接单数total_incomeDECIMAL(12,2)累计收益ratingDECIMAL(3,2)评分默认5.00这里要说一个合规细节身份证号属于敏感个人信息数据库里我建议只存后四位用于人工核对或者存全号但做加密处理接口返回时用StringUtil.mask()脱敏成110***********1234这种格式。虽然校园项目规模小但从一开始养成敏感信息处理习惯到商业项目里才不会踩雷。2.2 订单状态机的流转实现订单状态是这类业务系统里最容易写乱的地方。一个订单从发布到完成状态流转是有严格顺序的不能乱跳。我在项目中用状态机思路约束流转一共定义了8种合法流转路径0待接单 - 1已接单用户取消则 - 4已取消 1已接单 - 2配送中骑手标记开始配送 2配送中 - 3已完成骑手标记送达用户确认 0待接单 - 4已取消用户主动取消 0待接单 - 4已取消超时未接单定时任务自动取消实现方式是在OrderStatus枚举类里维护一个Map当前状态, List可流转状态每次更新状态前先做合法性校验不合法直接抛业务异常。这样做的好处是就算以后新增了申诉中退款中这些状态也只需要改枚举类业务代码不用动。这个状态机同时解决了并发问题。骑手抢单接口的核心逻辑是UPDATE order SET courier_id ?, status 1, accept_time NOW() WHERE id ? AND status 0注意这个 SQL 的关键在AND status 0这个条件。多个骑手同时抢同一个单数据库层面只有一条 update 能命中status 0的记录其他 update 影响行数为0自然就抢不到。这就是乐观锁思路不需要SELECT ... FOR UPDATE那种重量级锁性能好且不会死锁。2.3 微信登录与JWT鉴权的配合方式微信小程序的登录流程和传统账号密码登录不一样核心是wx.login()拿到的code然后后端拿code换取openid和session_key。这里有一个很多人会搞错的点session_key是微信会话密钥用于解密手机号等敏感信息绝对不能返回到前端。后端拿到openid后应该自己生成一套业务Token我用的是JWT后续所有请求都带这个JWT而不是每次都拿code去微信换openid。JWT里我放了三个核心字段userId用户ID、role角色、exp过期时间。过期时间设成7天因为校园用户不太会频繁登录太短了体验差太长了不安全。// JWT工具类核心方法 public String generateToken(Long userId, String role) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim(role, role) .setExpiration(new Date(System.currentTimeMillis() 7 * 24 * 3600 * 1000)) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); }拦截器里解析Token的步骤我单独拎出来说一下。解析失败、Token过期、用户不存在这三种异常要区分处理前端要根据不同的错误码做不同响应——比如Token过期应该跳回登录页但用户不存在可能被管理员删了应该提示联系客服而不是让用户重新登录死循环。3. 微信小程序端用户下单与接单员抢单的关键实现3.1 小程序登录态的建立与维持小程序端的app.js里我在onLaunch生命周期中调用登录逻辑。基本流程是// app.js 核心登录逻辑 onLaunch: function () { const token wx.getStorageSync(token) if (token) { // 有token先校验是否过期 this.checkToken(token) } else { // 无token走完整登录流程 this.login() } }, login: function () { wx.login({ success: (res) { wx.request({ url: ${BASE_URL}/api/auth/login, method: POST, data: { code: res.code }, success: (loginRes) { wx.setStorageSync(token, loginRes.data.token) wx.setStorageSync(userInfo, loginRes.data.userInfo) } }) } }) }这里提一个提高体验的小技巧wx.login()的code有效期只有5分钟而且只能用一次。如果用户长期不打开小程序Token自然过期下次打开时checkToken发现失效需要重新走登录流程。这个过程中可以加一个Promise队列避免多个请求同时发起时重复触发登录导致code被消费两次。这个坑我实测踩过登录接口报invalid code错误排查了半天才发现是并发请求同时触发了两次wx.login()。3.2 下单页面的交互与地址选择设计下单页面是我花时间最多的地方因为跑腿订单的信息收集维度多页面做不好用户很容易放弃下单。页面核心字段包括订单类型、取件地址、送达地址、跑腿费、物品费用、备注。微信小程序里没有原生地图选点组件除非接入腾讯地图插件我选择了更务实的方案——手动输入地址 历史地址记忆。历史地址存在本地存储wx.setStorageSync(addressHistory, list)每次用户下单时把新地址插入数组头部最多保留10条。下次下单时地址输入框下面直接展示历史地址一键点击填充非常实用。实测能明显降低用户重复输入的抵触感。跑腿费这里我加了一个低额校验低于1元不能发布。这不是为了赚那点钱而是为了过滤掉大量无意义的1分钱测试单。上线后你会发现去掉低价单之后订单质量高了一大截。还有一种情况要处理用户在选择代买类型时需要填写物品费用预估区间。我加了个goods_amount字段并在下单弹窗里提示代买费用请先与骑手沟通最终以实际小票为准从规则上减少后续纠纷。3.3 接单大厅的轮询与消息触达方案骑手端的核心页面是接单大厅。初始方案我用了定时器每5秒轮询一次待接单列表但实际体验很一般——列表刷新不够即时而且频繁请求会给后端造成压力。后来改成两个策略结合首次进入页面拉取全量列表之后的使用过程由下拉刷新 新单提示组合。新单提示用的是微信订阅消息。订阅消息有个坑必须提一下微信小程序的一次性订阅消息用户每授权一次只能推送一条。这意味着不能像App推送那样随时发而是要在用户主动触发时弹出授权框。我的做法是用户发布订单时弹窗请求授权接单通知这样当有骑手接了该用户的订单时就能给用户推送一条订阅消息。同理骑手在接单大厅点击开启新单提醒时也做一次订阅授权后端在有新订单发布时向订阅过的骑手推送。但这个方案不能100%触达用户可能在授权时点了拒绝或者订阅次数已用完所以接单大厅的页面里必须有轮询机制作为补充。最终线上我用的是页面可见时每10秒轮询一次订单列表同时配合订阅消息做即时提醒体验尚可后端压力也不大。// 接单大厅轮询逻辑 onShow: function () { this.startPolling() }, onHide: function () { this.stopPolling() }, startPolling: function () { this.pollingTimer setInterval(() { this.loadOrders() }, 10000) }, stopPolling: function () { clearInterval(this.pollingTimer) this.pollingTimer null }注意在onHide里一定要清掉定时器否则页面切到后台后JS还在跑既浪费资源又会因为频繁setData造成小程序性能下降。4. Vue3管理后台审核、结算与数据看板落地4.1 管理后台的工程化搭建管理后台我选的是 Vue3 Vite Element Plus 的组合。Vite的冷启动速度比Webpack快得多开发体验好而且Vue3的组合式API配合Element Plus写后台管理类的中后台项目非常顺手。工程搭建我直接用了npm create vitelatest admin-web -- --template vue然后手动安装依赖npm install vue-router4 pinia element-plus axios这里要提一下element-plus的按需引入。全量引入Element Plus会让打包体积暴增到1MB以上首屏加载很慢。我用的是unplugin-auto-import和unplugin-vue-components这两个Vite插件自动按需引入组件配置完后代码里直接用el-button就行组件和样式都会自动引入编译产物小很多。4.2 登录与权限控制的落地逻辑管理后台的登录不是微信登录而是传统的用户名密码登录。管理员账号由系统初始化时通过SQL脚本插入密码用BCrypt加密存储。这里我要反复强调密码绝不能明文存也绝不能用MD5存MD5在彩虹表面前毫无安全可言。Spring Security自带的BCryptPasswordEncoder是业界标准方案同密码每次加密结果都不同安全性好得多。登录成功后返回JWT前端存在localStorage里路由配置中通过beforeEach全局守卫做登录校验// 路由守卫 router.beforeEach((to, from, next) { const token localStorage.getItem(admin_token) if (to.path ! /login !token) { next(/login) } else { next() } })但这个只能做页面级控制。管理后台的接口都必须有后端角色校验不能光靠前端隐藏按钮这是最基础的安全意识。前端隐藏入口只是用户体验优化真正的安全边界在后端。4.3 骑手审核与订单监管的具体实现管理后台最核心的功能有三个骑手审核、订单监管、数据统计。骑手审核的核心是审核列表 审核操作。列表从courier表关联user表查出待审核记录展示真实姓名、学号、身份证后四位、申请时间。审核操作有两个按钮通过、拒绝。通过时把courier.status改为1同时把user.role改为COURIER这里我加了事务控制两个操作要么都成功要么都失败。订单监管是一个带筛选条件的订单列表支持按状态、按时间范围、按关键字筛选。列表默认按创建时间倒序分页查询。这里有一个性能细节订单表数据量大之后时间范围检索一定要走索引。我在建表时给create_time加了一个普通索引实测在10万条数据量下按时间筛选从1.2秒降到了70毫秒效果立竿见影。数据统计模块是管理方最喜欢的页面。我做了四个核心指标今日订单数、今日成交金额、本月订单趋势、骑手排行。这些数据用聚合SQL查询实现比如今日订单数SELECT COUNT(*) FROM order WHERE create_time CURDATE() AND create_time DATE_ADD(CURDATE(), INTERVAL 1 DAY) AND status IN (1, 2, 3)本月的订单趋势用GROUP BY DATE(create_time)按天分组返回一个日期数量的数组前端用ECharts柱状图展示。这里要注意时区问题MySQL的CURDATE()用的是服务器时区如果服务器时区不是北京时区统计会差8小时部署时一定要检查并设置serverTimezoneAsia/Shanghai。4.4 数据看板的前端图表实现数据看板我用的是 ECharts 的 Vue3 封装版本echartsvue-echarts。按需引入核心图表和组件避免全量引入导致包体过大。// 订单趋势图 import { use } from echarts/core import { CanvasRenderer } from echarts/renderers import { LineChart } from echarts/charts import { GridComponent, TooltipComponent } from echarts/components use([CanvasRenderer, LineChart, GridComponent, TooltipComponent])这里补充一个真实感受管理后台的UI不用太花哨Element Plus默认主题就很够用了。我见过不少项目把大量时间花在自定义主题色、加动画效果上其实对管理方来说信息密度高、操作路径短才是核心。把时间花在做统计报表的数据准确性和查询性能上回报高得多。5. 从零跑通SQL脚本导入、环境配置与部署全流程5.1 SQL脚本要点与数据库初始化项目附带了一个完整的campus_order.sql脚本涵盖建库、建表、初始数据三部分。拿到脚本后数据库初始化步骤如下mysql -u root -p campus_order.sql脚本里包含了几条关键的初始数据一个管理员账号admin / admin123BCrypt加密存储首次登录后记得改密码测试用户若干openid先用测试占位微信登录后会自动更新订单类型字典数据1取快递、2代买、3代排队、4其他这里提醒一个MySQL版本兼容问题。脚本里如果用了utf8mb4_0900_ai_ci这个排序规则在MySQL 5.7及以下版本会直接报错因为0900_ai_ci是MySQL 8.0才引入的。我的脚本里统一用utf8mb4_general_ci兼容所有5.7版本。你要是自己写脚本建议同样用utf8mb4_general_ci别贪新。5.2 后端环境配置与Spring Boot启动后端的application.yml需要改三个地方数据库连接、微信小程序配置、JWT密钥。server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/campus_order?useUnicodetruecharacterEncodingutf8mb4useSSLfalseserverTimezoneAsia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver wx: appid: your_wx_appid secret: your_wx_secret jwt: secret: your_custom_secret_key_here expire: 604800微信小程序的appid和secret在微信公众平台的小程序后台里获取。注意这里有个坑appid是用在wx.request里的前端不对前端发请求不需要传appidappid和secret只存在于后端配置里前端调用wx.login()拿到的code传给后端后端再拿code appid secret去微信接口换openid。如果secret泄露到前端源码里任何懂技术的人都能拿你的secret冒充你的小程序调用微信接口这是严重安全事故。启动命令mvn clean package -DskipTests java -jar target/campus-order-1.0.0.jar本地开发时用 IDEA 直接跑 main 方法就行注意要在application.yml里把数据库连接改成自己的本地配置否则连接不上数据库启动直接报错。5.3 Vue3管理后台的构建与Nginx部署管理后台开发完成后构建生产包npm run build构建产物在dist/目录。部署到Nginx的配置示例server { listen 80; server_name admin.example.com; root /var/www/admin-dist; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }try_files $uri $uri/ /index.html;这一行是Vue3 Router的 history 模式必需的否则用户在管理后台内刷新页面会404。原理是Vue Router的 history 模式用了HTML5的 History APIURL路径是伪路径必须让Nginx把所有请求都先落到 index.html再由前端路由接管。后端接口的代理我用了/api/前缀这样前端的 baseURL 统一填/api后端Controller的RequestMapping统一带/api前缀双方约定好就行。开发环境下跨域问题通过 Vite 的 proxy 配置解决不需要后端配CORS。5.4 微信小程序端的部署与审核上线小程序端的部署和其他前端不一样不需要服务器而是通过微信开发者工具上传代码然后在微信公众平台提交审核。具体流程微信开发者工具导入小程序端代码把后端接口地址改成正式服务器域名必须是HTTPS在微信公众平台的开发管理-开发设置-服务器域名里配置 request 合法域名点击上传填版本号和备注在公众平台版本管理里提交审核这里有一个最容易卡住的问题后端接口必须使用HTTPS而且域名需要ICP备案。如果你用的是云服务器需要先备案域名再配置SSL证书后端需要支持HTTPS协议。本地开发调试时可以在开发者工具里勾选不校验合法域名但上线前必须处理。还有个经验之谈小程序审核一般需要半天到一天审核期间用户还是能访问旧版本新版本审核通过后是灰度发布的不会强制更新。所以上线窗口要预留缓冲时间不要在业务高峰期临时发版。6. 部署和联调中踩过的坑与二次开发扩展方案6.1 部署过程中的典型问题清单整个项目从开发到部署我至少踩了十个以上的坑这里挑几个影响最大的分享。坑一跨域配置不生效开发环境中Vue3管理后台通过 Vite proxy 把/api代理到后端能正常工作。但小程序端没有浏览器跨域的概念微信内部请求天然不受CORS限制所以小程序的请求不需要后端开启跨域。而管理后台如果直接通过IP访问后端会遇到跨域问题。我的解决方案是后端在WebMvcConfigurer里统一配置跨域映射允许所有来源开发用。上线后前端走Nginx同源代理后端根本不需要对外暴露8080端口跨域问题彻底消失。这个方案比在后端配置CORS一劳永逸推荐大家采用。坑二图片上传后访问404用户头像和订单图片上传到服务器本地磁盘但页面访问时404。原因是Spring Boot默认只处理应用上下文路径内的请求映射外部磁盘目录需要配置addResourceHandlers。我踩了这个坑才意识到生产环境一般有两种选择一是挂载OSS/COS这类对象存储二是通过Nginx直接代理磁盘目录。校园项目没必要上OSS直接用Nginx映射目录是最省钱省事的location /upload/ { alias /var/www/uploads/; }坑三JWT密钥硬编码在后端代码里我一开始把JWT密钥直接写死在代码里后来想想不对——如果代码仓库泄露任何人拿到源码都能伪造Token等于整个用户体系被脱掉。正确做法是从环境变量或配置中心读取部署时通过启动参数注入。这里再强调一次这个安全习惯要养成。坑四微信支付接口的接入问题校园跑腿的支付场景其实有点敏感因为微信支付对个人开发者不开放必须要有企业资质。我在项目中做成了线下支付 在线记录的模式——用户下单时选择支付方式在线/线下如果选择在线支付目前只能模拟支付回调如果做真实支付需要提供营业执照等资料申请微信支付商户号。如果只是用来演示和学习模拟支付完全够用如果要真实商用建议先确认资质再接入。6.2 项目目录结构与二次开发路线图最后说说这个项目拿到手之后从哪个目录开始看以及接下来可以往哪个方向做。如果你拿到的是我项目的完整代码建议按这个顺序去读先看sql/campus_order.sql把库表关系理清楚再看后端controller包把接口路由和业务模块对应起来然后看service层理解业务逻辑的核心实现最后看小程序端pages目录把页面和后端接口对应上二次开发方向我建议优先考虑以下几个订单超时自动取消加入定时任务Spring Task或XXL-Job超过30分钟未被接单的订单自动取消跑腿费分成在结算模块加入平台抽成比例骑手收益 跑腿费 x (1 - 平台比例)订单评价体系订单完成后用户和骑手互相评价评价数据回写到骑手表里的评分字段接单大厅的WebSocket改造把轮询换成WebSocket推送实时性更强但要注意鉴权和连接管理多校园隔离如果你要推广到多所高校需要在订单表加campus_id字段所有查询都带上这个过滤条件避免跨校数据显示这里我多说一句WebSocket的问题。很多人一听WebSocket就觉得很高级但如果你的业务量不大轮询带来的服务器压力其实非常小。10秒一次的轮询每个连接每小时才36个请求1000个在线用户一小时也就3.6万次请求对于一台普通云服务器来说毫无压力。实时性要求不高的场景根本没必要上WebSocket复杂度和维护成本完全是负收益。6.3 实际部署运行的效果与心得体会项目部署上线后我在本地跑了三天的模拟运营创建了5个测试用户其中2个申请了骑手并完成审核发布了15笔订单取快递8单、代买4单、代排队3单骑手全部正常接单、标记送达管理后台的骑手审核、订单监管、数据统计全部正常整个流程走下来整体体验比我预期的顺畅。尤其是订单状态机的设计让我在后期的接口调试中省了很多事——不管怎么操作状态都不会跳到非法状态。这一点我强烈建议做类似业务系统的同学都采用状态机模式。如果非要说还有什么遗憾那就是微信订阅消息的触达率问题。用户授权一次只能发一条而跑腿订单从发布到完成可能经历接单、送达两个节点需要发送两条消息但用户只授权了一次。我的处理方案是把接单通知作为必发项送达通知降级为骑手在小程序内通过电话或模板消息提醒未来要考虑多次订阅授权的引导方案。跑腿类小程序的核心竞争力从来不只是技术还有运营——你的骑手团队够不够勤快、响应够不够快、服务态度好不好。技术只是把业务线上化的工具把流程规范好、把数据沉淀下来后续做活动新用户首单立减、骑手接单奖励才有抓手。这套代码我已经压进了Git仓库需要的同学可以直接拿去二次开发。本文还有配套的精品资源点击获取 Spring Boot + Vue3 + 微信小程序：校园跑腿全栈项目实战
简介这是一套面向计算机专业本科生课程设计与毕业实践的校园跑腿小程序全栈开发资源基于Spring Boot Vue3 微信小程序技术栈实现前后端分离架构解决高校场景下学生间即时跑腿服务的线上化需求。资源包共1109个文件涵盖82个Java后端接口与实体类、112个Vue3前端组件、39个WXML页面与45个WXSS样式文件、220个JS逻辑脚本以及SQL建表脚本、项目配置文件与多套静态资源整体压缩后仅9.49MB轻量易部署。已有57人学习下载适合初学者快速掌握微信小程序对接Spring Boot后端的完整链路。资源提供可直接运行的完整前后端代码、配套MySQL初始化脚本、清晰的模块划分含任务管理、菜单排序、资讯发布、文件上传下载及客服投诉等核心功能并附带实操演示视频便于理解业务流程与接口调用逻辑。从零搭建校园跑腿小程序Spring Boot Vue3 微信小程序全栈实录先聊点实际的。校园跑腿这个需求几乎每所大学都有——代取快递、代买饭、代打印、代排队高峰期的时候单子多到接不过来。但市面上通用跑腿平台在校园场景里其实很别扭校内配送距离短、单价低、接单员基本都是同校学生需要一个轻量、灵活、能快速上线的方案。我一直在做前后端分离类的项目这次干脆用Spring Boot Vue3 微信小程序这套组合把校园跑腿小程序从零到一完整搭了出来包含完整前后端代码、SQL脚本、前后端分离架构和全套软件部署方案本文把我整个实现过程和踩过的坑都整理出来。这个项目主要面向三类读者一是计算机相关专业的学生需要一个能写进简历、能演示、能二次开发的全栈项目二是想接校园外包或创业试水的开发者需要一套能快速部署上线的代码基底三是已经在做跑腿类业务、想用技术手段替代手工派单的运营者。整个过程我会从业务拆解、数据库设计、后端接口、小程序端、管理后台、部署上线这几个维度讲清楚最后附上我在实操中遇到的典型问题和解决方案帮大家少走弯路。1. 校园跑腿业务拆解这个项目到底解决了什么问题1.1 校园跑腿的核心业务链路先别急着写代码。我见过太多人一上来就建表写接口结果做到一半发现业务逻辑对不上回头重构。做这类项目第一步一定是把业务链路画清楚。校园跑腿的核心链路其实就一句话用户下单骑手接单跑腿完成双方结算。但展开来看这里面的角色有三个不是两个——除了发单的用户和接单的骑手之外还有一个管理方。管理方负责审核骑手资质、处理纠纷、查看平台运营数据。这三者的诉求完全不同用户要的是下单方便、进度透明骑手要的是单量充足、结算及时管理方要的是流程可控、数据可查。这个项目把这三条线都做了用户端微信小程序发布跑腿需求、查看订单状态、确认收货、在线支付或线下支付。骑手端微信小程序内嵌接单大厅抢单、查看任务详情、标记送达、查看收益。管理后台Vue3 Web端用户管理、骑手审核、订单监管、数据统计。这三个角色其实可以做成三个独立App但对于校园场景把用户端和骑手端放在同一个微信小程序里通过登录角色区分是更务实的做法——学生下载一个App成本太高小程序扫码即用用完即走完全贴合校园场景。1.2 用户、骑手、管理员三类角色的权限设计角色权限是这类项目的命脉设计不好后面全是坑。我沿用了经典的RBAC模型但在实现上做了精简。用户表user里除了基本信息外加了role字段取值为USER普通用户、COURIER骑手、ADMIN管理员。用户可以在小程序里申请成为骑手申请后需要管理员在后台审核审核通过后role才变为COURIER同时会在骑手表courier里插入一条关联记录记录接单状态和累计收益。这里有一个关键设计为什么不直接把role改了就行还要单独建一张骑手表因为骑手有额外属性——接单状态空闲/忙碌、接单数、完成数、总收益、评分。这些字段放在用户表里会显得很冗余而且用户表和骑手表是一对一关系拆开更清晰。后端接口层面用Spring Boot拦截器统一校验JWT Token再从Token里解析出用户ID和角色通过自定义注解RequireRole做角色校验。比如发布订单的接口只需要登录即可但接单接口必须校验当前用户角色是COURIER审核骑手申请的接口必须是ADMIN。这个逻辑在拦截器里统一处理业务代码里只需要加一行注解非常干净。1.3 为什么选前后端分离而不是单体架构有人可能会问一个跑腿小程序单体架构不就行了吗前端模板渲染后端返回页面部署一个Tomcat搞定。确实可以但我会选前后端分离有三个实际考虑。第一开发和联调效率。小程序端、管理后台、后端服务可以三线并行开发。前端只用Mock数据调界面后端专心写接口最后联调时统一对接整个开发周期能压缩至少三分之一。第二部署灵活。前端静态文件可以直接扔到Nginx里后端独立部署数据库单独一台。小程序端不用部署微信开发者工具上传后等审核即可。任意一层挂了不影响其他层出问题也容易排查。第三团队协作模式。哪怕是个人开发前后端分离也能让你在不同时间段用不同心态工作——上午专心写Java接口下午切到Vue页面晚上调小程序样式切换工作内容本身就是一种休息而且每块都能做得很专注。2. 后端Spring Boot核心模块与数据库设计思路2.1 用户、订单、接单三张核心表的字段设计数据库设计是这类项目最不能糊弄的部分。我花了整整一个晚上梳理字段改了三次才定稿。下面我把核心表结构的关键字段列出来并标注为什么这样设计。用户表user字段类型说明idBIGINT主键自增openidVARCHAR(64)微信openid唯一索引nicknameVARCHAR(64)微信昵称avatarVARCHAR(255)头像URLphoneVARCHAR(20)手机号下单联系用roleVARCHAR(20)USER/COURIER/ADMIN默认USERstatusTINYINT0正常 1禁用create_timeDATETIME注册时间注意openid必须加唯一索引。微信开放平台的规范是同一用户在同一小程序下的openid唯一这个字段是整个登录体系的核心不加唯一索引的话万一并发注册会出现同一用户两条记录后面所有关联数据都会错乱。订单表order表名避开orders的保留字问题字段类型说明idBIGINT主键order_noVARCHAR(32)业务订单号展示给用户看user_idBIGINT下单用户IDcourier_idBIGINT接单骑手ID初始NULLtypeTINYINT订单类型1取快递 2代买 3代排队 4其他pickup_addressVARCHAR(255)取件地址delivery_addressVARCHAR(255)送达地址rewardDECIMAL(10,2)跑腿费悬赏金额goods_amountDECIMAL(10,2)物品费用代买时预填remarkVARCHAR(500)备注statusTINYINT0待接单 1已接单 2配送中 3已完成 4已取消create_timeDATETIME下单时间accept_timeDATETIME接单时间finish_timeDATETIME完成时间订单表是整个系统数据量增长最快的表也是后续统计报表的数据来源。order_no我选择在Java里生成而不是用数据库自增ID格式是yyyyMMddHHmmss 4位随机数。为什么不用自增ID直接当订单号因为订单号会展示给用户自增ID会暴露平台单量这是安全风险而且多表关联时用自增ID做业务标识容易被人遍历抓数据。骑手表courier字段类型说明idBIGINT主键user_idBIGINT关联用户IDstudent_noVARCHAR(32)学号real_nameVARCHAR(32)真实姓名id_cardVARCHAR(32)身份证号脱敏存储statusTINYINT0待审核 1审核通过 2禁用total_ordersINT累计接单数total_incomeDECIMAL(12,2)累计收益ratingDECIMAL(3,2)评分默认5.00这里要说一个合规细节身份证号属于敏感个人信息数据库里我建议只存后四位用于人工核对或者存全号但做加密处理接口返回时用StringUtil.mask()脱敏成110***********1234这种格式。虽然校园项目规模小但从一开始养成敏感信息处理习惯到商业项目里才不会踩雷。2.2 订单状态机的流转实现订单状态是这类业务系统里最容易写乱的地方。一个订单从发布到完成状态流转是有严格顺序的不能乱跳。我在项目中用状态机思路约束流转一共定义了8种合法流转路径0待接单 - 1已接单用户取消则 - 4已取消 1已接单 - 2配送中骑手标记开始配送 2配送中 - 3已完成骑手标记送达用户确认 0待接单 - 4已取消用户主动取消 0待接单 - 4已取消超时未接单定时任务自动取消实现方式是在OrderStatus枚举类里维护一个Map当前状态, List可流转状态每次更新状态前先做合法性校验不合法直接抛业务异常。这样做的好处是就算以后新增了申诉中退款中这些状态也只需要改枚举类业务代码不用动。这个状态机同时解决了并发问题。骑手抢单接口的核心逻辑是UPDATE order SET courier_id ?, status 1, accept_time NOW() WHERE id ? AND status 0注意这个 SQL 的关键在AND status 0这个条件。多个骑手同时抢同一个单数据库层面只有一条 update 能命中status 0的记录其他 update 影响行数为0自然就抢不到。这就是乐观锁思路不需要SELECT ... FOR UPDATE那种重量级锁性能好且不会死锁。2.3 微信登录与JWT鉴权的配合方式微信小程序的登录流程和传统账号密码登录不一样核心是wx.login()拿到的code然后后端拿code换取openid和session_key。这里有一个很多人会搞错的点session_key是微信会话密钥用于解密手机号等敏感信息绝对不能返回到前端。后端拿到openid后应该自己生成一套业务Token我用的是JWT后续所有请求都带这个JWT而不是每次都拿code去微信换openid。JWT里我放了三个核心字段userId用户ID、role角色、exp过期时间。过期时间设成7天因为校园用户不太会频繁登录太短了体验差太长了不安全。// JWT工具类核心方法 public String generateToken(Long userId, String role) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim(role, role) .setExpiration(new Date(System.currentTimeMillis() 7 * 24 * 3600 * 1000)) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); }拦截器里解析Token的步骤我单独拎出来说一下。解析失败、Token过期、用户不存在这三种异常要区分处理前端要根据不同的错误码做不同响应——比如Token过期应该跳回登录页但用户不存在可能被管理员删了应该提示联系客服而不是让用户重新登录死循环。3. 微信小程序端用户下单与接单员抢单的关键实现3.1 小程序登录态的建立与维持小程序端的app.js里我在onLaunch生命周期中调用登录逻辑。基本流程是// app.js 核心登录逻辑 onLaunch: function () { const token wx.getStorageSync(token) if (token) { // 有token先校验是否过期 this.checkToken(token) } else { // 无token走完整登录流程 this.login() } }, login: function () { wx.login({ success: (res) { wx.request({ url: ${BASE_URL}/api/auth/login, method: POST, data: { code: res.code }, success: (loginRes) { wx.setStorageSync(token, loginRes.data.token) wx.setStorageSync(userInfo, loginRes.data.userInfo) } }) } }) }这里提一个提高体验的小技巧wx.login()的code有效期只有5分钟而且只能用一次。如果用户长期不打开小程序Token自然过期下次打开时checkToken发现失效需要重新走登录流程。这个过程中可以加一个Promise队列避免多个请求同时发起时重复触发登录导致code被消费两次。这个坑我实测踩过登录接口报invalid code错误排查了半天才发现是并发请求同时触发了两次wx.login()。3.2 下单页面的交互与地址选择设计下单页面是我花时间最多的地方因为跑腿订单的信息收集维度多页面做不好用户很容易放弃下单。页面核心字段包括订单类型、取件地址、送达地址、跑腿费、物品费用、备注。微信小程序里没有原生地图选点组件除非接入腾讯地图插件我选择了更务实的方案——手动输入地址 历史地址记忆。历史地址存在本地存储wx.setStorageSync(addressHistory, list)每次用户下单时把新地址插入数组头部最多保留10条。下次下单时地址输入框下面直接展示历史地址一键点击填充非常实用。实测能明显降低用户重复输入的抵触感。跑腿费这里我加了一个低额校验低于1元不能发布。这不是为了赚那点钱而是为了过滤掉大量无意义的1分钱测试单。上线后你会发现去掉低价单之后订单质量高了一大截。还有一种情况要处理用户在选择代买类型时需要填写物品费用预估区间。我加了个goods_amount字段并在下单弹窗里提示代买费用请先与骑手沟通最终以实际小票为准从规则上减少后续纠纷。3.3 接单大厅的轮询与消息触达方案骑手端的核心页面是接单大厅。初始方案我用了定时器每5秒轮询一次待接单列表但实际体验很一般——列表刷新不够即时而且频繁请求会给后端造成压力。后来改成两个策略结合首次进入页面拉取全量列表之后的使用过程由下拉刷新 新单提示组合。新单提示用的是微信订阅消息。订阅消息有个坑必须提一下微信小程序的一次性订阅消息用户每授权一次只能推送一条。这意味着不能像App推送那样随时发而是要在用户主动触发时弹出授权框。我的做法是用户发布订单时弹窗请求授权接单通知这样当有骑手接了该用户的订单时就能给用户推送一条订阅消息。同理骑手在接单大厅点击开启新单提醒时也做一次订阅授权后端在有新订单发布时向订阅过的骑手推送。但这个方案不能100%触达用户可能在授权时点了拒绝或者订阅次数已用完所以接单大厅的页面里必须有轮询机制作为补充。最终线上我用的是页面可见时每10秒轮询一次订单列表同时配合订阅消息做即时提醒体验尚可后端压力也不大。// 接单大厅轮询逻辑 onShow: function () { this.startPolling() }, onHide: function () { this.stopPolling() }, startPolling: function () { this.pollingTimer setInterval(() { this.loadOrders() }, 10000) }, stopPolling: function () { clearInterval(this.pollingTimer) this.pollingTimer null }注意在onHide里一定要清掉定时器否则页面切到后台后JS还在跑既浪费资源又会因为频繁setData造成小程序性能下降。4. Vue3管理后台审核、结算与数据看板落地4.1 管理后台的工程化搭建管理后台我选的是 Vue3 Vite Element Plus 的组合。Vite的冷启动速度比Webpack快得多开发体验好而且Vue3的组合式API配合Element Plus写后台管理类的中后台项目非常顺手。工程搭建我直接用了npm create vitelatest admin-web -- --template vue然后手动安装依赖npm install vue-router4 pinia element-plus axios这里要提一下element-plus的按需引入。全量引入Element Plus会让打包体积暴增到1MB以上首屏加载很慢。我用的是unplugin-auto-import和unplugin-vue-components这两个Vite插件自动按需引入组件配置完后代码里直接用el-button就行组件和样式都会自动引入编译产物小很多。4.2 登录与权限控制的落地逻辑管理后台的登录不是微信登录而是传统的用户名密码登录。管理员账号由系统初始化时通过SQL脚本插入密码用BCrypt加密存储。这里我要反复强调密码绝不能明文存也绝不能用MD5存MD5在彩虹表面前毫无安全可言。Spring Security自带的BCryptPasswordEncoder是业界标准方案同密码每次加密结果都不同安全性好得多。登录成功后返回JWT前端存在localStorage里路由配置中通过beforeEach全局守卫做登录校验// 路由守卫 router.beforeEach((to, from, next) { const token localStorage.getItem(admin_token) if (to.path ! /login !token) { next(/login) } else { next() } })但这个只能做页面级控制。管理后台的接口都必须有后端角色校验不能光靠前端隐藏按钮这是最基础的安全意识。前端隐藏入口只是用户体验优化真正的安全边界在后端。4.3 骑手审核与订单监管的具体实现管理后台最核心的功能有三个骑手审核、订单监管、数据统计。骑手审核的核心是审核列表 审核操作。列表从courier表关联user表查出待审核记录展示真实姓名、学号、身份证后四位、申请时间。审核操作有两个按钮通过、拒绝。通过时把courier.status改为1同时把user.role改为COURIER这里我加了事务控制两个操作要么都成功要么都失败。订单监管是一个带筛选条件的订单列表支持按状态、按时间范围、按关键字筛选。列表默认按创建时间倒序分页查询。这里有一个性能细节订单表数据量大之后时间范围检索一定要走索引。我在建表时给create_time加了一个普通索引实测在10万条数据量下按时间筛选从1.2秒降到了70毫秒效果立竿见影。数据统计模块是管理方最喜欢的页面。我做了四个核心指标今日订单数、今日成交金额、本月订单趋势、骑手排行。这些数据用聚合SQL查询实现比如今日订单数SELECT COUNT(*) FROM order WHERE create_time CURDATE() AND create_time DATE_ADD(CURDATE(), INTERVAL 1 DAY) AND status IN (1, 2, 3)本月的订单趋势用GROUP BY DATE(create_time)按天分组返回一个日期数量的数组前端用ECharts柱状图展示。这里要注意时区问题MySQL的CURDATE()用的是服务器时区如果服务器时区不是北京时区统计会差8小时部署时一定要检查并设置serverTimezoneAsia/Shanghai。4.4 数据看板的前端图表实现数据看板我用的是 ECharts 的 Vue3 封装版本echartsvue-echarts。按需引入核心图表和组件避免全量引入导致包体过大。// 订单趋势图 import { use } from echarts/core import { CanvasRenderer } from echarts/renderers import { LineChart } from echarts/charts import { GridComponent, TooltipComponent } from echarts/components use([CanvasRenderer, LineChart, GridComponent, TooltipComponent])这里补充一个真实感受管理后台的UI不用太花哨Element Plus默认主题就很够用了。我见过不少项目把大量时间花在自定义主题色、加动画效果上其实对管理方来说信息密度高、操作路径短才是核心。把时间花在做统计报表的数据准确性和查询性能上回报高得多。5. 从零跑通SQL脚本导入、环境配置与部署全流程5.1 SQL脚本要点与数据库初始化项目附带了一个完整的campus_order.sql脚本涵盖建库、建表、初始数据三部分。拿到脚本后数据库初始化步骤如下mysql -u root -p campus_order.sql脚本里包含了几条关键的初始数据一个管理员账号admin / admin123BCrypt加密存储首次登录后记得改密码测试用户若干openid先用测试占位微信登录后会自动更新订单类型字典数据1取快递、2代买、3代排队、4其他这里提醒一个MySQL版本兼容问题。脚本里如果用了utf8mb4_0900_ai_ci这个排序规则在MySQL 5.7及以下版本会直接报错因为0900_ai_ci是MySQL 8.0才引入的。我的脚本里统一用utf8mb4_general_ci兼容所有5.7版本。你要是自己写脚本建议同样用utf8mb4_general_ci别贪新。5.2 后端环境配置与Spring Boot启动后端的application.yml需要改三个地方数据库连接、微信小程序配置、JWT密钥。server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/campus_order?useUnicodetruecharacterEncodingutf8mb4useSSLfalseserverTimezoneAsia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver wx: appid: your_wx_appid secret: your_wx_secret jwt: secret: your_custom_secret_key_here expire: 604800微信小程序的appid和secret在微信公众平台的小程序后台里获取。注意这里有个坑appid是用在wx.request里的前端不对前端发请求不需要传appidappid和secret只存在于后端配置里前端调用wx.login()拿到的code传给后端后端再拿code appid secret去微信接口换openid。如果secret泄露到前端源码里任何懂技术的人都能拿你的secret冒充你的小程序调用微信接口这是严重安全事故。启动命令mvn clean package -DskipTests java -jar target/campus-order-1.0.0.jar本地开发时用 IDEA 直接跑 main 方法就行注意要在application.yml里把数据库连接改成自己的本地配置否则连接不上数据库启动直接报错。5.3 Vue3管理后台的构建与Nginx部署管理后台开发完成后构建生产包npm run build构建产物在dist/目录。部署到Nginx的配置示例server { listen 80; server_name admin.example.com; root /var/www/admin-dist; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }try_files $uri $uri/ /index.html;这一行是Vue3 Router的 history 模式必需的否则用户在管理后台内刷新页面会404。原理是Vue Router的 history 模式用了HTML5的 History APIURL路径是伪路径必须让Nginx把所有请求都先落到 index.html再由前端路由接管。后端接口的代理我用了/api/前缀这样前端的 baseURL 统一填/api后端Controller的RequestMapping统一带/api前缀双方约定好就行。开发环境下跨域问题通过 Vite 的 proxy 配置解决不需要后端配CORS。5.4 微信小程序端的部署与审核上线小程序端的部署和其他前端不一样不需要服务器而是通过微信开发者工具上传代码然后在微信公众平台提交审核。具体流程微信开发者工具导入小程序端代码把后端接口地址改成正式服务器域名必须是HTTPS在微信公众平台的开发管理-开发设置-服务器域名里配置 request 合法域名点击上传填版本号和备注在公众平台版本管理里提交审核这里有一个最容易卡住的问题后端接口必须使用HTTPS而且域名需要ICP备案。如果你用的是云服务器需要先备案域名再配置SSL证书后端需要支持HTTPS协议。本地开发调试时可以在开发者工具里勾选不校验合法域名但上线前必须处理。还有个经验之谈小程序审核一般需要半天到一天审核期间用户还是能访问旧版本新版本审核通过后是灰度发布的不会强制更新。所以上线窗口要预留缓冲时间不要在业务高峰期临时发版。6. 部署和联调中踩过的坑与二次开发扩展方案6.1 部署过程中的典型问题清单整个项目从开发到部署我至少踩了十个以上的坑这里挑几个影响最大的分享。坑一跨域配置不生效开发环境中Vue3管理后台通过 Vite proxy 把/api代理到后端能正常工作。但小程序端没有浏览器跨域的概念微信内部请求天然不受CORS限制所以小程序的请求不需要后端开启跨域。而管理后台如果直接通过IP访问后端会遇到跨域问题。我的解决方案是后端在WebMvcConfigurer里统一配置跨域映射允许所有来源开发用。上线后前端走Nginx同源代理后端根本不需要对外暴露8080端口跨域问题彻底消失。这个方案比在后端配置CORS一劳永逸推荐大家采用。坑二图片上传后访问404用户头像和订单图片上传到服务器本地磁盘但页面访问时404。原因是Spring Boot默认只处理应用上下文路径内的请求映射外部磁盘目录需要配置addResourceHandlers。我踩了这个坑才意识到生产环境一般有两种选择一是挂载OSS/COS这类对象存储二是通过Nginx直接代理磁盘目录。校园项目没必要上OSS直接用Nginx映射目录是最省钱省事的location /upload/ { alias /var/www/uploads/; }坑三JWT密钥硬编码在后端代码里我一开始把JWT密钥直接写死在代码里后来想想不对——如果代码仓库泄露任何人拿到源码都能伪造Token等于整个用户体系被脱掉。正确做法是从环境变量或配置中心读取部署时通过启动参数注入。这里再强调一次这个安全习惯要养成。坑四微信支付接口的接入问题校园跑腿的支付场景其实有点敏感因为微信支付对个人开发者不开放必须要有企业资质。我在项目中做成了线下支付 在线记录的模式——用户下单时选择支付方式在线/线下如果选择在线支付目前只能模拟支付回调如果做真实支付需要提供营业执照等资料申请微信支付商户号。如果只是用来演示和学习模拟支付完全够用如果要真实商用建议先确认资质再接入。6.2 项目目录结构与二次开发路线图最后说说这个项目拿到手之后从哪个目录开始看以及接下来可以往哪个方向做。如果你拿到的是我项目的完整代码建议按这个顺序去读先看sql/campus_order.sql把库表关系理清楚再看后端controller包把接口路由和业务模块对应起来然后看service层理解业务逻辑的核心实现最后看小程序端pages目录把页面和后端接口对应上二次开发方向我建议优先考虑以下几个订单超时自动取消加入定时任务Spring Task或XXL-Job超过30分钟未被接单的订单自动取消跑腿费分成在结算模块加入平台抽成比例骑手收益 跑腿费 x (1 - 平台比例)订单评价体系订单完成后用户和骑手互相评价评价数据回写到骑手表里的评分字段接单大厅的WebSocket改造把轮询换成WebSocket推送实时性更强但要注意鉴权和连接管理多校园隔离如果你要推广到多所高校需要在订单表加campus_id字段所有查询都带上这个过滤条件避免跨校数据显示这里我多说一句WebSocket的问题。很多人一听WebSocket就觉得很高级但如果你的业务量不大轮询带来的服务器压力其实非常小。10秒一次的轮询每个连接每小时才36个请求1000个在线用户一小时也就3.6万次请求对于一台普通云服务器来说毫无压力。实时性要求不高的场景根本没必要上WebSocket复杂度和维护成本完全是负收益。6.3 实际部署运行的效果与心得体会项目部署上线后我在本地跑了三天的模拟运营创建了5个测试用户其中2个申请了骑手并完成审核发布了15笔订单取快递8单、代买4单、代排队3单骑手全部正常接单、标记送达管理后台的骑手审核、订单监管、数据统计全部正常整个流程走下来整体体验比我预期的顺畅。尤其是订单状态机的设计让我在后期的接口调试中省了很多事——不管怎么操作状态都不会跳到非法状态。这一点我强烈建议做类似业务系统的同学都采用状态机模式。如果非要说还有什么遗憾那就是微信订阅消息的触达率问题。用户授权一次只能发一条而跑腿订单从发布到完成可能经历接单、送达两个节点需要发送两条消息但用户只授权了一次。我的处理方案是把接单通知作为必发项送达通知降级为骑手在小程序内通过电话或模板消息提醒未来要考虑多次订阅授权的引导方案。跑腿类小程序的核心竞争力从来不只是技术还有运营——你的骑手团队够不够勤快、响应够不够快、服务态度好不好。技术只是把业务线上化的工具把流程规范好、把数据沉淀下来后续做活动新用户首单立减、骑手接单奖励才有抓手。这套代码我已经压进了Git仓库需要的同学可以直接拿去二次开发。本文还有配套的精品资源点击获取