尧图网页设计 
简介这是一份面向计算机专业学生与Java Web开发初学者的毕业设计论文文档主题为基于JAVA的饭店点餐系统可用于课程设计参考、论文写作借鉴或同类项目开发思路学习。论文围绕B/S体系结构展开采用JAVA语言、MySQL数据库、Tomcat服务器与MyEclipse工具系统角色分为用户与管理员涵盖菜品明细管理、订单管理、菜品管理、厨师管理、菜品分类管理、餐桌座位管理及管理员管理七大功能模块并附有摘要、目录、绪论、开发技术介绍等完整章节结构。资源包内共1个doc文件压缩包大小约2.31MB内容为完整论文正文便于直接阅读与格式参考。目前已有153人学习浏览适合需要快速了解点餐系统设计流程、模块划分与论文撰写框架的读者参考使用。1. 饭店点餐系统用 Java 写2026 年还值不值得动手如果你正在搜「基于JAVA的饭店点餐系论文.doc」大概率不是想读一篇论文而是想把这个题目变成一个能跑起来、能演示、能写进简历或答辩材料的东西。我见过太多人卡在同一个地方论文目录写得漂亮真到建表、写接口、连数据库的时候发现连「桌台状态怎么流转」都说不清楚。饭店点餐系统这个场景表面是 CRUD实际藏着并发、状态机、权限和金额计算四类硬骨头。Java 做这件事的优势在于生态成熟Spring Boot 加 MyBatis 几乎是默认组合遇到问题搜得到答案面试时也能把「行级权限」「数据一致性」这些词讲出细节。这篇笔记按「先跑通最小闭环再补状态和权限最后处理并发和金额」的顺序展开适合要交课程设计的学生也适合想拿一个完整业务练手的 Java 后端新人。2. 先定技术栈和表结构别急着写 Controller2.1 为什么选 Spring Boot MyBatis 而不是 JPA饭店点餐系统的查询模式很固定按桌台查未支付订单、按菜品分类查在售菜品、按时间段统计营业额。这种场景下 SQL 可控性比 ORM 自动生成更重要。MyBatis 允许你把「查某桌当前未结订单」写成一条明确的 SQL字段和索引都能自己控制。JPA 在关联查询多的时候容易生成 N1 的 SQL排查起来像开黑匣子。常见做法是 Spring Boot 3.x 配 MyBatis-Plus基础 CRUD 不用写复杂统计自己写 XML。Java 环境变量配置如果还没弄好先把 JDK 17 装好java -version能输出就行别在这步耗太久。2.2 六张核心表的最小字段设计表结构定错后面改起来全是血泪。下面六张表覆盖了「桌台—菜品—订单—订单明细—用户—支付记录」这条主链字段只列必须的先跑通再扩。表名关键字段说明dining_tableid, table_no, capacity, statusstatus: 0空闲 1占用 2预订dishid, name, price, category_id, stock, statusstatus: 0下架 1在售ordersid, table_id, user_id, total_amount, status, create_timestatus: 0待支付 1已支付 2已取消order_itemid, order_id, dish_id, quantity, unit_price单价快照不随菜品改价变动sys_userid, username, password, rolerole: 0顾客 1服务员 2管理员paymentid, order_id, pay_type, amount, pay_time支付流水和订单分开order_item里的unit_price必须是下单那一刻的快照。我见过有人直接关联dish.price算总价结果菜品调价后历史订单金额全变了对账时翻车。orders.status用整数而不是字符串索引效率更高但要在代码里定义枚举别在 SQL 里硬写 0 和 1。2.3 建表 SQL 和索引该加在哪CREATE TABLE orders ( id BIGINT PRIMARY KEY AUTO_INCREMENT, table_id BIGINT NOT NULL, user_id BIGINT NOT NULL, total_amount DECIMAL(10,2) NOT NULL DEFAULT 0.00, status TINYINT NOT NULL DEFAULT 0, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, INDEX idx_table_status (table_id, status), INDEX idx_create_time (create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;idx_table_status服务「查某桌未结订单」这个高频查询idx_create_time服务营业额按天统计。金额字段用DECIMAL不用FLOAT浮点误差在收银场景是致命的。字符集统一utf8mb4菜品名里可能有生僻字或符号。建完表先插两条测试数据用SELECT确认字段类型和预期一致再往下写代码。3. 把点餐主流程跑通从选桌到下单的接口链路3.1 桌台状态流转的接口设计桌台状态是整个系统的入口。顾客扫码后先查桌台是否可用下单时把桌台置为占用结账后释放。三个接口对应三个动作RestController RequestMapping(/api/table) public class TableController { Autowired private TableService tableService; // 查询可用桌台列表 GetMapping(/available) public ResultListDiningTable available() { return Result.ok(tableService.listByStatus(0)); } // 开台空闲 - 占用 PostMapping(/{id}/occupy) public ResultVoid occupy(PathVariable Long id) { // 用乐观锁或条件更新防止重复开台 boolean ok tableService.updateStatus(id, 0, 1); return ok ? Result.ok() : Result.fail(桌台已被占用); } // 结账后释放占用 - 空闲 PostMapping(/{id}/release) public ResultVoid release(PathVariable Long id) { tableService.updateStatus(id, 1, 0); return Result.ok(); } }updateStatus的 SQL 必须带原状态条件UPDATE dining_table SET status#{newStatus} WHERE id#{id} AND status#{oldStatus}。这样两个服务员同时点同一桌只有一个能成功另一个返回影响行数 0。这是最轻量的并发控制比加锁简单比不管强太多。参数说明oldStatus和newStatus由调用方传入Service 层不写死方便后续加「预订」状态。3.2 下单接口金额计算和库存扣减的顺序下单是主流程里最容易出问题的一步。正确顺序是校验菜品在售 → 校验库存 → 计算金额 → 写订单 → 写明细 → 扣库存 → 占桌台。任何一步失败都要回滚。Transactional(rollbackFor Exception.class) public Long createOrder(OrderCreateDTO dto) { // 1. 校验并锁定菜品用 SELECT ... FOR UPDATE 防超卖 ListDish dishes dishMapper.selectByIdsForUpdate(dto.getDishIds()); BigDecimal total BigDecimal.ZERO; for (OrderItemDTO item : dto.getItems()) { Dish dish findDish(dishes, item.getDishId()); if (dish.getStatus() ! 1) throw new BizException(菜品已下架); if (dish.getStock() item.getQuantity()) throw new BizException(库存不足); total total.add(dish.getPrice().multiply(BigDecimal.valueOf(item.getQuantity()))); } // 2. 写订单 Orders order new Orders(); order.setTableId(dto.getTableId()); order.setTotalAmount(total); order.setStatus(0); orderMapper.insert(order); // 3. 写明细 扣库存 for (OrderItemDTO item : dto.getItems()) { Dish dish findDish(dishes, item.getDishId()); OrderItem oi new OrderItem(); oi.setOrderId(order.getId()); oi.setDishId(dish.getId()); oi.setQuantity(item.getQuantity()); oi.setUnitPrice(dish.getPrice()); // 快照 orderItemMapper.insert(oi); dishMapper.decreaseStock(dish.getId(), item.getQuantity()); } return order.getId(); }selectByIdsForUpdate在事务里对菜品行加排他锁防止两个人同时买最后一份。decreaseStock的 SQL 写成UPDATE dish SET stock stock - #{qty} WHERE id #{id} AND stock #{qty}影响行数为 0 就抛异常回滚。金额用BigDecimal的multiply和add不要用double。这个接口的坑在于如果先扣库存再写订单写订单失败时库存已经少了所以顺序不能反。3.3 用 Postman 或 curl 验证整条链路写完接口别急着写前端先用 curl 把链路走一遍# 1. 查可用桌台 curl http://localhost:8080/api/table/available # 2. 开台 curl -X POST http://localhost:8080/api/table/1/occupy # 3. 下单 curl -X POST http://localhost:8080/api/order/create \ -H Content-Type: application/json \ -d {tableId:1,items:[{dishId:1,quantity:2}]} # 4. 查订单 curl http://localhost:8080/api/order/1每步确认返回的code和data。如果第 3 步报「库存不足」去数据库看dish.stock是不是被之前的测试扣完了。验证通过后再写前端页面否则前后端一起调出问题分不清是谁的锅。4. 权限和状态机让系统像个真饭店在跑4.1 三种角色的行级权限怎么落地饭店点餐系统至少三种角色顾客只能看自己的订单服务员能看所有桌台和订单管理员能改菜品和价格。行级权限的意思是「同一张表不同角色看到不同行」。常见做法是在 SQL 里拼user_id条件而不是在 Java 里过滤。// MyBatis XML 里根据角色动态拼条件 select idlistOrders resultTypeOrders SELECT * FROM orders where if testrole 0 AND user_id #{userId} /if if testrole 1 AND status IN (0, 1) /if /where ORDER BY create_time DESC /select顾客角色role0只能查自己的服务员role1查待支付和已支付管理员不拼条件看全部。userId从登录 token 里取不要从前端传否则改个参数就能看别人订单。这个设计比在 Controller 里if (role 0) filterByUser()更安全因为过滤发生在数据库层漏掉的可能性小。4.2 订单状态机哪些流转合法哪些必须拦订单状态不是随便改的。合法流转只有待支付 → 已支付、待支付 → 已取消、已支付 → 已完成可选。其他流转一律拒绝。public enum OrderStatus { PENDING(0), PAID(1), CANCELLED(2), FINISHED(3); private final int code; // 定义合法流转 public static boolean canTransfer(int from, int to) { if (from 0 (to 1 || to 2)) return true; if (from 1 to 3) return true; return false; } }在更新状态前调canTransfer不合法就抛异常。我见过有人把「已取消」的订单又改成「已支付」对账时多出一笔钱。状态机写在 Java 枚举里比散落在各个 Service 里可靠。如果后续要加「退款」从已支付到已退款是新的合法边改枚举就行。4.3 定时任务处理超时未支付订单顾客下单后一直不支付桌台一直被占着后面的人用不了。常见做法是加一个定时任务每 5 分钟扫一次超过 15 分钟未支付的订单自动取消并释放桌台。Scheduled(fixedRate 300000) // 5 分钟 public void cancelTimeoutOrders() { LocalDateTime deadline LocalDateTime.now().minusMinutes(15); ListOrders timeoutOrders orderMapper.selectTimeout(0, deadline); for (Orders order : timeoutOrders) { order.setStatus(2); // 已取消 orderMapper.updateById(order); tableService.release(order.getTableId()); } }selectTimeout的 SQL 用status 0 AND create_time #{deadline}走idx_create_time索引。定时任务框架用 Spring 自带的Scheduled就够别一上来就上 Quartz。注意任务要加日志否则订单被取消了顾客来问你查不到是谁取消的。5. 避坑与排查那些让演示当场翻车的细节5.1 金额用 double 导致对账差几分钱现象订单明细加起来和总金额差 0.01 元演示时被老师或面试官一眼看出。原因double和float是二进制浮点0.1 0.2 ! 0.3。解决所有金额字段用DECIMAL(10,2)Java 里用BigDecimal构造时用new BigDecimal(0.1)而不是new BigDecimal(0.1)。比较用compareTo不用equals。5.2 并发下单导致库存扣成负数现象两个人同时买最后一份菜库存变成 -1。原因先查库存再扣中间没有锁。解决扣库存 SQL 带AND stock #{qty}条件影响行数为 0 就抛异常回滚。或者用SELECT ... FOR UPDATE在事务里锁行。两种方式选一种别混用。5.3 桌台状态更新丢失现象两个服务员同时给同一桌开台都提示成功但桌台只被占了一次。原因UPDATE没带原状态条件后一次覆盖前一次。解决UPDATE dining_table SET status1 WHERE id? AND status0判断影响行数。这是乐观锁的简化版不需要额外版本号字段。5.4 订单明细的菜品名查不到现象订单列表显示菜品名为空。原因order_item只存了dish_id菜品被删除后关联查不到。解决order_item里冗余存dish_name快照和unit_price一样。历史订单要能独立展示不依赖菜品表是否还在。5.5 定时任务把正在支付的订单取消了现象顾客刚点支付订单被定时任务取消。原因定时任务和支付接口并发支付接口还没更新状态定时任务已经扫到了。解决支付接口先更新状态再调支付网关定时任务取消前再查一次状态或者给订单加一个「支付中」的中间状态。简单做法是把超时时间设长一点比如 30 分钟减少撞车概率。6. 进阶技巧把论文里的「数据一致性」讲出真东西6.1 用本地消息表保证订单和支付记录一致订单支付成功后要写payment表两个写操作不在一个事务里就可能不一致。常见做法是本地消息表在订单库里建一张message表支付成功时在同一个事务里写订单状态和一条消息另一个线程读消息去写payment写完标记消息已处理。Transactional public void pay(Long orderId) { Orders order orderMapper.selectById(orderId); if (order.getStatus() ! 0) throw new BizException(订单状态不允许支付); order.setStatus(1); orderMapper.updateById(order); // 同事务写消息 Message msg new Message(); msg.setOrderId(orderId); msg.setType(PAYMENT); msg.setStatus(0); messageMapper.insert(msg); }另一个定时任务扫message表里status0的记录写payment后把status改成 1。这样即使写payment失败消息还在重试就行。这个方案比分布式事务轻比不管强。论文里写「保证数据一致性」时把这段讲清楚比堆概念有说服力。6.2 用接口自动化测试守住主流程改代码最怕把下单流程改坏。用 JUnit 加 MockMvc 写一个端到端测试每次改完跑一遍。Test public void testCreateOrder() throws Exception { // 先开台 mockMvc.perform(post(/api/table/1/occupy)).andExpect(status().isOk()); // 下单 String body {\tableId\:1,\items\:[{\dishId\:1,\quantity\:1}]}; mockMvc.perform(post(/api/order/create) .contentType(MediaType.APPLICATION_JSON) .content(body)) .andExpect(jsonPath($.code).value(0)) .andExpect(jsonPath($.data).isNumber()); // 验证库存减了 Dish dish dishMapper.selectById(1L); assertEquals(9, dish.getStock()); }这个测试覆盖了开台、下单、库存扣减三个关键点。参数说明dishId1的初始库存设为 10下单 1 份后断言为 9。每次改下单逻辑先跑这个测试绿了再提交。我自己的习惯是任何涉及金额和库存的改动没有测试覆盖就不合并。6.3 一个具体技巧用枚举代替魔法数字系统里到处是status0、role1过两周自己都忘了什么意思。把状态和角色定义成枚举数据库存 codeJava 里用枚举。public enum Role { CUSTOMER(0), WAITER(1), ADMIN(2); private final int code; Role(int code) { this.code code; } public int getCode() { return code; } public static Role of(int code) { for (Role r : values()) if (r.code code) return r; throw new IllegalArgumentException(未知角色: code); } }Controller 里Role.of(user.getRole())拿到枚举再判断权限。这样代码可读改角色定义只改一处。我吃过亏早期用if (role 1)判断服务员后来加了「经理」角色 code3忘了改某处判断经理登录后看不到订单。枚举加of方法能逼你在编译期想清楚所有分支。这套东西跑通后论文里的「系统实现」章节就有真东西可写表结构、接口链路、状态机、并发处理、一致性方案。别停在「增删改查」层面把库存扣减的顺序、金额快照、行级权限的 SQL 拼法写进去答辩时被问到细节也能接住。希望帮到你。本文还有配套的精品资源点击获取 Java饭店点餐系统实战：从表结构到并发处理，2026年还值得做吗？
简介这是一份面向计算机专业学生与Java Web开发初学者的毕业设计论文文档主题为基于JAVA的饭店点餐系统可用于课程设计参考、论文写作借鉴或同类项目开发思路学习。论文围绕B/S体系结构展开采用JAVA语言、MySQL数据库、Tomcat服务器与MyEclipse工具系统角色分为用户与管理员涵盖菜品明细管理、订单管理、菜品管理、厨师管理、菜品分类管理、餐桌座位管理及管理员管理七大功能模块并附有摘要、目录、绪论、开发技术介绍等完整章节结构。资源包内共1个doc文件压缩包大小约2.31MB内容为完整论文正文便于直接阅读与格式参考。目前已有153人学习浏览适合需要快速了解点餐系统设计流程、模块划分与论文撰写框架的读者参考使用。1. 饭店点餐系统用 Java 写2026 年还值不值得动手如果你正在搜「基于JAVA的饭店点餐系论文.doc」大概率不是想读一篇论文而是想把这个题目变成一个能跑起来、能演示、能写进简历或答辩材料的东西。我见过太多人卡在同一个地方论文目录写得漂亮真到建表、写接口、连数据库的时候发现连「桌台状态怎么流转」都说不清楚。饭店点餐系统这个场景表面是 CRUD实际藏着并发、状态机、权限和金额计算四类硬骨头。Java 做这件事的优势在于生态成熟Spring Boot 加 MyBatis 几乎是默认组合遇到问题搜得到答案面试时也能把「行级权限」「数据一致性」这些词讲出细节。这篇笔记按「先跑通最小闭环再补状态和权限最后处理并发和金额」的顺序展开适合要交课程设计的学生也适合想拿一个完整业务练手的 Java 后端新人。2. 先定技术栈和表结构别急着写 Controller2.1 为什么选 Spring Boot MyBatis 而不是 JPA饭店点餐系统的查询模式很固定按桌台查未支付订单、按菜品分类查在售菜品、按时间段统计营业额。这种场景下 SQL 可控性比 ORM 自动生成更重要。MyBatis 允许你把「查某桌当前未结订单」写成一条明确的 SQL字段和索引都能自己控制。JPA 在关联查询多的时候容易生成 N1 的 SQL排查起来像开黑匣子。常见做法是 Spring Boot 3.x 配 MyBatis-Plus基础 CRUD 不用写复杂统计自己写 XML。Java 环境变量配置如果还没弄好先把 JDK 17 装好java -version能输出就行别在这步耗太久。2.2 六张核心表的最小字段设计表结构定错后面改起来全是血泪。下面六张表覆盖了「桌台—菜品—订单—订单明细—用户—支付记录」这条主链字段只列必须的先跑通再扩。表名关键字段说明dining_tableid, table_no, capacity, statusstatus: 0空闲 1占用 2预订dishid, name, price, category_id, stock, statusstatus: 0下架 1在售ordersid, table_id, user_id, total_amount, status, create_timestatus: 0待支付 1已支付 2已取消order_itemid, order_id, dish_id, quantity, unit_price单价快照不随菜品改价变动sys_userid, username, password, rolerole: 0顾客 1服务员 2管理员paymentid, order_id, pay_type, amount, pay_time支付流水和订单分开order_item里的unit_price必须是下单那一刻的快照。我见过有人直接关联dish.price算总价结果菜品调价后历史订单金额全变了对账时翻车。orders.status用整数而不是字符串索引效率更高但要在代码里定义枚举别在 SQL 里硬写 0 和 1。2.3 建表 SQL 和索引该加在哪CREATE TABLE orders ( id BIGINT PRIMARY KEY AUTO_INCREMENT, table_id BIGINT NOT NULL, user_id BIGINT NOT NULL, total_amount DECIMAL(10,2) NOT NULL DEFAULT 0.00, status TINYINT NOT NULL DEFAULT 0, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, INDEX idx_table_status (table_id, status), INDEX idx_create_time (create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;idx_table_status服务「查某桌未结订单」这个高频查询idx_create_time服务营业额按天统计。金额字段用DECIMAL不用FLOAT浮点误差在收银场景是致命的。字符集统一utf8mb4菜品名里可能有生僻字或符号。建完表先插两条测试数据用SELECT确认字段类型和预期一致再往下写代码。3. 把点餐主流程跑通从选桌到下单的接口链路3.1 桌台状态流转的接口设计桌台状态是整个系统的入口。顾客扫码后先查桌台是否可用下单时把桌台置为占用结账后释放。三个接口对应三个动作RestController RequestMapping(/api/table) public class TableController { Autowired private TableService tableService; // 查询可用桌台列表 GetMapping(/available) public ResultListDiningTable available() { return Result.ok(tableService.listByStatus(0)); } // 开台空闲 - 占用 PostMapping(/{id}/occupy) public ResultVoid occupy(PathVariable Long id) { // 用乐观锁或条件更新防止重复开台 boolean ok tableService.updateStatus(id, 0, 1); return ok ? Result.ok() : Result.fail(桌台已被占用); } // 结账后释放占用 - 空闲 PostMapping(/{id}/release) public ResultVoid release(PathVariable Long id) { tableService.updateStatus(id, 1, 0); return Result.ok(); } }updateStatus的 SQL 必须带原状态条件UPDATE dining_table SET status#{newStatus} WHERE id#{id} AND status#{oldStatus}。这样两个服务员同时点同一桌只有一个能成功另一个返回影响行数 0。这是最轻量的并发控制比加锁简单比不管强太多。参数说明oldStatus和newStatus由调用方传入Service 层不写死方便后续加「预订」状态。3.2 下单接口金额计算和库存扣减的顺序下单是主流程里最容易出问题的一步。正确顺序是校验菜品在售 → 校验库存 → 计算金额 → 写订单 → 写明细 → 扣库存 → 占桌台。任何一步失败都要回滚。Transactional(rollbackFor Exception.class) public Long createOrder(OrderCreateDTO dto) { // 1. 校验并锁定菜品用 SELECT ... FOR UPDATE 防超卖 ListDish dishes dishMapper.selectByIdsForUpdate(dto.getDishIds()); BigDecimal total BigDecimal.ZERO; for (OrderItemDTO item : dto.getItems()) { Dish dish findDish(dishes, item.getDishId()); if (dish.getStatus() ! 1) throw new BizException(菜品已下架); if (dish.getStock() item.getQuantity()) throw new BizException(库存不足); total total.add(dish.getPrice().multiply(BigDecimal.valueOf(item.getQuantity()))); } // 2. 写订单 Orders order new Orders(); order.setTableId(dto.getTableId()); order.setTotalAmount(total); order.setStatus(0); orderMapper.insert(order); // 3. 写明细 扣库存 for (OrderItemDTO item : dto.getItems()) { Dish dish findDish(dishes, item.getDishId()); OrderItem oi new OrderItem(); oi.setOrderId(order.getId()); oi.setDishId(dish.getId()); oi.setQuantity(item.getQuantity()); oi.setUnitPrice(dish.getPrice()); // 快照 orderItemMapper.insert(oi); dishMapper.decreaseStock(dish.getId(), item.getQuantity()); } return order.getId(); }selectByIdsForUpdate在事务里对菜品行加排他锁防止两个人同时买最后一份。decreaseStock的 SQL 写成UPDATE dish SET stock stock - #{qty} WHERE id #{id} AND stock #{qty}影响行数为 0 就抛异常回滚。金额用BigDecimal的multiply和add不要用double。这个接口的坑在于如果先扣库存再写订单写订单失败时库存已经少了所以顺序不能反。3.3 用 Postman 或 curl 验证整条链路写完接口别急着写前端先用 curl 把链路走一遍# 1. 查可用桌台 curl http://localhost:8080/api/table/available # 2. 开台 curl -X POST http://localhost:8080/api/table/1/occupy # 3. 下单 curl -X POST http://localhost:8080/api/order/create \ -H Content-Type: application/json \ -d {tableId:1,items:[{dishId:1,quantity:2}]} # 4. 查订单 curl http://localhost:8080/api/order/1每步确认返回的code和data。如果第 3 步报「库存不足」去数据库看dish.stock是不是被之前的测试扣完了。验证通过后再写前端页面否则前后端一起调出问题分不清是谁的锅。4. 权限和状态机让系统像个真饭店在跑4.1 三种角色的行级权限怎么落地饭店点餐系统至少三种角色顾客只能看自己的订单服务员能看所有桌台和订单管理员能改菜品和价格。行级权限的意思是「同一张表不同角色看到不同行」。常见做法是在 SQL 里拼user_id条件而不是在 Java 里过滤。// MyBatis XML 里根据角色动态拼条件 select idlistOrders resultTypeOrders SELECT * FROM orders where if testrole 0 AND user_id #{userId} /if if testrole 1 AND status IN (0, 1) /if /where ORDER BY create_time DESC /select顾客角色role0只能查自己的服务员role1查待支付和已支付管理员不拼条件看全部。userId从登录 token 里取不要从前端传否则改个参数就能看别人订单。这个设计比在 Controller 里if (role 0) filterByUser()更安全因为过滤发生在数据库层漏掉的可能性小。4.2 订单状态机哪些流转合法哪些必须拦订单状态不是随便改的。合法流转只有待支付 → 已支付、待支付 → 已取消、已支付 → 已完成可选。其他流转一律拒绝。public enum OrderStatus { PENDING(0), PAID(1), CANCELLED(2), FINISHED(3); private final int code; // 定义合法流转 public static boolean canTransfer(int from, int to) { if (from 0 (to 1 || to 2)) return true; if (from 1 to 3) return true; return false; } }在更新状态前调canTransfer不合法就抛异常。我见过有人把「已取消」的订单又改成「已支付」对账时多出一笔钱。状态机写在 Java 枚举里比散落在各个 Service 里可靠。如果后续要加「退款」从已支付到已退款是新的合法边改枚举就行。4.3 定时任务处理超时未支付订单顾客下单后一直不支付桌台一直被占着后面的人用不了。常见做法是加一个定时任务每 5 分钟扫一次超过 15 分钟未支付的订单自动取消并释放桌台。Scheduled(fixedRate 300000) // 5 分钟 public void cancelTimeoutOrders() { LocalDateTime deadline LocalDateTime.now().minusMinutes(15); ListOrders timeoutOrders orderMapper.selectTimeout(0, deadline); for (Orders order : timeoutOrders) { order.setStatus(2); // 已取消 orderMapper.updateById(order); tableService.release(order.getTableId()); } }selectTimeout的 SQL 用status 0 AND create_time #{deadline}走idx_create_time索引。定时任务框架用 Spring 自带的Scheduled就够别一上来就上 Quartz。注意任务要加日志否则订单被取消了顾客来问你查不到是谁取消的。5. 避坑与排查那些让演示当场翻车的细节5.1 金额用 double 导致对账差几分钱现象订单明细加起来和总金额差 0.01 元演示时被老师或面试官一眼看出。原因double和float是二进制浮点0.1 0.2 ! 0.3。解决所有金额字段用DECIMAL(10,2)Java 里用BigDecimal构造时用new BigDecimal(0.1)而不是new BigDecimal(0.1)。比较用compareTo不用equals。5.2 并发下单导致库存扣成负数现象两个人同时买最后一份菜库存变成 -1。原因先查库存再扣中间没有锁。解决扣库存 SQL 带AND stock #{qty}条件影响行数为 0 就抛异常回滚。或者用SELECT ... FOR UPDATE在事务里锁行。两种方式选一种别混用。5.3 桌台状态更新丢失现象两个服务员同时给同一桌开台都提示成功但桌台只被占了一次。原因UPDATE没带原状态条件后一次覆盖前一次。解决UPDATE dining_table SET status1 WHERE id? AND status0判断影响行数。这是乐观锁的简化版不需要额外版本号字段。5.4 订单明细的菜品名查不到现象订单列表显示菜品名为空。原因order_item只存了dish_id菜品被删除后关联查不到。解决order_item里冗余存dish_name快照和unit_price一样。历史订单要能独立展示不依赖菜品表是否还在。5.5 定时任务把正在支付的订单取消了现象顾客刚点支付订单被定时任务取消。原因定时任务和支付接口并发支付接口还没更新状态定时任务已经扫到了。解决支付接口先更新状态再调支付网关定时任务取消前再查一次状态或者给订单加一个「支付中」的中间状态。简单做法是把超时时间设长一点比如 30 分钟减少撞车概率。6. 进阶技巧把论文里的「数据一致性」讲出真东西6.1 用本地消息表保证订单和支付记录一致订单支付成功后要写payment表两个写操作不在一个事务里就可能不一致。常见做法是本地消息表在订单库里建一张message表支付成功时在同一个事务里写订单状态和一条消息另一个线程读消息去写payment写完标记消息已处理。Transactional public void pay(Long orderId) { Orders order orderMapper.selectById(orderId); if (order.getStatus() ! 0) throw new BizException(订单状态不允许支付); order.setStatus(1); orderMapper.updateById(order); // 同事务写消息 Message msg new Message(); msg.setOrderId(orderId); msg.setType(PAYMENT); msg.setStatus(0); messageMapper.insert(msg); }另一个定时任务扫message表里status0的记录写payment后把status改成 1。这样即使写payment失败消息还在重试就行。这个方案比分布式事务轻比不管强。论文里写「保证数据一致性」时把这段讲清楚比堆概念有说服力。6.2 用接口自动化测试守住主流程改代码最怕把下单流程改坏。用 JUnit 加 MockMvc 写一个端到端测试每次改完跑一遍。Test public void testCreateOrder() throws Exception { // 先开台 mockMvc.perform(post(/api/table/1/occupy)).andExpect(status().isOk()); // 下单 String body {\tableId\:1,\items\:[{\dishId\:1,\quantity\:1}]}; mockMvc.perform(post(/api/order/create) .contentType(MediaType.APPLICATION_JSON) .content(body)) .andExpect(jsonPath($.code).value(0)) .andExpect(jsonPath($.data).isNumber()); // 验证库存减了 Dish dish dishMapper.selectById(1L); assertEquals(9, dish.getStock()); }这个测试覆盖了开台、下单、库存扣减三个关键点。参数说明dishId1的初始库存设为 10下单 1 份后断言为 9。每次改下单逻辑先跑这个测试绿了再提交。我自己的习惯是任何涉及金额和库存的改动没有测试覆盖就不合并。6.3 一个具体技巧用枚举代替魔法数字系统里到处是status0、role1过两周自己都忘了什么意思。把状态和角色定义成枚举数据库存 codeJava 里用枚举。public enum Role { CUSTOMER(0), WAITER(1), ADMIN(2); private final int code; Role(int code) { this.code code; } public int getCode() { return code; } public static Role of(int code) { for (Role r : values()) if (r.code code) return r; throw new IllegalArgumentException(未知角色: code); } }Controller 里Role.of(user.getRole())拿到枚举再判断权限。这样代码可读改角色定义只改一处。我吃过亏早期用if (role 1)判断服务员后来加了「经理」角色 code3忘了改某处判断经理登录后看不到订单。枚举加of方法能逼你在编译期想清楚所有分支。这套东西跑通后论文里的「系统实现」章节就有真东西可写表结构、接口链路、状态机、并发处理、一致性方案。别停在「增删改查」层面把库存扣减的顺序、金额快照、行级权限的 SQL 拼法写进去答辩时被问到细节也能接住。希望帮到你。本文还有配套的精品资源点击获取