简介基于SSM的餐饮管理系统设计与实现文档是一份面向JavaWeb方向课程设计、毕业设计及系统开发初学者的参考资料。资源围绕餐饮管理信息化需求从实际业务需求出发给出了从系统背景、技术选型到核心模块设计的完整方案。整个资源为1个docx文档压缩包大小945KB内容包含中英文摘要、绪论、开发工具介绍、系统模块设计等章节目录结构清晰便于按章节检索。文档重点介绍了B/S架构、MVC三层设计模式、Java语言、Eclipse开发环境以及MySQL数据库的应用并系统呈现了系统用户管理、菜品类别管理、餐桌信息管理、菜品信息管理、登录与退出等模块的实现思路与功能划分。目前已有35人浏览学习适合需要快速梳理系统设计流程、参考模块划分或撰写毕业设计论文的读者。借助文档所示的设计流程读者可以了解一个典型餐饮管理系统从需求分析、架构设计到数据库设计的实践过程为同类管理系统开发提供直接参考。1. 基于ssm的餐饮管理系统先定业务边界再做技术选型餐饮管理系统在高校毕业设计和中小企业外包项目里出现频率很高但大多数实现只做到「菜品管理 订单 CRUD」离真正能用的门店系统差着两个关键设计桌台状态流转和订单状态机。ssm 是 Spring SpringMVC MyBatis 的组合这套老牌框架在 2025 年的今天依然维护着大量存量系统新项目选它不是因为时髦而是因为招人容易、出问题好排查、部署门槛低。本文按「理论 → 骨架搭建 → 表设计 → 核心链路 → 并发处理 → 排错技巧」的顺序把一套餐饮管理系统的实现路径完整走一遍。适合正在做毕业设计的学生也适合需要快速接手 SSM 老项目的开发。整套方案不依赖特定 IDE命令行加文本编辑器就能跟下来。2. ssm项目骨架搭建Maven 依赖与三层配置的落地顺序2.1 SSM 三个框架在项目里各自负责什么Spring 管理对象生命周期SpringMVC 处理 HTTP 请求路由MyBatis 负责 SQL 与 Java 对象的映射。三者协作的典型请求路径是浏览器发请求 → DispatcherServlet 找到 Controller → Service 层执行业务逻辑 → Mapper 接口调用 MyBatis 代理对象 → 执行 SQL 返回结果。理解这个链路比背配置重要排错时每一步都有对应的日志和报错位置。一个常见误区是同时使用 Spring 的注解扫描和 XML 配置导致 Bean 被重复创建。SSM 项目里应该明确Spring 容器扫描Service、Repository注解SpringMVC 容器只扫描Controller注解两者扫描包严格分开。2.2 pom.xml 最小依赖集合用 Maven 管理依赖下面这组依赖是 SSM 项目里最常用的一套组合版本号选择 2023 年后仍在维护的稳定版本。properties spring.version5.3.31/spring.version mybatis.version3.5.16/mybatis.version /properties dependencies dependency groupIdorg.springframework/groupId artifactIdspring-webmvc/artifactId version${spring.version}/version /dependency dependency groupIdorg.springframework/groupId artifactIdspring-jdbc/artifactId version${spring.version}/version /dependency dependency groupIdorg.mybatis/groupId artifactIdmybatis/artifactId version${mybatis.version}/version /dependency dependency groupIdorg.mybatis/groupId artifactIdmybatis-spring/artifactId version2.1.2/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version /dependency dependency groupIdcom.alibaba/groupId artifactIddruid/artifactId version1.2.20/version /dependency /dependencies依赖里最关键的是mybatis-spring这个桥接包它负责把 MyBatis 的SqlSessionFactory交给 Spring 容器管理。没有这个包MyBatis 和 Spring 各管各的事务注解Transactional会完全失效。数据库连接池用 Druid生产环境建议开启监控页面开发阶段用默认配置即可。2.3 三个配置文件按「数据层 → 业务层 → 表现层」的顺序写配置加载顺序有讲究Spring 的根容器必须先于 SpringMVC 的子容器初始化否则 Controller 里注入 Service 会报空指针。以下是标准的配置骨架。!-- spring-dao.xml数据源 SqlSessionFactory Mapper 扫描 -- context:property-placeholder locationclasspath:jdbc.properties / bean iddataSource classcom.alibaba.druid.pool.DruidDataSource property namedriverClassName value${jdbc.driver} / property nameurl value${jdbc.url} / property nameusername value${jdbc.username} / property namepassword value${jdbc.password} / /bean bean idsqlSessionFactory classorg.mybatis.spring.SqlSessionFactoryBean property namedataSource refdataSource / property namemapperLocations valueclasspath:mapper/*.xml / property nametypeAliasesPackage valuecom.restaurant.entity / /bean bean classorg.mybatis.spring.mapper.MapperScannerConfigurer property namebasePackage valuecom.restaurant.dao / /beanSqlSessionFactoryBean的mapperLocations指定 XML 映射文件位置typeAliasesPackage让实体类可以用短名称引用。MapperScannerConfigurer会自动扫描 DAO 接口并生成代理对象省去手写实现类的重复劳动。DAO 接口上不需要加任何注解扫描器靠接口名与 XML 的 namespace 匹配来绑定。SpringMVC 的配置文件要单独开启注解驱动和静态资源放行否则前端页面引用的 CSS、JS 会被拦截器拦掉。mvc:annotation-driven / mvc:resources mapping/static/** location/static/ / context:component-scan base-packagecom.restaurant.controller /mvc:resource里的location以斜杠结尾是硬性要求漏掉斜杠会导致静态资源路径拼接错误。这三个文件写完后Tomcat 启动不报错只代表容器起来了真正的验证方式是请求一个简单的 Controller 接口能返回 JSON 或跳转页面才算骨架打通。3. 餐饮核心表设计与订单状态机的状态约束3.1 菜品、桌台、订单三张主表的关系餐饮管理系统的表结构比普通 CRUD 系统多了一层「桌台维度」。菜品归属于分类订单挂在桌台下订单明细关联菜品。这个关系决定了查询时至少会涉及三到四张表的连接MyBatis 的association和collection标签会在这一层发挥关键作用。桌台表需要冗余一个状态字段取值建议0 空闲、1 已开台、2 已点餐、3 待结账。直接查桌台状态比每次 JOIN 订单表判断要快得多这是餐饮系统里最常用的一个「用空间换时间」设计。CREATE TABLE tb_orders ( order_id bigint(20) NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 订单流水号, table_id int(11) NOT NULL COMMENT 桌台ID, member_id int(11) DEFAULT NULL COMMENT 会员ID可空, total_amount decimal(10,2) NOT NULL DEFAULT 0.00, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2制作中 3已上菜 4已完成 5已取消, create_time datetime NOT NULL, update_time datetime NOT NULL, PRIMARY KEY (order_id), UNIQUE KEY uk_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE tb_order_item ( item_id bigint(20) NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL, dish_id int(11) NOT NULL, dish_name varchar(100) NOT NULL COMMENT 冗余菜品名称防止菜品改价后历史订单错乱, price decimal(10,2) NOT NULL COMMENT 下单时的单价快照, quantity int(11) NOT NULL DEFAULT 1, PRIMARY KEY (item_id), KEY idx_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;订单明细表冗余了dish_name和price两个字段这是餐饮系统设计里的一个常见取舍菜品表的价格可以随时调整但历史订单必须保留下单那一刻的价格快照。JOIN 菜品表确实能省存储但报表统计和历史单据回看会出问题。3.2 状态机字段用 TINYINT 而非字符串状态字段最好用 TINYINT 配合代码里的枚举常量不用 VARCHAR 存中文。原因有两个存储空间小是一方面更重要的是避免中文在不同数据库连接编码下出现乱码导致状态判断失效。MyBatis 查询时用Integer类型接收状态字段业务层判断时引用统一的状态常量类不要在每个 Service 方法里直接写魔法数字。项目里通常会定义一个OrderStatus常量类把 0 到 5 映射成可读的常量名这样后续维护的人不用翻数据库注释也能看懂代码。表之间不建物理外键只保留逻辑关联。餐饮门店的点餐操作频繁且并发高数据库外键的约束检查会拖慢写操作速度万一出现误删外键关联数据整个订单链路会连锁报错。用应用层保证数据一致性是这类业务系统的常用做法。4. 点餐下单全链路实现Controller-Service-Mapper 的职责划分4.1 Controller 只做参数接收与结果包装Controller 层的职责是接收前端传来的 JSON 参数、调用 Service、把结果组装成统一的返回结构。业务判断和 SQL 操作都不应该出现在 Controller 里否则后期加一个微信小程序端时接口没法复用。RestController RequestMapping(/api/order) public class OrderController { Autowired private OrderService orderService; PostMapping(/create) public Result createOrder(RequestBody OrderCreateRequest request) { if (request.getTableId() null || request.getItems().isEmpty()) { return Result.error(桌台和菜品不能为空); } try { String orderNo orderService.createOrder(request); return Result.success(orderNo); } catch (BusinessException e) { return Result.error(e.getMessage()); } } }Result是统一的响应包装类包含code、message、data三个字段。前端判断code是否为 200 来决定是否提示错误这种约定在餐饮系统的多端对接里几乎是标配。校验放在 Controller 入口做初步过滤深层的业务校验交给 Service。4.2 Service 层处理订单状态流转创建订单的核心逻辑是校验桌台状态、计算总价、生成订单号、插入主表和明细表、更新桌台状态。这五步必须在一个事务里完成任何一步失败都要整体回滚。Transactional(rollbackFor Exception.class) public String createOrder(OrderCreateRequest request) { // 校验桌台是否为可下单状态 TableInfo table tableMapper.selectById(request.getTableId()); if (table.getStatus() ! 0 table.getStatus() ! 3) { throw new BusinessException(当前桌台不可点餐); } // 生成订单号并计算总价 String orderNo generateOrderNo(); BigDecimal total BigDecimal.ZERO; for (OrderItemRequest item : request.getItems()) { Dish dish dishMapper.selectById(item.getDishId()); total total.add(dish.getPrice().multiply(new BigDecimal(item.getQuantity()))); } // 插入订单主表 Order order new Order(); order.setOrderNo(orderNo); order.setTableId(request.getTableId()); order.setTotalAmount(total); order.setStatus(0); orderMapper.insert(order); // 批量插入明细 orderItemMapper.batchInsert(request.getItems(), orderNo); // 更新桌台状态 tableMapper.updateStatus(request.getTableId(), 2); return orderNo; }Transactional注解的rollbackFor必须写成Exception.class默认配置下只在运行时异常时回滚受检异常不会触发回滚这个坑在文件导出、金额计算等场景里很常见。桌台状态判断里允许 3 待结账状态继续点菜这是餐饮业务的真实需求——顾客加菜时不要求先结完上一轮账。4.3 Mapper 层用动态 SQL 处理批量插入批量插入订单明细最忌讳在 Java 里循环单条 insert几百个菜品会产生几百次数据库往返。MyBatis 的foreach标签可以拼一条多值 INSERT 语句性能提升一个数量级。insert idbatchInsert parameterTypelist INSERT INTO tb_order_item (order_no, dish_id, dish_name, price, quantity) VALUES foreach collectionlist itemitem separator, (#{item.orderNo}, #{item.dishId}, #{item.dishName}, #{item.price}, #{item.quantity}) /foreach /insertforeach的collection属性值固定为list对应 Mapper 接口方法里不加Param注解的 List 参数。如果方法签名是batchInsert(ListOrderItemRequest items, String orderNo)则必须用Param(items)显式指定参数名XML 里的collection也要相应改成items。MySQL 的max_allowed_packet默认是 64MB批量插入时注意单条 SQL 别超限正常的加菜单量远达不到。4.4 多表关联查询避免 N1 问题查询订单详情时主表、明细表、菜品表三张表联查。一种常见的错误写法是先查订单列表再循环查每个订单的明细这就是 N1 查询问题。正确的做法是 MyBatis 的collection标签一次性查完。resultMap idOrderDetailMap typeOrderDetail id propertyorderNo columnorder_no / result propertytableId columntable_id / result propertytotalAmount columntotal_amount / collection propertyitems ofTypeOrderItem id propertyitemId columnitem_id / result propertydishName columndish_name / result propertyprice columnprice / result propertyquantity columnquantity / /collection /resultMap select idselectOrderDetail resultMapOrderDetailMap SELECT o.order_no, o.table_id, o.total_amount, i.item_id, i.dish_name, i.price, i.quantity FROM tb_orders o LEFT JOIN tb_order_item i ON o.order_no i.order_no WHERE o.order_no #{orderNo} /selectcollection映射的ofType指向明细实体的全限定名或别名。注意主表字段和明细表字段不能重名否则结果集映射会串值。order_no在两个表里都有查询时用别名区分后映射配置里也要严格对应。5. 高并发点餐下的事务边界与库存扣减策略5.1 事务边界放在 Service 层而不是 DAO 层事务切面默认只对 public 方法生效且只在通过 Spring 代理调用时生效。同一个类内部的this调用不会触发事务这是事务失效的高频原因。正确的做法是把需要原子操作的业务逻辑放在独立的 Service 方法里由 Controller 调用而不是在 Service 内部互相嵌套调用。餐饮高峰期多个桌台同时下单数据库连接池默认 10 个连接很容易被打满。Druid 连接池可以按需调大初始连接和最大活跃连接数但最大连接数不是越大越好MySQL 默认 max_connections 是 151连接池配置需要考虑数据库自身的上限。5.2 库存扣减用乐观锁不用 select-then-update套餐菜品和限量菜品涉及库存扣减。常规写法是先 SELECT 查出库存判断大于零再 UPDATE 扣减这在并发场景下会超卖。两个请求同时查到库存为 1都通过判断各自执行 UPDATE最终库存变成 -1。-- 乐观锁扣减库存条件里带上库存数量 UPDATE tb_dish SET stock stock - #{quantity} WHERE dish_id #{dishId} AND stock #{quantity}执行这条 UPDATE 的返回结果是影响行数。返回 1 说明扣减成功返回 0 说明库存不足或菜品不存在。Service 层通过判断int rows dishMapper.deductStock(dishId, quantity); if (rows 0) throw new BusinessException(库存不足)来实现并发安全。这是一种最简单有效的乐观锁方案不需要额外加 version 字段。5.3 防止重复下单的幂等设计前端按钮重复点击、网络重试都可能让同一笔订单插入两次。餐桌点餐的幂等设计通常在订单号上做文章前端生成一个请求唯一标识后端在插入前检查该标识是否已存在。幂等方案实现方式适用场景唯一索引订单表加uk_order_no重复插入直接报错订单号由后端生成防重令牌前端提交前先获取 token后端校验后删除表单提交类操作状态判断更新时加WHERE status 0防止重复处理状态流转类操作幂等方案实现方式适用场景唯一索引订单表加 uk_order_no重复插入直接报错订单号由后端生成防重令牌前端提交前先获取 token后端校验后删除表单提交类操作状态判断更新时加 WHERE status 0状态流转类操作订单表里的uk_order_no唯一索引就是最底层的兜底防线业务上即使出现了重复请求数据库也会拒绝第二条重复的订单号插入。生成订单号时混入时间戳和随机数可以进一步降低碰撞概率。5.4 事务超时与死锁的排查方向Transactional(timeout 5)可以给事务设置超时时间单位是秒。餐饮系统的下单事务一般控制在几百毫秒内如果经常超时优先排查是不是批量插入的数据量太大或 SQL 缺少索引。死锁的典型场景是两张表反向更新比如同时更新订单表和桌台表时顺序不一致A 事务先更新桌台再更新订单B 事务先更新订单再更新桌台就可能互相等待。规范的做法是在所有事务方法里固定表的更新顺序。6. 联调阶段的 404/500 排查顺序与订单流水号跟踪技巧6.1 按请求链路分段定位问题的顺序联调时接口报错先看浏览器开发者工具 Network 面板的 HTTP 状态码。404 只可能是路由或静态资源问题跟业务代码无关优先查 SpringMVC 配置的component-scan是否扫描到了 Controller、RequestMapping路径是否写全。500 再看 Tomcat 日志的异常栈首行MyBatis 报的BindingException说明 Mapper 接口和 XML 的 namespace 不匹配SQLSyntaxErrorException说明表名或字段名拼写有问题。排查时把日志级别调到 DEBUG重点看 MyBatis 打印的 SQL 和执行参数。log4j.logger.com.restaurant.daoDEBUG只对 DAO 层生效不会刷屏。SQL 打印出来后才能确认参数有没有正确绑定很多where条件查不出数据的问题实际是参数类型不匹配导致查询条件恒为假。6.2 用订单流水号串起全链路日志这里推荐一个实用技巧订单流水号生成规则里带上日期和随机数比如ORD20250607123045001编码规则是ORD yyyyMMddHHmmss 三位随机数。这个号贯穿整个请求链路从 Controller 入口打日志开始到 Service 的事务提交结束排查问题的时候用日志文件搜索这个号码就能看到一条请求完整经过的所有节点和每个节点的耗时。# 按订单号过滤全链路日志 grep ORD20250607123045001 /tomcat/logs/catalina.out这条命令会输出该订单在 Controller、Service、Mapper 各层的日志记录。如果发现请求压根没进 Controller问题在 SpringMVC 的拦截器或web.xml的dispatcher映射上如果日志停在 Service 里某一行说明事务回滚了再往上看异常栈的具体位置。按照订单号排查比翻完整日志文件高效得多。本文还有配套的精品资源点击获取
基于SSM的餐饮管理系统实战：从表设计到高并发订单处理
简介基于SSM的餐饮管理系统设计与实现文档是一份面向JavaWeb方向课程设计、毕业设计及系统开发初学者的参考资料。资源围绕餐饮管理信息化需求从实际业务需求出发给出了从系统背景、技术选型到核心模块设计的完整方案。整个资源为1个docx文档压缩包大小945KB内容包含中英文摘要、绪论、开发工具介绍、系统模块设计等章节目录结构清晰便于按章节检索。文档重点介绍了B/S架构、MVC三层设计模式、Java语言、Eclipse开发环境以及MySQL数据库的应用并系统呈现了系统用户管理、菜品类别管理、餐桌信息管理、菜品信息管理、登录与退出等模块的实现思路与功能划分。目前已有35人浏览学习适合需要快速梳理系统设计流程、参考模块划分或撰写毕业设计论文的读者。借助文档所示的设计流程读者可以了解一个典型餐饮管理系统从需求分析、架构设计到数据库设计的实践过程为同类管理系统开发提供直接参考。1. 基于ssm的餐饮管理系统先定业务边界再做技术选型餐饮管理系统在高校毕业设计和中小企业外包项目里出现频率很高但大多数实现只做到「菜品管理 订单 CRUD」离真正能用的门店系统差着两个关键设计桌台状态流转和订单状态机。ssm 是 Spring SpringMVC MyBatis 的组合这套老牌框架在 2025 年的今天依然维护着大量存量系统新项目选它不是因为时髦而是因为招人容易、出问题好排查、部署门槛低。本文按「理论 → 骨架搭建 → 表设计 → 核心链路 → 并发处理 → 排错技巧」的顺序把一套餐饮管理系统的实现路径完整走一遍。适合正在做毕业设计的学生也适合需要快速接手 SSM 老项目的开发。整套方案不依赖特定 IDE命令行加文本编辑器就能跟下来。2. ssm项目骨架搭建Maven 依赖与三层配置的落地顺序2.1 SSM 三个框架在项目里各自负责什么Spring 管理对象生命周期SpringMVC 处理 HTTP 请求路由MyBatis 负责 SQL 与 Java 对象的映射。三者协作的典型请求路径是浏览器发请求 → DispatcherServlet 找到 Controller → Service 层执行业务逻辑 → Mapper 接口调用 MyBatis 代理对象 → 执行 SQL 返回结果。理解这个链路比背配置重要排错时每一步都有对应的日志和报错位置。一个常见误区是同时使用 Spring 的注解扫描和 XML 配置导致 Bean 被重复创建。SSM 项目里应该明确Spring 容器扫描Service、Repository注解SpringMVC 容器只扫描Controller注解两者扫描包严格分开。2.2 pom.xml 最小依赖集合用 Maven 管理依赖下面这组依赖是 SSM 项目里最常用的一套组合版本号选择 2023 年后仍在维护的稳定版本。properties spring.version5.3.31/spring.version mybatis.version3.5.16/mybatis.version /properties dependencies dependency groupIdorg.springframework/groupId artifactIdspring-webmvc/artifactId version${spring.version}/version /dependency dependency groupIdorg.springframework/groupId artifactIdspring-jdbc/artifactId version${spring.version}/version /dependency dependency groupIdorg.mybatis/groupId artifactIdmybatis/artifactId version${mybatis.version}/version /dependency dependency groupIdorg.mybatis/groupId artifactIdmybatis-spring/artifactId version2.1.2/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version /dependency dependency groupIdcom.alibaba/groupId artifactIddruid/artifactId version1.2.20/version /dependency /dependencies依赖里最关键的是mybatis-spring这个桥接包它负责把 MyBatis 的SqlSessionFactory交给 Spring 容器管理。没有这个包MyBatis 和 Spring 各管各的事务注解Transactional会完全失效。数据库连接池用 Druid生产环境建议开启监控页面开发阶段用默认配置即可。2.3 三个配置文件按「数据层 → 业务层 → 表现层」的顺序写配置加载顺序有讲究Spring 的根容器必须先于 SpringMVC 的子容器初始化否则 Controller 里注入 Service 会报空指针。以下是标准的配置骨架。!-- spring-dao.xml数据源 SqlSessionFactory Mapper 扫描 -- context:property-placeholder locationclasspath:jdbc.properties / bean iddataSource classcom.alibaba.druid.pool.DruidDataSource property namedriverClassName value${jdbc.driver} / property nameurl value${jdbc.url} / property nameusername value${jdbc.username} / property namepassword value${jdbc.password} / /bean bean idsqlSessionFactory classorg.mybatis.spring.SqlSessionFactoryBean property namedataSource refdataSource / property namemapperLocations valueclasspath:mapper/*.xml / property nametypeAliasesPackage valuecom.restaurant.entity / /bean bean classorg.mybatis.spring.mapper.MapperScannerConfigurer property namebasePackage valuecom.restaurant.dao / /beanSqlSessionFactoryBean的mapperLocations指定 XML 映射文件位置typeAliasesPackage让实体类可以用短名称引用。MapperScannerConfigurer会自动扫描 DAO 接口并生成代理对象省去手写实现类的重复劳动。DAO 接口上不需要加任何注解扫描器靠接口名与 XML 的 namespace 匹配来绑定。SpringMVC 的配置文件要单独开启注解驱动和静态资源放行否则前端页面引用的 CSS、JS 会被拦截器拦掉。mvc:annotation-driven / mvc:resources mapping/static/** location/static/ / context:component-scan base-packagecom.restaurant.controller /mvc:resource里的location以斜杠结尾是硬性要求漏掉斜杠会导致静态资源路径拼接错误。这三个文件写完后Tomcat 启动不报错只代表容器起来了真正的验证方式是请求一个简单的 Controller 接口能返回 JSON 或跳转页面才算骨架打通。3. 餐饮核心表设计与订单状态机的状态约束3.1 菜品、桌台、订单三张主表的关系餐饮管理系统的表结构比普通 CRUD 系统多了一层「桌台维度」。菜品归属于分类订单挂在桌台下订单明细关联菜品。这个关系决定了查询时至少会涉及三到四张表的连接MyBatis 的association和collection标签会在这一层发挥关键作用。桌台表需要冗余一个状态字段取值建议0 空闲、1 已开台、2 已点餐、3 待结账。直接查桌台状态比每次 JOIN 订单表判断要快得多这是餐饮系统里最常用的一个「用空间换时间」设计。CREATE TABLE tb_orders ( order_id bigint(20) NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 订单流水号, table_id int(11) NOT NULL COMMENT 桌台ID, member_id int(11) DEFAULT NULL COMMENT 会员ID可空, total_amount decimal(10,2) NOT NULL DEFAULT 0.00, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2制作中 3已上菜 4已完成 5已取消, create_time datetime NOT NULL, update_time datetime NOT NULL, PRIMARY KEY (order_id), UNIQUE KEY uk_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE tb_order_item ( item_id bigint(20) NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL, dish_id int(11) NOT NULL, dish_name varchar(100) NOT NULL COMMENT 冗余菜品名称防止菜品改价后历史订单错乱, price decimal(10,2) NOT NULL COMMENT 下单时的单价快照, quantity int(11) NOT NULL DEFAULT 1, PRIMARY KEY (item_id), KEY idx_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;订单明细表冗余了dish_name和price两个字段这是餐饮系统设计里的一个常见取舍菜品表的价格可以随时调整但历史订单必须保留下单那一刻的价格快照。JOIN 菜品表确实能省存储但报表统计和历史单据回看会出问题。3.2 状态机字段用 TINYINT 而非字符串状态字段最好用 TINYINT 配合代码里的枚举常量不用 VARCHAR 存中文。原因有两个存储空间小是一方面更重要的是避免中文在不同数据库连接编码下出现乱码导致状态判断失效。MyBatis 查询时用Integer类型接收状态字段业务层判断时引用统一的状态常量类不要在每个 Service 方法里直接写魔法数字。项目里通常会定义一个OrderStatus常量类把 0 到 5 映射成可读的常量名这样后续维护的人不用翻数据库注释也能看懂代码。表之间不建物理外键只保留逻辑关联。餐饮门店的点餐操作频繁且并发高数据库外键的约束检查会拖慢写操作速度万一出现误删外键关联数据整个订单链路会连锁报错。用应用层保证数据一致性是这类业务系统的常用做法。4. 点餐下单全链路实现Controller-Service-Mapper 的职责划分4.1 Controller 只做参数接收与结果包装Controller 层的职责是接收前端传来的 JSON 参数、调用 Service、把结果组装成统一的返回结构。业务判断和 SQL 操作都不应该出现在 Controller 里否则后期加一个微信小程序端时接口没法复用。RestController RequestMapping(/api/order) public class OrderController { Autowired private OrderService orderService; PostMapping(/create) public Result createOrder(RequestBody OrderCreateRequest request) { if (request.getTableId() null || request.getItems().isEmpty()) { return Result.error(桌台和菜品不能为空); } try { String orderNo orderService.createOrder(request); return Result.success(orderNo); } catch (BusinessException e) { return Result.error(e.getMessage()); } } }Result是统一的响应包装类包含code、message、data三个字段。前端判断code是否为 200 来决定是否提示错误这种约定在餐饮系统的多端对接里几乎是标配。校验放在 Controller 入口做初步过滤深层的业务校验交给 Service。4.2 Service 层处理订单状态流转创建订单的核心逻辑是校验桌台状态、计算总价、生成订单号、插入主表和明细表、更新桌台状态。这五步必须在一个事务里完成任何一步失败都要整体回滚。Transactional(rollbackFor Exception.class) public String createOrder(OrderCreateRequest request) { // 校验桌台是否为可下单状态 TableInfo table tableMapper.selectById(request.getTableId()); if (table.getStatus() ! 0 table.getStatus() ! 3) { throw new BusinessException(当前桌台不可点餐); } // 生成订单号并计算总价 String orderNo generateOrderNo(); BigDecimal total BigDecimal.ZERO; for (OrderItemRequest item : request.getItems()) { Dish dish dishMapper.selectById(item.getDishId()); total total.add(dish.getPrice().multiply(new BigDecimal(item.getQuantity()))); } // 插入订单主表 Order order new Order(); order.setOrderNo(orderNo); order.setTableId(request.getTableId()); order.setTotalAmount(total); order.setStatus(0); orderMapper.insert(order); // 批量插入明细 orderItemMapper.batchInsert(request.getItems(), orderNo); // 更新桌台状态 tableMapper.updateStatus(request.getTableId(), 2); return orderNo; }Transactional注解的rollbackFor必须写成Exception.class默认配置下只在运行时异常时回滚受检异常不会触发回滚这个坑在文件导出、金额计算等场景里很常见。桌台状态判断里允许 3 待结账状态继续点菜这是餐饮业务的真实需求——顾客加菜时不要求先结完上一轮账。4.3 Mapper 层用动态 SQL 处理批量插入批量插入订单明细最忌讳在 Java 里循环单条 insert几百个菜品会产生几百次数据库往返。MyBatis 的foreach标签可以拼一条多值 INSERT 语句性能提升一个数量级。insert idbatchInsert parameterTypelist INSERT INTO tb_order_item (order_no, dish_id, dish_name, price, quantity) VALUES foreach collectionlist itemitem separator, (#{item.orderNo}, #{item.dishId}, #{item.dishName}, #{item.price}, #{item.quantity}) /foreach /insertforeach的collection属性值固定为list对应 Mapper 接口方法里不加Param注解的 List 参数。如果方法签名是batchInsert(ListOrderItemRequest items, String orderNo)则必须用Param(items)显式指定参数名XML 里的collection也要相应改成items。MySQL 的max_allowed_packet默认是 64MB批量插入时注意单条 SQL 别超限正常的加菜单量远达不到。4.4 多表关联查询避免 N1 问题查询订单详情时主表、明细表、菜品表三张表联查。一种常见的错误写法是先查订单列表再循环查每个订单的明细这就是 N1 查询问题。正确的做法是 MyBatis 的collection标签一次性查完。resultMap idOrderDetailMap typeOrderDetail id propertyorderNo columnorder_no / result propertytableId columntable_id / result propertytotalAmount columntotal_amount / collection propertyitems ofTypeOrderItem id propertyitemId columnitem_id / result propertydishName columndish_name / result propertyprice columnprice / result propertyquantity columnquantity / /collection /resultMap select idselectOrderDetail resultMapOrderDetailMap SELECT o.order_no, o.table_id, o.total_amount, i.item_id, i.dish_name, i.price, i.quantity FROM tb_orders o LEFT JOIN tb_order_item i ON o.order_no i.order_no WHERE o.order_no #{orderNo} /selectcollection映射的ofType指向明细实体的全限定名或别名。注意主表字段和明细表字段不能重名否则结果集映射会串值。order_no在两个表里都有查询时用别名区分后映射配置里也要严格对应。5. 高并发点餐下的事务边界与库存扣减策略5.1 事务边界放在 Service 层而不是 DAO 层事务切面默认只对 public 方法生效且只在通过 Spring 代理调用时生效。同一个类内部的this调用不会触发事务这是事务失效的高频原因。正确的做法是把需要原子操作的业务逻辑放在独立的 Service 方法里由 Controller 调用而不是在 Service 内部互相嵌套调用。餐饮高峰期多个桌台同时下单数据库连接池默认 10 个连接很容易被打满。Druid 连接池可以按需调大初始连接和最大活跃连接数但最大连接数不是越大越好MySQL 默认 max_connections 是 151连接池配置需要考虑数据库自身的上限。5.2 库存扣减用乐观锁不用 select-then-update套餐菜品和限量菜品涉及库存扣减。常规写法是先 SELECT 查出库存判断大于零再 UPDATE 扣减这在并发场景下会超卖。两个请求同时查到库存为 1都通过判断各自执行 UPDATE最终库存变成 -1。-- 乐观锁扣减库存条件里带上库存数量 UPDATE tb_dish SET stock stock - #{quantity} WHERE dish_id #{dishId} AND stock #{quantity}执行这条 UPDATE 的返回结果是影响行数。返回 1 说明扣减成功返回 0 说明库存不足或菜品不存在。Service 层通过判断int rows dishMapper.deductStock(dishId, quantity); if (rows 0) throw new BusinessException(库存不足)来实现并发安全。这是一种最简单有效的乐观锁方案不需要额外加 version 字段。5.3 防止重复下单的幂等设计前端按钮重复点击、网络重试都可能让同一笔订单插入两次。餐桌点餐的幂等设计通常在订单号上做文章前端生成一个请求唯一标识后端在插入前检查该标识是否已存在。幂等方案实现方式适用场景唯一索引订单表加uk_order_no重复插入直接报错订单号由后端生成防重令牌前端提交前先获取 token后端校验后删除表单提交类操作状态判断更新时加WHERE status 0防止重复处理状态流转类操作幂等方案实现方式适用场景唯一索引订单表加 uk_order_no重复插入直接报错订单号由后端生成防重令牌前端提交前先获取 token后端校验后删除表单提交类操作状态判断更新时加 WHERE status 0状态流转类操作订单表里的uk_order_no唯一索引就是最底层的兜底防线业务上即使出现了重复请求数据库也会拒绝第二条重复的订单号插入。生成订单号时混入时间戳和随机数可以进一步降低碰撞概率。5.4 事务超时与死锁的排查方向Transactional(timeout 5)可以给事务设置超时时间单位是秒。餐饮系统的下单事务一般控制在几百毫秒内如果经常超时优先排查是不是批量插入的数据量太大或 SQL 缺少索引。死锁的典型场景是两张表反向更新比如同时更新订单表和桌台表时顺序不一致A 事务先更新桌台再更新订单B 事务先更新订单再更新桌台就可能互相等待。规范的做法是在所有事务方法里固定表的更新顺序。6. 联调阶段的 404/500 排查顺序与订单流水号跟踪技巧6.1 按请求链路分段定位问题的顺序联调时接口报错先看浏览器开发者工具 Network 面板的 HTTP 状态码。404 只可能是路由或静态资源问题跟业务代码无关优先查 SpringMVC 配置的component-scan是否扫描到了 Controller、RequestMapping路径是否写全。500 再看 Tomcat 日志的异常栈首行MyBatis 报的BindingException说明 Mapper 接口和 XML 的 namespace 不匹配SQLSyntaxErrorException说明表名或字段名拼写有问题。排查时把日志级别调到 DEBUG重点看 MyBatis 打印的 SQL 和执行参数。log4j.logger.com.restaurant.daoDEBUG只对 DAO 层生效不会刷屏。SQL 打印出来后才能确认参数有没有正确绑定很多where条件查不出数据的问题实际是参数类型不匹配导致查询条件恒为假。6.2 用订单流水号串起全链路日志这里推荐一个实用技巧订单流水号生成规则里带上日期和随机数比如ORD20250607123045001编码规则是ORD yyyyMMddHHmmss 三位随机数。这个号贯穿整个请求链路从 Controller 入口打日志开始到 Service 的事务提交结束排查问题的时候用日志文件搜索这个号码就能看到一条请求完整经过的所有节点和每个节点的耗时。# 按订单号过滤全链路日志 grep ORD20250607123045001 /tomcat/logs/catalina.out这条命令会输出该订单在 Controller、Service、Mapper 各层的日志记录。如果发现请求压根没进 Controller问题在 SpringMVC 的拦截器或web.xml的dispatcher映射上如果日志停在 Service 里某一行说明事务回滚了再往上看异常栈的具体位置。按照订单号排查比翻完整日志文件高效得多。本文还有配套的精品资源点击获取