SSM餐饮管理系统实战：从数据库设计到订单状态流转

1. 餐饮管理系统到底要解决什么问题

1.1 门店的日常运转有哪些环节

一个餐饮门店每天看起来只是“点菜、上菜、结账”，但真正做过的人都知道，这几个动作背后牵扯的环节远比想象中多。前台要管桌台状态，后厨要按单出菜，收银要计算折扣和会员价，老板还要看今天到底卖了多少、哪些菜卖得好、哪些原料快用完了。这些问题如果全部靠纸笔和对讲机，高峰期一忙起来，漏单、错菜、跑单几乎必然发生。

我做这个SSM餐饮管理系统项目时，第一件事不是写代码，而是把一家中小型餐厅的完整运作流程画了一遍。越是这种贴近实际业务的项目，需求梳理越不能省，因为后面所有的表结构、接口设计都是从流程图里倒推出来的。餐饮管理系统本质上解决三件事：第一，把点餐、出餐、结账这条主链路从线下搬到线上，降低沟通成本；第二，让老板和管理者能实时掌握经营数据，不用等月底手工对账；第三，通过菜品管理、分类管理、上下架控制，灵活调整菜单，配合实际经营。

1.2 系统的角色划分与功能边界

系统设计第一步是分角色。我按实际使用场景划分了两种角色：管理员和收银员/前台，如果有扩展需求还可以加后厨端，但第一期不需要把摊子铺太大。

• 管理员：管理菜品分类、菜品信息，设置桌台，查看营业统计，管理订单，维护系统用户。
• 收银员/前台：开台、点餐、下单、结账、查看订单详情，日常操作类需求都集中在这里。

权限边界清晰之后，登录注册、拦截器校验、菜单权限这些功能才有落点。餐饮管理系统不同于普通个人博客，它的核心是订单流程，不是内容发布，所以整个系统的功能设计必须围绕“下单 → 出菜 → 结账”这条链路展开，菜品管理和分类管理本质上都是为下单服务的基础数据维护。

2. 为什么选SSM这套组合，而不是图省事上Spring Boot

2.1 SSM三个框架的分工

SSM就是Spring + SpringMVC + MyBatis的组合。很多新手第一次听到这三个名字，觉得是一堆框架叠在一起，其实它们各管一段，彼此不重叠。

Spring是整套系统的地基，负责管理对象。你写的Service、DAO、Controller这些都是Java对象，对象之间的依赖关系如果手动new，代码会耦合到没法维护，Spring的IoC容器把这些对象的创建和装配接管了，要用的时候直接注入。Spring还提供事务管理，后面讲订单入库时你就能体会到一个事务注解有多重要。

SpringMVC负责接收HTTP请求，把请求参数绑定到Java对象上，调Service处理完业务之后跳转页面或返回JSON。通俗地说，SpringMVC是门面，所有前端发来的请求都先经过它。

MyBatis负责数据库操作，把Java方法和SQL语句映射起来。写一个接口方法，配上一段SQL，返回结果自动封装成对象。它比JDBC省去大量重复代码，又比Hibernate更直观可控，适合餐饮这种SQL逻辑比较明确的系统。

2.2 版本选型与项目目录组织

技术选型时有一个关键决策点：用SSM还是Spring Boot。Spring Boot确实配置更少、启动更快，但SSM这种手动配置XML和配置类的方式，能让你更清楚地理解Spring底层原理——Bean是怎么扫描的、拦截器怎么注册的、事务代理是怎么生效的。假如你还在学习阶段，或者项目本身需要维护老代码，SSM依然是扎实的基础。

我当时用的版本组合是：

项目目录按Maven标准结构组织：controller包放接口层，service包放业务逻辑，dao/mapper包放数据库操作接口，entity/pojo包放实体类，resources下放Spring配置、MyBatis映射文件和数据库配置。这样分包最大的好处是，每层职责一眼能看出来，排查问题时不用到处翻文件。

