毕业设计年年有，JavaWeb方向的题库翻来覆去就那么几个，但“订餐管理系统”这个题目几乎每年都会出现在各大高校的选题列表里。它不像电商、社交那样体量庞大，做起来容易失控；也不像图书管理、学生信息管理那样过于平淡，答辩时很难讲出亮点。餐饮行业的业务场景足够真实：菜品分类、购物车、订单流转、库存联动，甚至会员营销——每一个环节都能找到明确的业务痛点，也对应着后端开发中的经典问题。

这套系统我从前端页面到数据库设计完整带过两届学生，中间踩过的坑和总结出的方法论，基本都在这篇文章里了。无论你是刚打开IDEA还不知道怎么建项目，还是已经写完代码正在准备答辩PPT，都能从里面找到对应的参考内容。文章不会粘贴整段源码，重点是拆解"每一行代码为什么要这么写"、数据表为什么要这么设计、以及哪些地方是答辩时老师必问的高频考点。

1. 题目选择的门道：为什么订餐管理是"高性价比"毕设题

每年选题季都有学生来问我："老师，这个题目是不是太简单了？""会不会和别人的系统撞车？"我的回答通常是：毕设的价值不在于题目有多前沿，而在于你能不能把一个完整业务闭环讲清楚。订餐管理系统恰恰是一个"麻雀虽小、五脏俱全"的典型场景。

1.1 业务复杂度恰好卡在本科毕设的"舒适区"

一个合格的JavaWeb毕设，至少需要覆盖三个层面：前端交互、后端业务逻辑、数据库设计。订餐系统在这三个层面都有恰到好处的施展空间。

• 前端方面，菜品展示页需要图片和价格渲染，购物车需要动态增减商品数量，这考验的是JSP或Vue的基础操作能力。
• 后端方面，下单要校验库存、计算总价、生成订单号，这考验的是业务逻辑的严谨性。
• 数据库方面，至少需要用户表、菜品表、订单表、订单明细表四张核心表，它们之间存在明确的主外键关系，这一套走下来，数据库设计的核心能力基本就全覆盖了。

换个题目对比你就明白了。教务管理系统听起来很简单，但光是一个"排课"功能就能牵扯出教师、教室、班级、时间这四者的冲突检测，业务模型相当烧脑，而且做完之后对能力提升的帮助很有限。电商系统则过于庞大，商品SKU、秒杀、支付回调，任何一个点单独拿出来都能写一篇硕士论文，本科阶段做完的极少，大部分是半成品。

订餐系统的优势就在这个"中间地带"——既不会因为太简单导致无话可说，也不会因为太复杂导致烂尾。

1.2 论文好写、答辩好讲是隐藏优势

毕设除了写代码，还要过论文和答辩两关。很多学生代码写得挺好，但论文写不出来，核心原因就是业务场景太抽象，无从下笔。订餐系统的业务链路极其直观：用户浏览菜品、加入购物车、提交订单、商家接单、完成配送或到店自取。每一步都可以对应论文中的一章，逻辑顺滑，不需要硬凑字数。

更重要的是，这个题目贴近日常生活，答辩时老师不需要你解释业务背景。哪怕老师完全不懂系统内部实现，他也能理解"点餐、支付、出餐"这套流程。当你能把一个老师本来就熟悉的场景讲清楚，答辩难度天然就降低了一半。

1.3 适合哪些技术基础的学生选

我做过一个粗略的分类，供你参考：

你现在的水平处在哪一档，就选择对应档位的实现方案。强行上高难度技术栈，代码全是复制拼凑的，答辩一追问就露馅，还不如老老实实把Servlet和JSP吃透，做一个完完整整的项目出来。

2. 技术选型：别一上来就想着Spring Cloud微服务

技术选型是很多毕设生的第一个分岔路口。有同学打开CSDN，看到别人用Spring Cloud做了个订餐系统，立刻觉得自己也用微服务才算"高级"。这种思路对于一个仅有一个后端服务、几张数据表的毕设来说，完全是在给自己挖坑。

2.1 毕业设计的正确技术栈选择标准

判断技术栈是否合适的标准就三条：

