做校园食堂订餐系统的毕业设计，很多同学一开始都觉得"不就是个点餐网站吗"，真上手才发现，从选题到答辩，处处是坑。选题太大会做不完，数据库设计不合理会越改越乱，版本兼容问题能折腾你一下午，答辩时老师问一句"你这个订单并发怎么处理的"就卡壳。这篇文章我会把基于Java+Spring Boot+MySQL这套技术栈做校园食堂订餐系统的完整思路、核心实现和踩坑记录都拆开讲清楚，包括怎么设计功能范围、数据库表怎么建才合理、登录认证、下单防超卖、图片上传、部署演示这些关键环节的处理方式，还有答辩前需要重点准备的问题。

这篇文章适合正在做毕业设计的学生、想拿Spring Boot练手的初学者，以及带毕设的导师参考。我不讲那种高大上的微服务、分布式，就围绕"一个学生能独立完成、老师看了觉得工作量够、答辩能讲清楚"这个目标来写。

1. 项目准备与需求拆解

1.1 毕业设计做订餐系统的真实工作量

先说个扎心的事实：毕业设计真正留给写代码的时间，往往比你想象的少得多。实习、考研复试、春招、考公，各种事情挤在一起，真正能静下心来写项目的时间可能只有两到三周。所以选"校园食堂订餐系统"这种题目，本身就是个聪明的选择——业务场景贴近学生生活，需求容易理解，功能复杂度适中，既能体现工作量又不会收不住。

我见过不少同学选了很宏大的题目，什么"智慧校园综合服务平台"，结果光需求分析就写了二十多页，代码实现却只做了个登录注册，答辩的时候被老师追问就露馅了。反观订餐系统，核心业务链非常清晰：用户登录→浏览菜品→加入购物车→提交订单→支付（模拟）→商家接单→用户取餐。每一个环节都有明确的功能和页面，工作量可控，也方便展示。

另一个实际问题是，招投标类的毕设题目，老师在意的往往不是功能多花哨，而是你对整个业务闭环的理解程度。食堂订餐系统天然包含了"用户端"和"管理端"两个视角，这就能自然引出角色权限管理、订单状态流转、数据统计这些加分项。后面我会详细说怎么用最少的代码把这些点都拿住。

1.2 功能清单：不是多多益善，而是够用且能讲清楚

很多同学设计功能时容易走极端——要么功能少得可怜（只有一个CRUD），要么恨不得把美团外卖的所有功能都塞进去。我的建议是，功能设计遵循"用户端做闭环、管理端做管理、统计做亮点"这个原则。

用户端需要保证的核心功能有这些：

• 注册登录（学生学号 + 密码）
• 浏览菜品，按分类筛选（热菜、凉菜、主食、饮品等）
• 菜品详情展示（图片、价格、描述、月销量）
• 加入购物车，购物车数量增减、删除
• 提交订单、模拟支付（这里不需要接真实支付接口）
• 我的订单，查看订单状态（待支付、已支付、制作中、待取餐、已完成、已取消）
• 个人中心，修改个人信息、头像

管理端需要保证的核心功能有这些：

• 管理员登录（独立角色）
• 菜品管理：新增、编辑、上下架、删除
• 菜品分类管理
• 订单管理：查看所有订单、更新订单状态
• 销售统计：按日/按周的订单量、销售额图表展示

再加一个可以灵活取舍的扩展功能：公告管理、用户管理（禁用账号）、数据导出。不要小看这些"扩展功能"，它们是答辩时应对"你这系统还能再加点什么"这类问题的弹药。

这里要特别提醒：不要做"商家端"！为什么？因为食堂订餐的常见模式是"学生下单 → 食堂统一接单制作"，这跟外卖平台（用户下单 → 骑手接单 → 商家接单）的业务模型不一样。如果你强行加入"骑手配送"、"商家接单审核"，虽然功能多但业务逻辑变复杂，而且和"食堂取餐"的场景不符，答辩时老师一旦深挖业务合理性就容易翻车。食堂场景就是"线上下单、线下取餐"，模型越简单越贴合实际。

