每年一到准备毕业设计的时候，“校园跑腿系统”这个题目几乎必上榜。它在校园场景里足够具体，用到的技术栈又正好是 Spring Boot + 微信小程序这一套主流组合。今天要说的这个项目，除了完整源码，还带了设计文档、运行视频和讲解视频，本质上不是那种只有一个下单页面的演示Demo，而是把“发单—接单—支付—配送—结算—评价”整条链路做完整的闭环系统。校园里学生能通过小程序发布取快递、带饭、代买零食这类需求，跑腿员在另一端抢单配送，管理员在后台处理审核和异常订单，所有状态变化都留痕可查。
先交代一下适合人群。如果你是准备拿这个题目做毕业设计或课程设计的同学，这套项目能帮你省掉从零搭环境的体力活；如果你想学微信小程序和 Java 后端到底怎么联调，它提供了前后端完整可运行的代码；如果你是想在校园内部做一个真实跑腿服务原型的团队，这也能作为起步底子。下面我会按整体设计、功能拆解、部署运行、问题排查四个方向走，尽量把拿到源码后最容易卡住的地方提前讲透。
1. 项目核心价值与整体设计思路
1.1 先看这套系统能做什么：四个角色与三条业务主线
校园跑腿系统表面上是一个小程序应用，实际里面包含了四类参与者：普通用户、跑腿员、管理员，以及作为协调者的系统本身。普通用户在小程序里发布跑腿需求，填写任务描述、跑腿费、取件地点和送达地点；跑腿员在订单广场看到可接订单之后抢单；配送完成后用户评价，跑腿员的账户收入增加；管理员则在后台负责跑腿员认证审核、订单仲裁、异常退款和公告维护。这四个角色不是各管各的，而是通过“订单”这条主线互相咬合。
我把这套系统的运行逻辑拆成三条业务主线，这比单纯看页面功能更能理解项目。
第一条是订单线。一个订单从发布开始，要经历待接单、已接单、配送中、已完成这几个正向状态，同时还要考虑已取消、退款中等反向状态。订单线最重要的不是按钮点击，而是状态流转必须受控。用户在什么时候发的单、谁在什么时候接的单、为什么被取消，都要有明确的记录可查，否则出了问题连排查入口都找不到。
第二条是资金线。用户发单时涉及跑腿费支付，系统可以扣减用户余额或者走模拟支付流程；跑腿员完成订单后，跑腿费进入其账户余额；跑腿员申请提现，管理员审核后打款。这里最关键的是每笔资金变动都要有流水，不能光在余额字段上加加减减。
第三条是消息线。订单状态发生变化后，用户和跑腿员需要得到通知，不管用轮询、订阅消息还是 WebSocket，实时性和准确性都得保证。
把这三条线理顺后，系统骨架就清楚了。我也建议你拿到任何跑腿项目时，第一件事不要看页面样式，而是打开数据库看订单表、钱包流水表和订单状态记录表是怎么设计的，一眼就能看出项目质量。
1.2 为什么选 Spring Boot + 微信小程序这套组合
很多同学问我，这个题目能不能用其他方案？当然能，但 Spring Boot + 微信小程序确实是目前综合成本最低的选择，也是出活最稳的搭配。
Spring Boot 的核心优势在于上手门槛和工程化之间的平衡。它内置了 Tomcat，不需要单独部署 Servlet 容器；通过起步依赖把 Spring MVC、MyBatis 这些东西整合进来，配置比传统 SSM 项目精简很多。对毕业设计来说，启动一个独立进程就能验证后端接口，写 Controller、Service、Mapper 三层结构本身就是主流套路，答辩时老师能顺着这个分层快速理解代码。而且 Java 技术栈的参考资料量大，遇到问题搜起来不费劲。
微信小程序解决的则是“前端装在哪儿”的问题。大学校园里，用户不需要下载额外 App，扫码打开小程序就能用。校园跑腿这种低频服务场景，小程序比原生 App 轻量太多。同时小程序前端通过 HTTP 接口跟 Java 后端通信，这种前后端分离的模式是目前商业项目最常见的结构，学会之后迁移到管理后台、营销页面都很顺手。
版本选型上，我建议优先采用 Spring Boot 2.x 搭配 JDK 8。原因很朴素：这套组合的踩坑资料最全、运行最稳定，视频演示呈现的也是这套环境。如果用了 Spring Boot 3，强制要求 JDK 17，很多老教程的配置就不完全适用，对新手来说没必要增加这层不确定性。
2. 功能模块拆解与核心实现要点
2.1 用户端和跑腿员端的核心功能分布
小程序端是用户和跑腿员接触最频繁的部分，也是系统门面。用户端的重点功能大致分成五块。
第一块是登录鉴权。小程序通过 wx.login 获取临时 code，后端拿着 code 换回 openid，然后生成一个自定义 token 返回前端。后续请求都带上这个 token，后端用拦截器统一校验。这里要注意，不要在数据库里保存用户的明文密码，微信生态下用 openid 做身份唯一标识就足够了。
第二块是发单。用户填写跑腿类型、任务描述、取件地址、送达地址、跑腿费、期望完成时间。后端不只是接收这些字段，还要做初始化和校验。比如用户余额不足时不能允许发单；订单创建后要生成唯一订单号，并同步写一条状态日志。
第三块是订单广场和抢单。跑腿员查看待接单列表，点击抢单。这个动作看似简单，实际上是最容易出并发事故的地方。两个跑腿员同时点抢单，同一个订单不能分给两个人，必须在数据库层做条件更新，而不是先查再改。
第四块是配送执行。跑腿员抢单成功后联系用户，随后按节点提交“已取件”“已送达”操作。加上订单详情里的联系方式、地址信息，整个配送链路就完整了。
第五块是评价和个人钱包。用户完成订单后可以打星、选服务标签、写文字评价；跑腿员可以查看收入明细、申请提现。个人中心这块经常被新手做得很薄，但答辩老师很爱问，因为余额和流水一旦对不上，整个资金设计就会被质疑。
2.2 管理后台与数据统计：不要让后台变成摆设
很多跑腿示例项目把大量精力放在小程序端，管理后台只留两三个页面，这是很亏的事情。后台完整度往往能拉开项目档次。
管理后台最基础的功能是用户管理。管理员要能查看所有用户、禁用违规账号、设置管理员角色，还要处理跑腿员入驻申请。跑腿员的认证资料必须经过管理员审核，审核通过后才有接单资格。这个流程做出来，就能在答辩时说明白“系统如何保证跑腿员身份真实”。
订单管理是后台的兜底能力。管理员要能看到全部订单，按订单号、用户、状态、时间范围筛选。当用户和跑腿员发生争执时，管理员可以介入处理，把订单改到合法状态，或者执行退款。这类异常介入操作一定要记录日志，谁操作的、改了什么、备注是什么，都要有迹可循。
数据统计是后台的加分项。每日新增订单数、完成订单数、单量高峰时段、跑腿员接单排行、用户复购率，这些指标哪怕不做成复杂图表，也至少要提供统计接口，按日期维度汇总订单量。答辩现场老师一旦问“系统上线之后你怎么判断运营情况”，有数据面板和只有一堆列表是完全不同的印象。
另外我会建议在管理后台加一个简单的公告管理，管理员可以发布系统通知，小程序首页展示公告。这个小功能工作量不大，但能让系统显得更完整，更像一个可运营的产品。
2.3 数据库设计：订单表、用户表、流水表怎么建
跑腿系统的地基是数据表设计。我拿到源码后会先看五张核心表，这五张表决定整个项目能跑多远。
用户表保存基础信息，包括 openid、昵称、头像、手机号、角色、账户余额、状态。角色字段区分普通用户和跑腿员，状态字段用于禁用。余额字段虽然放在用户表里，但实际变动必须配合流水表使用。
订单表是核心表，字段要包含订单号、发布人ID、接单人ID、订单类型、详细描述、取件地址、送达地址、跑腿费、订单状态、支付状态、创建时间、更新时间。订单号必须唯一，常见做法是时间戳加随机数，也可以用雪花算法。
订单状态日志表特别容易被忽略，但绝对不能省。每一个订单每次状态变化，都要往这张表里写一行，记录旧状态、新状态、操作人、备注和时间。有了这张表，用户端“订单轨迹”才能做出来，管理员介入时才有判断依据。
钱包流水表记录每个用户的每一笔余额变化，字段包括用户ID、变动类型、变动金额、变动前余额、变动后余额、关联单号。发单时的扣减、完成后的入账、提现时的出账，都必须写流水。如果只改余额不写流水，以后对账就是一笔糊涂账，这是答辩中最容易被追问的设计缺陷。
评价表相对简单，保存订单ID、评价人ID、被评价人ID、评分、标签、内容即可。跑腿员个人页的评价聚合就是从这里查出来的。
设计时我会把订单状态定义为 tinyint 数字，比如 0 已取消、1 待接单、2 已接单、3 配送中、4 已完成，不直接存“待接单”这种字符串。数字状态便于程序判断和索引，展示层再做映射。数据库统一使用 utf8mb4 字符集，避免表情符号和生僻字乱码。
2.4 消息通知与订单状态流转：轮询还是长连接
这个点不仅是功能实现问题，也是答辩时容易被问到的设计题。
小程序端要获取订单状态变化，方案无非几种。轮询最简单可靠，前端每隔几秒请求一次最新状态，缺点是有点延迟，请求频繁会浪费带宽。WebSocket 能做到服务端主动推送，实时性好，但小程序端要考虑连接建立、断线重连、心跳保活，复杂度明显上升。微信订阅消息适合关键节点通知，比如“订单已取件”“订单已送达”，但前提是用户必须先授权订阅，否则不能推送。
我建议这套系统采用折中方案。订单列表用下拉刷新加定时轮询，关键节点用订阅消息通知。数据库层面，所有状态流转统一收拢到一个 Service 方法里完成，而不是在 Controller 里散落着直接改状态。这样做的好处是校验规则集中，后续新增退款、申诉等状态时，不容易漏掉非法流转。
从实际效果看，轮询延迟在一两秒内，对校园跑腿场景完全够用。如果老师问“能不能做成实时推送”，你可以说 WebSocket 方案已经在设计上预留了接口，再进行局部替换即可，这比现场手忙脚乱改代码安全得多。
3. 把项目跑起来：环境配置与部署完整步骤
3.1 环境准备清单与版本匹配说明
拿到源码之后，第一件事不是读代码，而是把本地环境对齐到和视频一致的版本。我建议你按清单准备：JDK 1.8 或 11，Maven 3.6 以上，MySQL 5.7 或 8.0，开发工具用 IDEA 或者其他你熟悉的 Java IDE，小程序部分用微信开发者工具。如果项目里涉及到 Redis，还要提前装好 Redis 服务端，并在 application.yml 里把地址和密码改正确。
这里特别强调版本匹配。Spring Boot 2.x 对应 JDK 8 以上，Spring Boot 3.x 至少需要 JDK 17。如果视频里是 Spring Boot 2.7 配 JDK 8，你本地就不要用 JDK 17 硬跑。Maven 依赖下载慢的问题也很常见，建议在 Maven 的 settings.xml 里配置国内镜像源，速度会明显提升。
还有一个小提示：不要一上来就启动主程序。先把 MySQL、Redis 这些外部服务确认已经在运行，再启动 Spring Boot。很多启动失败都不是代码问题，而是数据库连接被拒。
3.2 数据库初始化与后端配置修改
数据库初始化一般分两步。第一步，在 MySQL 中创建一个空数据库，字符集选 utf8mb4。第二步，执行源码目录下提供的 SQL 文件，把建表和初始数据一次性导入。用数据库工具或命令行都可以，导入完成后确认核心表都生成完毕，特别是用户表、订单表、钱包流水表里有没有自带测试数据。自带测试数据能省不少事，跑演示的时候不用频繁造数据。
随后打开后端工程里的 application.yml 或 application.properties，重点处理三处配置。
数据库连接配置是最基本的。URL 要包含数据库名称、时区参数 serverTimezone=Asia/Shanghai，以及字符集参数 characterEncoding=utf8，否则很容易出现时间偏移和中文乱码；数据库用户名和密码改成自己本机的实际值。
文件上传配置也要检查。如果项目包含用户头像、订单图片上传，需要设置一个本地或服务器上的上传目录，确保目录真实存在且有写权限。否则上传时会出现文件找不到或者没有权限的报错。Windows 下路径写法是盘符加反斜杠，Linux 下则需要关心权限归属。
小程序参数配置是联调关键。AppID 和 Secret 需要填进配置文件里，但不要把 Secret 提交到公开仓库，最好用本地的局部配置或环境变量来管理。如果项目涉及微信支付，本地开发通常不具备商户号条件，所以大部分教学项目会提供模拟支付开关。直接开启模拟支付既能完整演示，又不会卡在支付回调环节。
3.3 小程序端导入与本地联调
小程序端的运行步骤相对固定。用微信开发者工具导入项目中的小程序目录，填入一个测试 AppID 即可，不需要注册正式小程序账号，也不需要上线发布。随后修改小程序端的全局请求地址配置，把后端地址指向本机或者局域网 IP。
本地开发时有个关键开关：在微信开发者工具“详情—本地设置”里勾选“不校验合法域名”。因为本地调试时你访问的后端地址通常是 http://192.168.x.x:8080 这样的 HTTP 地址，线上小程序会拦截非 HTTPS 请求，但开发工具放开校验后就可以正常联调。
真机调试时最容易踩坑的是地址问题。手机微信访问的后端地址必须是你电脑的局域网 IP，不能是 localhost。手机和电脑要在同一个路由器网络下，否则请求直接失败。我经常看到有同学小程序页面一直加载不出来，最后发现是 baseURL 里还写着 localhost。
后端服务默认监听 0.0.0.0，一般不需要改。但 Windows 防火墙可能会拦截端口，遇到小程序发不出请求、浏览器却能访问的情况，记得在防火墙设置里放行对应端口。你可以先用浏览器直接访问后端的某个接口地址，能看到 JSON 返回，再回到小程序里调试，能节省很多无效排查时间。
3.4 源码、文档、运行视频、讲解视频怎么配合使用
这套项目交付物包含了源码、文档、运行视频和讲解视频，顺序用对，效率会高很多。
我第一次接触这类项目时，建议先看运行视频，完整过一遍用户发单、跑腿员接单、管理后台处理的流程，先把“系统长什么样”装进脑子里。第二步读文档，重点看需求分析和数据库设计说明，理解角色划分和订单状态定义。第三步自己动手配置环境，跟着运行视频的步骤把项目跑起来。确认能跑通之后，再回头读源码，从 Controller 入口一路看到 Mapper 的 SQL，重点关注登录拦截、订单状态流转和支付逻辑这三块。最后用讲解视频做体系化复习，它会覆盖整体架构和核心设计点，正好匹配答辩的问题方向。
我不建议的顺序是：先啃源代码、再跑项目、最后看视频。没有运行概念时直接读代码，很容易陷入“每个文件都看过，但不知道系统怎么串起来”的困境。
还有一个实用技巧：如果视频里演示的数据库名称、端口和你本地不一致，以文档为准；如果文档和代码本身有出入，以实际运行的代码为准。把这些差异记录下来，既是笔记，也能用来应对答辩时“这个配置为什么是这样”的提问。
4. 踩坑记录与问题排查速查表
4.1 前后端联调最常见的5个问题
我协助过不少同学排查这类项目，遇到的其实不是深奥技术问题，而是几个基础联调点。
第一个是请求 404。小程序请求后端接口返回 404，通常就是 baseURL 配错、端口配错或者后端没启动。先用浏览器直接访问这个接口看能不能返回 JSON，这一步能快速定位是前端路径问题还是后端没起来。
第二个是 401 或 403。登录拦截器拦截了没有携带 token 的请求。检查小程序请求头里是否加了 Authorization 字段，再检查后端拦截器的白名单配置。登录接口、获取配置等接口通常要放行，其余接口必须校验身份。
第三个是图片上传失败。常见原因是上传目录不存在，或者 Spring Boot 配置的静态资源映射没有指到实际目录。把配置里的路径改成真实存在的目录，并确认目录有写权限，问题基本能解决。
第四个是数据库中文乱码。连接串没加 characterEncoding=utf8、数据库表字符集不是 utf8mb4，都会导致乱码。处理时要从连接串、数据库字符集、前端编码三层一起排查。
第五个是接口能通，但页面数据不变化。这种情况通常是更新语句没生效，或者前端用了旧缓存。打开后端日志看 SQL 是否真的执行成功，再确认事务是否提交。像抢单这种场景，如果更新行数为 0，说明条件没满足，并不一定是接口坏了。
这几类问题我用一个速查表总结，方便对号入座。
| 现象 | 常见原因 | 处理方向 |
|---|---|---|
| 请求 404 | baseURL 路径或端口错误 | 浏览器直连接口验证后端 |
| 401/403 | token 缺失或过期 | 检查请求头与拦截器白名单 |
| 图片上传失败 | 目录不存在或无权限 | 创建目录并修正映射配置 |
| 中文乱码 | 连接串或字符集不一致 | 统一使用 utf8mb4 |
| 数据更新后不变 | 更新语句失败或前端缓存 | 查看后端日志与事务提交 |
4.2 订单并发与状态机：抢单场景的实战方案
抢单是跑腿系统里最值得展开讲的一个点，因为这是真正的并发场景。
先说错误示范。很多简化版项目会先查订单状态，判断可接后执行更新。这套流程在单人测试时没问题，但一旦两个跑腿员同时抢，两人都可能读到“待接单”状态，然后都执行更新，最终一个订单出现两个接单人。解决思路是把“判断”和“更新”合并成一条条件更新语句，直接在数据库层做原子操作。
@Mapper public interface OrderMapper { @Update("UPDATE `order` SET runner_id = #{runnerId}, status = 2, accept_time = NOW() " + "WHERE id = #{orderId} AND status = 1") int grabOrder(@Param("orderId") Long orderId, @Param("runnerId") Long runnerId); }这条 SQL 的巧妙之处在于，把“订单必须是待接单状态”作为更新条件。数据库执行时，如果订单已经被别人抢走，更新行数为 0，Service 层根据返回值判断为“抢单失败”。不用加锁，也不用复杂的事务，性能和安全都够用。
订单状态机也值得专门梳理。正向链路是待接单、已接单、配送中、已完成，反向链路是已取消、退款中。每个状态转移都应在 Service 层集中校验，不能任由业务代码到处直接改状态。比如已完成订单不能取消，已接单订单取消时要考虑是否影响跑腿员信用，这些规则集中收口后，后面扩展退款、申诉等逻辑就容易得多。
资金操作要配合订单状态和流水表一起处理。用户发单扣减余额时，在同一事务里写订单表和流水表；跑腿员完成订单后，给跑腿员增加余额的同时也要写流水。事务方法记得加 @Transactional，否则订单状态变了但流水没写，后续对账永远对不平。
4.3 交付与答辩准备：文档、演示、源码三件套怎么准备
最后说交付和答辩实战。源码、文档、视频这三件套，不只代表你拿到的项目交付物，更是你未来向老师展示项目时必须准备的三样东西。
文档部分要确保包含需求分析、系统架构说明、数据库设计、接口说明和核心业务流程。答辩老师翻文档最常看数据表关系和接口描述，这两块一定不能省。如果原始文档缺了图表，自己补一张简单的角色用例图或 ER 图，打印出来带进答辩现场，展示效果很加分。
演示部分建议准备两条完整流程。第一条是用户发布跑腿订单、跑腿员抢单、取件、送达、评价；第二条是用户取消订单、管理员介入处理。这样既展示正向闭环，又展示异常处理，比只演示“能发单能接单”有说服力得多。
答辩高频问题通常集中在这几类：为什么用这种表结构；token 如何鉴权；抢单并发怎么处理；支付是什么方案；系统如何防刷单。这些问题都要能在源码里找到对应实现。演示前把后端、数据库、微信开发者工具全部启动好，现场演示时不要边翻代码边操作，节奏一乱容易漏步骤。
讲解视频的录制逻辑可以按“业务流程—架构模块—核心代码—演示回放”四段式来做。每段控制几分钟，不要在一个页面上讲太久，重点讲状态流转、并发处理、资金闭环和登录鉴权这几个亮点。核心点讲透，比堆砌十几个页面截图有效得多。
我个人在实际使用中最大的体会是：拿到任何跑腿项目，不要只把它当成一个“能跑”的作品，而是把订单状态、余额流水、接口鉴权这三条主线从头捋一遍。老师的问题基本都藏在这三条线里。哪怕后续你想扩展优惠券、多校区、LBS距离排序，也都是在这个健壮的地基上加功能的事。把地基搞明白，这套系统在你手里才算真正跑稳了。
