SpringBoot+Vue+MySQL高校外卖系统毕业设计全流程解析

1. 项目概述

1.1 核心需求解析

校园外卖服务系统平台，这个题目在毕业设计里属于典型的“前后端分离+业务闭环”类项目。为什么这类项目经久不衰？因为它恰好踩中了高校场景里真实存在的痛点：食堂窗口排队时间长、外卖App配送费贵、周边商家出餐信息不透明。学生想快速吃饭，商家想扩大客源，学校想规范管理，三方的需求在这个系统里都能找到对应的功能落点。

从这个标题看，它已经明确给出了完整的技术栈：SpringBoot做后端服务、Vue做前端页面、MySQL做数据持久化。这三个东西组合在一起，就是一个标准的企业级Web应用开发范式。对于计算机相关专业的学生来说，这套技术栈几乎等于“默认选项”——社区资料丰富、招聘市场需求大、踩坑案例多，做毕业设计时遇到问题基本上搜得到答案。

我见过不少学生卡在选题阶段，要么选纯理论类题目被导师质疑“工作量不足”，要么选算法类题目被数学推导折磨到头秃。相比之下，这类带完整业务场景的管理系统类题目，有明确的功能清单可以交付，有数据库设计可以展示，有接口文档可以整理，最关键的是——它能跑起来给导师演示。这在答辩时候就是实打实的亮点。

1.2 适用人群与前置知识

• 计算机相关专业大三大四学生，正在准备毕业设计选题或已确定此题目
• 有Java基础但没完整做过前后端分离项目的同学，需要一份“照着做能跑通”的完整参考
• 打算用SpringBoot+Vue技术栈找工作、准备项目经验但缺乏实战素材的求职者
• 对校园场景业务系统感兴趣，想了解订单流转、用户权限管理等核心逻辑的后端开发者

需要的前置知识其实门槛不高：Java语法基础、MySQL增删改查、HTML/CSS/JavaScript的基本概念。如果你没系统学过SpringBoot和Vue也没关系，但你要有个心理准备——这类框架的学习曲线比纯Servlet时代的开发方式平缓得多，约定大于配置，很多东西框架已经帮你处理好了，你只需要理解“数据怎么从数据库流到用户屏幕”这条主线。

2. 整体设计思路与技术选型

2.1 为什么是SpringBoot而不是SSH或SSM

老一代开发者可能更熟悉SSH（Struts+Spring+Hibernate）或SSM（Spring+SpringMVC+MyBatis），但放到毕业设计这个场景里，SpringBoot几乎是唯一理性的选择。

SpringBoot的核心价值在于“自动化配置”。以前用SSM搭一个项目，需要手动配置web.xml、spring-mvc.xml、mybatis-config.xml，一堆XML文件里任何一个标签写错，项目启动就直接报错，排查半天可能只是少了一个空格。SpringBoot把这些全给你兜住了，它通过依赖管理和自动配置机制，让你用最少的配置把项目跑起来。

举个例子：你想让SpringBoot连上MySQL，只需要在application.properties或application.yml里写几行数据源配置，然后加一个starter依赖。以前那套复杂到劝退新人的连数据库操作，现在变成了一件极简的事。这对毕业设计的开发效率提升是巨大的——你的时间应该花在业务逻辑实现上，而不是消耗在环境搭建里。

SpringBoot还有一个隐藏优势，它的内嵌Tomcat让你打包即部署。传统Servlet项目部署需要安装独立的Tomcat，再手动把war包扔进webapps目录。SpringBoot默认打包成可执行jar包，java -jar 一行命令就能启动整个服务。这在写部署文档的时候也特别好写，对评审老师来说更直观。

2.2 为什么前端选Vue而不是React或JQuery

前后端分离是现在Web开发的绝对主流，Vue、React、Angular三选一，选Vue的原因很实在。

第一，学习曲线平缓。React的JSX语法、Hooks概念、受控组件这些思想，对没有前端框架经验的学生来说需要时间消化。Vue则不同，它的模板语法和原生的HTML非常接近，v-for、v-if、v-model这几个指令几个小时就能上手，数据绑定是自动的，你不用关心底层的DOM操作。同样一个登录表单，Vue写起来就是简洁，this.form.username直接和input双向绑定。