2.3 这套技术栈的适配场景

如果你的场景是中小型餐饮门店的后台管理，并发量不大，数据量在万级到十万级，SSM完全够用。它不像微服务那样复杂，也不像纯Servlet/JSP那样低效，处在一个很合适的中间位置。

但我也要泼一盆冷水：SSM的配置确实繁琐。相比Spring Boot的自动配置，SSM需要手动配置数据源、事务管理器、视图解析器、拦截器等，第一次搭项目时容易因为配置项缺失或冲突卡住。不过换个角度看，这些配置过程本身就是最好的学习材料，你用SSM踩过一次配置的坑，后面用Spring Boot时会突然明白很多“为什么会自动生效”的问题。

3. 数据库设计：菜单、餐桌、订单三个核心不抓好，后面全是坑

3.1 核心表清单与设计思路

数据库设计是这个项目的重头戏。我见过很多人一上来就建表，建到一半发现字段对不上，又回头改，结果代码和表结构互相牵制，改得焦头烂额。正确的做法是先把实体关系理清楚。

餐饮管理系统的最小核心表有六张：

• 管理员表（admin）：id, username, password, real_name, role, create_time
• 菜品分类表（category）：id, name, sort, status
• 菜品表（dish）：id, category_id, name, price, image, description, status
• 桌台表（desk）：id, name, seat_count, status
• 订单主表（orders）：id, order_no, desk_id, total_amount, pay_type, status, create_time, pay_time
• 订单明细表（order_detail）：id, order_id, dish_id, dish_name, dish_image, price, quantity, subtotal

六张表之间的关系很清晰：分类和菜品是一对多，餐桌和订单是一对多，订单和订单明细是一对多。菜品表里冗余了分类名称吗？没有，查的时候join分类表就行，冗余容易造成数据不一致。订单明细表里冗余了菜品名称和图片呢？冗余了，这是有意为之，因为菜品可以删除或改名，但历史订单必须保持当时的下单快照。

3.2 几个关键字段的设计细节

金额字段必须用DECIMAL，这个没有商量的余地。Java里用float和double存金额，运算时会出精度问题，1.1加2.2可能等于3.3000000000000003。数据库里DECIMAL(10,2)，Java实体里用BigDecimal，两步都做到，金额计算才稳。

状态字段不要用字符串，用int或tinyint，配上注释标明含义。比如菜品status，0代表下架，1代表上架，这样判断和查询都方便。订单状态设计如下：

每个状态都要有更新时间字段，比如confirm_time, finish_time，方便后续统计每单耗时，分析出餐效率。

还有两个通用字段我强烈建议每张业务表都加：create_time和update_time。这两个字段的价值平时看不出来，一旦要排查数据问题或者做数据统计分析，你会发现没有时间字段根本无从下手。create_time在插入时用数据库默认值CURRENT_TIMESTAMP，update_time在更新时应用代码里手动赋值，或者用ON UPDATE CURRENT_TIMESTAMP，看个人习惯。

3.3 订单状态机的设计，宁可一开始多想两步

订单状态是整个系统里最容易出bug的地方。状态不是随便设几个值就行，状态之间的流转关系要提前定清楚，不能让订单从“已下单”直接跳到“已完成”，中间的制作和上菜环节必须有记录。

我当时设计的状态流转规则是这样的：已下单 → 制作中 → 已上菜 → 已完成，已下单状态下可以取消，已上菜之后不能取消。这样设计的原因很实际：后厨看到新订单才能开始做，菜没上齐就结账会造成纠纷，已完成的订单不可逆是为了对账需要。

在代码层面，状态流转要做到三点：第一，更新状态时必须带条件，比如UPDATE orders SET status = 1 WHERE id = ? AND status = 0，防止并发情况下状态被覆盖；第二，状态变更要记录时间字段；第三，对外提供的状态变更接口要校验当前状态是否允许跳转到目标状态。这些细节现在做好了，后面联调时能省很多事。

