基于Spring Boot的校园食堂订餐系统设计与实现：从毕业设计到二次开发

简介这份资源是面向计算机专业学生与Java Web开发学习者的毕业设计完整文档聚焦疫情背景下校园食堂就餐拥挤、外卖不健康、点餐不便等现实痛点给出了一套可落地的订餐系统设计方案。文档围绕Spring Boot轻量框架与B/S架构展开前台采用可跨Android、iOS、H5及小程序的uni-app后台结合MySQL存储完整覆盖手机端选菜、订单提交与限时修改撤销、一卡通在线支付、菜品销售统计等核心模块并附系统测试与调试过程。资源包共1个doc文件约3.32MB内容为论文全文含中英文摘要、系统总体设计、功能实现与总结展望结构完整、论述详实。目前已有9268人学习下载适合需要参考选题思路、功能模块划分、技术选型论证与论文写作框架的读者可据此快速梳理毕设脉络、对照实现要点并查漏补缺。1. 从一份毕业设计文档说起校园食堂订餐系统到底解决了什么问题每年毕业季后台总有人问我要一份能跑起来的 Spring Boot 项目参考。这次拆的是一份完整的毕业设计文档——《基于 Spring Boot 的校园食堂订餐系统的设计与实现》。它不是那种只停留在需求分析层面的空壳论文而是把需求、架构、数据库、核心模块代码、测试用例都写全了的一套落地材料。系统面向校园场景学生用手机端选菜下单商家在后台维护菜品、处理订单、看销售统计管理员管餐厅和商家。技术栈是 Spring Boot uni-app MySQLB/S 架构前后端分离。如果你正在找一个结构完整、业务闭环清晰、适合二次开发的 Java 全栈练手项目这份文档值得认真读一遍。2. 技术选型与整体架构为什么是 Spring Boot 加 uni-app 这套组合2.1 后端为什么选 Spring Boot 而不是传统 SSM文档里明确写了后台使用 Spring Boot 新型轻量开发框架这在毕业设计里是个很务实的选择。传统 SSM 要配一堆 XML光是把 MyBatis、Spring MVC、数据源、事务管理器串起来就得折腾半天对刚上手的学生来说心智负担太重。Spring Boot 的自动装配把大部分约定俗成的配置都收走了一个application.yml加几个 starter 依赖就能把 Web 层、持久层、事务跑起来。从项目实际需要看这个系统的后端职责很清晰接收前端请求、校验参数、操作数据库、返回统一格式的 JSON。没有复杂的分布式事务没有高并发削峰Spring Boot 的内嵌 Tomcat 加默认连接池完全够用。文档里提到的公共模块类——连接数据库、分页显示、返回信息格式、表格工具类——本质上就是 Spring Boot 项目里最常见的几个基础设施封装后面第 4 章会逐个拆。2.2 前端为什么用 uni-app 而不是纯 Vue这里有个容易被忽略的细节文档摘要里写的是“前台技术使用可跨 Android、IOS、H5、小程序的 uni-app 进行开发”但关键词和正文里又反复出现 vue.js。这两者不矛盾——uni-app 本身就是基于 Vue 语法的跨端框架写一套代码可以编译到多个平台。对校园订餐场景来说学生不一定都装 AppH5 和小程序才是触达成本最低的入口uni-app 正好覆盖这个需求。如果换成纯 Vue 做 Web 端学生得打开浏览器输网址体验上差一截如果做原生 App开发和维护成本又太高。uni-app 在这个项目里是个性价比很高的折中。实际开发时页面用 Vue 的模板语法写调用后端接口用uni.request条件编译处理各端差异。2.3 B/S 架构下的角色划分系统采用基本 B/S 互联网架构角色分三类学生/教职工、商家、食堂管理员。学生端是移动端订餐入口商家端和管理员端是后台管理界面。文档第 2 章的功能需求把权限边界划得很清楚角色核心功能对应模块学生/教职工浏览菜品、下单、支付、查订单、取消订单用户订餐、我的订单商家菜品增删改查、发布菜单、订单处理、销售统计菜品管理、订单管理、菜品统计食堂管理员新增/删除商家、查看商家详情餐厅管理这种三角色划分在数据库设计上会体现为用户表加角色字段登录后根据角色跳不同首页。后面讲登录模块时会看到具体的拦截逻辑。2.4 开发运行环境清单文档第 2 章给了明确的软硬件环境照着配基本不会翻车项目要求操作系统Windows 10Web 服务Tomcat 7.0Spring Boot 内嵌可替代数据库MySQL 8.0后端 IDEIntelliJ IDEA 2019.3.1 x64前端 IDEWebStorm 2020.1 x64CPU1.6G 主频 4 核内存4G 及以上磁盘最低 1TB提示文档写的是 Tomcat 7.0 外置部署但 Spring Boot 项目通常用内嵌 Tomcat 直接java -jar启动实际搭建时不必单独装 Tomcat把打好的 jar 跑起来即可。MySQL 8.0 要注意驱动版本和连接串里的时区参数这是新手最容易卡住的地方。3. 数据库与模块设计从 E-R 图到五张核心表的落地3.1 数据库设计原则与 E-R 图分析文档第 3 章明确了几条数据库设计原则归纳起来就是表结构要贴合业务实体、字段类型要精确、主外键关系要清晰、避免冗余存储。系统涉及的实体主要有用户学生/教职工、商家、餐厅、菜品、订单、订单明细。E-R 图里能看出几个关键关系一个餐厅下有多个商家一个商家维护多个菜品一个用户可以有多个订单一个订单包含多条菜品明细。这种一对多和多对多的关系落到表设计上就是菜品表带商家 ID 外键订单表带用户 ID 外键订单明细表同时带订单 ID 和菜品 ID。订单明细表是典型的中间表用来解决订单和菜品之间的多对多关系同时记录下单时的菜品快照单价、数量避免菜品后续改价影响历史订单。3.2 核心数据表结构根据文档第 3.3.3 节“数据表的创建”和功能模块描述可以还原出几张核心表的结构。下面用建表语句的形式给出字段名按常见命名习惯补全实际以文档原表为准-- 用户表学生、教职工、商家、管理员共用用 role 区分 CREATE TABLE sys_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE COMMENT 登录账号, password VARCHAR(100) NOT NULL COMMENT 加密后的密码, real_name VARCHAR(50) COMMENT 真实姓名, role TINYINT NOT NULL COMMENT 1学生 2教职工 3商家 4管理员, card_no VARCHAR(30) COMMENT 一卡通卡号, phone VARCHAR(20), create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 餐厅表管理员维护 CREATE TABLE restaurant ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) NOT NULL COMMENT 餐厅名称, location VARCHAR(200) COMMENT 位置描述, status TINYINT DEFAULT 1 COMMENT 1营业 0停业 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 菜品表商家维护关联餐厅 CREATE TABLE dish ( id BIGINT PRIMARY KEY AUTO_INCREMENT, restaurant_id BIGINT NOT NULL COMMENT 所属餐厅, name VARCHAR(100) NOT NULL COMMENT 菜品名称, price DECIMAL(10,2) NOT NULL COMMENT 单价, stock INT DEFAULT 0 COMMENT 供应量, material VARCHAR(200) COMMENT 原材料, image_url VARCHAR(255) COMMENT 图片地址, status TINYINT DEFAULT 1 COMMENT 1上架 0下架, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_restaurant (restaurant_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 订单表记录订单主信息 CREATE TABLE orders ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL UNIQUE COMMENT 订单号, user_id BIGINT NOT NULL COMMENT 下单用户, restaurant_id BIGINT NOT NULL COMMENT 所属餐厅, total_amount DECIMAL(10,2) NOT NULL COMMENT 订单总额, status TINYINT DEFAULT 0 COMMENT 0待支付 1已支付 2已完成 3已取消, pay_time DATETIME COMMENT 支付时间, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_user (user_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 订单明细表记录每笔订单的菜品快照 CREATE TABLE order_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id BIGINT NOT NULL COMMENT 订单ID, dish_id BIGINT NOT NULL COMMENT 菜品ID, dish_name VARCHAR(100) COMMENT 下单时菜品名快照, price DECIMAL(10,2) COMMENT 下单时单价快照, quantity INT NOT NULL COMMENT 数量, KEY idx_order (order_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这段建表语句有几个设计点值得说。第一用户表用role字段区分四种身份而不是拆成四张表好处是登录逻辑统一坏处是角色专属字段比如一卡通卡号会稀疏存储对这个规模的项目来说可以接受。第二订单明细表冗余了dish_name和price这是有意为之——菜品改价或下架后历史订单展示的仍是下单时的信息这是订单类系统的通用做法。第三订单表加了order_no唯一索引对外暴露订单号而不是自增 ID避免被遍历。3.3 功能模块划分与数据流文档第 3.4 节把系统功能模块拆成五块食堂管理、菜品管理、食堂订餐管理、菜品统计管理、系统管理。对应到代码结构上后端一般按 controller、service、mapper 三层组织每个模块一组类。数据流图上能看到两条主链路一条是学生端“浏览菜品 → 加购 → 提交订单 → 支付 → 查看订单”另一条是商家端“维护菜品 → 接收订单 → 更新状态 → 统计销售”。这两条链路在数据库层面是交汇的学生下单写orders和order_item商家处理订单读同一批表并更新status统计模块则对order_item按dish_id聚合求和。理解了这个交汇点后面看订单管理和统计模块的代码就不会迷路。4. 核心模块代码拆解公共类、登录、订单与统计的实现细节4.1 公共模块类统一返回格式与分页封装文档第 4.1 节列了四个公共模块类连接数据库、分页显示、返回信息格式、表格工具类。其中“返回信息格式”是整个前后端协作的契约最值得先看。常见做法是定义一个泛型结果类包含状态码、提示信息、数据体public class ResultT { private Integer code; // 200成功500失败401未登录 private String message; // 提示信息 private T data; // 业务数据 public static T ResultT success(T data) { ResultT r new Result(); r.setCode(200); r.setMessage(操作成功); r.setData(data); return r; } public static T ResultT fail(String message) { ResultT r new Result(); r.setCode(500); r.setMessage(message); return r; } // getter/setter 省略 }这个类的价值在于把“成功/失败”的判断标准化。前端拿到响应后先看code200 才取data渲染否则弹message。如果没有这层封装每个接口返回结构都不一样前端得写一堆兼容逻辑维护起来很痛苦。分页封装通常配合 MyBatis 的分页插件使用Service 层接收pageNum和pageSize两个参数返回一个包含total总条数和list当前页数据的对象。文档里“分页显示”被单独列为一个公共类说明作者把它做成了可复用的工具菜品列表、订单列表、统计列表都走同一套分页逻辑。4.2 登录模块角色区分与拦截器登录是文档第 4.2 节的重点。这个系统的登录不只是校验账号密码还要根据角色决定跳转和权限。核心逻辑分两步先查用户再比对密码最后把用户信息写入 Session 或返回 Token。PostMapping(/login) public ResultUserVO login(RequestBody LoginDTO dto, HttpSession session) { // 1. 按用户名查用户 User user userService.getByUsername(dto.getUsername()); if (user null) { return Result.fail(账号不存在); } // 2. 密码比对实际项目用 BCrypt 等加密这里示意 if (!passwordEncoder.matches(dto.getPassword(), user.getPassword())) { return Result.fail(密码错误); } // 3. 写入会话供拦截器校验 session.setAttribute(loginUser, user); // 4. 返回脱敏后的用户信息含角色 UserVO vo new UserVO(); vo.setId(user.getId()); vo.setRealName(user.getRealName()); vo.setRole(user.getRole()); return Result.success(vo); }参数说明LoginDTO承载前端传来的用户名和密码HttpSession用来存登录态后续请求靠拦截器从 Session 里取loginUser判断是否登录。UserVO是视图对象故意不带密码字段避免敏感信息泄露。配套的拦截器大致长这样public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest req, HttpServletResponse resp, Object handler) { Object user req.getSession().getAttribute(loginUser); if (user null) { // 未登录返回 401前端跳登录页 resp.setStatus(401); return false; } return true; } }这里有个容易踩的坑拦截器要排除登录接口和静态资源否则登录请求本身会被拦下来形成死循环。配置类里用excludePathPatterns(/login, /static/**)处理。4.3 订单管理下单、改单与状态流转订单模块是文档第 4.3.3 节的内容也是整个系统业务最重的地方。学生下单时要做三件事校验菜品库存、生成订单主记录、写入订单明细。这三步必须在一个事务里完成否则可能出现订单生成了但明细没写进去的脏数据。Transactional(rollbackFor Exception.class) public String createOrder(Long userId, ListOrderItemDTO items) { // 1. 计算总价并校验库存 BigDecimal total BigDecimal.ZERO; for (OrderItemDTO item : items) { Dish dish dishMapper.selectById(item.getDishId()); if (dish null || dish.getStatus() 0) { throw new BizException(菜品已下架 item.getDishId()); } if (dish.getStock() item.getQuantity()) { throw new BizException(库存不足 dish.getName()); } total total.add(dish.getPrice().multiply(new BigDecimal(item.getQuantity()))); } // 2. 生成订单主记录 Orders order new Orders(); order.setOrderNo(generateOrderNo()); // 时间戳随机数 order.setUserId(userId); order.setTotalAmount(total); order.setStatus(0); // 待支付 orderMapper.insert(order); // 3. 写入明细并扣减库存 for (OrderItemDTO item : items) { Dish dish dishMapper.selectById(item.getDishId()); OrderItem oi new OrderItem(); oi.setOrderId(order.getId()); oi.setDishId(dish.getId()); oi.setDishName(dish.getName()); // 快照 oi.setPrice(dish.getPrice()); // 快照 oi.setQuantity(item.getQuantity()); orderItemMapper.insert(oi); dishMapper.decreaseStock(dish.getId(), item.getQuantity()); } return order.getOrderNo(); }逻辑说明Transactional保证三步要么全成功要么全回滚库存校验放在循环里逐条做虽然效率不是最优但对校园食堂这种单笔订单菜品数量有限的场景完全够用generateOrderNo()用时间戳加随机数生成唯一订单号比直接用自增 ID 安全。改单和撤单的逻辑类似核心是判断订单状态——只有“待支付”状态才允许修改或取消已支付的订单要走退款流程文档里提到“一定时间范围修改和撤销订单”实际实现就是在 Service 层加一个时间窗口判断。4.4 菜品统计按菜品聚合销售数据统计模块是商家最关心的功能文档第 4.3.4 节描述的功能是“查询菜品统计列表信息和导出菜品统计列表信息”。实现上就是对订单明细表按菜品分组求和再关联菜品和订单表过滤时间范围SELECT oi.dish_id, oi.dish_name, SUM(oi.quantity) AS total_qty, SUM(oi.price * oi.quantity) AS total_amount FROM order_item oi JOIN orders o ON oi.order_id o.id WHERE o.status IN (1, 2) -- 只统计已支付和已完成 AND o.create_time BETWEEN #{start} AND #{end} GROUP BY oi.dish_id, oi.dish_name ORDER BY total_qty DESC;这条 SQL 的关键在WHERE条件只统计已支付和已完成的订单待支付和已取消的不算销售额否则统计结果会虚高。按dish_id和dish_name一起分组是因为明细表里存的是快照名称同一菜品 ID 理论上名称一致但保险起见一起带上。导出功能一般用 EasyExcel 或 POI 把查询结果写成 Excel文档里“表格工具类”大概率就是干这个的。5. 避坑与常见问题搭建和调试时最容易翻车的几个点5.1 启动报数据库连接失败现象Spring Boot 启动时抛Communications link failure或Access denied。原因通常是 MySQL 8.0 的驱动类名和连接串参数没配对——8.0 要用com.mysql.cj.jdbc.Driver连接串要带serverTimezoneAsia/Shanghai和useSSLfalse。解决检查application.yml里的url、username、password确认数据库已建库且账号有权限。5.2 登录后刷新页面又回到登录页现象登录成功但跳转后接口返回 401。原因多半是 Session 没保持住前端请求没带 Cookie或者跨域配置里allowCredentials没开。解决前端uni.request确认withCredentials为 true后端跨域配置用allowedOriginPatterns而不是allowedOrigins(*)并开启allowCredentials(true)。5.3 下单时库存扣成负数现象并发下单后菜品库存出现负值。原因先查库存再扣减两步之间没有原子性两个请求同时通过校验。解决扣减 SQL 加条件UPDATE dish SET stock stock - #{qty} WHERE id #{id} AND stock #{qty}根据影响行数判断是否扣减成功失败则抛异常回滚。5.4 统计金额和订单列表对不上现象菜品统计的总金额比订单列表里已支付订单的总额少。原因统计 SQL 的WHERE条件漏了某种订单状态或者时间范围用了create_time但业务上应该按pay_time统计。解决先明确统计口径——按支付时间还是下单时间、包含哪些状态——再统一 SQL 条件最好在文档里写死口径避免后续改动时两边不一致。5.5 uni-app 端请求后端跨域被拦现象H5 端调接口报 CORS 错误但 Postman 正常。原因浏览器同源策略拦截后端没配跨域或配置不完整。解决后端加全局跨域配置类允许前端开发地址如果前端用 HBuilderX 内置服务器也可以在manifest.json里配代理。上线后前后端同域部署就不存在这个问题。6. 二次开发改造思路从毕业设计到能用的系统还差哪几步拿到这份文档和配套代码后如果只是跑通看效果按第 2 章的环境清单配好、导入 SQL、改数据库连接、启动前后端就差不多了。但真要拿去二次开发有几个地方我建议优先动。第一是支付模块。文档里写的是“线上学生一卡通支付”毕业设计阶段大概率是模拟支付——点一下按钮就把订单状态改成已支付。真实场景需要对接学校一卡通系统的接口或者至少做一个支付回调的幂等处理。改造时把支付逻辑抽成独立的PaymentService接口模拟实现和真实实现分开后面换起来不动订单主流程。第二是订单状态机。现在状态是 0 到 3 四个值散落在各个 Service 里用 if 判断。建议抽一个状态流转的枚举或配置表明确“待支付只能转已支付或已取消”“已支付只能转已完成”非法流转直接抛异常。这样后面加退款、加配送状态时不会把判断逻辑写乱。第三是统计口径的固化。第 5 章提到的统计对不上问题根子在口径没写死。改造时把统计 SQL 抽到独立的 Mapper 方法里方法名带上口径比如sumByPayTimeRange并在注释里写清楚包含哪些状态。商家端加一个时间筛选默认查最近七天避免全表扫描。第四是权限控制。现在靠拦截器判断是否登录但没判断“这个商家能不能改那个餐厅的菜”。建议在 Service 层加数据权限校验商家操作菜品前先校验dish.restaurant_id是否属于当前登录商家管理员才放开全量。这一步不做多商家场景下会出现越权改别人菜品的问题。验证改造是否成功我一般用三个动作一是用两个不同商家的账号交叉操作确认越权被拦二是并发压一下下单接口看库存会不会扣负三是把统计结果和手工从订单表算出来的数对一遍差一分钱都要查清楚。说个自己的教训。早些年我改这类订单系统图省事直接在 Controller 里写业务逻辑结果后面加一个“取消订单要退库存”的需求发现扣库存的代码散在三个地方改漏一处就出了脏数据。从那以后我每次动订单相关代码都强制走一遍“下单、支付、取消、再查库存”的完整链路确认每一步的库存和状态都对得上才提交。希望这份拆解能帮你少走点弯路把这份毕业设计真正跑起来、改下去。本文还有配套的精品资源点击获取