做一个毕设性质的SpringBoot菜品销售系统，到底要掌握哪些核心东西？项目拿到手之后怎么跑通、怎么讲解、怎么应对答辩？这篇博文就结合我见过的大量同类项目，把从立项、表结构设计、后端接口实现到配套文档的使用方法，一次性讲透。如果你是准备做相关课题的学生，或者刚入门想找一个完整项目练手的开发者，这篇文章应该能帮你省下不少摸索的时间。

1. 项目全貌与受众定位

1.1 这套系统到底解决什么问题

先别急着打开代码，把需求看清楚再说。标题里那一长串“菜品销售系统/菜品管理系统/餐饮销售系统/菜品点餐系统/菜品订单系统/餐饮管理系统”，本质上是同一个业务内核在不同角度下的叫法：以菜品为中心，以订单为主线，串起前台用户点餐和后台商家管理的一套Web应用。

这类系统的典型使用场景有两类：一类是中小型餐厅、食堂、外卖档口做线上点餐和管理；另一类是高校软件工程专业的毕业设计或课程设计选题。对于前者，系统需要实际承担日常运营；对于后者，它更像是一个展示开发者对Java后端全流程掌握程度的载体。有意思的是，这个项目正是在第二类场景中最为常见——因为它的业务规模不大不小，刚好能把SpringBoot的核心功能全部覆盖，又不会复杂到让初学者望而却步。

从功能模块上看，核心闭环是这样的：用户注册登录后浏览菜品列表，按分类筛选，把喜欢的菜加入购物车，结算生成订单；管理员在后台维护菜品分类和菜品信息，处理订单状态，查看销售统计。简单说，前台的每一次点餐操作，后台都有对应的数据变化，这就是一套完整的信息管理系统该有的样子。

1.2 哪些人最适合拿这个项目练手

我从实际经验出发，给读者画个像。如果你是以下几类人，这套项目值得花时间研究：

第一类，正在准备毕业设计的学生。这类项目最大的优点是“麻雀虽小五脏俱全”，从环境搭建到部署上线有一条完整的链路。你用Java写后台、用MySQL存数据、用Bootstrap或Vue写页面，最后交付的是包含源码、论文、调试文档在内的成套材料，直接对标毕业设计的全部要求。

第二类，自学Java后端半年左右、想找一个完整项目积累经验的开发者。平时刷教程都是一个个零散的Demo，缺乏一个能把SpringBoot、MyBatis、MySQL、Redis、JWT这些技术串起来的机会。这个项目恰好是天然的练手项目，业务简单、表关系清楚、出Bug也好排查。

第三类，想给朋友或亲戚的小餐饮店做个简单管理系统的人。不用上那些重型微服务架构，单机部署、一台服务器或者一台老电脑就能跑起来，实用性反而更强。

1.3 配套材料怎么配合着用

拿到课程设计或毕业设计级别的项目，配套材料往往比源码本身更值得先看。这套项目附带的材料包括源码、LW（论文/设计文档）、调试文档和讲解视频或笔记。很多同学拿到手就直接跑代码，结果环境配不通就卡住了，其实正确的打开顺序是：先读调试文档了解环境要求，再快速浏览论文搞清楚业务需求是怎么写的，最后才动手跑代码。

调试文档解决的是“怎么跑起来”的问题，一般会写明JDK版本、Maven配置、数据库初始化脚本、启动步骤和默认账号密码。论文解决的是“怎么讲清楚”的问题，包括选题背景、需求分析、数据库设计、系统实现和测试这些章节。讲解材料则是把代码和论文化成口头表达，帮你应对导师的提问。

2. 技术选型背后的逻辑拆解

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

做技术选型时，我经常被问到：为什么现在的毕设项目几乎清一色是SpringBoot，很少看到早期那种SSH（Spring+Struts+Hibernate）的项目了？这个问题背后的答案，恰好能解释这个技术栈成为主流的原因。

