简介：基于Java的校园跑腿系统毕业设计资料，主要面向计算机相关专业毕业生和需要完成同类型课题的开发者。系统聚焦大学生因学业与社交活动繁忙而在购物、买饭、取快递等排队事务上浪费时间的问题，围绕食堂菜品信息管理、超市商品信息管理、快递站管理、销售量统计、用户管理、订单管理、订单支付、跑腿接单管理、跑腿订单评价等核心功能进行设计实现，采用Spring Boot与Vue技术栈，使用MySQL存储数据，以Tomcat作为服务器，并包含需求分析、可行性分析、系统设计、功能测试等完整的开发流程。资料包共1个doc文件，大小8.07MB，内容为体系完整的毕业设计论文文档，涵盖中英文摘要、目录、绪论、相关技术简介、系统详细设计等章节，结构清晰，可作为论文写作和系统复现的参考范本。目前已有43人学习浏览。阅读该文档，读者能系统梳理校园跑腿业务的模块划分与数据库设计思路，理解主流Web开发技术在真实项目中的综合运用，对完成毕业设计、准备答辩以及后续系统二次开发都具有切实帮助。
1. 系统整体设计与技术选型分析
1.1 需求背景与目标定位
校园跑腿系统这类题目，在每年毕业季都会反复出现，但真正能把它做扎实的同学并不多。它看起来就是一个“用户下单、跑腿员接单、完成配送”的简单流程，实际上涉及用户角色划分、订单状态机管理、并发抢单、消息实时推送等一系列问题，非常适合用来展示完整的Java Web开发能力。
我在设计这套系统时，把目标定位在三个层面：第一，功能闭环要完整，从下单、支付、派单、接单、送达、评价全流程能跑通；第二，角色权限要清晰，学生用户、跑腿员、管理员三方各有一套操作界面和权限边界；第三，技术栈要具备一定现代性，尽量贴近企业真实项目常用的组合，而不是停留在纯JSP+Servlet的老套路上。这样无论你是用来做毕业设计答辩，还是想写进简历作为项目经历，都有足够的内容可以讲。
1.2 为什么选Spring Boot + MyBatis-Plus这套组合
技术选型是答辩时老师必问的环节，不能只说“因为流行”，得说出取舍逻辑。我最终确定的是Spring Boot 2.x + MyBatis-Plus + MySQL + Redis这套组合，前端管理端用Layui或Vue Element Admin，用户端配合uni-App打包成小程序形态。
Spring Boot的核心价值在于自动配置，省掉了大量XML配置，让项目结构更清爽，这对于课程设计和毕业设计这种时间有限的项目来说优势很明显。MyBatis-Plus则在MyBatis基础上提供了通用Mapper和条件构造器，单表CRUD不用写SQL，能把开发效率提升一大截。Redis在这里不是摆样子，我把它用在两个地方：一是用户登录token的缓存，二是订单过期未接单时的自动状态回滚。这两个场景在后文会展开说明。JDK版本我建议用1.8，虽然现在已经出了更高版本，但1.8的生态兼容性最好，部署到服务器上不容易出幺蛾子。
提示：如果你在学校答辩时被问到“为什么不用SSH/SSM”，回答重点放在“Spring Boot约定优于配置，降低了整合成本，同时保留了Spring生态的完整事务与AOP能力”上，这个答案既客观又有深度。
2. 数据库设计与状态流转机制
2.1 核心表结构与关键字段设计
跑腿系统的数据库设计是整个项目的地基，地基没打好，后面写代码全是别扭。我规划了八张核心表：用户表、跑腿员表、管理员表、订单表、接单记录表、评价表、意见反馈表、系统配置表。
用户表（t_user）的字段不算复杂，但有两处需要特别注意。一是使用手机号作为登录唯一标识，并且增加唯一索引，这是为了配合短信验证码登录的方式，符合校园场景下学生不喜欢记密码的习惯。二是密码字段虽然可以设默认值，但在跑腿员入驻审核通过前，该字段需要保持为空，这个状态我用一个专门的status字段管理。跑腿员信息我单独建了一张扩展表（t_runner），与用户表一对一关联，存校园卡照片、身份证号、接单次数、完单率等运营维度数据，而不是堆在用户表里，这个设计在答辩时可以主动解释成“满足第二范式的垂直拆分思路”。
订单表（t_order）是绝对的核心表，字段设计要直接决定业务逻辑写起来顺不顺手。我的核心字段包括：订单编号（order_no）、下单用户ID、跑腿员ID、订单类型（代拿快递/代买商品/代排队/其他）、取件地址、送达地址、期望送达时间、订单状态、配送费、商品金额、备注、创建时间、支付时间、接单时间、完成时间。其中订单编号不要用自增ID直接暴露给用户，我用时间戳+随机数生成一个对外可见的串号，避免别人通过订单号推断出平台单量。
2.2 订单状态机的定义与状态流转约束
订单状态是整个系统最容易被写乱的环节。很多同学用一个字符串字段存状态，然后在Service层里散落着一堆if判断，结果就是改一处崩三处。我从一开始就定义了一个状态机模型，用数字状态码统一约束流转路径。
| 状态码 | 状态含义 | 可流转到的状态 |
|---|---|---|
| 0 | 待接单 | 1、4 |
| 1 | 已接单待取件 | 2、4 |
| 2 | 配送中 | 3、4 |
| 3 | 已完成 | 5 |
| 4 | 已取消 | 无 |
| 5 | 已评价 | 无 |
状态机的核心逻辑是：任何状态跳转都必须经过统一的OrderStatusTransition组件校验，不允许在业务代码里直接setStatus。这个组件里我写了一个静态的Map存储合法流转关系，流转时先查表校验再执行更新。这样做的好处是，就算未来接手代码的人不熟悉业务，也能顺着这个表快速理解订单生命周期，答辩时把这个设计讲清楚，老师一眼就能看出你是有工程意识的。
数据库层面还需要做约束兜底，订单状态更新语句必须带上期望的旧状态，比如UPDATE t_order SET status = 2 WHERE order_id = ? AND status = 1，这样即便并发场景下两次请求同时到来，也只有一个能更新成功。这个细节其实是为后文要讲的抢单功能做铺垫，但放在订单状态管理里实现统一更合理。
3. 核心功能实现与关键代码解析
3.1 登录鉴权与用户角色权限控制
登录这块我没有引入Spring Security这种重型框架，而是用JWT + 拦截器的方式实现了一套轻量级鉴权。为什么不用Security？很简单，毕业设计项目里涉及到的权限模型就是“用户、跑腿员、管理员”三种固定角色，用Security的过滤器链和权限表达式反而增加了理解成本，答辩的时候你还得解释一堆配置。拦截器加注解的方式，自己掌控力更强，出问题排查起来也更快。
JWT的生成和校验我封装在JwtUtil工具类里，使用HS256算法签名，密钥配置在application.yml中，token有效期设为24小时。用户登录成功后生成token返回前端，前端每次请求在Header中携带，拦截器里校验通过后把用户ID解析出来存入ThreadLocal，后续业务代码直接用UserContext.currentUserId()获取当前操作人。
角色权限的控制，我用一个@RequireRole注解搞定，拦截器里读取注解配置的角色码，再和当前用户的角色码比对，不一致直接返回403。无需写死方法调用权限，加在Controller方法上即可。
@Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface RequireRole { int[] value(); }接线员场景的登录逻辑，我额外做了锁定判断：如果密码连续输错5次，账号锁定30分钟。这个需求看着小，但涉及Redis自增计数、过期时间、阈值判断三个点，写起来也不简单，趣味性反而很高。
3.2 抢单功能的高并发处理思路
抢单是整个系统的技术亮点，也是面试/答辩最容易拿分的地方。跑腿员端有一个“可抢订单”列表，里面展示所有待接单的订单，多个跑腿员可以同时点击抢单，但必须保证一个订单只能被一个跑腿员抢走。
我一开始想的是先查订单状态、判断是待接单、再UPDATE。后来发现不对，多线程下这个判断和更新并不是原子的，查询时状态是0，但更新时可能已经被别人改成1了。这个问题本质上就是超卖问题，和秒杀系统里库存扣减是同一类问题。
最终采用方案是乐观锁式条件更新，在SQL层面直接加上状态限制：
UPDATE t_order SET runner_id = #{runnerId}, status = 1, accept_time = NOW() WHERE order_id = #{orderId} AND status = 0通过MyBatis-Plus执行这个Update，然后判断受影响行数，如果为1说明抢单成功，如果为0说明被其他人抢先了，立即抛出“手慢了，订单已被抢走”的提示。这个方案根本不需要引入分布式锁，性能高、逻辑清晰，而且能完美应对中小规模并发场景。
抢单成功后，还要向抢单者推送消息。推送方案我选的是WebSocket，为什么不用轮询？因为轮询费资源、延迟还不可控。WebSocket连接建立后保持长连接，服务端在订单状态发生变化时主动推送最新状态。这里有个实际部署的坑，就是WebSocket的连接数受到Tomcat默认线程池限制，如果并发很大容易堆积，但毕设场景完全够用。我在Nginx层配置了WebSocket的升级请求支持，并开启了连接空闲超时时间60秒，保证代理层不会过早断开连接。
3.3 订单派发与自动取消流程
关于派单逻辑，我参考了真实跑腿平台的做法：用户下单后，系统先把订单投递到“待接单池”，跑腿员实时看到并自行抢单，没有采用平台强制指派方式。原因很简单，校园场景下跑腿员数量和分布都比较随机，强制指派容易造成“没人愿意跑”或者“跑腿员位置偏离”的问题，自由抢单模式反而能通过价格自调节让订单资源高效分配。
但自由抢单有一个副作用，就是如果订单一直没人接怎么办。我的处理是：下单时允许用户选择“加急模式”，加急订单超过5分钟、普通订单超过15分钟未接单，系统通过定时任务扫描订单表，把连续超时未接单的订单状态自动转为取消，并原路退回支付金额。这个定时任务就是基于Spring注解@Scheduled实现的，每10秒执行一次，配合Redis缓存初始化校验，防止重复扫描处理。
@Scheduled(fixedRate = 10000) public void scanTimeoutOrders() { List<Order> timeoutOrders = orderMapper.selectList( new LambdaQueryWrapper<Order>() .eq(Order::getStatus, 0) .lt(Order::getCreateTime, DateUtils.addMinutes(new Date(), -timeoutMinutes)) ); timeoutOrders.forEach(order -> { // 状态回滚 + 退款逻辑 orderService.autoCancelOrder(order.getOrderId()); }); }4. 项目开发过程中遇到的高频问题与排查思路
4.1 环境与配置层面的经典报错
这个项目在部署和运行阶段，很多同学会在环境配置上浪费大量时间。我在这里整理几个我实际遇到、也经常帮学弟学妹解决的典型问题，按频率排列如下：
| 问题现象 | 根因分析 | 解决方案 |
|---|---|---|
| Tomcat启动闪退 | JDK未配置JAVA_HOME或版本不兼容 | 确认JDK安装路径，配置JAVA_HOME并追加到PATH |
| MySQL连接报Public Key Retrieval错误 | MySQL 8默认认证插件为caching_sha2_password | JDBC URL中添加allowPublicKeyRetrieval=true&useSSL=false |
| 数据库中文乱码 | 连接字符集未指定 | URL追加characterEncoding=utf8；确保库表charset为utf8mb4 |
| 前后端跨域请求失败 | 未配置CORS或拦截器拦截了OPTIONS请求 | 编写WebMvcConfigurer实现addCorsMappings，放行预检请求 |
| 更新操作返回0但数据未变 | 乐观锁条件不满足，WHERE中的status与库中不一致 | 打印SQL日志检查条件值；确认操作前已刷新最新状态 |
MySQL 8的时区问题也要特别注意，如果你连接的数据库报The server time zone value 'Öйú±ê׼ʱ¼ä'这种错误，就是没有指定时区导致的。在JDBC URL后面加上serverTimezone=Asia/Shanghai即可解决。这个报错的信息显示乱码，很多人第一时间以为是字符集问题，实际是时区问题，别被表象误导了。
4.2 代码逻辑层面的隐蔽Bug与避坑技巧
环境问题排查起来相对直接，代码逻辑层面的隐藏Bug才更折磨人。我印象最深的一个Bug是：订单完成后用户可以评价，但同一个订单被恶意请求连续提交了多条评价，导致评价表里出现重复数据。排查后发现是评价接口缺少“是否已评价”的幂等校验。修复方案是在评价表上给order_id加唯一索引，同时插入前再针对订单状态为3（已完成）判断一次，双保险。这个教训延伸出一个通用经验：任何涉及“提交类”的接口，都必须从数据库约束和业务逻辑两个维度做幂等控制。
另一个隐藏得比较深的Bug出现在订单取消环节。我在代码里先判断订单状态，再执行取消更新，但因为没有强制带上旧状态做条件，在多线程测试时出现了“跑腿员正在配送的订单被用户取消成功”的脏数据。后来统一调整成上文提到的条件更新写法，问题彻底解决。这个Bug看似和抢单功能类似，但它是反向场景，所以排查时第一次压根没往并发方向想，花了不少时间。
最后分享一个容易被忽略的点：前后端联调时，如果WebSocket一直连不上，先别查Java代码，用浏览器开发者工具的Network面板看WebSocket的握手请求状态码，如果返回了404，大概率是路径写错了，如果返回403，则是拦截器拦截了握手请求。我项目里的权限拦截器一开始没有放行/ws/**路径，导致所有前端WebSocket连接全部失败，排查了好几个小时才定位到问题。
4.3 项目可扩展方向与实际部署建议
如果你做完这个项目还有余力，我建议抽时间做两个小升级：一是把WebSocket的单机推送改成集成消息中间件广播，这样可以支持多实例部署，也算接触了分布式架构中消息异步解耦的思想；二是给订单增加一个简单的路径规划展示，调用在线地图API，把取件地和送达地标出来，这个功能展示效果好，答辩时也会很加分。
部署环境方面，如果只是做课程设计或毕业设计展示，Windows本机运行完全够用，但如果你要放到云服务器上——比如带着系统去参加比赛路演——建议使用Linux + Nginx + 独立MySQL的组合。打包时用mvn clean package生成jar包，通过nohup java -jar school-runner.jar &后台启动。保险起见，配置文件中将日志文件路径指定为绝对路径，否则使用systemctl管理服务时会因为相对路径找不到日志文件。
注意：生产环境部署千万不要开着Spring Boot的DevTools热部署功能，否则频繁触发类加载重启，会造成莫名其妙的内存溢出或端口占用问题。
5. 写在最后的实操心得
整个项目从零到完整实现，我大概用了三周业余时间。回头复盘，最有价值的其实不是最终的代码和文档，而是踩过那些坑之后建立起来的排查思路。技术上，Spring Boot给你省去的配置越多，你就越要清楚底层发生了什么；业务上，跑腿系统虽然看起来只是一个小众场景，但里面的订单状态机、并发抢单、消息推送、幂等设计，都是企业级业务系统里天天要面对的核心问题。如果你正在做类似题目，我强烈建议把状态机设计和抢单的条件更新这两块吃透，这两个点比你代码里用了多少新技术都更能证明你的工程能力。
最后再分享一个小技巧，写毕业设计文档时，不要把“技术介绍”章节写成Java、Spring Boot的官方文档翻译，而是每介绍一个技术就要说明“在本系统中承担了什么职责、为什么非它不可”。这样写出来的文档逻辑自洽，答辩老师追问时你也不慌。因为本质上，考察的不是你背了多少知识点，而是你有没有基于真实需求做出合理技术决策的能力。
本文还有配套的精品资源，点击获取