4. 核心功能实现：从登录鉴权到订单闭环

4.1 登录认证与权限拦截

系统的第一道关口是登录。管理员和收银员共用一张表，通过role字段区分权限。密码不存明文，用MD5加盐的方式处理。具体做法是：用户注册时生成一个随机盐值，密码是MD5(明文密码 + 盐值)，数据库中同时存盐值和加密后的密码。

登录逻辑用代码表示大概是这样的：

java复制public Admin login(String username, String password) {
    Admin admin = adminMapper.findByUsername(username);
    if (admin == null) {
        throw new ServiceException("用户名不存在");
    }
    String encrypted = MD5Util.md5(password + admin.getSalt());
    if (!encrypted.equals(admin.getPassword())) {
        throw new ServiceException("密码错误");
    }
    return admin;
}

登录成功后，把管理员对象放进Session，然后通过SpringMVC拦截器做权限控制。拦截器是所有Controller方法的关卡，未登录用户访问后台接口时直接重定向到登录页，不需要在每个Controller里重复写判断逻辑。这里有一个容易忽略的点：拦截器要配置放行路径，登录接口、静态资源、验证码图片这些不需要登录就能访问的资源必须排进exclude列表，否则会出现“页面还没登录却被要求登录”的怪圈。

4.2 菜品管理：图片上传与上下架

菜品管理是典型的CRUD加文件上传。新建菜品时，管理员填写菜名、分类、价格、描述，上传一张菜品图片。图片上传使用commons-fileupload组件，配置一个MultipartResolver，限制单个文件大小在2MB以内。图片保存到服务器本地指定目录，比如/upload/dish/，数据库里存相对路径，页面展示时拼接访问路径。

这里有一个细节：图片访问路径不能是一个写死的绝对路径，否则项目换环境部署时全部图片都会失效。我当时把上传目录配置在properties文件里，部署时改配置文件即可。菜品的上下架用status字段控制，下架的菜品在点餐页面不展示，但在订单历史里仍然能查到名称和价格快照，这就是之前说冗余字段起作用的地方。

菜品列表的查询需要和分类表做关联，页面展示时显示分类名称。因为菜品相对数量不大，没有做分页，但加了分类筛选和关键字搜索，实际操作中够用。如果你担心图片上传到本地目录会占服务器空间，可以换成OSS对象存储或者云存储，但在SSM项目中本地上传方案是最快的落地方式。

4.3 下单流程：购物车、订单主表和明细表的事务一致性

下单是整个系统最核心的流程，也是事务管理最能体现价值的地方。用户在点餐页面选择菜品加入购物车，购物车数据我放在Session里，用一个Map来存：key是菜品ID，value是数量。选择完菜品后，点击提交订单，前端把桌台ID和购物车清单发给后端。

后端处理下单的逻辑分三步：

1. 计算订单总金额。遍历购物车里的菜品，根据菜品ID查库拿到当前价格，乘以数量累加。
2. 插入订单主表，拿到自增ID。
3. 遍历购物车，逐条插入订单明细表，每一条都关联订单主表的ID。

这三步必须在一个事务里。如果主表插入成功但明细表插入时失败，没有事务包裹的话，就会出现一个没有明细的“幽灵订单”。有了事务，任何一步失败，前面所有操作全部回滚。实现也很简单，在Service方法上加上@Transactional注解即可：

java复制@Transactional
public Order createOrder(CreateOrderDTO dto) {
    // 1. 计算金额
    // 2. 插入主表
    // 3. 插入明细表
}

这里要提醒一个新手容易犯的错：事务注解要加在public方法上，而且不能是同类内部调用。比如类A有方法a()和方法b()，a()内部直接调用b()，即便b()上有@Transactional也不会生效，因为Spring的事务靠代理机制实现，内部调用绕过了代理。这个坑我在后面单独讲。

4.4 订单状态流转与后厨联动

