Spring Boot智能餐厅管理系统实战：从订单流转到库存防超卖

做餐饮数字化项目，和做一套普通的管理后台不太一样，业务链路特别长：顾客扫桌上二维码点餐、后厨按订单做菜、服务员上菜核单、收银结账、库存扣减、销售报表，任何一个环节断了，餐厅运营都会出乱子。我最近完整走完了一个基于 Spring Boot 的智能餐厅管理系统的设计与实现，从需求分析、数据库建模、接口开发到前端联调上线，整个过程踩了不少坑，也验证了很多好用的方案。这篇文章就把这套系统从设计到落地的完整过程拆开讲，重点放在订单流转、库存防超卖、实时推送这类容易被忽略的细节上，适合正在做毕业设计或者想自己搭一套餐饮管理系统的开发者参考。

1. 项目从哪来：业务流程梳理与技术选型

1.1 餐厅到底需要系统管住什么

很多初学者一上来就照着“电商后台”的思路设计餐厅系统，结果做出来一堆花哨功能，门店根本用不上。要理解餐厅系统，先回到那个最原始的场景：顾客坐下，服务员递来纸质菜单，顾客勾选菜品，服务员跑到吧台报单，厨师按纸条做菜，最后结账时一张一张算。高峰期一来，漏单、催单、菜品估清不及时、结账对不上账都是家常便饭。

这套系统要解决的就是这些真实痛点。经过和几个做餐饮的朋友反复聊，我把核心用户群体分成了四类：顾客、服务员、后厨、管理者。顾客需要扫码点餐、查看菜品详情、在线支付；服务员需要管理桌台、核单、加菜、发起结账；后厨需要看到新订单、区分“待制作”和“制作中”、标记出餐；管理者需要维护菜品、管理库存、查看门店实时经营数据。四类角色的诉求完全不同，设计上必须分开考虑，但又要在订单这条主线上串起来。

1.2 技术栈为什么这么选

技术选型上，我没有一开始就上微服务，也没有用冷门框架，而是采用了一套很稳的组合：Spring Boot + MyBatis-Plus + MySQL + Redis + Vue 3 + Element Plus。这套组合的优势在于：Spring Boot 生态成熟，社区资料多；MyBatis-Plus 把单表 CRUD 简化了一大半；Redis 承担验证码、菜品缓存、Token 存储；Vue 3 做前后端分离的管理端。顾客点餐端我用的是 H5，部署在 Nginx 下，和同一个后端域名共用，避免小程序审核带来的时间成本。

为什么不用微服务？餐饮门店的场景，即使一个连锁品牌有几十家店，单店的日订单量也就是几百到一两千单，单体架构完全撑得住。微服务带来的注册中心、网关、链路追踪、分布式事务成本，对一个小团队来说不但不能提效，反而会拖慢开发进度。更合适的做法是“模块化单体”：一个 Spring Boot 应用里按业务域分包，模块之间通过明确接口交互。真到了需要拆分的规模，模块边界本来就是清晰的，拆分也只是时间问题。

如果你的运行环境支持最新版本，直接用 Spring Boot 3.x + JDK 17 完全没问题，代码反而更简洁。我出于兼容性考虑用了 JDK 8 基线，下面的示例代码都没用到高版本特性，直接用最稳妥的写法。

1.3 系统模块划分与边界

这套系统我拆成了六个核心模块：系统管理、菜品管理、桌台管理、订单中心、后厨中心、统计报表。

系统管理管用户、角色、权限；菜品管理管分类、菜品、上下架、库存；桌台管理管桌台的占用状态和二维码映射；订单中心是核心，负责创建订单、支付回调、取消、加菜、结账；后厨中心负责接单、制作状态流转、出餐提醒；统计报表负责日报、菜品销量排行、翻台率。