第二，中文社区生态成熟。Element UI、Vant、Ant Design Vue这些组件库，都是中文文档齐全的。遇到布局问题、组件用法问题，搜索引擎一搜一大把解决方案。你总不能指望做毕业设计的时候，每次踩坑都要去读英文文档慢慢啃吧？Vue的社区资料丰富程度，决定了你踩坑后能多快爬出来。

第三，Vue Router和Vuex（或Pinia）的配套工具链一致性强。路由怎么管理、全局状态怎么共享，整个Vue生态给你一套标准答案。React那边React Router和Redux的搭配虽然也是标准做法，但自由度高的同时意味着你有更多决策要做——这对新人反而是一种负担。

2.3 MySQL承载校园场景的合理解释

校园外卖系统的数据量级，用MySQL是完全合理的选型。很多学生纠结要不要上MongoDB，要不要用Redis做缓存，其实在毕业设计这个粒度上，MySQL已经把90%的问题解决了。

我算过一笔账：一个万人规模的高校，假设每天有2000单外卖订单，每单涉及用户信息、商家信息、商品信息、订单详情、配送记录，累积一个月的数据量也就是几十万条。这个量级对MySQL来说是小儿科，只要索引建得合理，查询响应时间都在毫秒级别。

MySQL带来的另一个好处是事务支持。外卖系统的核心业务流程——下单扣库存、订单状态流转、支付回调，这些操作必须保证数据一致性。@Transactional注解一加，SpringBoot帮你管好事务边界，出了问题可以回滚。这在MongoDB里实现起来就麻烦得多。

Redis在这种系统里当然可以当缓存用，但说实话，对毕业设计来说它是锦上添花而非雪中送炭。你完全可以先把系统跑通，再考虑引入Redis做热点数据的缓存优化，作为论文里“系统优化”章节的加分项。

2.4 角色权限模型设计

校园外卖系统天然有多方参与者，角色划分是最早就要想清楚的事。我建议用四个角色来搭建权限模型：

• 学生用户（C端）：浏览商家、下单、支付、评价、管理收货地址和个人信息
• 商家用户（B端）：管理店铺信息、维护菜品、处理订单（接单/出餐/完成）
• 配送员：查看配送任务、接单配送、更新配送状态
• 系统管理员（Platform端）：管理所有用户账号、审核商家入驻、处理投诉反馈、查看运营数据

这四个角色的权限边界要清晰。SpringBoot里常见的做法是整合Spring Security或Shiro做认证和授权，用JWT（JSON Web Token）解决跨域身份验证问题。用户登录成功后后端签发一个token，前端存储这个token，每次请求Header里带上来，后端通过拦截器或过滤器校验身份和权限。

3. 数据库设计与核心业务表结构

3.1 实体关系梳理

画ER图的时候，我习惯先把核心实体列出来，再逐个建立它们之间的关系。校园外卖系统的主要实体大概有这么几个：

用户表（user）、商家表（seller）、店铺表（shop）、商品分类表（category）、商品表（product）、购物车表（cart）、订单表（orders）、订单详情表（order_detail）、配送表（delivery）、地址表（address）、评价表（review）、优惠券表（coupon）等。

这些实体之间的关联关系是：一个用户有多个地址，可以下多个订单；一个商家有一个店铺，一个店铺有多个商品分类，每个分类下有多个商品；一个订单对应多个订单详情，每个详情对应一个商品和数量；一个订单可以有一个配送记录；一个用户可以发多个评价。

3.2 核心表的DDL设计要点

先说用户表。密码字段我建议存MD5、BCrypt或SHA-256的哈希值——毕业设计项目里你可以简单点用MD5加盐，但如果想体现工程素养，用BCrypt更专业。需要说明的是这篇文章里我会重点讲系统性实现的逻辑，具体加密代码网上有大量成熟工具类可以参考。

创建基础用户表参考以下结构：