先说Struts，它的核心价值在于Web层的Action拦截，但在前后端分离逐渐成为主流之后，Struts这种把页面控制和业务逻辑强耦合的框架就越来越笨重。Hibernate的ORM确实强大，但对新手来说，配置复杂、SQL不可见、性能调优困难，反而成了负担。SpringBoot则把“约定大于配置”的理念发挥到了极致。内嵌Tomcat意味着你不需要单独装一个Web服务器，起步依赖（Starter）帮你把各种的库的版本统一管好，自动配置帮你省掉了大量XML配置。

这等于什么？早期SSH时代配一个项目可能要折腾一整天，现在SpringBoot新建一个空项目到能跑出Hello World，只要几分钟。对学习者来说，省下来的时间可以花在业务逻辑本身。

2.2 前端部分：模板引擎还是前后端分离

这个选择直接影响整个项目的代码结构和论文写法。我见过两类做法，各有利弊。

传统做法是Thymeleaf或者JSP做服务端渲染，页面由后端直接返回。这种方式的好处是架构简单，不需要考虑跨域问题，session天然可用；浏览器上访问一个URL就能看到完整页面。对毕业设计来说，演示时打开浏览器直接操作，不容易出幺蛾子。

前后端分离的做法是后端只提供JSON接口，前端用Vue或者React单独部署。这个方案更贴近企业实际开发，对后续找工作的经验积累有帮助，但相应地会增加项目复杂度——你得处理跨域、Token存储、前端打包部署这些额外的问题。

我的建议是：如果你的目标是稳妥毕业、把精力放在后端逻辑上，选Thymeleaf模板引擎就足够了；如果导师明确要求“前后端分离架构”，或者你自己想多学点前端技术，再选Vue。这不是技术高低的问题，而是成本和收益的权衡。

2.3 持久层框架：MyBatis还是MyBatis-Plus

这个项目的持久层选型，我强烈推荐MyBatis-Plus，而不是纯MyBatis。原因很直接：单表增删改查在业务系统里占了七成以上，MyBatis-Plus的BaseMapper直接把insert、delete、update、selectAll这些通用方法都内置了，你连SQL都不用写。再加上分页插件，写列表查询的代码量能减少一半。

纯MyBatis的优势在于SQL完全自己控制，适合复杂多表联查场景。但说句实话，餐饮销售系统的查询复杂度远没到非手写SQL不可的程度。哪怕后期要写统计SQL，也只需要在Mapper里加几个自定义方法就好，两者可以共存。

有一个细节值得注意：MyBatis-Plus的字段映射默认是把数据库字段的驼峰和下划线互转，比如数据库里的user_name会自动映射成Java里的userName。很多同学没注意配置，导致代码查询出null，第一反应就是“框架出Bug了”，其实检查一下驼峰映射配置就能解决。

2.4 JWT还是Session

登录鉴权这块，不同年代的项目用的方案也不同。老一点的用Session + Cookie，新一点的基本都是JWT。这套项目既然是基于SpringBoot的较新版本，用JWT是更合理的选择。

JWT的核心思路是：用户登录成功后，服务端生成一个包含用户ID、角色、过期时间等信息的加密字符串，客户端保存这个Token，后续每次请求在请求头里带上它。服务端不需要保存登录状态，只要验签通过就放行。这就是无状态认证，水平扩展的时候不用考虑Session粘滞问题。

但JWT也有缺点，最大的是“无法主动失效”。比如用户改密码后，旧Token在到期前仍然有效，这在某些对安全要求较高的场景中是隐患。餐饮管理系统的安全级别没那么高，选JWT足够。实现的时候，记得在拦截器里校验Token，并且把不需要登录就能访问的接口（比如登录接口本身、菜品浏览接口）在配置里排除掉。

注意：写论文时技术选型章节一定要写清楚“为什么选JWT而不是Session”，不要只罗列技术名词。导师最反感的就是只列名词、不讲理由的凑字数。

3. 数据库设计：从概念到建表的完整推导

3.1 核心实体的识别与关系梳理

很多同学拿到需求就直接打开Navicat建表，这是错误做法。哪怕系统再小，也应该先在草稿纸上把实体和关系画出来，想清楚再动手。