1.3 技术选型：为什么Spring Boot+MySQL是稳妥之选

Java + Spring Boot + MySQL这套组合，可以说是毕业设计界的"标准答案"，但你要能说清楚为什么选它，而不是只会说"大家都在用"。

• Spring Boot的优势在于"约定大于配置"。它内置了Tomcat，不需要额外部署Web容器，启动时自动配置数据源、自动扫描组件，这让你把精力放在业务代码而不是繁琐的XML配置上。
• 配合Spring MVC的注解开发（@RestController、@Service、@Mapper），一个请求从Controller到Service到Mapper的链路非常清晰，也方便答辩时讲分层架构思想。
• MySQL是关系型数据库的最佳选择，免费、稳定、社区资料多。校园订餐的数据模型是典型的"实体-关系"模型：用户、菜品、订单、订单明细，这些用表的关联关系表达最自然。
• 还有一个现实优势：资料多。你遇到的90%的问题，都能在技术社区找到解决方案。对时间紧的毕设党来说，这一点能救命。

有人会问，用MyBatis还是MyBatis-Plus？我推荐直接上MyBatis-Plus。它内置了通用的单表CRUD方法（BaseMapper），你不需要手写insert、updateById这些重复的SQL，可以把精力放在联表查询和业务逻辑上。而且它自带分页插件，后面做订单列表分页、菜品分页直接调用就行。

ORM选择上还有人会纠结，要不要用JPA？我的建议是不要。JPA虽然封装程度更高，但它的关联映射和级联操作对初学者来说黑盒感太强，出了问题不好排查。MyBatis-Plus的SQL是你自己写的，业务跑了什么SQL一眼就能看到，这对应付答辩时的"你这个数据的查询逻辑是怎样的"这类问题非常有帮助。

2. 数据库设计与核心表结构

2.1 表结构设计：五张核心表搭起整个业务骨架

数据库设计是毕业设计里最见功力的部分。我见过太多同学建表随随便便，字段命名混乱，类型乱用，没有外键也没有索引，写完代码后联调时bug百出。订餐系统核心需要设计这些表：

用户表（user）：

• id：主键，BIGINT，自增
• username：学号/用户名，唯一索引
• password：加密存储（使用BCrypt）
• nickname、phone、avatar
• role：角色区分（USER/ADMIN）
• create_time：创建时间
• deleted：逻辑删除标记

这里有个容易被忽视的细节：password字段的存储长度。BCrypt加密后的字符串长度是60位，如果你默认用VARCHAR(50)，一存就报错。类似这种类型长度问题，比业务逻辑bug更常见。

菜品分类表（category）：

• id、name、sort（排序权重）、create_time

菜品表（dish）：

• id、category_id（关联分类表）、name、description
• price：DECIMAL(10,2)，注意不能用FLOAT或DOUBLE
• image：菜品图片URL
• monthly_sales：月销量，用于排序展示
• status：上下架状态（1上架 0下架）
• create_time、update_time

价格为什么必须用DECIMAL？因为FLOAT/DOUBLE在计算机底层是近似存储，0.1+0.2的结果会让你在算总价时看到一长串小数。DECIMAL是按字符串/定点数存储的，精确计算，金融和订单相关的一律用它。

购物车表（cart）：

• id、user_id、dish_id、quantity
• 这里做个唯一约束（user_id, dish_id），避免同一用户对同一菜品产生多条购物车记录。这个约束在代码里也要有对应逻辑：加入购物车时先查是否存在，存在就update数量而不是insert。

订单表（orders）：

• id、order_no（订单编号，要有业务含义）、user_id
• total_amount：订单总金额
• status：订单状态（0待支付 1已支付 2制作中 3待取餐 4已完成 5已取消）
• remark：备注（口味偏好、辣度要求）
• create_time、pay_time、finish_time

订单明细表（order_item）：

• id、order_id（关联订单表）、dish_id、dish_name（冗余快照）、dish_image（冗余快照）
• price：下单时菜品价格（冗余快照）
• quantity：数量
• subtotal：小计金额

