又到了毕业设计的高峰期，这两年咨询我最多的问题就是"老师，餐饮管理系统怎么选技术栈""后台怎么设计""部署文档能不能看懂"。说实话，SpringBoot+Vue+MySQL这套组合，现在已经成为很多高校毕业设计的主流选择，不光是餐饮系统，超市、图书馆、校园二手交易，底层逻辑都是同一套东西。这个题目能在标题里把"源码+数据库+论文+部署文档"都列出来，说明你找的参考项目比较完整，但完整不代表你能顺利跑起来，更不代表你答辩时能说清楚。这篇博文主要写给准备做或正在做同类系统的同学，我会从技术选型逻辑、数据库设计、前后端实现、部署流程和论文写作几个角度拆开讲，把标题背后那些实际会遇到的问题都摊开说清楚。
1. 项目整体设计与技术选型思路
1.1 为什么是SpringBoot+Vue+MySQL的组合
很多同学拿到这个标题后，第一反应是"这套组合老掉牙了"。确实，从技术新颖度来说，SpringBoot已经不算新鲜，但我要说的是，毕业设计的核心目标从来不是追求最新技术，而是向评委证明你掌握了完整的软件工程流程。SpringBoot简化了Spring的配置流程，不用再写一堆XML配置文件，内嵌了Tomcat，一个jar包就能启动整个后端服务，这对学生来说大大降低了环境搭建的障碍。Vue作为前端框架，组件化开发的方式和前后端分离的架构，恰好对应了目前企业级开发的主流模式，答辩时你可以很自然地讲出"前后端通过RESTful API进行通信"这句话的实战含义。
MySQL就更不用说了，关系型数据库的标杆，生态成熟，相关的视频教程和文档数量庞大，遇到任何问题都能查到解决方案。这套组合还有一层隐性优势：招聘市场上大量业务系统用的就是这套架构，哪怕你毕业后不做这个方向，至少能让你熟悉一套标准的全栈开发流程。
1.2 功能模块怎么划分才算需求完整
餐饮管理系统的功能划分，很多初学者容易陷入两个极端。一个极端是功能太少，只有登录和增删改查，答辩时评委问一句"你的系统如何支撑餐厅日常运营"，你答不上来。另一个极端是功能太多，会员积分、排队叫号、库存预警全都往里塞，结果时间不够，代码质量稀碎，连基本功能都有bug。
合理的做法是抓住餐饮业务的核心闭环。前台用户端主要包含用户注册登录、菜品浏览、菜品分类筛选、购物车、在线点餐、订单查看、个人资料管理。后台管理端则包含员工账号管理、菜品管理（上下架、批量导入、库存调整）、菜品分类管理、订单处理（接单、出餐、完成）、桌台管理、销售数据统计。这里要注意，餐饮系统的统计功能非常容易出彩，比如通过订单数据生成每日销售额曲线、热门菜品排行，这既是技术亮点，也是论文里"系统测试与结果分析"章节的好素材。
我还建议你加入一个简单的公告或轮播图模块。这个模块技术上很简单，但能让评委感觉到你考虑了真实场景，比如餐厅需要发布促销活动或营业时间调整公告。功能不需要多，覆盖住业务闭环，再加一两个亮点，就完全够用了。
1.3 交付文件里的四件套分别是什么角色
标题里提到的源码、数据库、论文、部署文档，看似独立，实际上有一个很清晰的逻辑关系。源码是整个系统的血肉，反映你的编码能力和架构理解；数据库是系统的骨架，它决定了业务模型是否合理；论文是你要向评委表达的核心成果，代码写了三万字，论文讲不清楚，等于没做；部署文档则解决一个很现实的问题，就是让评委能快速看到系统在运行的效果。
拿到别人分享的参考项目后，我的建议是不要直接改源码，先把数据库文件导入本地，跑起来看看表结构和初始化数据，理解业务模型和系统功能之间的映射关系。然后阅读前后端代码，画出大致的数据流转图，等完全理解了再动手修改和扩展。四件套的合理使用顺序和迭代顺序完全相反：先数据库、再源码、然后部署、最后写论文。你会发现，前三步做扎实了，论文写作会异常顺畅，因为你每写一段文字，脑子里都立着一个正在运行的系统副本。
2. 数据库设计：餐饮系统的骨架
2.1 核心表结构与字段设计
一个完整的餐饮管理系统，数据库表数量一般在10到15张之间。少于这个范围，说明功能设计大概率不完整；多于这个范围，可能是过度设计。核心表至少应该包括：用户表、员工表、菜品分类表、菜品表、订单表、订单明细表、桌台表、公告表。下面我挑几个容易出错的地方重点说。
用户表和员工表建议分开设计。用户表面向小程序或网页端的顾客，字段包括主键id、手机号、密码、昵称、头像、注册时间、状态。员工表面向餐厅内部人员，字段包括主键id、工号、姓名、密码、角色（管理员/服务员/厨师）、联系电话、入职时间。分开设计的逻辑在于两个表的查询场景完全不同，顾客端高频操作是登录和下单，员工端高频操作是登录后台处理订单，权限边界从数据层就开始分离，不会出现一个restaurant_user表里既存顾客又存员工还要用role字段区分的混乱局面。
菜品表和分类表是典型的一对多关系，菜品表通过category_id关联分类表。菜品表字段中，除了常规的名称、图片、描述、价格，建议加一个status字段控制上下架，这个字段不是摆设，它支撑的是前台菜品列表的实时刷新和后台的上下架操作。为什么不用delete物理删除？道理很简单，如果菜品被历史订单引用，物理删除会导致明细表数据不完整，统计模块出错。还有一种做法是加库存字段，但如果系统不做库存预警，这个字段反而增加操作负担，要根据自己系统的需求取舍。
订单表和订单明细表的设计是数据库层的核心难点。订单表存一次下单行为的主信息，包括订单编号、用户id、桌台id、订单状态（待支付/已支付/制作中/已完成/已取消）、支付方式、下单时间、总金额、备注。订单明细表存的是每个菜品的数据快照，包括菜品id、菜品名称、下单时的单价、数量。注意"数据快照"这四个字非常关键，菜品名称和单价必须冗余一份到明细表里，因为菜品表里菜品价格可能后续调整，但历史订单里的价格不能跟着变，否则统计报表会失真。
2.2 表关系与业务闭环如何走通
从业务闭环来看，一次完整流程是这样的：用户在前台选择菜品，系统把菜品id和数量组合生成订单数据，关联到订单明细表；用户提交订单，订单表新增一条状态为"待支付"的记录；支付完成后，后台员工端看到这笔订单，点击接单，状态变为"制作中"；出餐完成点击完成，状态变为"已完成"。整个过程中，订单表和明细表配合，订单表回答"谁点了餐、花了多少钱、现在到哪一步了"，明细表回答"具体点了哪几个菜、每个菜多少钱、数量是多少"。
这个数据流的设计有个隐藏好处：如果你要扩展打印小票功能、对接第三方配送平台，核心数据模型不需要变动，只需要在订单状态节点上增加事件处理逻辑。我就见过一些同学的参考项目把订单状态设计成字符串，什么"已下单""已接单"都往一个字段里塞，虽然也能跑，但扩展性和可读性都很差。正确做法是定义一个状态枚举，前端显示时映射成中文，后端处理时直接用枚举判断，这样既避免了魔法字符串，又降低了代码出错的概率。
2.3 数据库SQL脚本要注意的细节
拿到数据库文件后，第一件事检查SQL文件的编码格式。很多参考项目是用Navicat导出的，默认编码可能是utf8mb4，但Windows下另存后可能变成gbk，导入时就会出现中文乱码。建议用Notepad++或VS Code打开SQL文件，查看头部是否有charset=utf8mb4这样的标记，如果没有，导入前先执行set names utf8mb4。
第二件事是确认MySQL版本。如果你的本地环境是MySQL 8.0，但参考项目的SQL文件是针对5.7生成的，通常问题不大；反过来，如果SQL文件用了8.0才支持的语法比如窗口函数，在5.7上导入就会报错。我的建议是直接装MySQL 8.0版本，因为8.0已经成为当前主流，同时注意驱动配置，MySQL 8.0对应的是mysql-connector-java 8.x版本，连接URL里还要加上useSSL=false和serverTimezone=Asia/Shanghai，否则容易出现时区相关的报错。
3. 后端核心实现与代码细节
3.1 项目分层结构与启动配置
SpringBoot项目拿到手后，第一步不是看代码，而是看整体目录结构。一个规范的分层结构应该是Controller、Service、Mapper（或Dao）、Entity、Config、Common（放统一返回结果和异常处理器）、Utils这几个包。有的参考项目会把业务代码全部堆在Controller里，我能理解，工作量小嘛，但这样的代码答辩时非常经不起追问，评委随便问一句"你的事务控制在哪里"就没法回答。
谈到选型，实体类和数据访问层之间有两种主流方案，一个是MyBatis-Plus，一个是Spring Data JPA。毕业设计场景我更推荐MyBatis-Plus，原因是它兼顾了效率和可控性，内置的BaseMapper直接提供单表增删改查，你不用写繁琐的SQL就能完成80%的数据操作，同时复杂查询又支持自定义XML和LambdaQueryWrapper，方便你在论文里展示"自己掌握了复杂查询的编写能力"。配合代码生成器，可以从数据库表直接生成实体类和Mapper代码，节约大量重复劳动。
启动配置上，application.yml里最核心的三块内容是数据源、MyBatis-Plus配置和服务器端口。数据源配置除了常规的url、username、password以外，建议配置连接池参数比如initial-size、max-active、min-idle，这是面试和答辩时能加分的技术细节。MyBatis-Plus的配置注意设置map-underscore-to-camel-case为true，这样数据库的下划线字段可以自动映射成Java的驼峰属性，避免实体类里写一堆@TableField注解。
3.2 登录鉴权和权限控制的实现方案
登录模块看起来简单，实际上有非常多的细节需要考虑。现在主流的方案有两种：JWT和Session。我建议使用JWT无状态登录，原因是它更符合前后端分离的架构特征，后端不用维护会话状态，前端的token存储在localStorage或请求头里，接口通过拦截器校验token即可。Token里只放用户id、用户名和角色，有效期设置成24小时，过期后前端拦截401响应后跳转登录页即可。
这里容易出现的一个设计缺陷是：很多参考项目把用户表和员工表合在一起做登录，结果就是登录成功后还要再查一次角色，才能决定跳转到哪个首页。更好的做法是登录时直接返回用户信息以及角色列表，前端根据角色动态渲染路由，比如管理员可以看到后台管理菜单，普通用户只能看到前台商城页面。Java后端通过自定义注解@RequireRole配合拦截器做接口权限控制，这样每个Controller方法上标一个@RequireRole("ADMIN")，既清晰又安全。
密码存储的问题也值得说，直接存明文密码的项目我见过不少，这是重大安全隐患。至少要做到MD5加盐或BCrypt加密再存储，SpringSecurity里自带的BCryptPasswordEncoder可以顺手集成一下，代码量不大，但论文的安全章节就有素材可写了。
3.3 订单处理的核心逻辑
订单接口的设计能直接看出一个人的工程素养。以提交订单为例，前端传递过来的参数包括桌台id、菜品id列表、数量列表和备注，后端要做的事情至少包括四步。第一步校验桌台状态是否空闲；第二步根据菜品id列表查出菜品单价，计算总金额；第三步创建订单主记录；第四步遍历菜品明细，批量插入订单明细表，同时更新桌台状态。这四步必须在同一个事务里执行，任何一步失败，整个订单都要回滚，否则就会出现"订单表里有钱，明细表里没菜"的数据不一致问题。
事务控制在SpringBoot里实现很简单，在Service实现类上标一个@Transactional注解就行。但我见过很多同学标了注解但还是出问题，原因出在自调用上：同一个类里一个方法调用另一个带@Transactional的方法，事务会被绕过，成立的前提是Spring的代理机制。正确的做法是把订单处理的完整流程放在独立Service类的方法里，Controller只负责参数接收和结果返回，不要在Controller中拼装业务逻辑。
结算环节还有一个容易忽视的点：金额计算不能在前端完成再直接传给后端，前端传来的金额数据一律视为不可信。正确逻辑是后端从数据库取菜品单价，用后端计算总金额，这样才能避免用户通过浏览器调试工具篡改金额。我当时做系统的时候，为了体现这一点，还在总金额字段上加了数据库校验约束，确保金额和明细表冗余价乘以数量的汇总值一致，答辩时把这个细节讲出来，评委基本都是认可的。
4. 前端实现与页面开发要点
4.1 Vue项目的初始化与路由设计
拿到前端源码后，第一眼看package.json，判断用的是Vue 2还是Vue 3，以及配套的UI组件库。目前大多数毕业设计项目还是基于Vue 2和Element UI，但如果你准备自己新建项目，我建议直接上Vue 3加Element Plus。Vue 3的组合式API在组织复用逻辑方面优势明显，而且社区生态已经非常成熟，遇到问题基本都能搜到答案。
前端目录结构方面，标准的做法是src下分views（页面组件）、components（公共组件）、router（路由配置）、store（Vuex或Pinia状态管理）、utils（axios封装和工具函数）、api（接口请求模块）。很多新手代码的问题是所有请求都直接在组件里写axios，看似省事，但实际上接口维护成本高，且违背了关注点分离原则。正确做法是先在api目录定义一个模块，比如menu.js里统一导出getMenuList这类方法，组件里调用方法而不直接跟axios耦合，后期后端接口地址变了，只需要改一个文件。
路由设计上需要区分静态路由和动态路由。登录页、注册页这些是静态路由，任何人都能访问；首页、后台管理页应该是动态路由，用户登录后根据角色从后端获取可访问的页面集合，再通过router.addRoute动态添加。这样一来，未登录用户直接输入后台URL是无法访问的，这也在前端层面实现了权限控制。如果你拿到的参考项目没做这个，我建议花时间加上，这个功能写进论文是妥妥的亮点。
4.2 关键页面组件与交互逻辑
前台页面中，菜品展示页是最能体现前端基本功的页面。合理的实现是一个菜品分类的侧边栏加一个菜品网格的右侧区域，点击分类时通过接口请求对应分类的菜品数据。Element Plus里可以用el-tabs做分类切换，每一类下的菜品用el-card展示图片、名称、价格和描述，用户点击"加入购物车"按钮时，通过Vuex或Pinia维护一个购物车列表。购物车状态存放在全局store里而不是组件内部，很重要，因为购物车数据要在点餐页和结算页两个不同的路由下共享。
购物车做出来后，常见的bug是数量加减后总价没有同步刷新。原因多半是直接修改了对象的属性，但没有触发Vue的响应式更新。Vue 3里注意用reactive或ref包裹购物车数据，数量、单价、总价全部通过计算属性派生出来，这样只要基础数据变化，视图层就会自动刷新。
后台管理页面中，菜品管理表单是最核心的内容。新增菜品时，除了基本信息外还要支持图片上传，这是很多人忽略的技术点。图片上传有个关键配置：前端通过FormData格式提交图片文件，后端接口和静态资源映射要配合好。本地开发时，上传的图片会存到服务器某个目录，需要在SpringBoot里配置静态资源映射，这样前端img标签才能直接访问到图片URL。如果生产环境想更简单，可以把图片转成Base64存储到数据库，但缺点是数据库体积膨胀明显，还是推荐静态图片存储方案。
4.3 前后端联调与接口调试技巧
前后端联调阶段最容易出的问题就是跨域。解决跨域有两种思路，第一种在SpringBoot后端配置全局CorsFilter，允许前端开发服务器（默认端口8080或5173）跨域调用；第二种通过前端Vite或webpack的proxy代理转发，把/api开头的请求代理到后端地址。我的建议是开发阶段用代理的方式，不需要修改后端代码，上生产环境后用Nginx统一处理更清晰。
接口调试时建议安装一个API调试工具，我自己用得比较多的是Apifox，也用过Postman，目的是一样的，就是先在后端接口还没完全写好的情况下用Mock数据模拟请求，等后端接口写完后快速切换成真实接口。还有一个习惯值得推荐：定义统一的返回结构体，比如{code:200, message:"success", data:...}，这样前端axios拦截器可以统一拦截code异常，弹出错误提示，不用每个接口单独写错误处理逻辑。
前端代码质量上，我强烈建议至少封装一个公共的request工具模块，里面统一配置baseURL、token请求头、401跳转逻辑、响应错误提示。这样做的好处不光是代码规范，更重要的是答辩演示时不会因为某个接口报错，前端弹出一堆红色异常，非常影响印象分。
5. 部署实施与环境配置详解
5.1 本地环境搭建和数据库导入
部署文档写得好不好，直接决定了系统能不能被快速复现。最稳妥的本地环境组合是：JDK 1.8或JDK 11、Maven 3.6以上、MySQL 8.0、Node.js 14以上，前端依赖用npm或pnpm安装。我见过不少部署失败案例，罪魁祸首往往是版本不匹配，比如JDK 17运行SpringBoot 2.x项目，或者Node版本太低导致Vue 3项目安装依赖失败。
数据库导入步骤要按顺序走。第一步创建数据库实例，建议通过命令行或Navicat新建一个库，命名为restaurant或类似的名字，字符集选择utf8mb4；第二步选择导入SQL文件并执行，观察是否有报错；第三步验证导入结果，关键检查点是订单明细表是否有初始化数据、菜品分类表是否关联到了正确的菜品上。很多同学导入后只看到表数量对了就认为成功，其实表里数据为空或内部关联断裂才是运行时报错的根源。导入完成后，还要检查数据库账号权限，确保应用程序使用的账号有增删改查权限，而不是只能用root账号连接。
5.2 后端打包启动的正确姿势
后端项目启动有开发模式和部署模式两套路径。开发模式下直接在IDE里点运行Main类，方便调试；部署模式下执行mvn clean package -DskipTests，打包出jar文件，然后在服务器或本地执行java -jar命令启动。这里需要特别注意一个坑：如果你用的是MyBatis-Plus代码生成器，生成的实体类带有@TableId(type = IdType.INPUT)之类的注解，打包后如果数据库主键策略不对，会在插入数据时报告主键冲突，所以打包前务必确认数据库表的主键自增策略与实体注解匹配。
jar包启动时还有个常见问题：控制台中文乱码。Windows下执行java -jar xxx.jar时，如果程序输出日志有中文，可能出现乱码或报错。解决办法是启动命令里加上-Dfile.encoding=utf-8参数。另外，SpringBoot内嵌Tomcat默认端口是8080，如果端口被占用，有两种调整方案，要么在application.yml里修改server.port，要么启动命令后加--server.port=8081临时指定，第二种方式在演示多个项目同时运行时很有用。
后端启动成功的标志不是控制台打出大大的SpringBoot标志就万事大吉，还要访问一下接口的健康检查地址，比如/swagger-ui.html或自定义的/test接口，确认数据库连接正常。这一步能筛掉一大半"假启动成功"的情况。
5.3 前端构建部署与上线方案
前端本地开发时，npm run serve或npm run dev启动开发服务器即可。但要交付一个完整的演示环境，最好进行生产构建：执行npm run build，打包后生成dist目录。dist目录是纯静态文件，可以直接放进nginx的html目录或本地用tomcat托管。
关于dist目录能否直接用file协议双击打开，这里明确说一下：不行。因为Vue项目打包后需要经过HTTP服务器访问，而不是file协议直接打开，否则会出现路由空白和接口请求失败。本地演示时最简单的方案是安装nginx，配置一个server块，root指向dist目录，并做好前端路由history模式的try_files转发规则：location / { try_files $uri $uri/ /index.html; }。不配try_files的话，刷新页面会出现404，这是前后端分离项目最经典的坑之一。
如果你需要把前后端部署到同一个服务器，nginx还可以做反向代理，把/api/路径下的请求转发到SpringBoot服务地址，这样浏览器访问时完全没有跨域问题。部署文档里除了写配置，我强烈建议附带一份部署自检清单，比如：数据库服务是否启动、后端jar包是否在运行、nginx是否配置正确、防火墙端口是否放行。按照清单一项一项打勾，比盲猜快得多。
6. 常见问题排查与处突实录
6.1 数据库连接类问题分析
这类问题在部署中占比极高，读研和工作时给同事排查环境问题，一半以上的时间都在处理数据库连接。下面把典型场景整理出来，方便对照排查。
| 现象 | 可能原因 | 排查与解决 |
|---|---|---|
| Access denied for user | 数据库账号密码错误或权限不足 | 核对application.yml中数据库账号密码，用Navicat手动测试连接，确认具备读写权限 |
| Unknown database | 数据库名错配 | 检查库名是否一致，特别是大小写和命名后缀 |
| Communications link failure | 数据库服务未启动或端口不对 | 确认MySQL服务已启动，用netstat命令检查3306端口监听状态 |
| Server returns invalid timezone | MySQL时区配置问题 | 在JDBC URL后添加serverTimezone=Asia/Shanghai |
| Table doesn't exist | SQL导入不完整 | 重新导入SQL文件，检查是否有走错数据库或未执行全部脚本 |
数据库自检的时候，我习惯写一条最简单的查询，确认用户表里能否查询到初始化管理员账号。如果表存在但查询为空，说明初始化数据没导入，需要补执行数据脚本。
6.2 前后端联调跨域与接口报错处置
跨域问题报错信息里通常会出现CORS、Access-Control-Allow-Origin这类关键词。排查时先确认请求是从前端哪个端口发出的，再确认后端CorsFilter配置允许的来源列表是否涵盖该端口。开发阶段的临时手段是在前端Vite配置server.proxy，把/api代理到后端，这样请求从浏览器看是同源的，能绕过跨域限制。生产环境用nginx反代是最规范的解法，进入生产前建议把开发阶段的跨域宽限配置关闭，避免出现安全风险。
接口返回401或403，通常是token缺失或没有权限。先确认前端axios拦截器是否在header里塞了token，再确认后端登录接口返回的token是不是被正确存储。如果是403，大概率是后端接口权限注解和用户实际角色不匹配，需要检查代码里@RequireRole的角色名称和数据库里角色记录是否一致，比如大小写或全半角差异。
6.3 前端构建和后端打包的冷门坑位
npm install阶段报错有两个高频原因，一是node版本太新导致node-sass安装失败，建议把node-sass替换成dart-sass，或者统一用sass包，二是网络源不稳定，切换到国内镜像源再执行安装，速度会有质的提升。
后端Maven打包卡在下载依赖，基本是没配国内镜像源的问题。检查Maven的settings.xml，确认mirror配置指向阿里云或腾讯云镜像，随手一改能省下大量时间。另外，Java编译报错时先看是不是Lombok没安装或版本不兼容，这是一类非常隐蔽的报错，代码语法完全正确，但IDE或编译器就是找不到getter和setter方法。
7. 毕业设计论文撰写与答辩准备
7.1 论文各章节的核心写作思路
论文和博客有个很大区别，博客可以随性，但论文需要体现完整的研究方法论。毕业设计论文的框架通常遵循：绪论、相关技术、需求分析、系统设计、系统实现、系统测试、总结与展望。很多同学在写"相关技术"这一章时，会把手头的资料大段糍抄，这种做法风险很高。正确的写法是，针对你项目里真正用到的关键点做归纳，比如介绍SpringBoot时围绕"约定优于配置、内嵌服务器、自动装配"展开，介绍Vue时围绕"数据驱动、组件复用、虚拟DOM"展开，每一段都要能在你代码里找到对应实例。
需求分析章节建议用Use Case图和用例描述表格，说清楚每个角色的操作流程。这块要落到具体的功能点，不要写"系统具有良好扩展性"这类空话。扩展性好不好，评委眼里看的是代码结构，而不是论文里的形容词。
系统设计章节最重要的是画好架构图、功能结构图和E-R图，不要觉得画图麻烦，这几张图往往决定了第一印象。系统实现章节对应核心模块逐块展示代码和界面截图，但注意代码不能整段粘贴，应该挑关键的注解和方法，配合文字说明业务逻辑，表达能力和代码能力在这个环节会被同时打分。
7.2 答辩时最容易踩中的问题和应对方案
答辩回答问题的策略是"诚实承认加适度引导"。评委通常会从三个方向发问：一是技术选型问题，问为什么用JWT而不用Session，你可以从无状态、扩展性、前后端分离适配三个角度回答；二是安全性问题，问密码如何处理、接口怎么做权限控制，把BCrypt加盐和拦截器权限注解的实践经验讲出来；三是业务场景问题，问高并发点餐时如何保证数据一致，你可以把订单事务控制和数据库锁的思考抛出来，哪怕系统本身没有真实高并发环境，也说明你想过这个问题。
理论背得很熟但项目细节完全不知道，是答辩翻车的重灾区。一定要亲手过一遍部署流程，知道哪个文件改了会有什么效果，哪个表加字段会影响到哪个接口。我见过不少同学，手一抖把自己项目的管理后台密码输错三次，锁在登录页外面，场面一度非常尴尬。
另外一个实操建议，答辩前准备一份一页纸的项目亮点总结，写上三个最有说服力的功能或技术点，例如"封装了统一返回体和全局异常处理""订单模块采用事务控制保证数据一致性""前端实现动态路由权限控制"，答辩时无论评委问什么，都尽量往准备好的方向上引导，现场流畅度和逻辑性至少提升一个档次。
7.3 如何在基础项目之上做出差异化
如果你的参考项目和身边同学撞了题目，不要慌，也不用推翻重来。基础功能大家都一样，拉开差距的是扩展功能完成度和细节的打磨深度。前端可以加一个基于ECharts的销售数据可视化面板，展示近一周营业额和菜品销量排行；后端可以加一个导入导出功能，用EasyExcel把订单数据导出成Excel；还可以加一个基于定时任务实现的小功能，比如每天自动统计销量更新菜品热度榜。
我个人的体会是，毕业设计最大的收获往往不是技术栈本身，而是"在一个完整约束条件下做成一件事"的工程能力。数据库字段设计不合理，你拆开重来；前端打包后图片不显示，你查到是路由器匹配问题；论文查重率高了，你把口语化表达改成学术化论述。这些具体的问题解决过程，会一点点拉起你的系统设计能力和排查能力。答辩结束把项目封存的时候，翻翻自己写过的SQL和代码提交记录，那种成就感才是毕设真正留给你的东西。