仔细看这个项目的名称：菜品销售系统。围绕“卖菜”这个动作，最起码涉及的实体有：用户（谁在买）、菜品（卖什么）、分类（菜品怎么组织）、订单（一次购买行为）、订单明细（一笔订单里具体买了哪些菜）。稍微扩展一下，还有购物车（结算前的暂存）、管理员（后台操作用）、公告或轮播图（营销内容）。

这几个实体之间最核心的关系是订单和菜品之间的多对多关系：一个订单可以包含多个菜品，一个菜品也可以出现在多个订单里。但在关系型数据库里，多对多关系必须通过中间表拆成两个一对多。于是就有了订单明细表（order_item），它记录订单ID、菜品ID、数量、单价，这样既保留了冗余数据防止菜品价格变动影响历史订单，又让表关系变得规整。

用户和订单是一对多关系，一个用户可以有多个订单。分类和菜品是一对多关系，一个分类下有多个菜品。购物车和用户是一对一或一对多关系，取决于你允许多个购物车还是一个购物车。

3.2 关键表的字段设计与理由

先说用户表。标准字段包括id、username、password、phone、avatar、role、status、create_time。role字段用来区分普通用户和管理员，可以用tinyint类型存数字，0表示用户、1表示管理员。为什么不直接建两张表？因为登录逻辑是一样的，用一个字段区分角色能避免大量重复代码。

密码存储是最需要注意的点。直接存明文等于把用户数据裸奔。要求严格的话必须用BCrypt加密，SpringSecurity里自带这个工具。即使项目没引入SpringSecurity框架，也可以通过引入spring-security-crypto这个单独的工具包来实现加解密。数据库中保存的永远是加密后的字符串，登录校验时用matches方法比对。这是代码评审和论文里的高频扣分点，务必重视。

菜品表需要字段：id、name、category_id、price、image、description、status、create_time、update_time。price字段建议用decimal(10,2)，避免Float精度丢失问题。image字段存的是图片路径而不是图片的二进制数据，这是一个非常关键的设计规范——图片文件存在本地磁盘或对象存储里，数据库只存路径字符串。二进制大对象进数据库会导致表体积膨胀，查询性能严重下降，读取时还要额外做转换，纯属自找麻烦。

订单表和订单明细表是设计中的重头戏。订单主表字段包括order_no、user_id、total_amount、status、pay_type、address、remark、create_time。order_no用业务编号而不是自增ID做主键候选，因为自增ID容易暴露业务量，而且多表操作后不方便追溯。状态字段status建议用数字枚举，0待支付、1已支付、2已发货/制作中、3已完成、4已取消。写论文时这一块配一个状态流转图特别加分。

订单明细表则要有order_id、dish_id、dish_name、dish_image、price、quantity、total_amount。这里故意冗余了dish_name和dish_image，原因是菜品信息会改，但订单历史不应该跟着变。下单时快照一份到明细表，后面就算菜品的名字改了，老订单上仍然能看到当时的菜名和价格。

3.3 建表SQL与初始化数据的注意事项

建立表结构时，字符集选择utf8mb4而不是utf8。utf8mb4是utf8的超集，能存表情符号，而且本质上是一样的存储空间。如果用了utf8，用户地址里带个emoji就直接报错了。排序规则用utf8mb4_general_ci就行，不区分大小写，符合业务需求。

初始化数据方面，至少要在dish表里准备好十几条真实菜品记录，分类也要建全：热菜、凉菜、汤品、主食、饮品。图片可以直接用网上的免费图片链接，也可以放本地静态资源路径。我通常建议后者，演示时不依赖外网环境，放在服务器上也不会出图挂掉的问题。

如果项目自带SQL脚本，优先使用自带脚本。但跑完脚本后一定要用Navicat或者DataGrip打开看看，别只看到“执行成功”就以为万事大吉。我之前就碰到过因SQL脚本和代码里的字段名对不上导致启动直接报错的案例，早检查早省事。

4. 后端核心功能：从零到接口联调

4.1 项目初始化和统一返回结构