1. 你是否能独立解释清楚每一个注解的作用。
2. 运行环境是否简单可控（最好一台机器就能部署）。
3. 代码量是否在你的可控范围内。

如果一个技术你只是听说过名字，没写过一行代码，那它就不应该出现在你的毕设里。面试官或答辩老师最反感的就是"用了高级技术但一问三不知"。

2.2 从"省事"和"有亮点"两个角度做选择

对于大多数JavaWeb方向的订餐系统，我推荐三套成熟方案，按难度递增排序：

考虑到"毕业设计毕设参考"这个搜索场景，绝大多数人是第一次接触完整项目开发。我的建议是：方案A和方案B二选一，优先推荐方案B。Spring Boot虽然是框架，但它帮你省去了大量XML配置的时间，能让精力集中在业务代码上，而且"用过Spring Boot"写在简历上本身就是一个加分点。

2.3 开发环境配置里的版本兼容问题

JAVA开发的第一步就是配环境，而这恰恰是劝退最多人的环节。JDK、Tomcat、Maven、MySQL任何一个版本不匹配，后面都会跑出千奇百怪的报错。这里直接分享一套我实测稳定的版本组合，2025年了还在用它带毕设：

• JDK 8 或 JDK 11（不要上JDK 17，除非你确定所有依赖都兼容）
• Maven 3.6.3 或 3.8.x（3.9也可以，但不要用最新版）
• Tomcat 9（内嵌或外置均可，方案B推荐使用Spring Boot内嵌Tomcat）
• MySQL 5.7 或 8.0（8.0建议用5.1.49以上版本的驱动）
• IDEA 2024/2025 社区版或专业版均可

注意：如果使用MySQL 8.0，JDBC驱动类名是com.mysql.cj.jdbc.Driver，URL需要加上serverTimezone=Asia/Shanghai，不加这个参数会报时区错误。这个问题每一届都有学生问。

2.4 项目结构到底怎么分包才合理

技术栈定了之后，接下来就是项目的包结构。很多参考项目里的包结构乱七八糟，Controller里直接写JDBC，Service里面居然还有System.out.println——这种代码看多了容易把新人带偏。规范的包结构应该是这样：

com.example.order ├── controller # 控制层，接收请求，返回结果 ├── service # 业务层，核心业务逻辑 │ └── impl # 业务层实现类 ├── mapper # 数据访问层（MyBatis接口） ├── entity # 实体类，对应数据库表 ├── dto # 数据传输对象（如购物车DTO、下单DTO） ├── vo # 视图对象（如菜品展示VO、订单详情VO） ├── config # 配置类（WebConfig、MybatisConfig） ├── common # 公共类（统一返回结果、异常处理） └── utils # 工具类（JWT工具、日期工具等）

不要小看这个包结构，答辩时老师看一眼你的项目结构图，基本就知道你有没有真正理解分层架构。Controller只负责参数接收和结果返回，Service只负责业务逻辑，Mapper只负责数据库操作——这个原则写清楚，比任何华丽的代码都能撑住场面。

3. 订餐系统的核心功能拆解：从用户下单到商家接单的完整闭环

很多学生在设计功能模块时有个通病：想到什么功能就加什么功能，最后做出来一个"功能大全"，但每个功能都很浅。正确的做法是先梳理核心业务的主链路，把主链路跑通后再考虑扩展功能。

3.1 核心业务主链路（必须完整实现的部分）

订餐系统的主链路可以概括为八个字：浏览、加购、下单、出餐。展开来说就是：

1. 用户登录注册：注册时校验用户名唯一性，登录时校验密码。密码不能明文存储，至少用MD5加盐处理（如果能用BCrypt更好，答辩有亮点）。
2. 菜品浏览与分类筛选：首页展示菜品列表，支持按分类（热菜、凉菜、主食、饮品等）筛选，分页展示。
3. 菜品详情与购物车管理：点击菜品可查看详情，加入购物车时可选择数量，购物车页面支持修改数量、删除商品、计算总价。
4. 订单提交与结算：从购物车生成订单，生成唯一的订单编号，保存订单主表和订单明细表，同时扣减菜品库存。
5. 订单管理：用户端可以查看自己的历史订单和订单状态（待接单、制作中、已完成、已取消），管理员端可以查看所有订单、修改订单状态和删除或下架菜品。