订单创建成功后，收银员在前台页面上操作状态流转。查看待接单订单列表，点击“接单”后订单状态从0变1，点击“上菜”后状态变2，用户结账后状态变3。每个操作对应一个Controller接口，通过订单ID和当前状态条件更新订单状态。

这个功能从代码层面看很简单，核心是状态的校验。我自己封装了一个订单状态流转的Service方法：

java复制public void updateOrderStatus(Integer orderId, Integer targetStatus) {
    Order order = orderMapper.selectById(orderId);
    if (order == null) {
        throw new ServiceException("订单不存在");
    }
    // 校验当前状态是否允许流转到目标状态
    if (!canTransit(order.getStatus(), targetStatus)) {
        throw new ServiceException("订单状态不允许变更");
    }
    orderMapper.updateStatus(orderId, targetStatus);
}

后厨联动的核心在于，后厨界面看到的是“待接单”和“制作中”的订单，而不是所有订单。这里可以通过状态字段筛选实现：后厨页面只查询status=0和status=1的订单。如果后续要上实时推送，可以引入WebSocket，但第一期轮询刷新也能满足基本需求。

4.5 营业额统计与菜品排行

运营数据是老板最关心的部分。统计模块我实现了两个核心维度：按日/月的营业额统计和菜品销量排行。

营业额统计的思路是：查询订单表中已完成的订单（status=3），按日期分组求和。SQL大概是这样的：

sql复制SELECT DATE_FORMAT(create_time, '%Y-%m-%d') AS day, SUM(total_amount) AS amount
FROM orders
WHERE status = 3 AND create_time >= #{startTime} AND create_time <= #{endTime}
GROUP BY day
ORDER BY day

日期格式化函数DATE_FORMAT在MySQL里很常用，按天、按月统计都可以用它。统计结果返回给前端后，用ECharts画折线图或柱状图，老板一眼就能看到营业趋势。

菜品销量排行是订单明细表的聚合查询，同样按时间范围过滤，按菜品名称分组，SUM(quantity)取总销量，ORDER BY销量DESC取前10：