2.2 订单明细为什么要冗余菜品名称和价格

很多同学在第一次设计订单明细表时，只放order_id和dish_id这两个外键，觉得"需要菜品信息时再去联查dish表不就行了？"这个思路在做练习题时可以，但放在真实的订单场景里就有隐患。

试想一个场景：食堂后台把"鱼香肉丝"的价格从12元改成了14元。如果订单明细里没有价格快照，历史订单里的"鱼香肉丝"显示的就是14元——订单金额对不上，财务对账混乱。同样的道理，如果菜品被删除了，订单明细表里只剩一个dish_id，关联不到菜品数据，历史订单就成了一张"没有内容的空单"，对用户端"查看历史订单详情"来说是不可接受的。

所以规范的订单明细设计一定要做冗余，把下单那一刻的菜品名称、图片、价格都备份一份。这样订单明细就是一个完整自洽的数据记录，不依赖菜品表是否存在。这叫"快照模式"，是订单类系统的基本设计原则。答辩的时候，把这个设计讲出来，老师会认为你考虑到了数据一致性问题。

2.3 字段设计的几个坑：逻辑删除、时间字段、状态枚举

先聊逻辑删除。这个功能对新手来说很抽象，但非常重要。你可能觉得"删除菜品就直接DELETE不就行了？"，但你想想，如果菜品被删了，用户的收藏记录、订单明细里的关联、统计报表里可能还要追溯，直接物理删除会导致大量数据关联失效。更常见的是，你写联表查询时有可能会忘了关联条件，物理删除的数据会让整个查询结果出现空洞。

逻辑删除的实现很简单：在表中加一个deleted字段，默认0，删除时执行UPDATE SET deleted=1而不是DELETE。MyBatis-Plus里可以配置全局逻辑删除，这样你写的selectById、selectList这些方法，会自动带上WHERE deleted=0的条件，对业务代码完全透明。

再说时间字段。建表时统一用datetime类型，不要用timestamp。虽然timestamp节省空间，但它有2038年问题，而且受时区影响，处理起来容易出诡异bug。datetime配合DEFAULT CURRENT_TIMESTAMP作为create_time，update_time在每次更新时手动设置，或者在MyBatis-Plus里用@TableField(fill = FieldFill.INSERT_UPDATE)配合MetaObjectHandler自动填充。

还有状态字段类型的选择。订单状态status我建议直接用TINYINT，0-5对应业务里的不同含义，后面在代码里用枚举类或常量类维护。不要用字符串类型存"待付款""已支付"这样的中文状态值，一个是存储冗余，另一个是修改状态名称时要动数据库。用数字存，显示时再通过枚举映射成中文，这才是规范做法。

3. 后端核心功能实现与踩坑实录

3.1 用户登录与Token认证的完整流程

食堂订餐系统里，用户端和管理端是两种角色，所以登录认证一定要有"角色区分"的意识。这里我用的是JWT（JSON Web Token），它的好处是服务端不需要存储会话信息，客户端拿着Token请求，服务端验签通过就算认证通过，非常适合前后端分离或非极端高并发的毕设场景。

具体流程是这样的：用户提交学号和密码，后端通过用户名从数据库查询用户记录，用BCrypt校验密码（注意，BCrypt验证不是把密码解密成明文，而是拿着明文去比对哈希值，正确写法是bcryptPasswordEncoder.matches(rawPassword, encodedPassword)）。校验通过后，用JWT工具类生成Token，Token里可以放userId、username、role，设置过期时间，然后返回给前端。

在前端保存Token是个常见的坑。很多同学直接存localStorage，但存在XSS攻击风险；存sessionStorage，则关闭页面就丢失。对于毕设项目，我建议存localStorage，方便，而且你并不需要真正防范XSS攻击场景，后面有空再补。

后端需要做的事是写一个拦截器（HandlerInterceptor）或者过滤器（Filter），对所有需要登录的接口做Token校验。实现思路是：写一个JwtInterceptor，在preHandle方法里从请求头（Header的Authorization字段，格式为"Bearer " + token）取出Token，解析校验，放入ThreadLocal或Request attribute里，然后放行；解析失败则返回401状态码和提示信息。