这四个模块就是系统的骨架，优先级也是从高到低。如果时间不够，可以先砍掉管理员端的统计报表，也不要砍掉订单状态流转——因为"状态流转"才是体现系统逻辑闭环的关键。

3.2 订单状态机设计（答辩高频考点）

订单状态是整个系统中最重要的业务概念。不好的设计是用一个String字段随便存"已支付""未支付""已完成"，然后前端全凭感觉展示。稍微专业一点的做法是用int类型的status字段表示状态值，配合常量类统一定义：

0：待付款（用户在确认订单后、支付前的状态） 1：待接单（已付款，等待商家确认） 2：制作中（商家已接单，正在备餐） 3：待配送/待自取（制作完成，等待送达或用户到店取餐） 4：已完成（订单完结） 5：已取消（用户主动取消或超时未支付自动关闭）

状态流转路径需要严格限制，比如待付款状态下可以取消，但制作中状态就不能随意取消；已完成状态是终态，不能再跳转回前面任何一个状态。这个逻辑最好写在Service层里做一个专门的状态校验方法：

// 定义允许的状态流转路径 private static final Map<Integer, List<Integer>> STATUS_FLOW = new HashMap<>(); static { STATUS_FLOW.put(0, Arrays.asList(1, 5)); // 待付款 -> 待接单 / 已取消 STATUS_FLOW.put(1, Arrays.asList(2, 5)); // 待接单 -> 制作中 / 已取消 STATUS_FLOW.put(2, Arrays.asList(3)); // 制作中 -> 待配送 STATUS_FLOW.put(3, Arrays.asList(4)); // 待配送 -> 已完成 }

答辩时如果能主动讲出"我用状态机约束了订单的状态流转，避免脏数据产生"，这一句话的含金量比得上写一百个CRUD接口。

3.3 购物车的数据存储：Redis还是Cookie还是数据库

购物车是另一个体现设计功力的点。很多参考项目用Session来存购物车，这种做法最简单，但有一个明显缺陷：用户关掉浏览器购物车就没了。要判断具体的存储方案，还是要看项目的整体复杂度：

• 用Session/Cookie存储：实现简单，无需额外表。适合纯入门级项目。缺点是换设备购物车不共享。
• 用数据库存储购物车表：数据持久化，结构清晰，可以记录用户-id对应的购物车明细。缺点是每次增删改查要多走一次数据库，会多出一些查询开销。但毕设场景完全能承受，推荐使用。
• 用Redis存储购物车：性能优，但需要在项目里多集成一个Redis依赖，环境配置成本增加。如果你学有余力可以加，但不建议为了炫技硬上。

我的建议是选择数据库存储方案。理由有两个：第一，购物车表的设计CREATE TABLE语句本身就可以写进论文里，充实数据库设计章节；第二，购物车和订单的转换逻辑是天然的业务关联，能在答辩中展示你对"主外键关联"和"事务操作"的理解。

3.4 管理员端功能：别把CRUD做得太无聊

管理员端是很多毕设的得分洼地——不少学生把后台做成了"增删改查"四件套，页面之间跳来跳去，看着功能不少，但答辩时老师说"这不就是一张表一个页面嘛"，场面就很尴尬。

想让后台显得有含金量，建议在以下三个方面做些设计：

1. 菜品的上下架状态管理：菜品要有"上架/下架"的布尔字段，下架的菜品前端不展示，但后台仍然能查到。这个设计看似简单，实际解决了"订单历史和菜品删除之间的矛盾"——如果菜品直接物理删除，历史订单里的菜品名和价格就变成null了，这是设计缺陷。
2. 订单的多条件筛选：订单列表页提供按订单编号、用户姓名、订单状态、下单时间范围组合查询。这个功能可以在Mapper中写动态SQL，只要你用过<if>标签就足够体现你对MyBatis动态SQL的掌握。
3. 营业数据简单统计：统计今日订单数、今日营业额、热销菜品Top5。不需要做复杂的报表，一条SQL加个分组查询就能实现，但放在后台首页作为数据卡片展示，整体观感会提升一个档次。