模块划分的关键是让“订单中心”成为唯一的数据源。菜品模块只管菜品本身，不关心订单；库存模块只提供扣减接口，不自己改订单状态。各模块通过 Service 接口互相调用，不直接访问对方数据库表。后续想加“扫码核销”“会员积分”，只新增模块就行，不影响现有链路。

2. 架构设计与数据库建模

2.1 请求到底怎么走：分层架构

整体采用经典的 Controller-Service-Mapper 三层架构，配合 DTO/VO 做数据传输。Controller 层只负责接收参数和返回结果，不做业务逻辑；Service 层承载业务规则；Mapper 层只做数据库交互。为了保证接口返回格式统一，我封装了一个Result<T>，所有接口都返回 code、message、data 三段式结构。

public class Result<T> { private Integer code; private String message; private T data; // 省略构造方法、getter/setter }

前端拿到 code 为 0 才认为成功，其他情况一律弹出 message 里的内容。整个后端配了全局异常处理器@RestControllerAdvice，业务异常直接抛BizException("xx")，由全局处理器统一包装返回。这样做的最大好处是，前端对接完全不需要关心内部异常类型，只认状态码，联调效率高很多。

2.2 数据库建模：餐饮场景的表关系

数据库是这套系统设计中最重要的一环。餐饮业务和电商最大的区别在于“订单 + 桌台 + 菜品”的强关联，而且存在加菜、退菜、换桌等特殊情况。核心表设计如下：

订单选择主从表结构，而不是把所有菜品塞进一个字段，原因是统计需求太常见了：按菜品维度做销量排行、按时间维度做营业额分析、按桌台维度做反台率。如果订单里存的是拼接字符串，每次分析都要拆字符串，性能差还容易出错。

订单明细里我冗余了dish_name和price字段。这不是违反规范，而是有意为之。菜品名称和价格随时可能调整，如果明细不冗余，历史订单展示时价格会跟着菜品的当前价格变，对账就对不上。冗余后，历史订单永远保持下单那一刻的真实快照。

CREATE TABLE orders ( id BIGINT NOT NULL AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT '订单编号', table_id BIGINT NOT NULL COMMENT '桌台id', total_amount DECIMAL(10,2) NOT NULL DEFAULT 0 COMMENT '订单总金额', status TINYINT NOT NULL DEFAULT 0 COMMENT '0待支付 1已支付 2制作中 3待上菜 4已完成 5已取消', create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_order_no (order_no), KEY idx_table_status (table_id, status) ) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4 COMMENT ='订单表';

2.3 订单状态机：让业务进度可追踪

字段里的status不是随便定义的，我把订单生命周期设计成了一个有限状态机。状态机的好处是让每个操作都明确“从哪来、到哪去”，避免代码里随意赋值，把状态改乱了。

状态只能按从 0 到 4 的顺序正向流转，不允许跳转。比如订单不能从“制作中”直接到“已完成”，必须先出餐。这个校验我放在 Service 层统一处理，而不是散落在各个 Controller 里。遇到退款场景，我单独加了一个pay_status字段区分支付状态，不混在订单状态里，否则状态数量膨胀后判断逻辑会非常痛苦。

3. 核心功能实现：点餐下单与实时推送

3.1 用户认证与 JWT 令牌

系统里既有顾客 H5，也有员工管理端，认证方式我统一采用 JWT。顾客扫码后拿微信授权码换 token，员工拿账号密码换 token。JWT 的好处是后端无状态，服务端不需要存储会话，适合前后端分离部署。

public class JwtUtil { private static final SecretKey KEY = Keys.hmacShaKeyFor( "your-256-bit-secret-your-256-bit-secret".getBytes(StandardCharsets.UTF_8)); public static String generateToken(Long userId, String role) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim("role", role) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + 86400000)) .signWith(KEY, SignatureAlgorithm.HS256) .compact(); } }

登录接口校验通过后生成 token 返回给前端，前端后续请求在 header 里带Authorization: Bearer xxx。后端写一个拦截器统一解析 token，解析失败直接返回 401。注意密钥不能用代码里写死的默认值，生产环境要放到配置中心或环境变量里。