sql复制SELECT dish_name, SUM(quantity) AS total_quantity, SUM(subtotal) AS total_amount
FROM order_detail
WHERE order_id IN (SELECT id FROM orders WHERE status = 3 AND create_time >= #{startTime})
GROUP BY dish_name
ORDER BY total_quantity DESC
LIMIT 10

这里用了子查询过滤出已完成订单的明细，防止把取消订单里的菜品也统计进去，这个细节很容易漏。

5. 实际开发中踩过的坑和完整排查链路

5.1 启动时报“mapper not found”的排查经过

项目启动后，Spring容器创建DAO对象时直接抛异常，提示找不到UserMapper这个类。我第一反应是Mapper接口忘记加注解了。检查之后发现注解加了，那问题出在哪？

顺着启动日志往下看，发现MyBatis扫描mapper包时提示“Invalid bound statement (not found)”，意思是Mapper接口找到了，但对应的SQL语句没找到。这一步把排查方向引向了XML映射文件。检查resources目录下的mapper包，发现UserMapper.xml确实存在，但文件名和接口名不一致——文件叫UserMapper1.xml，接口叫UserMapper.java，MyBatis默认按接口全限定名匹配XML，名称对不上就绑定失败。

修改方法很简单，把XML文件名改成UserMapper.xml，然后重新验证。同时检查XML里的namespace，必须写接口的全限定名，比如com.example.mapper.UserMapper。这两个地方同时正确，MyBatis才能把接口方法和SQL绑定起来。这个坑很容易踩，建议你在启动时如果报mapper相关的错，优先检查文件和namespace。

5.2 接口返回406的排查：Jackson依赖与返回类型

某个查询菜品列表的接口，前端请求后返回406 Not Acceptable，浏览器上直接显示。这个状态码的意思是服务器无法返回客户端可接受的内容类型。

排查链路是这样走的：前端用了Ajax请求，设置了Accept: application/json，后端用@ResponseBody注解想把返回对象转成JSON。406说明后端没成功把对象序列化成JSON，最常见的原因是项目里没引入Jackson依赖。Spring MVC进行对象转JSON时，默认使用Jackson，缺少依赖时转换器不被注册，框架找不到能处理JSON响应的消息转换器。

解决方式是检查pom.xml，加上jackson-databind依赖：

xml复制<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-databind</artifactId>
    <version>2.9.9</version>
</dependency>

另外还有一种情况：如果返回的结果是String类型，比如返回一个包装过的JSON字符串，Spring MVC不会做二次序列化，String类型的返回值直接原样输出。所以如果你用了@ResponseBody但返回的是String，前端拿到的Content-Type是text/plain而不是application/json，解析也会出问题。判断方法是看返回类型，能直接返回对象就不要先转成String再返回。

5.3 @Transactional不生效的常见原因

订单创建的事务，我一开始测试时没问题，后来加了一个“创建订单后更新菜品销量”的操作，模拟菜品销量库存不足抛异常，结果发现订单还是被插入成功了。这说明事务没有生效。

排查过程从三个角度展开：

第一，确认Service类是否被Spring管理。如果Service类上没有@Service或@Component注解，类不会被Spring扫描到，@Transactional自然无效。检查后确认注解存在。

第二，确认事务管理器是否配置。Spring MVC中可以配置DataSourceTransactionManager并开启注解驱动，缺少这一步，@Transactional会被忽略。检查Spring配置文件，事务管理器已配置。

第三，也是最容易忽视的点：调用方式。我是在Controller里把Service注入进来调用的，按理说是外部调用，代理应该生效。后来仔细看代码，发现我这个Service里写了一个public方法createOrderAndUpdateStock()，它内部直接调用了this.createOrder()和this.updateStock()。因为@Transactional放在内部被调用的方法上，而this调用不会经过Spring代理，所以注解被直接跳过。而外部入口方法createOrderAndUpdateStock()又没有加@Transactional，导致整个操作没有事务保护。

解决办法是把事务注解加到外部入口方法上，也就是调用链最上层那个public方法。内部方法可以不加，这样从代理进来的入口有事务，内部方法都在同一个事务里执行。这也是一个很典型的Spring AOP代理机制问题，理解了代理，事务这块就不会再有疑问。

5.4 PageHelper分页的坑

菜品列表和订单列表数据量稍大后，我引入了PageHelper分页插件。引入后遇到一个非常诡异的bug：第一个查询列表的接口分页正常，但紧接着调用另一个查询接口时，返回的数据也被分页了，而且还报了“Page count is zero”之类的错误。

原因是PageHelper通过ThreadLocal保存分页参数，如果不进行消费或清理，参数会残留到当前线程后续的查询中。Tomcat的线程是复用的，一个请求用过的线程可能被下一个请求继续使用，就出现了“跨接口分页”的诡异现象。

解决办法有两个：一是确保每次设置分页后，紧跟的查询是对应的查询语句，不要中间穿插其他数据库操作；二是在查询结束后手动清理ThreadLocal，PageHelper提供了PageHelper.clearPage()方法，或者在finally块中调用。更稳妥的做法是用MyBatis插件机制自带的拦截器处理，但那个配置相对复杂，实战中先确保“设置分页后立刻查询”这个规则不被打破，就能避开大部分问题。

6. 部署上线与后续优化方向

6.1 用Druid管理连接池

数据库连接池我选用的是阿里Druid。它比默认的dbcp或c3p0多了一个明显优势：内置监控页面，可以在线查看SQL执行耗时、并发数和连接池使用情况。配置方式是在Spring的数据库配置文件中指定DruidDataSource，并开启StatFilter和WallFilter。WallFilter是SQL防火墙，能拦截部分SQL注入攻击，对安全性有一定提升。

连接池的几个关键参数值得关注：initialSize是初始化连接数，maxActive是最大活跃连接数，minIdle是最小空闲连接数，maxWait是获取连接的最大等待时间。餐饮管理系统的并发量不高，initialSize设5，maxActive设20，maxWait设60000毫秒就够用。参数不是越大越好，连接数过大反而浪费数据库资源。

6.2 war包部署到Tomcat的关键步骤

SSM项目通常打包成war包部署。用Maven打包前，有几个地方要检查：

数据库配置文件里不能用本地数据库的localhost地址，要改成服务器上的数据库IP或域名。Maven打包时使用指定的profile，比如：

bash复制mvn clean package -DskipTests -Pprod

这样会读取resources目录下对应的生产环境配置文件，避免把开发环境的数据库密码带到生产环境。

打包完成后，把target目录下的war包放到Tomcat的webapps目录，启动Tomcat即可。如果你希望项目以根路径访问，比如直接通过域名根路径访问后台，需要把war包改名为ROOT.war。不用改的访问路径是/项目名/。

部署过程中最容易踩的坑是JDK版本不一致。本地用JDK8编译，服务器上如果只有JDK7，启动时大概率报UnsupportedClassVersionError。部署前先用java -version确认服务器JDK版本，最好和本地保持一致。

6.3 安全与健壮性上的几个点

SSM项目属于传统Web开发，安全方面不能完全照搬前后端分离项目那一套。我做了几个基础防护：

数据库访问统一使用MyBatis的#{}占位符，不要用${}。同样一个条件查询，用${}拼接用户输入有可能被注入SQL，用#{}则走预编译，参数被当作字符串处理，注入攻击基本失效。

密码存储用加盐MD5。虽然现在更推荐BCrypt，但SSM项目里为了不过度引入新依赖，加盐MD5是常见方案。使用MD5时一定要加盐，不加盐的MD5在彩虹表面前和明文没什么区别。

表单提交做基础参数校验。后端接口接收的数据一定要校验，比如下单时菜品数量必须大于0，金额必须大于等于0，不能完全相信前端传来的值。很简单的一个道理：接口可以被Postman直接调用，绕过前端的校验逻辑。

管理端的操作日志也值得做。虽然餐饮管理系统的用户少，但谁在什么时候改了什么菜品价格、谁取消过订单，真要查起来能把人折腾死。用Spring AOP做一个简单的日志切面，记录Controller方法的调用人、参数、耗时，成本不高，收益长远。

6.4 再往后可以怎么扩展

一期功能跑通后，会看到很多可以扩展的方向。

菜品模块可以加套餐组合、口味标签、每日特价。订单模块可以加退款流程、打印小票的模板管理。统计模块可以加同期对比、客流量统计、菜品毛利分析。如果门店多，还可以扩展多店铺的数据隔离。

更贴近实际的方向是库存联动。如果后厨有原料库存表，菜品下单时可以自动扣减原料数量，原料不足时下单界面给出提示。这个功能从技术上说，就是在下单事务里加一次库存检查与扣减，但需要把菜品和原料的映射关系建好，属于业务设计的复杂度，不是技术复杂度。

再进一步可以考虑将点餐端做成微信小程序或H5，让顾客扫码自助点餐。后端接口基本可以复用，只在前端形态上变化。到时候需要注意的就不是SSM本身，而是接口鉴权方式，可以考虑引入JWT替代Session，这是另一个话题了。

这个餐饮管理系统做下来，我个人最大的体会是：技术选型不是越新越好，而是越匹配场景越好。SSM这套组合虽然配置繁琐，但每层代码的逻辑都很直白，遇到问题容易定位。反而是需求理解和数据库设计这些“非代码”的部分，才是决定项目成败的关键。如果你正在做一个SSM相关的管理系统类项目，不妨把更多精力放在实体关系梳理和状态流转设计上，代码写起来反而轻松。最后再分享一个实际操作中的小技巧：开发阶段多打印SQL日志，MyBatis配置里把log-impl设为StdOutImpl，能看到每条SQL执行时的完整参数，排查数据问题会快很多。