4. 数据库设计：订单表的主键为什么不能是自增ID

数据库设计是毕设论文中最容易对称的部分，也是最容易翻车的地方。很多参考项目的数据库表就只有三四张表，每张表三四个字段。这种设计交上去会被导师直接打回。一套合格的订餐系统数据库，至少应该有六张以上的表。

4.1 核心表结构概览

以下是我在带毕设时反复使用的一套表结构，直接复制可以作为设计参考：

注意表名不能叫order，因为ORDER是SQL关键字，直接用会报语法错误。改成orders是最省事的方式。

4.2 订单表主键设计：为什么不能直接用自增ID

这是技术上最重要的一个细节。订单表的主键如果直接使用自增ID，会带来两个问题：一是订单号容易被猜到，竞对可以通过遍历订单号获取所有订单信息；二是自增ID在分布式环境下无法保证全局唯一。

正确做法是设计一个独立的order_number字段，使用业务编码规则生成：

订单号 = 时间戳 + 用户ID后四位 + 随机数 示例：2025061410304512341234

这里说的是一套比较常用的生成方式，你也可以简化为"日期+随机数"：

public static String generateOrderNumber(Long userId) { SimpleDateFormat sdf = new SimpleDateFormat("yyyyMMddHHmmss"); String timeStr = sdf.format(new Date()); String userSuffix = String.format("%04d", userId % 10000); int random = (int) ((Math.random() * 9 + 1) * 1000); return timeStr + userSuffix + random; }

为什么订单号比自增ID更适合做主键？核心原因是它能承载业务信息。看到订单号就能大致推断出下单时间，这在商家排查问题时极其高效。论文的数据库设计章节里，把"订单号的生成策略"作为一个小节单独写，既实用又能体现设计深度。

4.3 冗余字段设计：内存换性能的艺术

设计order_detail表时有一个容易踩的坑：订单明细到底要不要保存冗余的dish_name和dish_image？我的回答是要，而且必须保存。

原因很简单：订单是历史数据，菜品是可变数据。如果商家改了菜品名，或者后来干脆删除了这个菜品，历史订单明细里的外键ID依然指向菜品表，但菜品数据已经不存在了，那么用户查看历史订单时就会显示一片空白。把菜品名称和价格冗余到订单明细表中，实际是"以空间换时间"的经典取舍——既保证历史数据可追溯，又避免多表关联查询。

这个细节在答辩时完全可以主动讲出来："我对订单明细做了冗余设计，虽然不符合纯粹的第三范式，但综合考虑了历史数据稳定性和查询性能，这是一个工程妥协的取舍。"——这段话一出来，设计深度立马上了一个台阶。

4.4 外键到底要不要加

大部分前端出身的参考代码里根本看不到外键约束，因为MySQL默认引擎InnoDB虽然支持外键，但很多项目为了删数据方便，直接不建外键，依靠代码逻辑维护关联关系。这种做法在真实开发中确实常见，但在毕业设计中，我还是建议把逻辑外键体现在ER图上，即在表设计时清晰标注表间关联关系，但不一定真的在数据库层加FOREIGN KEY约束。

更稳妥的做法是：物理上不加外键，但在设计文档的ER图中画出表之间的关联虚线。这样既避免了"删数据时被外键限制"的麻烦，也让老师明白你知道表间该有怎样的关系。同时，由于相关字段都建了索引，多表JOIN查询的性能也能得到保障。

5. 核心代码实现思路：从登录鉴权到下单事务的完整链路

很多自学项目的人有个误区：代码喜欢从Controller层开始写，页面跳转能通就认为功能做完了。但真正合格的开发者会先思考数据模型和业务边界，再动手写代码。这一节我按"从外到内"的顺序，把关键模块的实现思路完整过一遍。

5.1 用户登录与身份鉴权：过滤器还是拦截器

用户登录后，系统如何知道你是已登录用户，无权限的人如何被拦截，这是每个Web项目都要解决的基础问题。最传统的方案是Session，登录成功后session.setAttribute("user", user)，退出时session.invalidate()。

实现一个简单的登录拦截器，核心思路是放行登录相关的路径，其余路径则检查Session中是否存在用户信息：

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); Object user = session.getAttribute("user"); // 用户未登录，重定向到登录页 if (user == null) { response.sendRedirect("/login"); return false; } // 已登录，放行 return true; } }