创建SpringBoot项目时，建议用Spring Initializr直接生成，选好Java 8或11（取决于你本机JDK版本，别盲目求新）、SpringBoot 2.7.x左右的稳定版本、Web依赖、MyBatis-Plus依赖、MySQL驱动、Lombok、Validation。Swagger或knife4j建议一开始就集成，后面调试接口会非常方便。

我自己在做这类项目时，有个强烈的建议：先写一个统一的Result类。所有接口的返回值都包一层Result，里面包含code、message和data三个字段。比如成功是code=200，业务异常是code=500。这一步虽然多写几行代码，但价值巨大：前端或者调试工具看到的返回结构是一致的，不用每个接口单独判断；统一处理异常时也方便；在论文的系统实现章节里，展示一个统一返回结构的设计说明是非常好的素材。

public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.code = 200; result.message = "操作成功"; result.data = data; return result; } public static <T> Result<T> error(String message) { Result<T> result = new Result<>(); result.code = 500; result.message = message; return result; } }

4.2 登录鉴权与拦截器配置

登录接口的逻辑看起来简单：接收用户名密码、查询数据库、比对密码、生成Token返回前端。但这一步藏着不少细节。

密码比对使用BCrypt时，注意要用matches方法来比对明文和密文。有些同学图省事，把数据库里的密文直接decode再对比，这就错了。BCrypt的密文里包含盐值，每次加密同一个密码结果都不同，它只能通过专门的matches方法验证。

获取当前登录用户的方式，既可以用拦截器解析Token后存入ThreadLocal，也可以简化为在Controller方法里接收一个从拦截器传递过来的userId参数。我倾向于用ThreadLocal配合一个@CurrentUser注解实现，代码看起来更优雅。但如果你求稳，在一个简单的BaseController里封装getUserId()方法也能用。

拦截器的配置要特别注意放行路径。登录接口、菜品列表和详情接口、图片访问路径，这些都是用户没登录时就要访问的，必须放行。而所有需要登录的操作，比如加购物车、提交订单、查看个人中心，都要经过Token校验。如果配置反了，前端页面就会在登录后仍然请求失败，调试时特别容易掉进这个坑里。

4.3 菜品分类与菜品管理的后端逻辑

菜品分类的接口就是典型的单表CRUD，用MyBatis-Plus写起来几乎是模板化操作：列表接口用selectList，添加用insert，修改用updateById，删除用deleteById。唯一让人纠结的是分类的删除——如果这个分类下还有菜品，直接删除会导致数据库外键约束报错，或者数据逻辑混乱。

合理的做法是删除前先查询一下该分类下的菜品数量。如果大于零，要么禁止删除、返回提示信息“该分类下还有菜品，无法删除”，要么做软删除，把分类的deleted字段置为1。菜品管理这里也有同样的注意事项，虽然菜品往往是逻辑删除，但分类通常直接删除，在处理时要把关联设计考虑进去。

菜品列表的分页查询是高频接口。MyBatis-Plus的分页功能很成熟，配置一个分页插件，然后在service里调用Page方法即可。多条件组合查询时，记得用LambdaQueryWrapper的like方法处理模糊搜索，用eq处理精确匹配。

Page<Dish> page = new Page<>(current, size); LambdaQueryWrapper<Dish> wrapper = new LambdaQueryWrapper<>(); wrapper.like(StringUtils.hasText(name), Dish::getName, name) .eq(categoryId != null, Dish::getCategoryId, categoryId) .eq(Dish::getStatus, 1) .orderByDesc(Dish::getCreateTime); dishMapper.selectPage(page, wrapper);

这段代码里值得解释的是第一个参数StringUtils.hasText(name)。当用户没有输入搜索关键词时，name是空值，这个条件就会被自动忽略。这就是MyBatis-Plus最实用的特性之一——条件构造器，它能在你去拼接SQL时帮你省掉大量if判断。

4.4 购物车与订单：最容易翻车的核心链路