sql复制CREATE TABLE `user` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `username` varchar(50) NOT NULL COMMENT '登录账号',
  `password` varchar(255) NOT NULL COMMENT '密码（加密存储）',
  `real_name` varchar(50) DEFAULT NULL COMMENT '真实姓名',
  `phone` varchar(20) DEFAULT NULL COMMENT '手机号',
  `avatar` varchar(255) DEFAULT NULL COMMENT '头像URL',
  `role` tinyint(4) NOT NULL DEFAULT '1' COMMENT '角色：1学生，2商家，3配送员，4管理员',
  `status` tinyint(4) NOT NULL DEFAULT '1' COMMENT '状态：1正常，0禁用',
  `school` varchar(100) DEFAULT NULL COMMENT '所属学校',
  `user_no` varchar(50) DEFAULT NULL COMMENT '学号/工号',
  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_username` (`username`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='用户表';

订单表是另一个重点，它承载了业务中最核心的数据流。订单表的状态字段建议用整数存储而不是字符串，方便状态机的流转控制：

sql复制CREATE TABLE `orders` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `order_no` varchar(32) NOT NULL COMMENT '订单编号',
  `user_id` bigint(20) NOT NULL COMMENT '下单用户ID',
  `shop_id` bigint(20) NOT NULL COMMENT '店铺ID',
  `total_amount` decimal(10,2) NOT NULL COMMENT '订单总金额',
  `pay_amount` decimal(10,2) NOT NULL COMMENT '实付金额',
  `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '订单状态：0待支付，1已支付待接单，2已接单待配送，3配送中，4已完成，5已取消',
  `address` varchar(255) NOT NULL COMMENT '收货地址',
  `receiver_name` varchar(50) NOT NULL COMMENT '收货人',
  `receiver_phone` varchar(20) NOT NULL COMMENT '收货人电话',
  `remark` varchar(255) DEFAULT NULL COMMENT '备注',
  `pay_time` datetime DEFAULT NULL COMMENT '支付时间',
  `delivery_time` datetime DEFAULT NULL COMMENT '送达时间',
  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_order_no` (`order_no`),
  KEY `idx_user_id` (`user_id`),
  KEY `idx_shop_id` (`shop_id`),
  KEY `idx_status` (`status`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='订单表';

建索引的时候要替未来的查询语句着想。学生端高频查询是“查我的订单”，所以user_id必须有索引；商家端高频查询是“查我店铺的待处理订单”，所以shop_id和status的组合索引价值很大。这一步如果没做，数据量一旦上来，慢查询就会拖垮整个系统体验。

3.3 订单状态机的设计思维

外卖订单最核心的流转逻辑是状态机模型。学生在设计状态时很容易犯的错是想到哪加到哪，最后出现逻辑漏洞或状态死锁。我的建议是先画一张状态流转图：

待支付 -> 已支付待接单 -> 已接单待配送 -> 配送中 -> 已完成，这是正常链路。分支路径包括：待支付超时自动取消、商家接单前用户取消、配送中异常取消需平台介入。每个状态之间的跳转必须由特定角色触发特定行为，后端接口层面要做判断——用户不能把订单从“配送中”直接改成“已完成”，这个动作的权限只属于配送员。

用整数值定义状态，配合一个状态机工具类来管理，比用字符串散落在业务代码里要优雅得多。代码层面可以用策略模式实现，每个状态下放对应可执行的操作，不合法操作直接被拦截。这样写出来的业务逻辑很难出漏洞。

4. 后端核心模块实现与接口设计

4.1 项目目录结构与分层规范

后端项目我推荐按照下面这种结构来组织，它遵循了经典的分层架构：

code复制com.campus.order
├── common          // 通用类：统一返回结果、全局异常处理、工具类
├── config          // 配置类：MyBatis配置、拦截器注册、跨域配置
├── controller      // 控制层：接收前端请求，返回数据
├── service         // 业务层：业务逻辑处理
│   └── impl        // 业务实现类
├── mapper          // 数据访问层：MyBatis的Mapper接口
├── entity          // 实体类：对应数据库表的结构
├── dto             // 数据传输对象：接收前端参数
├── vo              // 视图对象：返回给前端的数据
└── utils           // 工具类：JWT生成解析、文件上传等

这种分层的核心思想是“单向依赖”。Controller层只依赖Service层，Service层只依赖Mapper层。这样做的直接好处是代码可测试、可替换，出了问题能快速定位在哪一层。不少学生喜欢把业务逻辑直接写在Controller里，图省事，但一旦项目规模变大，维护起来简直是噩梦。

Controller里应该只做三件事：接收参数、调用Service、返回结果。参数校验放在大门口做，业务规则在Service层做。

4.2 统一返回结果与全局异常处理

一个好的后端接口设计，一定要有统一的数据格式。前端对接接口的时候，最忌讳的就是每个接口返回结构都不一样。我常用的统一返回结构是这样的：

json复制{
  "code": 200,
  "message": "success",
  "data": {
    "token": "xxx.xxx.xxx",
    "userInfo": { "id": 1, "username": "student01" }
  }
}

code为200表示业务成功，非200表示业务失败；message是提示信息；data是实际载荷数据。配合一个全局异常处理器，统一把业务异常、参数校验异常、系统异常转换成这个格式，前端的每个请求处理逻辑就会非常简洁——先判断code是不是200，是的话处理data，不是的话弹出message。

4.3 登录认证与JWT实践

毕业设计做登录功能，直接上Spring Security的话配置成本偏高。我实际测试过，用拦截器+JWT来管理用户认证是一个轻盈且清晰的方案。JWT令牌分成三部分：Header、Payload、Signature。服务端用私钥或密钥对前两段签名，客户端无法篡改数据内容。我通常把用户ID、用户名、角色这些必要信息放进JWT的claims里，后端接口从令牌里解析出用户身份，无需查询数据库。

JWT实现认证的具体逻辑分成三步：

1. 用户提交用户名密码，后端校验后生成token并返回
2. 前端把token存在localStorage或Vuex里，每次请求在axios拦截器中加进header
3. 后端写一个拦截器拦截所有需要登录的路径，校验token的合法性，解析出用户信息放入请求上下文

对于角色鉴权，还可以在拦截器里加上权限判断。比如/admin开头的接口只允许管理员访问，/seller开头的接口只允许商家访问。这样简单的路径匹配模式，在实际项目中完全够用。

4.4 下单接口的逻辑边界

下单接口是整个系统里逻辑最密集的接口，牵涉的数据表有好几张。我从开发过类似系统的经验出发，说一下具体流程设计建议：

1. 前端把购物车里的商品列表、收货地址ID、优惠券ID、备注一起提交给后端
2. 后端校验用户登录状态和地址归属，然后遍历商品列表：校验商品是否属于同一店铺、商品是否在售、库存是否充足
3. 计算订单总金额，根据优惠券信息算出实付金额，生成唯一的订单号和订单记录
4. 批量扣减库存，把购物车对应的商品清空
5. 返回订单号给前端，前端携带订单号跳转支付

这里最关键的“为什么”：为什么不把价格计算交给前端？因为前端的数据是能被用户篡改的。假设一个用户把商品单价改成0.01元提交到后端，后端不校验的话，系统就亏大了。所以所有涉及金额、库存的操作都必须以服务端数据库里的数据为准。前端传过来的数量可以作为参考，但单价和总价必须后端自己算。

下单过程要用@Transactional保证原子性：如果扣库存成功但生成订单失败，事务回滚，库存也要恢复原样，绝不能出现数据不一致的情况。

4.5 并发场景下的超卖问题

校园外卖在午高峰时段，同一家店的热门菜品可能同时被多个人下单。如果库存扣减逻辑是“先查询库存够不够，再执行update语句减库存”，在高并发下会出问题：两个请求同时查到库存还有2份，各自执行库存减1，实际上最后只剩0份，库存就被扣超了。

正确做法是使用乐观锁或者原子性更新。只用一条SQL解决判断+更新：

sql复制UPDATE product SET stock = stock - 1 
WHERE id = #{productId} AND stock > 0;

这条语句由数据库保证了原子性：如果更新影响行数为0，说明库存不足或商品已被下架，后端返回“库存不足”的提示。执行601次并发请求，只有库存量那么多次能成功，不多不少。

注意：如果你的项目里涉及支付环节的幂等性设计，一定要处理好订单状态为“已支付但未回调”的边界情况，防止用户重复支付或系统重复发单。

作为毕业设计，你在论文里如果能把这类并发场景的解决方案写进去，会算作一个不错的性能优化加分项。

5. 前端实现与交互层解析

5.1 前端项目结构设计

前端部分我推荐基于Vue Cli或Vite脚手架来创建项目。一个清晰的前端目录结构大概是这样：

code复制src
├── api             // 接口请求封装，按模块划分：user.js, order.js, shop.js
├── assets          // 静态资源：图片、样式
├── components      // 公共组件：轮播图、商品卡片、购物车面板等
├── router          // 路由配置：前端路由表，含路由守卫
├── store           // 状态管理：Vuex或Pinia
├── views           // 页面视图
│   ├── home        // 首页：店铺列表、商品分类导航
│   ├── user        // 用户中心：个人信息、地址管理、订单列表
│   ├── seller      // 商家端：店铺管理、商品管理、订单处理
│   └── admin       // 管理端：用户管理、数据统计
├── App.vue
└── main.js

接口请求模块按业务域拆分，避免所有请求都堆在一个文件里。每个API模块封装对应的请求方法，例如：

javascript复制// api/order.js
import request from '@/utils/request'

export function createOrder(data) {
  return request({
    url: '/api/order/create',
    method: 'post',
    data
  })
}

export function getOrderList(params) {
  return request({
    url: '/api/order/list',
    method: 'get',
    params
  })
}

5.2 路由守卫与前端权限控制

前端路由要做一层防线，虽然真正的安全校验在后端，但前端做路由守卫是为了更好的用户体验：用户没登录访问需要登录的页面时，直接踢回登录页。

javascript复制router.beforeEach((to, from, next) => {
  const token = localStorage.getItem('token')
  const userRole = localStorage.getItem('role')

  if (to.meta.requiresAuth && !token) {
    next({ path: '/login', query: { redirect: to.fullPath } })
    return
  }

  if (to.meta.role && to.meta.role !== userRole) {
    next({ path: '/403' })
    return
  }

  next()
})

这里在meta里可以为每个路由声明需要的角色，比如商家后台的页面meta.role为'2'。前端的权限控制虽然可以做到菜单显示层面，但真正的数据权限还是以后端接口控制为准。

5.3 购物车与订单确认页的数据联动

购物车模块的前端设计里，最容易出现的问题是本地购物车数据和服务端数据不同步。我的建议是：可以让购物车数据存在本地（localStorage或Vuex），但在用户点击“去结算”进入订单确认页时，一定让后端根据商品ID实时计算价格和库存。

这么设计的道理很清楚：购物车里的商品可能已经下架、价格可能已经变动、库存可能已经不足。订单确认页必须回显后端实时计算的结果，让用户看到最新的总数，避免下单时才发现价格对不上。

前端还有一个高频需求是“倒计时关单”——很多外卖平台都会在订单支付页面做一个倒计时显示。这个倒计时的时长应该由后端配置并返回，前端根据截止时间做本地倒计时，超时后请求后端确认订单状态是否已自动取消。前端定时器要清理干净，否则组件切走之后定时器还在跑，控制台会报错。

5.4 商家端与用户端的UI区分

一个校园外卖系统，C端和B端的界面设计逻辑是迥异的。

用户端（学生视角）的核心目标是“快速下单”：首页店铺列表按距离或销量排序，分类导航清晰，商品列表带图片、价格、销量、月售，加购按钮显眼。界面追求简洁明快，字体偏大，主色调暖色系更容易激发食欲。可以用一些卡片式布局和毛玻璃效果增强年轻感。

商家端（商家视角）的核心目标是“高效处理”：店铺信息编辑表单、菜品批量上架、订单列表按状态分组（待接单、待配送、已完成），操作按钮明确（接单、出餐、完成），颜色风格偏商务、克制。

很多学生做毕业设计，觉得功能实现完就行了，界面不用太讲究。我的经验是：一套整洁的前端界面，在答辩演示时能明显提升老师的第一印象。没必要用到很高级的动效，关键是信息层级清楚、按钮语义明确、无明显的布局错乱。

6. 部署流程与踩坑记录

6.1 本地开发环境准备清单

先把环境列清楚，避免装到一半发现版本不兼容：

JDK版本上，我建议直接用8或11。新版本的JDK虽然特性多、性能好，但毕业设计阶段没必要为了省那点内存去折腾兼容性问题。有些服务器上的MySQL是5.7的，JDK 8连MySQL 8.0的连接驱动在5.7下也就加个参数的事，问题不大。

6.2 打包构建与启动实操

先打包后端，项目根目录执行：

bash复制mvn clean package -DskipTests

在target目录下会生成一个可执行的jar包，比如campus-order-0.0.1-SNAPSHOT.jar。然后启动：

bash复制java -jar target/campus-order-0.0.1-SNAPSHOT.jar --spring.profiles.active=prod

这里加了一个spring.profiles.active=prod参数，意思是激活prod配置文件。我习惯在application.yml里按环境拆分配置，本地开发用application-dev.yml连本地数据库，部署上线用application-prod.yml连云服务器数据库。这样写的好处是显而易见的：本地开发和线上环境切换不需要改代码，只需要改启动参数。

前端打包更简单：

bash复制npm run build

打包完成后dist目录里就是纯静态文件，可以有以下两种部署方式：

• 方式一：把dist目录里的文件放到Nginx里做静态托管，Nginx配置反向代理把/api开头的请求转发到SpringBoot服务
• 方式二：直接把dist目录里的文件放到SpringBoot的静态资源目录里，Java服务同时提供前后端资源（这种方式更快，但不适合前后端分离的正式发布）

推荐方式一。Nginx的反向代理配置大概是：

nginx复制server {
    listen 80;
    server_name yourdomain.com;

    root /var/www/dist;
    index index.html;

    location / {
        try_files $uri $uri/ /index.html;
    }

    location /api/ {
        proxy_pass http://localhost:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

注意try_files这一行：前端路由是history模式时，刷新页面路径可能不匹配服务器上的真实文件，必须回退到index.html让前端路由接管。

6.3 部署时的常见报错与处理

以下是我自己踩过以及帮学生排查过的经典故障，整理成了表格：

时效性问题不用太担心，遇到具体报错直接复制关键信息搜索是目前最高效的方案，多数报错都能找到现成记录。

6.4 云服务器部署的关键检查点

如果你打算把系统部署到云服务器上，注意几个关键检查点，这是整个部署流程里最重要的经验总结：

• 云服务器的安全组规则：一定放行80端口（HTTP）、8080端口（后端）。我当时配了安全组只允许80端口通过，结果后端8080端口访问不了，排查了很久才发现是安全组的锅
• MySQL绑定地址：云上MySQL默认可能只绑定了127.0.0.1，要改成0.0.0.0或者在服务器上用命令行连接。本地连远程数据库要注意数据源配置里别写错地址
• 防火墙：systemctl stop firewalld是很多人在服务器上做的事，其实允许对应端口更稳妥
• 上传目录读写权限：如果是用了本地上传图片功能，注意tomcat或SpringBoot运行用户对上传目录的写权限。没权限时上传报错，报错信息可能很隐晦，别在这个坑上浪费时间

说句实在话，部署环节在整个毕业设计里的权重并不低。能把整套系统跑在云端、能用手机浏览器正常访问，这份“真实感”比任何文档都更能打动答辩老师。

7. 常见问题与排查技巧实录

7.1 登录接口报401的排查过程

曾经帮一位同学排查过一个经典问题：前端能正常请求登录接口，但登录成功后跳转首页再刷新，就报401无权限。排查思路是：先看后端日志，确认请求有没有到Controller；再检查前端请求头，看token有没有正确传递；最后查后端拦截器对token的校验逻辑。

最后定位在token有效期设置太短。他设置的是30分钟过期，用户在开发过程中经常超过这个时间，重新刷新页面时token已失效。解决办法很简单：把token有效期改到7天。另外一个容易被忽略的地方是，拦截器在放行OPTIONS预检请求时要直接返回，否则浏览器的跨域预检会失败。

7.2 图片上传成功但页面不显示

这是一个比较高频的问题。检查思路比较直接：先确认图片是不是真的传到了服务器磁盘或云存储；再看前端img标签的src地址是相对路径还是完整路径；最后确认后端是否配置了静态资源映射。

SpringBoot默认映射的静态资源目录是/static、/public等，如果你把上传的图片存在了项目运行目录的/upload目录下，需要在配置类里加一个资源映射器，把/upload/开头的请求映射到对应磁盘路径。这个映射配置很简单，但很多同学的图片问题就死在“后端明明返回了路径，前端就是加载不出来”这一步。

7.3 数据库中文乱码的彻底解决

MySQL中文乱码是老生常谈的问题，最直接的解法是：建库时指定字符集CREATE DATABASE xxx DEFAULT CHARACTER SET utf8mb4;，表也使用utf8mb4。连接串要加characterEncoding=utf8参数。这种情况下，服务器上看到的字符是完整的。

还有一点容易被忽略：如果你是从Windows本地导出SQL再导入Linux服务器，文件编码格式的不同也可能导致乱码，用Notepad++或VS Code把文件转成UTF-8无BOM格式再导入。

7.4 前端控制台常见的Vue相关报错

Vue项目中控制台报错最多的是这么几类：

• Cannot read property 'xxx' of undefined：通常在接口返回数据还没到达时，模板渲染就尝试访问了某个不存在对象的属性。解决方案是v-if判断数据是否已加载，或者用{{ data?.name }}可选链语法兜底
• Computed property "xxx" was assigned to but it has no setter：给计算属性赋值导致的，计算属性默认只有getter。改成data或者在computed里加setter函数
• [Vue Router warn]: No match found for location with path "/xxx"：找不到对应的路由，检查路由表有没有定义该路径或者路径拼写是否有误

8. 论文撰写与答辩准备思路

8.1 论文结构建议

论文结构一般遵循学校给的模板，但核心内容上我建议按这样的逻辑组织：

• 第一章绪论：写校园外卖的背景、意义、国内外现状、主要工作内容。现状部分要引用几篇文献，不要全靠自己瞎编
• 第二章相关技术介绍：讲清楚SpringBoot、Vue、MySQL这些技术是什么、为什么选他们。这部分不用写太深，点到为止就行
• 第三章系统分析：需求分析（功能性需求和非功能性需求）、可行性分析（技术可行性、经济可行性、操作可行性）、用例分析
• 第四章系统设计：总体架构设计、功能模块设计、数据库设计（ER图、主要数据表结构）、接口设计
• 第五章系统实现：每个核心功能模块的截图+关键代码片段+简单说明。前后端关键代码贴出来
• 第六章系统测试：测试环境、功能测试用例表格（测试项、输入、预期结果、实际结果）、性能测试简况
• 第七章总结：主要工作贡献、不足、改进方向。

核心原则是：系统设计图的完整度和数据库设计的规范性，最能影响判卷老师的第一印象。界面截图要真实、运行数据要真实，不要用拼凑的假数据。

8.2 答辩演示重点

答辩演示时间往往限定在10到15分钟。时间很短，你完整演示一遍流程都够呛。我建议把演示脚本精心设计成一条最流畅的闭环路径：

1. 注册并登录一个学生账号
2. 浏览首页店铺，选择一家店，往购物车加几个商品
3. 去结算，选地址，提交订单
4. 模拟支付（可以选一个演示环境的mock支付）
5. 切换商家账号，看到新订单，点击接单
6. 切换配送员账号，接单配送，更新配送状态
7. 切回学生账号，看到订单已完成，进行评价

这个闭环涵盖了系统最核心的几条业务链路，展示了所有角色，每个动作在页面上都有可见反馈，不说废话，一气呵成。如果时间充裕，可以补一个管理员登录的演示，体现平台监管能力。

8.3 容易被问到的答辩问题

根据经验，答辩老师常问的问题集中在这么几个方向：

• “这个系统的架构为什么要这样分层？”——答：分层是为了降低耦合度、提高复用性和可维护性，展示你对工程实践的理解
• “订单并发场景你是怎么处理的？”——答：原子性SQL减库存+事务控制，展开讲乐观锁与悲观锁的区别
• “如果不使用前端框架，你还能实现这些功能吗？”——答：可以，但开发效率低、代码维护难，Vue的组件化、响应式绑定提升了开发体验
• “项目里遇到的最大困难是什么？怎么解决的？”——这里注意，实话实说但别暴露自己能力短板。我当时回答的是在并发测试时发现超卖问题，通过分析锁机制和事务边界解决了，这个回答既真实又体现了解决问题的能力
• “哪些地方还可以改进？”——答：引入Redis缓存、增加消息队列削峰、完善数据分析模块

9. 实际项目经验分享

9.1 做好代码备份与版本管理

我见过太多学生只在本地电脑存了一份代码，结果硬盘坏了、文件夹误删、电脑重装系统，好几周的成果说没就没。这种事故在毕业季频繁发生。

在项目初期就应该用Git做版本管理，不要求你掌握多复杂的分支模型，最基本的操作就够用：git init初始化仓库，每次完成一个小功能后git add+git commit -m "描述信息"，然后推送到一个远端仓库。GitHub和Gitee都可以建私人仓库，代码免费托管。关键节点再打一个tag，比如v1.0、v2.0。这个习惯的好处，等到改崩了想回滚版本的时候就体会到了。

9.2 控制编码式开发的时间范围

有些同学喜欢先把所有代码写完，再统一调试。这个做法是有风险的：一口气写完几千行代码，最后报错的时候，你根本不知道错误是刚写的这部分引入的，还是更早的某一行埋下的雷。

我在实际动手时有一个习惯：每完成一个功能模块，立刻启动应用自测一遍，走通后再进入下一个模块。比如写完用户模块的注册登录，就马上启动前后端联调验证，确认没毛病了再开始写商品模块。这种迭代式开发虽然看起来比“闷头写大项目”慢，但实际上能避免后期大规模返工，总耗时反而是更短的。

9.3 善用日志定位问题

后端写代码的时候一定不要吝啬log.info和log.error。特别是订单流程这种多表联动的逻辑，每个阶段打一条日志，出问题的时候看日志就能快速定位是哪一步断了。千万不要什么都用System.out.println打印。SpringBoot自带Logback，配置一下就可以区分控制台输出和文件输出，日志文件保留30天的滚动记录。

前端也一样，关键的接口请求在network面板多看一眼，返回值是不是预期结构，请求头带了哪些参数，这些信息比反复刷新页面瞎猜有效得多。

9.4 测试数据的艺术

做毕业设计系统，你提交给导师看的时候，系统里如果全是“商品1”“商品2”“用户A”“用户B”这种数据，观感是很差的。一定要花一点时间造一批真实感强的数据。

我当时做演示系统，模拟了十多所高校周边的商铺：店铺名用的是一些会让评委有代入感的店名，主打菜品配了价格和月售数量，用户头像和菜品图片特意找了一些无版权图片，订单数据也生成了近一个月的完整记录。演示的时候切到订单列表，整屏数据整整齐齐，瞬间感觉系统“活”了起来。测试数据还可以作为论文第六章测试环节里的数据基础。

9.5 给你的时间规划建议

毕业设计拉扯几个月是很正常的，但有效时间其实不需要那么多。我建议如此规划节奏：第一个月完成选题、技术预研、需求分析、数据库设计；第二个月完成前端页面和后端核心接口的开发；第三个月整体联调、修复Bug、部署上线、开始写论文；最后留出一个月专心写论文、做PPT、准备答辩稿。真正写论文的过程，如果前期设计和编码过程有详实的记录，速度不会慢，因为很多素材可以直接从开发过程里整理出来。

写代码和写论文穿插着进行是更优的策略：每完成一个模块，就在论文里把对应的章节初稿写上，代码和文档同步更新，避免最后突击赶文。突击赶出来的论文，文字质量和逻辑结构大概率是经不起推敲的。

你把这个项目当成一次完整的工程实践来做，做完以后，你对SpringBoot自动装配原理的理解、对Vue组件通信的掌握、对MySQL事务与索引的认知、对前后端联调与部署的熟悉程度，都会上一个台阶。这套技术栈和“管理后台+用户端”的系统形态，在真实企业项目里也是被反复验证过的经典组合，你毕业之后找工作，写到简历上的项目经验大概率就是这类东西。希望这份拆解能帮你在做毕业设计的时候少走几步弯路，一次通过。