这里有个细节一定要处理好：静态资源和登录/注册接口必须放行，否则你整个页面都打不开。注册一个WebMvcConfigurer，addInterceptors里用excludePathPatterns放行/api/auth/login、/api/user/register、/dish/**（菜品浏览可能需要未登录状态访问）等路径。这个坑我见过至少三个同学踩，白屏半天，一查是拦截器把登录接口也给拦截了。

3.2 下单接口的幂等性和事务控制

下单是订餐系统最核心的接口，也是事务控制的重头戏。我先说一个简单版本：前端点击"提交订单"，后端接收订单数据（购物车里的菜品list、备注、总金额），然后在一个事务里做这些事：

1. 根据userId查到购物车数据（这里要从头查数据库，不能信任前端传过来的菜品列表，这是安全底线）
2. 遍历购物车项，去dish表查出当前价格，计算每个明细的小计和总金额（同样不能信任前端传来的金额，前端传过来的金额只做展示参考，后端要以自己算出来的为准）
3. 生成订单主表记录，状态为"待支付"
4. 批量生成订单明细记录
5. 清空购物车

注意，这一步不能扣减库存。为什么？因为真实的食堂场景是"先下单后支付再制作"，而且食堂菜品的库存管理非常粗放（菜品扫完即止），精确到每份的库存扣减对毕设来说没有必要，反而会引入大量并发问题。这里不扣库存，是为了让逻辑复杂度可控。

上面的多步操作必须在同一个事务里。Spring Boot里这很简单，在Service方法上加上@Transactional注解即可。但是要注意几个失效场景：方法必须是public的、不能同类内部调用（比如update去调insert，不经过代理）、异常默认只在RuntimeException时回滚（如果你手动抛了受检异常，要指定rollbackFor）。我用过的是@Transactional(rollbackFor = Exception.class)，一劳永逸。

还有一个隐藏很深的点：事务方法内调用下单逻辑时，如果购物车里有菜品已经下架了要怎么办？我的建议是直接抛出异常，事务回滚，提示用户"有菜品已下架，请返回购物车确认"。这样逻辑简单清晰，不会产生部分成功部分失败的脏数据。

3.3 防止超卖：并发下单场景的正确处理方式

食堂订餐虽然不是秒杀系统，但答辩时老师很喜欢问一个问题："如果两个用户同时下单同一道菜，菜只剩最后一份了，你怎么处理？"这个问题考察的就是并发场景下的数据一致性。

如果你的系统没有库存概念，这个问题其实可以用业务设计巧妙回避——前面说了食堂场景可以不深度管理库存，而是用"售罄标记"来决定菜品下架。但如果你还是想在菜品表里加一个stock库存字段，那就要认真考虑并发问题了。

最简单的方案是使用乐观锁。在dish表加一个version字段，扣减库存时不是直接update stock，而是执行：

UPDATE dish SET stock = stock - 1, version = version + 1 WHERE id = ? AND version = ?

如果影响行数为0，说明version不匹配（别人已修改过），要么重试要么抛出"手慢了，库存不足"。

这个方案比分布式锁、悲观锁都更适合毕设。分布式锁需要引入Redis等中间件，会让你的项目复杂度上一个台阶；悲观锁（SELECT FOR UPDATE）虽然简单但长期持有数据库连接，性能差且不好讲解。乐观锁的代码改动量最小，只需要在实体增加version字段、Mapper上写一个带version条件的update语句，而且讲起来很加分——"我用的是乐观锁控制并发"听起来比"我什么都没做"强太多了。

3.4 菜品图片上传：本地存储与虚拟路径映射

菜品图片上传在订餐系统里几乎是必备功能。管理端新增菜品时要上传图片，而文件上传涉及两个层面的配置：存储位置和访问映射。

我推荐的方案是把文件存储到本机的指定目录，比如项目目录/uploads/dish/，文件名用UUID重命名（防止中文名乱码和重复），图片类型做校验（只允许jpg、png、jpeg）。然后通过Spring Boot的虚拟路径映射，把/uploads/**这个URL映射到本地磁盘目录，这样用户端访问菜品图片时就是http://localhost:8080/uploads/dish/xxxx.jpg。

关键配置在WebMvcConfigurer里：

registry.addResourceHandler("/uploads/**").addResourceLocations("file:" + uploadPath + "/");

这里的uploadPath建议配置在application.yml里，不要写死，方便本地和服务器部署时调整。

踩过的坑有两个：第一个，本地Windows路径和Linux服务器路径的拼接方式不一样，Windows是D:/xxx/uploads，Linux是/home/xxx/uploads，路径末尾一定要保留分隔符，否则文件写入位置会不对；第二个，当文件体积较大时Spring Boot默认单次请求最大文件大小是1MB，超过就会报错。要在配置里调大参数：

spring: servlet: multipart: max-file-size: 10MB max-request-size: 10MB

这个坑在演示时特别容易丢人，你明明选了张正常照片，结果死活传不上去。

4. 前端页面、交互与联调细节

4.1 模板引擎还是前后端分离：怎么选才最省事

前端部分有两条路：用Thymeleaf等等模板引擎做服务端渲染，或者用Vue/React做前后端分离。

对比一下就知道怎么选。Thymeleaf的优点是项目结构简单，不需要运行Node环境，启动Spring Boot就能直接访问页面，适合对前端不太熟悉的同学；缺点是页面交互能力弱，异步刷新、动态更新DOM都要靠jQuery和Ajax堆，代码会比较乱。

前后端分离（Vue + Axios）的优点是页面交互体验好，前端代码更清晰，而且只要你使用Vue CLI（脚手架），本地开发时还能有热更新功能；缺点是你要额外运行一个前端项目，跨域问题要用代理解决，最终部署时需要把前端build出来的静态文件整合进Spring Boot的resources/static目录，或者用Nginx（但Nginx对毕设来说太重了）。

我的建议是，如果你时间紧、只想快速跑通，那就用Thymeleaf + 服务端渲染 + jQuery。如果你有一点Vue基础，就果断上Vue + Element UI。现在Vue生态太成熟了，Element UI的表格、表单、分页、对话框组件拿来即用，管理端的界面一晚上就能搭完，用户端的微信小程序风格页面虽然要自己写CSS，但工作量也不大。

以我自己带过项目的经验，前端工作量的大头不在页面数量，而在"状态同步"——购物车数量、订单状态、菜品上下架，这些数据只要页面一刷新就丢，要通过接口重新拉取，很多同学在联调时被这个问题折磨到怀疑人生。

4.2 购物车模块的联调细节

购物车是食堂订餐系统用户端的"主战场"，也是前后端联调最容易出错的地方。我说几个你一定会遇到的细节。

第一，加入购物车的交互。前端点击"加入购物车"按钮时，要传dishId和quantity给后端。后端的逻辑是：先查购物车表，如果该用户已有这条菜品记录，则累加数量；否则新增记录。有同学图省事，传一个"quantity"给后端直接用update语句把数量覆盖，这样用户加一份又加一份时，数量就变成最后一份而不是累加，这跟用户预期明显不符。

第二，购物车列表的展示。展示时不是直接select cart表，而是需要联查dish表拿到菜品名称、图片、当前价格。这里推荐一个统一的DTO对象，比如CartVO，包含dishId、dishName、dishImage、price、quantity、subtotal。别嫌封装麻烦，前端拿一个VO比操作三个Map方便得多，代码可读性也高。

第三，购物车总价的计算。我的建议是总价不要存数据库，每次请求时遍历购物车项乘出小计再累加，返回给前端。前端每次勾选、修改数量后重新调用接口获取最新总价，避免前端本地计算带来的精度不一致。有些同学偷懒在前端乘完再传给后端，结果一分钱差异被老师演示时抓到，特别尴尬。

第四，状态处理。用户在下单后清空购物车。但"清空"是在下单接口内部实现的，用户如果中途放弃了支付，购物车已经没了，用户重新去结算时列表是空的，体验很差。更好的方案是先创建订单为"待支付"状态，但不清空购物车；等支付成功后（模拟支付回调）再清空购物车。这样即使用户取消支付，购物车数据还在，可以重新下单。

4.3 菜品分类筛选、订单状态流转的页面实现

用户端首页的经典布局是"顶部筛选 + 菜品列表"。分类筛选最简单的方式是点击分类标签时，前端请求/dish/list?categoryId=xxx&page=1&pageSize=8这种带参数的接口。为了演示效果好，建议做成"分类 + 关键词搜索 + 分页 + 排序（销量/价格）"组合筛选，前端用Element UI的分页组件，后端用MyBatis-Plus的分页插件。

订单状态流转是管理端的重点工作流。你可以把状态机的思想简化成"按钮驱动"：管理端的订单列表每一行显示"操作"按钮，根据当前状态决定显示什么操作。比如"待支付"状态显示"取消订单"；"已支付"显示"接单"；"制作中"显示"完成制作"；"待取餐"显示"确认取餐"。这个流转过程封装在一个Service方法里，每一步都做状态合法性校验——比如"已完成"的订单不能被"取消"，不然数据逻辑就乱了。

前端显示订单状态时，可以用el-tag标签加不同颜色（灰色待支付、蓝色已支付、橙色制作中、绿色已完成），视觉上很清楚。用户端"我的订单"列表同样按照状态标签展示，点击订单详情跳转到详情页，详情内容由订单主表和明细表联合查出。这里注意，前面提到的订单明细冗余快照就发挥作用了——不管菜品现在是否被修改或删除，历史订单详情永远完整。

5. 部署、测试、论文与答辩经验

5.1 本地联调、测试数据与异常验证

项目做完了不等于万事大吉，毕业设计里最拉胯的就是演示时当场爆炸。所以在交付前，一定要建立一套完整的测试数据，覆盖演示过程中出现的各种界面状态。

我的做法是，准备两组账号：一组普通学生用户（已注册、有购物车数据、有历史订单）和一组管理员账号。在管理端，菜品分类要有至少4个，每个分类下要有至少5道菜，菜品图片要提前配好，价格要有零有整（比如4.5、8.8这样的），最好有一两道菜设置为"已下架"状态。订单数据要有各个状态：待支付、已支付、制作中、待取餐、已完成、已取消各来几单，销售统计图表才会有数据可看。

在演示之前，把所有接口用测试工具（Apifox或者Postman）跑一遍。重点验证这些容易出现异常的场景：

• 未登录访问需要认证的接口，返回是否友好提示
• 登录时密码错误，是否返回401并提示
• 下单时购物车为空，是否报错
• 重复提交下单，是否产生重复订单（这个涉及幂等性，如果能处理最好）
• 管理员编辑菜品时传了超长字符串，数据库是否会报长度错误

只要这些场景都验证过，演示时大概率不会翻车。建议把项目启动的完整过程在笔记本上走一遍，从启动MySQL、启动后端、启动前端到最终刷出页面，最好是凉机操作（关掉所有环境再打开），确认不会出现端口占用、配置遗漏这类环境问题。

5.2 答辩演示的顺序设计与常见问题

答辩演示是有策略的。很多同学一上来就点开页面从头刷到尾，老师看得昏昏欲睡，也不知道你的系统到底哪里厉害。我的建议是分三步走：

第一步，用1-2分钟讲清楚"系统是干什么的、面向谁、核心业务闭环是什么"。不要讲需求背景讲十分钟，老师不想听，直接说"这个系统面向校园食堂，用户在线下单、管理员管理菜品和订单，线上线下结合"就够了。

第二步，演示用户端核心流程。用一个学生账号登录，从浏览菜品、分类筛选、加入购物车、修改数量、提交订单、模拟支付、查看订单状态和订单详情，一气呵成。演示时边说边操作，让老师看到数据流——"我现在下了一单，我们切到管理员端，可以看到这个订单已经跑过来了"。

第三步，演示管理端。重点是菜品管理和订单管理。尤其要把状态流转演一遍：从"已支付"点到"接单"再到"完成制作"，让老师看到页面上的状态标签在变化。最后打开销量统计图表，补充一句"这里的数据是通过订单表按月/状态实时统计出来的，没有用假数据"，这句加分。

接下来是能否加分的关键。老师大概率会问这几个问题，你提前准备好答案：

• "你这个系统用了什么技术栈？为什么选Spring Boot？"（答：Spring Boot约定优于配置、生态成熟、便于快速开发，MySQL存储关系型数据，MyBatis-Plus提高单表CRUD效率。）
• "订单并发时怎么处理数据一致性的？"（答：乐观锁控制库存扣减，结合@Transactional保证事务原子性；如果没做，要如实说并补充改进思路。诚实比硬编一个"我用了分布式锁"强得多，老师一眼能看穿。）
• "JWT和Session有什么区别？为什么用JWT？"（答：JWT无状态、适合前后端分离、天然支持跨域，Session需要服务端存储。这里不需要展开太多，但一定要能说出本质差异。）
• "如果某个菜品被删掉了，历史订单里的明细会怎么样？"（答：订单明细表做了数据冗余快照，即使菜品删除，历史订单也能正确显示。）

5.3 时间规划与论文写作的实战建议

最后说说时间分配和论文写作，这是很多人低估的部分。我的建议是总时间按照"数据库设计1天 + 后端开发7天 + 前端开发4天 + 联调与测试2天 + 论文与PPT 4天 + 缓冲2天"来排。如果现在离答辩还剩两周多，这个节奏是能走完的。

论文写作有两条捷径：一是"图表化"。把ER图、系统架构图、功能模块图、核心业务时序图画好，插入Word里，论文的篇幅和观感立刻就上去了。画图工具可以用PlantUML或者ProcessOn，不需要多漂亮，结构清晰就行。二是"代码展示+讲解"结合。论文里贴核心代码片段时，不要整段贴完，挑出最关键的几行，配上注释和设计意图说明。比如乐观锁的那段update语句、JWT拦截器的preHandle方法，这就是工作量最好的证明。

论文中需要特别强调的是"数据表设计的理由"。哪怕是同一张user表，你也要能说出"为什么username加唯一索引""为什么用逻辑删除""为什么订单明细要做冗余快照"。往往自己的项目自己最懂，这恰恰是答辩中最自信的地方。

查重这块，各学校要求不同。但无论如何，不要整段从网上抄，也不要用破解版的降重工具。正确的做法是：技术原理和概念用自己的话重新组织，项目描述全部基于自己写的代码来反推，这样查重率自然不会高。你亲手写的代码和跑通的流程，就是最好的"原创性证明"。

提示：如果你的学校要求论文必须包含"系统测试"章节，不要只写"功能测试全部通过"这种空话。列出几条真实的测试用例，包括前置条件、输入数据、预期结果、实际结果。例如"用户输入错误密码，提示'账号或密码错误'，实际结果一致"。测试表格一贴，论文的诚意和专业度立刻提升。

写在最后

带过这么多届毕业设计，我最大的体会是：毕业设计这个事，难的不是技术，而是"在有限的时间里用稳健的方案把闭环跑通"。很多同学一开始想用微服务、消息队列这些花哨的架构，最后被各种中间件折磨到放弃；反而那些老老实实从Spring Boot + MySQL做起来的，最后都顺顺利利过了答辩。

如果你现在正在做食堂订餐系统，或者准备拿类似题目做毕业设计，我希望这篇指南能帮你少走点弯路。数据库表设计时多想想订单明细为什么要冗余，写下单接口时多想想事务边界在哪，答辩前多想想老师会从哪个角度挑战你——这些"多想一步"的习惯，才是毕业设计给你留下的最宝贵的东西。

最后分享一个小技巧：项目代码里多写点注释，尤其是核心业务方法。答辩时翻代码给老师看，注释清晰的项目会留下"这个学生代码规范、思路清晰"的好印象。祝答辩顺利。