校园跑腿网站毕设实战：SpringBoot+Vue前后端分离开发完整指南

想在毕业设计这道坎上选一个“常见但又不太水”的题目，SpringBoot + Vue 的校园跑腿网站确实是个很稳的选项。它既不像纯管理系统那样只有增删改查，又不至于像分布式秒杀那样要压测、要消息队列、要 Redis 集群，难度刚好卡在一个本科生跳一跳够得着的位置。

这篇博文我按实际开发的顺序来讲，从需求拆解、数据库设计、后端接口、前端页面，到最后的部署和答辩准备，全部走一遍。适合正在做毕设、课设，或者想在小团队里快速搭出一套前后端分离项目的人参考。你要是只想要一个能过查重、能演示的完整系统，这篇内容可以直接照着落地。

先说结论：校园跑腿这个业务，核心就三句话——用户发单、骑手接单、跑完结算。把这三点做成闭环，系统就成立。剩下的全部是锦上添花。

1. 需求分析与技术选型：先想清楚再动手

很多人拿到题目就急着建工程，写了两天代码才发现订单状态不知道该设计成什么样，用户权限也乱成一团。这种问题根子不在编码，而在需求没有理清。

1.1 校园跑腿的“真需求”到底是什么

校园跑腿和美团、饿了么这类平台是有本质区别的。校内的配送半径小、用户群体固定、订单金额低，最典型的场景就是“宿舍楼下取快递”“食堂带饭”“超市代买”。因此系统设计不需要考虑复杂的运力调度，不需要算配送费，也不需要LBS实时派单，核心就是供需两侧的高效匹配。

我的用户角色拆分是三端：普通学生、跑腿骑手、系统管理员。普通学生要能发布订单、查看订单状态、取消订单、确认送达并评价；骑手要能浏览订单大厅、抢单、更新配送状态、查看自己的收入；管理员要能做用户审核、订单管理、公告管理、基础数据配置。

功能模块我最终收敛成这些：登录注册、个人中心、订单大厅、发布订单、接单/配送、评论、钱包充值、公告通知、后台管理。那些类似于“社交功能”“实时聊天”“路线规划”的，全部砍掉。不是不能做，而是做出来大概率会卡住进度，而且演示时根本不是评委关注的重点。

1.2 为什么选SpringBoot+Vue而不是其他组合

这个选型说实话有点“被生态推着走”的意思，但确实是目前国内Java后端项目里最稳的组合。

后端选SpringBoot，主要看中它的“约定大于配置”。以前用SSM框架写一个项目，XML配置文件能写到怀疑人生，SpringBoot通过自动配置把这些都简化了。再加上内置Tomcat，打一个Jar包就能跑，部署成本非常低。而且SpringBoot的生态太完整了，认证用JWT、持久层用MyBatis-Plus、文档用Swagger，几乎每踩一个坑都有现成方案。

前端选Vue，原因是它足够轻、文档亲民、社区资料多。Vue的响应式数据绑定和组件化开发让页面开发效率明显提升，Element UI / Element Plus一套组件库拿过来，后台界面的颜值立刻就有保障。相比React，Vue的上手曲线更平滑，遇到问题在中文搜索引擎里几乎都能找到答案。

这里要劝一句：除非你有特别强的理由，否则不建议在这个项目上引入微服务、分布式事务、消息队列这类重型组件。你是在做毕业设计，不是在做高并发的电商平台。技术栈应该为业务服务，而不是为了炫技把项目搞成四不像。

1.3 需要提前划清的边界

项目开始前，一定要把“能做”和“不做”写清楚，这是后期不烂尾的关键。

支付环节，我直接做成了“模拟支付”。也就是用户点击支付按钮后，系统默认支付成功并从余额中扣除，不接入真实微信/支付宝。原因很简单，个人开发者申请支付接口需要营业执照，而且真实支付涉及回调、证书、退款等一堆问题，不适合毕设场景。

定位环节，初期只用了校内热门地点的下拉选择，比如“1号宿舍楼”“图书馆”“东门菜鸟驿站”。如果要做地图选点，前端可以再集成腾讯地图或高德地图的JavaScript API，但这属于加分项而非必备项。

这些边界确定以后，项目一下子变得可落地了，至少不会在中期突然发现某个功能做不下去。

2. 架构设计与数据模型：先画图再写代码

我见过太多同学把数据库建得乱七八糟，用户表里放地址、订单表里放好评率，最后查询时全靠Java代码里各种循环赋值，效率极低。数据库设计是后端开发的骨架，这里省时间，后面一定加倍还回来。

2.1 前后端分离的工程结构与目录规划

我把项目分成了两个独立工程：

text复制school-runner-front
├── public
├── src
│   ├── api               // 接口请求统一封装
│   ├── assets
│   ├── components        // 公共组件
│   ├── router            // 路由配置
│   ├── store             // 状态管理（Vuex / Pinia）
│   ├── utils             // 工具函数
│   ├── views             // 页面组件
│   ├── App.vue
│   └── main.js

school-runner-server
├── src/main/java/com/example/runner
│   ├── config            // 配置类（CORS、拦截器、MyBatisPlus）
│   ├── controller        // 控制层
│   ├── service           // 业务层
│   ├── mapper            // 数据访问层
│   ├── entity            // 实体类
│   ├── common            // 统一返回体、异常处理、工具类
│   └── RunnerApplication.java
├── src/main/resources
│   ├── mapper            // MyBatis XML文件
│   ├── application.yml
│   └── sql/init.sql

这个结构是当前Java后端项目最普遍的分层方式。控制层只接收参数和返回结果，业务逻辑全在Service层，数据操作在Mapper层。这样写的好处有两个：一是后期如果改了需求，只需要动对应层级的代码，不用满项目翻；二是答辩问“三层架构”的时候，你能讲得比书上的例子更实在。

2.2 核心数据表的设计与字段取舍

我的数据库一共有8张表，核心表如下：

订单表里我单独把order_no提出来，不光是为了好看，而是考虑到用户可以按订单号查询，管理员也需要一个不暴露自增主键的单号来沟通。status字段我用tinyint存储，注释说明含义，因为订单状态在Java代码里会有对应的枚举类，数据库里存数字效率更高也更好维护。

有一张表我差点忘了写，后来才发现很关键：wallet_log。用户余额变动必须留下流水，不然用户说“我充过钱怎么没了”时，你连查证的方式都没有。流水表只做增加，不做更新和删除，这种表在业内叫“流水账”，设计原则就是只追加、不修改。

2.3 统一返回体与接口规范

接口返回格式如果不统一，前端处理起来就是一场灾难。一会儿{success:true, data:{}}，一会儿{code:200, result:{}}，前端每个请求都要单独判断。所以第一步就是定死返回体。

我的统一返回结构如下：

java复制@Data
public class Result<T> {

    private Integer code;
    private String msg;
    private T data;

    public static <T> Result<T> success(T data) {
        Result<T> result = new Result<>();
        result.setCode(200);
        result.setMsg("操作成功");
        result.setData(data);
        return result;
    }

    public static <T> Result<T> error(St