3.2 下单接口：事务边界与库存防超卖

点餐下单是整个系统的核心。基本流程是：顾客选择菜品和数量，进入“确认下单”页，后端校验桌台状态、校验菜品是否上架、计算总价、冻结库存，创建订单，最后返回支付参数。这个流程里最容易出问题的是库存扣减和事务边界。

我这样说可能有些抽象，打个比方：店里一天只有 20 份招牌烤鸭，两个顾客同时下单，如果代码先查库存再更新库存，就可能出现两个请求都看到库存 20，结果一更新变成负数，超卖。解决思路不是用“先查后改”，而是用数据库条件更新。

@Transactional(rollbackFor = Exception.class) public Long createOrder(CreateOrderDTO dto) { Dish dish = dishMapper.selectById(dto.getDishId()); if (dish == null || dish.getStatus() != 1) { throw new BizException("菜品不存在或已下架"); } int rows = dishMapper.deductStock(dto.getDishId(), dto.getQuantity()); if (rows == 0) { throw new BizException("库存不足"); } // 创建订单主表、插入明细、生成支付单 }

对应 SQL：

UPDATE dish SET stock = stock - #{quantity} WHERE id = #{dishId} AND stock >= #{quantity}

stock >= quantity这个条件自带原子判断，数据库行锁会保证同一时间只有一个事务能更新成功。影响行数为 0 就是库存不足，直接抛异常回滚，不用自己加锁。整个下单方法加上@Transactional，从扣减库存到生成订单明细，任何一个环节失败都会整体回滚，不会出现“库存扣了但订单没建”的脏数据。

有一个细节要提醒：事务别跨网络调用。如果下单流程里启动了事务，中间又去调支付接口，支付接口需要几十秒甚至更久，数据库连接会被长期占用，高并发下单时连接池很容易被打满。正确的做法是把“创建本地订单”和“请求支付”放在两个阶段，订单先落库为待支付状态，支付回调回来再异步更新订单状态。

3.3 用 WebSocket 把新订单推给后厨

后厨大屏的数据不能靠刷新页面，订单创建后必须实时推送。我用了 WebSocket 做主动推送，后端在订单创建成功后，把包含桌号、菜品列表、订单号的消息推送到后厨端和传菜端。

@Component @ServerEndpoint("/ws/kitchen") public class KitchenWebSocket { private static final Map<String, Session> SESSION_MAP = new ConcurrentHashMap<>(); @OnOpen public void onOpen(Session session) { SESSION_MAP.put(session.getId(), session); } @OnClose public void onClose(Session session) { SESSION_MAP.remove(session.getId()); } public static void pushNewOrder(String message) { SESSION_MAP.values().forEach(session -> { try { session.getBasicRemote().sendText(message); } catch (IOException e) { // 记录日志，忽略单个连接异常 } }); } }

下单成功后调用KitchenWebSocket.pushNewOrder(json),后厨屏幕收到消息后自动弹出新订单卡片，后厨点击“接单”后订单状态变为“制作中”，再次推送“制作中”状态到传菜台，告知服务员准备上菜。这套实时链路比服务员跑腿传话可靠得多，店里高峰期时后厨不需要抬头喊“XX桌好了”，屏幕上清清楚楚。

3.4 结算与统计报表

结账时，服务员发起结账请求，后端校验订单状态，计算实收金额，更新订单状态为“已完成”，同时释放桌台，让下一桌客人可以入座。桌台上扫码二维码和table_id做绑定，顾客重新扫码时如果桌台已占用，会提示当前有人就餐。

统计报表这块，通过 SQL 按天分组汇总即可。比如一天的营业额：

SELECT DATE(create_time) AS day, COUNT(*) AS order_count, SUM(total_amount) AS income FROM orders WHERE status = 4 GROUP BY DATE(create_time) ORDER BY day DESC;

菜品销量排行则从order_item表按dish_name分组聚合。这两个报表数据量不大，直接实时查数据库没问题。数据量大了以后再考虑离线汇总，前期不用过度设计。

4. 权限控制、菜品缓存与联调实战

4.1 RBAC 权限模型落地

系统有四类角色，不同角色能访问的接口完全不同。我的做法是 RBAC 模型：用户关联角色，角色关联菜单权限，接口通过注解控制访问权限。

Spring Security 里配置一个简单的SecurityFilterChain，优先放行登录接口和顾客点餐相关接口，其余接口全部要求认证。权限控制用@PreAuthorize("hasRole('ADMIN')")注解标注在敏感接口上，比如菜品维护、库存调整、员工管理这些接口只允许管理员访问。

@PreAuthorize("hasRole('ADMIN')") @PostMapping("/api/admin/dish") public Result<Void> saveDish(@RequestBody DishDTO dto) { dishService.saveDish(dto); return Result.success(); }

这里有一个容易忽略的坑：角色名和权限标识不要在代码里写死字符串。我一开始把角色名直接写在注解里，后来要加一个“店长”角色，能看报表但不能改菜品，就显得非常别扭。改成权限标识后用数据去配置角色和权限的关联，后续扩展角色只需要在数据库里加一条记录，不用改代码。

4.2 菜品接口的缓存策略

顾客扫码进入菜单页时，会一次性拉取所有上架菜品。这个接口在用餐高峰期访问频率非常高，如果每次都查 MySQL，数据库压力不小。我用 Redis 缓存菜品分类和菜品列表，key 简单设计为menu:list，缓存整个菜单结构。

更新策略是“先更新数据库，再删除缓存”。管理员修改菜品或上下架时，Service 层更新数据库后，直接删掉menu:list这个 key。下一次顾客访问时缓存不存在，就会回源数据库并重新写入缓存。极端情况下，删除缓存失败会导致旧数据残留，我再加一个延迟双删的补偿，或者通过消息队列异步重试删除。

注意：不要用“先删缓存再更新数据库”的顺序，一旦数据库更新失败，缓存里存的就是旧数据，顾客看到的还是下架前的内容，问题会更隐蔽。

缓存不仅要存菜单，还要设置过期时间，比如 1 小时。即使有脏数据，也能在一个小时后自动纠正。这一点在手动测试和线上排查时都很有用。

4.3 前后端联调的必要约定

前后端分离之后，联调时的摩擦点其实比写代码多得多。我这次把接口规范提前固定下来，减少了很多返工。

第一，统一接口路径前缀。后端接口全部带/api，服务端接口带/api/admin，顾客端接口带/api/customer。通过前缀区分来源，便于在网关层做限流和放行。

第二，统一时间格式。所有接口返回的日期字段统一为yyyy-MM-dd HH:mm:ss，不传时间戳。前端展示更直接，也不容易因为时区问题出现偏移。

第三，跨域配置。本地开发时前端跑在localhost:5173，后端跑在8080，必配跨域；生产环境用 Nginx 做反向代理，把/api转发到后端服务，前端页面和后端接口同域，跨域问题就不会出现。Nginx 上反向代理时再加一行proxy_set_header X-Real-IP $remote_addr;，方便后端日志里追踪真实客户端 IP。

第四，token 失效处理。401 响应后前端统一拦截跳转登录页，而不是每个页面自己处理。全局在 axios 拦截器里处理一次，后面所有页面都不会再为登录态切换写重复代码。

5. 疑难问题与避坑经验

5.1 加了 @Transactional 却没生效

这是我在项目里遇到最多的一个坑，新手尤其容易踩。典型场景是：在 Service 里写了一个createOrder方法加了@Transactional，然后在同一个类里另一个方法调用它，结果库存没扣成功，订单却落库了，事务完全没有回滚。

原因是 Spring 的事务基于 AOP 代理实现，只有通过代理对象调用方法时，事务才会被拦截。类内部直接用this调用，绕过了代理，事务自然失效。

排查方式很简单：在方法入口打日志，看错误发生时异常是否被吞掉。很多事务不生效的问题，不是因为代理问题，而是在事务方法内try...catch把异常吞了。Spring 默认只在 RuntimeException 时回滚，如果你捕获了异常又没继续抛出去，数据库操作已经提交，事务自然回滚不了。正确的做法是没把握就不要在事务方法内吞异常，交给全局异常处理器统一处理。

另外还要确认，数据库表引擎必须是 InnoDB。MyISAM 不支持事务，@Transactional加得再多，也不会真正回滚。建表时我统一指定ENGINE = InnoDB，避免这个隐性问题。

5.2 WebSocket 连不上 / 频繁断开

WebSocket 在本地开发时好好的，部署到服务器上就连接失败，这个现象多半是 Nginx 配置问题。WebSocket 协议升级依赖两个请求头：Upgrade和Connection，默认情况下 Nginx 转发 HTTP 请求时并不会带上它们。

解决方式是在 Nginx 的 location 中加入：

location /ws/ { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; }

频繁断开的问题，也和服务器空闲超时有关。Nginx 默认会在 60 秒内没有数据交互时断开连接，而点餐系统的 WebSocket 在没有新单时就没有数据可传。前端要做心跳机制，每隔 30 秒发送一个 ping 消息，后端收到后返回 pong，用活跃数据保住连接。前端监听onclose事件，断开后做指数退避重连，避免断线风暴。

5.3 慢 SQL 与索引优化

报表统计时，订单表的数据会越来越多。如果 orders 表没有建合适索引，按时间分组统计时全表扫描，数据到几万条时查询就会明显变慢，几十万条时可能直接卡死。

我给订单表的create_time建了普通索引，给order_item表的order_id建了普通索引，报表查询基本都走索引。排查慢 SQL 时，用 Mysql 的EXPLAIN看执行计划，重点看type列是不是ref或range，如果显示ALL，就说明正在全表扫描，需要补索引。

EXPLAIN SELECT DATE(create_time), COUNT(*), SUM(total_amount) FROM orders WHERE status = 4 GROUP BY DATE(create_time);

另外要小心DATE(create_time)这种对索引列做函数的写法，它会让索引失效。查询时间范围时应该写成create_time >= '2025-01-01 00:00:00' AND create_time < '2025-01-02 00:00:00'，这样索引才能正常工作。

5.4 分页接口漏数据与 MyBatis-Plus 分页失效

列表接口全部做分页，菜品列表、订单列表、报表明细都离不开分页。MyBatis-Plus 的分页功能需要先配置分页插件，很多人漏掉这一步，导致分页对象传进去后，返回的total永远是 0，或者查询结果不分页。

@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }

分页漏数据还有另一个场景：后端查询订单列表按create_time排序时，如果毫秒级的时间完全相同，排序结果是不确定的。比如第 1 页查到了 10 条数据，第 2 页又查到了同样的几条，用户会看到数据重复或者漏掉。解决方式是排序字段带上主键，写成ORDER BY create_time DESC, id DESC，保证排序完全稳定。

从我的实操体验来说，这套系统最值得投入时间的地方不是花哨的功能，而是订单链路的数据一致性和实时性。库存防超卖的条件更新、事务边界、WebSocket 的心跳重连，这几个点看着简单，但在高峰期真刀真枪跑起来才知道它们的重要性。如果你也在做类似的项目，我建议先把订单状态机画清楚，再写代码；先把接口返回格式定好，再联调。细节上的偷懒，最后都会在联调和上线时加倍找回来。未来如果店面扩张到多门店，这套单体架构也能通过模块边界顺利演进，先把手上的闭环跑通，比什么都实在。