在Spring Boot中注册拦截器，注意要排除登录接口、注册接口、静态资源路径：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new LoginInterceptor()) .addPathPatterns("/**") .excludePathPatterns("/login", "/register", "/dish/list", "/dish/detail", "/css/**", "/js/**", "/images/**"); } }

提示：登录拦截器的核心价值在于"统一的鉴权入口"。答辩时老师问"怎么防止用户不登录直接访问下单接口"，你要能立刻回答出"我通过拦截器统一校验了用户登录态"。

5.2 下单模块：事务是绝对不能少的

下单操作是订餐系统中最核心、也最容易出Bug的功能。很多参考项目里的下单操作就是一个简单的INSERT语句，这其实是不对的。一个完整的下单流程至少包含四个步骤：

1. 查询购物车中选中的菜品列表。
2. 校验菜品的库存是否足够。
3. 生成订单编号，插入orders表和order_detail表。
4. 扣减菜品库存（UPDATE dish SET stock = stock - #{number} WHERE id = #{id} AND stock >= #{number}）。

这四个步骤要么全部成功，要么全部失败。如果订单插入成功但库存扣减失败，就会出现"用户下单成功但商家没货发"的严重问题。所以Service层的下单方法必须加上事务管理：

@Transactional(rollbackFor = Exception.class) public OrderVO createOrder(Long userId, List<CartDTO> cartItems, String address) { // 1. 生成订单号 // 2. 计算总金额 // 3. 保存订单主表 // 4. 保存订单明细表 // 5. 扣减库存 }

这里尤其要注意rollbackFor = Exception.class。如果不指定这个参数，Spring默认只在抛出RuntimeException时才回滚事务，如果代码里捕获了异常并吞掉，事务就永远不会回滚，脏数据就这么产生了。

下完单之后要清空购物车，也应该放在同一个事务里执行。

5.3 Mapper层动态SQL：实现多条件组合查询

以订单列表的多条件查询为例。如果只实现"固定SQL查询"，代码写起来简单但灵活度差；使用MyBatis动态SQL，就可以按需拼接条件：

<select id="pageOrders" resultType="com.example.order.vo.OrderVO"> SELECT * FROM orders <where> <if test="orderNumber != null and orderNumber != ''"> AND order_number LIKE CONCAT('%', #{orderNumber}, '%') </if> <if test="userId != null"> AND user_id = #{userId} </if> <if test="status != null"> AND status = #{status} </if> <if test="beginTime != null"> AND create_time &gt;= #{beginTime} </if> <if test="endTime != null"> AND create_time &lt;= #{endTime} </if> </where> ORDER BY create_time DESC </select>

这个<where>标签非常聪明——如果所有的if都不满足，它会自动去掉SQL中的WHERE关键字，不产生语法错误；如果某个if满足，它又会自动去掉前面多余的AND。MyBatis中这个标签背后的逻辑，建议认真看一看源码，面试问到动态SQL时能讲出"关键字自动去除原理"，印象分就会完全不同。

5.4 统一返回结果：让前端少做一层判断

很多学生在Controller里喜欢直接返回一个Map或者ModelAndView，每次返回的数据结构都不一样，前端解析时苦不堪言。实际项目中更常见的做法是定义一个通用的响应体：

@Data public class Result<T> { private Integer code; // 状态码，200成功，500失败 private String message; // 提示信息 private T data; // 泛型数据 }

Controller中所有接口都返回Result：

@PostMapping("/add") public Result<Void> add(@RequestBody CartDTO cartDTO) { cartService.addToCart(cartDTO); return Result.success(); } @GetMapping("/list") public Result<List<DishVO>> list(@RequestParam Long categoryId) { List<DishVO> list = dishService.listByCategory(categoryId); return Result.success(list); }

这样做的好处是前端有一套统一的处理逻辑：先判断code == 200，是则取数据渲染页面，否则弹提示信息。你在写论文时也可以把"统一返回对象"作为一个设计亮点写进去——它体现了后端接口设计的规范性和一致性。

5.5 图片上传：一个容易被忽略的静态资源映射坑

菜品图片上传是毕设里常见但容易被卡住的功能。核心逻辑是：前端将图片文件上传到后端，后端将文件保存到服务器本地磁盘，然后返回一个可访问的URL。这里最大的坑在于，保存后的图片默认无法通过浏览器直接访问，因为Spring Boot默认只暴露static目录下的静态资源。

解决方案分两步。第一步，在配置文件中指定上传保存目录：

file: upload-path: D:/upload/

第二步，添加一个资源映射配置，将/images/**请求映射到本地磁盘目录：

@Configuration public class WebConfig implements WebMvcConfigurer { @Value("${file.upload-path}") private String uploadPath; @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/images/**") .addResourceLocations("file:" + uploadPath); } }

完成这一步，上传的图片就能通过http://localhost:8080/images/xxx.jpg访问了。这个功能几乎每一届都会有人卡住，提前知道，可以省下不少时间。

6. 联调与测试：本地怎么把系统完整跑起来

功能代码写完后，下一步是联调测试。很多学生在这里出了问题：IDE里点运行，浏览器输入地址，页面显示出来了，就认为项目做好了。实际上中间还藏着很多细节问题。

6.1 一套标准的本地启动检查顺序

我建议按照这个顺序逐一检查，确保整个系统启动时不出意外：

1. 启动MySQL服务，确认3306端口没有被占用，使用Navicat或命令行连接成功。
2. 检查数据库连接配置——application.yml中的用户名、密码、数据库名是否与本机一致。
3. 检查MySQL版本对应驱动，使用8.0的MySQL必须配上8.x的驱动依赖，使用5.7的则对应5.1.49。
4. 启动项目，观察控制台日志。如果出现Port 8080 was already in use，说明端口被占，要么关掉占用进程，要么在配置里换一个端口（server.port=8081）。
5. 初始化数据，执行项目提供的SQL脚本。

6.2 测试用例到底要不要写

关于测试，有一个很现实的矛盾：毕业设计要求写测试，但大部分学生从来没写过测试。我的建议是不必强求做单元测试——写一堆Assert.assertEquals反而容易暴露设计问题。但是有一个低成本高回报的替代方案：做好接口测试记录。用Postman或Apifox逐个测试接口，把请求参数、返回结果截图，放在论文的"系统测试"章节中作为测试用例和测试结果展示。这是论文中"系统测试"章节最标准的素材来源，比源代码重要得多。

6.3 典型的Bug场景排查

列举几个我见过的高频Bug，你大概率会遇到其中一两个：

场景一：登录成功后刷新页面又跳回登录页。

排查思路：检查拦截器的排除路径是否包含了静态资源路径；检查Session中是否有用户信息；检查重定向是forward还是redirect，如果是redirect确认浏览器地址栏的变化。

场景二：下单报错：Cannot call commit when autocommit is enabled。

排查思路：多数据源配置导致的事务代理失效，或Service方法没有被Spring管理。检查ServiceImpl是否标注@Service，方法是否为public，以及类是否被Spring容器扫描到。

场景三：菜品图片上传成功但页面无法显示。

排查思路：参考5.5节的静态资源映射配置，检查/images/**映射是否正确，确认文件确实保存在了配置目录下。

场景四：No qualifying bean of type Mapper。

排查思路：启动类上没有加@MapperScan注解，或者Mapper接口上缺少@Mapper注解。二选一加上，问题就会解决。

7. 论文与答辩准备：怎么把"做完了"转成"做好了"

代码写完之后，论文和答辩的准备是同等重要的环节。很多学生代码写得好但答辩翻车，主要原因是不会讲"设计决策"。下面挑几个论文写作和答辩中最典型的场景给出参考。

7.1 论文架构怎么安排更顺畅

毕设论文的结构虽然各校有差异，但核心章节是大同小异的。以订餐管理系统为基础，我建议按这个主线来组织：

7.2 论文中一定要有的三张图

第一张是系统架构图。不需要画得很复杂，画清三层架构（Controller、Service、Mapper）及它们之间的调用关系即可。第二张是功能结构图。用思维导图的形式画出用户端和管理员端各自的功能菜单，让导师一眼看清系统有哪些模块。第三张是数据库ER图。用工具画出所有表结构，标好主外键。这三张图画好，论文的"设计"部分就已经成功了一半。

画图工具直接用ProcessOn或draw.io，都是免费的，导出的图片可以无缝插入Word。

7.3 答辩高频问题提前准备

根据往年经验，整理了一份答辩老师最爱问的问题清单，每个问题都要能脱稿回答两三句：

问题一：系统有哪些角色？各自能做什么？

参考回答：系统分为用户和管理员两个角色。用户登录后可以浏览菜品、添加购物车、提交订单、查看历史订单；管理员登录后台可以管理菜品分类、菜品信息、处理订单状态和查看统计报表。

问题二：下单时如何保证数据一致性？

参考回答：我在下单的Service方法上加了@Transactional事务管理，包括插入订单表、插入订单明细、扣减库存这些操作放在了同一事务中。任何一个环节出错都会整体回滚，不会留下部分成功的数据。

问题三：密码是明文存储吗？

参考回答：不是。我使用MD5（或BCrypt）对密码进行加密后存储。登录时对传入密码做同样加密后与数据库比对。（这里要强调不能明文存储，哪怕你没有加密也要在答辩前把代码补上。）

问题四：一个菜品的库存为0时，前端还能下单吗？

参考回答：不能。后端在下单前会校验库存是否充足，并且使用了带条件更新的SQL语句，库存不足时更新操作会返回0行，我会同时抛出一个业务异常来终止订单提交。

问题五：如果用户下单后没有支付成功，库存会一直扣减吗？

参考回答：不会。我这里的设计是下单后库存立即扣减、订单为待付款状态，超时未支付会自动取消订单并回补库存。（如果你的设计是支付成功后扣库存，也要能讲清楚自己的思路。）

提醒：答辩时最忌讳的就是"这个问题我之前没考虑到"。如果准备时间来得及，建议你把自己系统里的薄弱点提前走一遍，用一个相对合理的理由就能圆回来，别沉默或硬编。

7.4 演示环境的稳定是答辩的基本盘

最后讲一个所有答辩翻车案例里最可惜的场景：系统代码没问题，但是在答辩现场跑不起来。原因通常是这几类：MySQL服务没启动、端口被占用、数据库连接配置失效、电脑休眠导致会话中断。建议在答辩前一天做一次"冷启动测试"：关机重启电脑，只打开IDEA和MySQL，按顺序启动项目，完整跑一遍登录、下单、查单主链路。这个过程能暴露绝大多数环境问题，也能让你对演示流程更有把握。

8. 写在最后：从毕设到简历项目的一条不大不小的建议

做完这一套系统，你手上的产出其实不只是"能过毕设"，而是一份可以直接写进简历的"项目经历"。建议你把项目核心亮点梳理成一段话，放在简历的项目经验栏里，例如：

• 设计并实现了一个基于Spring Boot + MyBatis的订餐管理系统，覆盖菜品管理、购物车、订单流转、库存扣减等完整业务链路。
• 通过Redis分布式ID或自定义规则生成订单编号，保证订单号唯一且可溯源。
• 使用拦截器实现用户登录鉴权，统一处理后端接口的登录校验。
• 采用@Transactional事务管理方案，解决下单流程中订单与库存的数据一致性问题。

面试官看到这条项目经历，大概率会追问"你这个系统的订单状态是怎么设计的""库存扣减遇到并发请求怎么处理"——这些问题的答案，其实在前面几节内容里都已经有了解答。所以，认真把这一套做完，不只是给毕设一个交代，也是在为求职铺垫一段能经得起深挖的项目经验。

如果时间还充裕，再分享一个后续可以扩展的方向：在现有系统里增加一个"菜品销量排行"的统计模块，或者接一个ECharts数据可视化的大屏，展示今天的营业数据。这个扩展不需要重新建表，基于订单明细表一条分组SQL就能实现，但做完之后答辩和简历都会多一个亮点。

好了，就写到这里。动手做完一个完整项目之后你会发现，毕设没有想象中那么难，真正难的是"开始"。把环境配置好，把第一张表建出来，把第一个接口跑通，后面的事情就顺了。