购物车和订单是整套系统的业务重心，也是设计和实现上最容易出错的地方。先理清购物车的存储方式，通常两种方案：内存态缓存或数据库表。小系统直接用Redis缓存购物车，性能好、功能也够用；但为了毕业设计的稳定性、演示时不依赖Redis，我仍然建议单独建一张cart表来做持久化，结构为id、user_id、dish_id、quantity即可。这样做的额外好处是：如果将来要做“购物车同步”功能，数据已经在数据库里了。

购物车加菜接口的核心逻辑是“有则加数量，无则新增记录”，用一条selectByUserIdAndDishId查询出来，如果存在就对数量加一，否则插入新记录。没有看明白这个逻辑的人，一上来就无条件insert，结果同样的菜在购物车里出现好几条，是一个比较常见的低级错误。

提交订单是整套系统里事务性最强的一步，既要把订单主表和订单明细表写入，又要扣除菜品库存，还要清空用户购物车中已下单的商品。如果这三步任何一步失败，都会导致数据不一致——比如订单生成了但购物车没清空，或者购物车清空了但订单明细缺失。因此必须用Spring的@Transactional注解包住整个方法，保证原子性。

@Transactional(rollbackFor = Exception.class) public Long createOrder(OrderCreateRequest request) { // 1. 查询购物车中选中的商品 List<Cart> cartList = cartMapper.selectList(...); if (cartList == null || cartList.isEmpty()) { throw new BusinessException("购物车为空"); } // 2. 计算总价，创建订单主表 Order order = new Order(); order.setStatus(0); order.setUserId(request.getUserId()); // 计算totalAmount... // 3. 循环创建订单明细 for (Cart cart : cartList) { Dish dish = dishMapper.selectById(cart.getDishId()); // 写入 order_item... } // 4. 清空购物车 cartMapper.deleteByUserId(request.getUserId()); return order.getId(); }

这里有个经验之谈：创建订单时不要接收前端传过来的总价totalAmount，而是后端根据菜品表的当前价格重新计算。否则谁要是改一下前端请求里的总价，就能以0.01元下单了。虽然餐饮系统的安全性要求不是最高级别，但这种服务端计算总价的设计原则，在答辩时讲出来会加分不少。

订单支付逻辑，毕设项目中一般做模拟支付即可。支付状态可以从待支付直接改成已支付，不用真的对接第三方支付。但在代码里要留一个扩展点，比如定义一个PayService接口，当前只有一个MockPayServiceImpl实现。论文里写“预留了对接真实支付渠道的扩展能力”，这种设计意识很能体现思考深度。

4.5 后台管理与统计报表

后台管理端的功能包括菜品管理、分类管理、订单管理和用户管理。这些模块本质都是CRUD加一点条件筛选，难度不大。真正体现含金量的是数据统计模块。

统计模块至少要做三个指标：菜品销量排行、每日订单数、分类销售占比。实现这样的统计有两种途径：一种是在Java里查出所有数据然后循环统计，另一种是直接用SQL的group by和聚合函数做统计。第二种效率更高，代码也更简洁，因为统计逻辑在数据库里算完，传输到应用层的就是最终结果。

SELECT dish_name, SUM(quantity) AS total_quantity FROM order_item GROUP BY dish_name ORDER BY total_quantity DESC LIMIT 10;

这种分组统计统计的逻辑不复杂，但前端展示时配上ECharts就能做出很漂亮的柱状图和饼图，是整个系统演示时的最大亮点之一。答辩时把销量趋势图一放，比说十句话都有说服力。

5. 调试文档与论文的写作套路

5.1 调试文档里必须写清楚哪些东西

调试文档的核心目标是：一个从没接触过这个项目的人，照着文档能在一个小时内把系统跑起来。我见过太多同学写的调试文档只有一句“导入项目到IDEA，启动即可”，这种文档等于没写。

一份合格的调试文档至少包含这些内容：环境要求清单（JDK版本、Maven版本、MySQL版本）、数据库初始化步骤（如何执行SQL脚本，如何修改application.yml中的数据库连接）、启动步骤（IDEA里如何配置启动类，是否要配置Maven镜像）、初始账号密码（用户端和管理员端各一个）、常见启动报错的解决方法。

关于环境的版本，有一点特别想强调：**Spring Boot 2.x 必须在JDK8或11上运行，如果你用的是最新版JDK17甚至21，很多老项目根本跑不起来。**这是我看到的最常见的技术翻车现场，先花五分钟确认版本兼容比什么都重要。

5.2 论文的结构和字数布局

毕业设计论文的章节结构，我个人建议这样分配：第一章绪论写背景和意义，约1500字；第二章需求分析那就写用户角色分析、功能需求、非功能需求，2000字左右；第三章数据库设计包括E-R图和数据表说明，2500字；第四章系统实现是重头戏，按模块展示核心代码并配截图，4000字以上；最后一章是系统测试和总结，2000字。

值得注意的是，论文里贴代码不要整段贴，挑关键方法就行。贴太多代码会让论文看起来很空，仿佛是文档拼接。好的做法是：先用文字把逻辑讲清楚，再贴一段10-15行的核心代码作为佐证，然后配上截图——接口请求截图或者页面操作截图。

管理系统截图这个细节，很多同学容易忽略。文档和论文需要用到大量截图，建议在系统跑通后，花半小时把所有功能点的截图统一截一遍。图片命名规范一点，比如01-登录界面.png、02-菜品列表.png，这样写论文时插入配图就非常顺手。

6. 典型踩坑场景与调试记录

6.1 环境层面的经典疑难

端口被占用是最常见的问题，没有之一。SpringBoot默认8080端口，如果本机的Tomcat或其它服务占用了它，启动就会报端口绑定失败。排查方法：

• 命令行执行netstat -ano | findstr 8080 看看哪个进程占了端口，
• 找到对应PID后在任务管理器里结束进程，或者直接在application.yml里换一个端口，比如8081。如果是自己开发环境，换端口更快。

数据库连接失败是紧排在后面的坑。报错信息通常是Access denied for user或Communications link failure。前者是密码不对，后者多半是MySQL服务没启动、host和port配错、数据库名不对、时区参数没设置。最稳妥的办法是把连接串写成下面这样：

spring: datasource: url: jdbc:mysql://localhost:3306/dish_system?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: yourpassword

注意serverTimezone一定不要漏掉。MySQL 8.0默认时区跟国内不一样，不加这个参数极大概率报错。

Maven依赖下载慢也是新手容易卡住的点。默认中央仓库在国外，国内网络环境下非常不稳定。最好在Maven的settings.xml里配置阿里云镜像，速度会从爬行变成快进。

6.2 运行时接口层面的典型问题

接口返回404是最让人摸不着头脑的情况之一。通常不是接口不存在，而是访问路径写错了。SpringBoot的Controller映射区分大小写，/api/dish和/api/Dish是两个不同的路径。建议全局搜索一下前端JS或Postman里请求的路径，对照Controller的@RequestMapping逐字检查，对了，还要检查是不是有上下文路径——server.servlet.context-path配置了的话，所有请求都要带上前缀。

实体类字段映射成null的问题出现频率也很高。检查两类原因：数据库列名和Java字段名是否因为驼峰映射没配置而对应不上。比如Java是dishName，数据库是dish_name，如果application.yml里没写map-underscore-to-camel-case: true，查询结果集里dishName就是null。另外一个原因是查询参数没传对，前端传的是name，后端取名dishName，接不到参数自然查不到数据。

事务不生效的情况在订单模块比较常见。很多人以为在Controller方法上加了@Transactional就能回滚，实际这是个误区。@Transactional只会对RuntimeException回滚，但确实会因为各种原因失效，比如方法被同类内部调用导致代理失效，或者异常被catch吞掉了导致事务感知不到。排查思路是：确认注解加在service方法上，确认方法是被外部完整调用的，确认没有try-catch吞异常。把这个排查过程写进实习日志或遇到的坑里，是非常好的个人积累。

6.3 上传图片常见问题

菜品管理功能里往往需要上传图片，这里也有经典问题。本地存储图片的物理路径和访问URL的映射关系怎么配置，是一个绕不开的坑。SpringBoot默认不会把本地磁盘的任意文件映射成可访问的URL，你需要写一个静态资源映射配置类，把某个URL路径映射到本地的某个磁盘目录。比如请求 /images/dish01.jpg，它实际映射到 /usr/local/upload/dish01.jpg。

配置完成后还有一个演示环境问题：如果图片保存在本机的绝对路径下，项目部署到服务器后路径变了，图片就会全部挂掉。建议在application.yml里配置一个自定义属性比如file.upload-path，代码里通过@Value读取，部署时只要改配置文件就行。这个“配置与代码分离”的思想，值得写在论文的设计原则上。

上传文件大小默认有限制，SpringBoot默认是1MB，超过就报错。如果你要用高清菜品图，记得同时配置spring.servlet.multipart.max-file-size和max-request-size为10MB左右。

7. 从毕设到真实项目的扩展空间

7.1 缓存层：给系统提速

当前的系统中，菜品列表每次被请求都会查一次数据库。如果流量上来，数据库压力会显著增大。引入Redis做缓存是一个性价比很高的优化方向。菜品是读多写少的数据，把菜品列表缓存到Redis里，管理员更新菜品时就删除对应缓存，下一次查询时再重建缓存，就能极大地减少数据库压力。

这个优化点的代码实现并不复杂，但对系统性能的影响立竿见影。答辩的时候，导师非常喜欢问“你的系统有没有做性能优化”。你可以从容地回答：菜品列表接口用了Redis缓存，缓存击穿和穿透的问题也做了基本防护——空值缓存和随机过期时间，至少在简单应用层面这两层足够用。

7.2 接口文档自动化与前后端协作

手工维护接口文档效率很低。更好的选择是在项目里引入knife4j，这是Swagger的中文增强版。依赖引入配置好之后，自动扫描Controller生成文档。前端开发者和后端开发者都对着同一份文档，谁也不会因为更新不及时而扯皮。这也是“工程化思维”的一种表现。

在毕业设计里加入Swagger后的截图，会让界面显得非常专业，因为你会多出一套文档界面出来，整个系统一下就有了工业级的感觉。

7.3 消息通知和更多业务闭环

真实的餐饮系统不止下单和出餐这么简单，还可以加一些闭环功能：用户下单后给商家发一条消息通知；订单制作完成时给用户推送状态消息；用户评价功能、优惠券功能、会员积分功能。这些扩展都可以在现有表结构上增加字段或者新增关联表来实现，整体不会伤筋动骨。

考虑到毕设的周期有限，扩展功能并不是越多越好，选出两三个亮点功能深度打磨，比一次性铺开一堆半成品更明智。我个人建议优先做Redis缓存和评价功能，一个体现性能优化意识，一个体现业务闭环意识，都是导师眼里的加分项。

7.4 部署上云的实践价值

做完本地运行后，尝试把项目部署到阿里云、腾讯云或华为云的轻量应用服务器上，这个动作的实际价值常常被轻视。打包成jar包、配置生产环境的数据库、开通安全组端口、使用宝塔面板或者Docker镜像部署、申请一个域名或IP访问系统，这已经是一个非常完整的后端学习闭环了。

部署过程中还会遇到本机开发时不存在的问题，比如数据库密码强度策略不一致、服务器防火墙不放行对应端口、jar包启动后内存不足导致OOM等。你处理掉这些问题、把项目完整呈现在公网可访问的状态时，对这个系统的理解已经比只做本地开发的同学高出一截了。

从拿到项目源码到把它变成自己的作品，需要经历的远不是解压导入这一步。把表结构画明白、把请求链路理清楚、把每个接口的try-catch和事务边界看清楚，然后用调试文档把环境跑通，最后用论文和讲解把逻辑讲圆，这套项目就算真正变成你的东西了。我个人在实际接触中的感受是，与其搜索各种新颖技术堆叠出来的炫技项目，不如把一个结构清楚的业务系统做到能吃透每一步。菜品销售系统恰好提供了这样的纵深，它不深奥，但它完整。