Spring Boot + SSM智慧餐厅点餐系统开发实战：从架构到部署全解析

1. 项目整体拆解：智慧餐厅点餐系统到底在做什么

先说结论，这类名为 springboot_ssm841智慧餐厅点餐管理系统 的项目，本质上是一个典型的管理信息系统（MIS），只不过业务场景落在了餐饮行业。它不是什么高深的前沿技术，而是把餐厅前厅点餐、后厨出菜、员工管理、菜品管理等日常流程，全部搬到线上，用一套系统统一调度。

系统名称里的 841 通常是开发者或学校内部的项目编号，没实际业务含义。真正要紧的是后半句：ssm三个角色 员工。SSM 指 Spring + Spring MVC + MyBatis 这套老牌 Java Web 组合，三个角色则是“管理员”“员工”“顾客”或者“管理员”“厨师”“收银员”，取决于你们毕业设计开题时的需求文档。我在实际接触过的多个同类项目里，见过最常见的角色划分是：

这个项目适合谁？两类人。一类是做 Java Web 课程设计或者毕业设计的在校生，需要一套能跑通、能讲清楚原理的完整案例；另一类是刚入行想搞懂 Spring Boot + SSM 怎么整合、真实业务系统的代码边界怎么划分的初级开发。你跟着搭一遍，可能比看十篇零散教程更有收获。

那为什么这套系统到今天还有参考价值？因为它在技术选型上非常“标准”。Spring Boot 负责简化配置和快速启动，Spring MVC 负责请求路由，MyBatis 负责数据库操作，三者职责边界清晰，非常适合拿来理解 Java Web 开发的基本套路。就算现在微服务、云原生喊得再响，中小型企业内部管理系统用类似架构搭建的仍然一抓一大把。

1.1 三个角色的权限边界要怎么设计

权限设计是整个系统最先要捋清楚的东西。别一上来就写代码，先用表格把三个角色能干什么、不能干什么列出来，再设计表结构。

我通常这样梳理：

• 管理员：对员工进行增删改查，重置员工密码，维护菜品分类和菜品信息，查看整店营业数据，比如日营收、月订单量、热门菜品排名。
• 员工：日常营业动作，包括给顾客开台、录入或修改订单、后厨看到待出餐列表后标记出品完成、收银员执行结账操作。
• 顾客（如果是小程序或H5端）：注册登录后，查看菜单，把菜品加入购物车，提交订单，查看自己的历史订单。

这里有一个细节容易踩坑：员工角色内部是不是还要细分？比如收银员和厨师的权限明显不一样。如果你的 sys_user 表里只有用户和角色两张表，那员工就只能绑一个角色。如果需求里明确说了“员工”有三种岗位，那你还要加一层岗位或部门字段，或者干脆把员工也理解成“可以配置多个角色”的实体。我建议毕业设计里不要贪多，三个角色就足够了，否则后面的权限拦截代码会成倍增加。

角色权限确定后，你在 Spring Boot 里的实现方案其实是固定的：用拦截器（HandlerInterceptor）或者 Filter 拦截请求路径，按 URL 前缀判断角色。比如 /admin/** 只允许管理员访问，/staff/** 只允许员工访问，/customer/** 允许游客访问。再加上登录时把当前用户的角色 code 写入 session 或 Token，后续接口里再判断一下有没有权限，就足够应付这类项目了。

1.2 拆解成功能模块后，工作量其实不大

把这套系统拆成模块，横向看大概是这么几块：

1. 用户管理模块：登录、注册（如果有顾客端）、员工账号维护、密码修改。
2. 菜品管理模块：菜品分类、菜品信息的增删改查、上下架、图片上传。
3. 桌台管理模块：桌台信息维护、开台、换台、并台（后两个通常简化为状态修改）。
4. 订单模块：顾客下单、菜品明细、订单状态流转、结账。
5. 统计报表模块：按日/周/月统计订单数和营业额。
6. 员工操作台：待出餐列表、出品标记。

看着多，但落到数据库就是七八张表，落到代码就是经典的 Controller-Service-Mapper 三层结构。我见过不少人把这个项目复杂化了，比如加了一堆用不上的 VO、DTO 转换、设计模式，结果答辩时自己也讲不清。毕业设计或者练手项目，重点是把业务闭环跑通，代码分层干净，逻辑清晰，这比花哨的架构重要得多。

2. 技术选型解析：Spring Boot + SSM，为什么这套组合至今不过时

热词里反复出现 springboot 和 ssm，说明这确实是搜索量极高的组合。很多人搞不清楚 Spring Boot 和 SSM 到底是什么关系，先把这件事说明白。

SSM 是 Spring、Spring MVC、MyBatis 三个框架的缩写组合。传统 SSM 项目，需要你手动写一堆 XML 配置：web.xml、spring-mvc.xml、mybatis-config.xml、数据源配置、事务配置……光是让 Hello World 跑起来，新手往往就要折腾半天。而且各 Jar 包版本之间的兼容性问题非常折磨人。

Spring Boot 做的事，就是把这些配置大量简化。它用“约定大于配置”的思路，把常用的配置项做成了自动配置，你只需要在 application.yml 里写必要参数，比如数据源地址、端口号等，剩下的它帮你处理。Spring Boot 并不是替代了 SSM，而是把 Spring MVC 和 MyBatis 整合到了自己的生态里，让开发者用更少的配置写出同样的功能。

所以这个项目标题写成 springboot_ssm841，实际含义是：基于 Spring Boot 作为基础框架，内部使用 Spring MVC 处理 Web 层，使用 MyBatis 处理持久层。现在的开发实践中，很少有人再手动搭建传统 SSM XML 工程了，而 Spring Boot + MyBatis 的组合在中小型项目中仍然非常普遍。

2.1 Spring Boot 版本怎么选才不踩坑

热词里有“springboot版本太高”“idea不能创建springboot项目不能使用jdk1.8”“springboot 2.7.18”“springboot从2.x版本升级到3.5.x版本”，这些词集中反映了一个问题：版本选择对新手来说是个大坑。

直接给结论，如果你用的是 JDK 1.8，那 Spring Boot 2.7.18 基本是最后的稳定选择。Spring Boot 3.x 开始强制要求 JDK 17 及以上，很多还在用 JDK 8 的环境直接装不上。而且 3.x 版本里，javax.* 包名变成了 jakarta.*，如果你引用的第三方工具包还停留在 javax 时代，升级后编译直接报错。

具体到智慧餐厅点餐系统这个项目，我的建议是：

如果你非要用 Spring Boot 3.x，那就老老实实换 JDK 17，同时把所有依赖检查一遍，尤其是 PageHelper、Druid 这些常用库，确认它们有适配 3.x 的版本。另外 Spring Boot 3 里 MyBatis 要使用 mybatis-spring-boot-starter 3.0+，否则运行时会报 ClassNotFoundException。

2.2 SSM 整合中最容易写错的三处配置

虽然 Spring Boot 简化了配置，但三处配置你仍然要手写，而且特别容易出错。

第一处是数据源。application.yml 里的 spring.datasource.url 中，MySQL 8.0 的驱动类是 com.mysql.cj.jdbc.Driver，URL 后面最好带上 serverTimezone=Asia/Shanghai&useUnicode=true&characterEncoding=utf8，否则插入中文会乱码，或者报时区错误。我见过无数个新手在这里被绊倒。

yaml复制spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://localhost:3306/restaurant?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai
    username: root
    password: 123456

第二处是 MyBatis 的 Mapper 扫描。启动类上要加 @MapperScan 注解，或者在每个 Mapper 接口上加 @Mapper 注解。两者选一个就行，但别两种混着来，新手经常犯这个错误导致启动时提示找不到 Bean。

第三处是事务配置。Spring Boot 里事务只需要在 Service 方法或类上标注 @Transactional，不需要像传统 SSM 那样写 <tx:advice>。但要注意一点，@Transactional 必须由 Spring 代理调用才生效。同类内部通过 this 调用另一个带事务的方法，事务会失效。这在后面订单下单逻辑里非常常见，我会专门在排查实录里讲。

2.3 MyBatis 分页插件的用法，别再用拦查询自己封装了

热词里专门问到“mybatis的分页插件的用法 springboot”，这个确实是做管理系统的高频需求。餐厅点餐系统里订单列表、菜品列表、员工列表都要分页。

现在主流方案是使用 PageHelper，用法非常简单：

java复制PageHelper.startPage(pageNum, pageSize);
List<Order> orderList = orderMapper.selectOrderList();
PageInfo<Order> pageInfo = new PageInfo<>(orderList);

核心就三步：

1. 在查询前调用 PageHelper.startPage(pageNum, pageSize)。
2. 紧接着执行你的查询方法，PageHelper 会拦截这条 SQL，自动拼接 LIMIT 语句。
3. 用 PageInfo 包装查询结果，里面已经帮你算好了总记录数、总页数、当前页码等。

有几个坑必须注意。第一，PageHelper.startPage 只对下一条执行的 SQL 生效，所以别在它后面穿插别的查询逻辑。第二，分页查询结果不要做复杂的集合操作，比如循环里再查数据库，否则 PageHelper 会分页错乱。第三，如果你返回给前端的是 List，页码信息会丢，你要么直接返回 PageInfo，要么手动把 total 传给前端。

排序方面，我习惯在 XML 里使用 order by 直接拼接排序字段，但字段名一定不要来自前端参数直接拼接，防止 SQL 注入。最稳妥的做法是后端定义一个排序字段白名单，前端传 createTime 或者 orderAmount，后端映射成实际字段名，再传给 XML。

3. 数据库设计与核心表结构

数据库设计是这种信息管理系统的地基。代码写得再漂亮，表结构设计不合理，后面写 SQL 的时候处处难受。智慧餐厅点餐系统的核心流程是“顾客进店-开台-点餐-后厨出品-结账”，所有表都要围绕这个链路展开。

我给出一个相对标准的设计，覆盖三个角色的核心需求。

3.1 核心表清单与字段说明

1. 用户表 sys_user

2. 菜品分类表 categorie

3. 菜品表 dish

4. 桌台表 dining_table

5. 订单表 orders

6. 订单明细表 order_detail

为什么 order_detail 要冗余 dish_name 和 price？因为菜品信息可能会改，比如改价或改名，但历史订单必须保持当时的下单快照。这是订单系统设计的常识性问题，很多初学者不冗余，结果后来菜单一改，历史订单对不上。

3.2 订单状态流转与状态机设计

订单状态是整个系统最核心的业务数据，前后台所有操作都围绕它展开。我建议把状态定义成常量类，统一管理，业务代码里别散落着魔法数字。

java复制public class OrderStatus {
    public static final int CREATED = 0;   // 待处理
    public static final int SERVING = 1;   // 制作中/已出餐
    public static final int FINISHED = 2;  // 已完成
    public static final int CANCELLED = 3; // 已取消
}

状态流转方向一般是：

• 顾客或员工创建订单后：状态置为 CREATED。
• 后厨看到待出餐菜品，开始制作，制作完成标记：状态置为 SERVING，或者维护单独一个“出品状态”字段。
• 收银员结账完成后：状态置为 FINISHED。
• 异常情况如顾客取消：状态置为 CANCELLED。

实际操作时，很多人会把“订单状态”和“出品状态”混在一个字段里，逻辑会乱。我建议拆开：订单状态管全局，出品状态管明细。比如一张桌点了5个菜，可能3个已经上了，2个还在做，如果只用一个字段，你根本没法表达这种中间状态。订单表里放 status，订单明细表里放 item_status（0待制作，1制作中，2已上菜），这样后厨出菜的进度就能准确控制。

状态变更的时机要在 Service 层统一控制，最好封装成独立方法，比如 submitOrder()、startCook()、finishItem()、payOrder()。每个方法里更新状态前先校验当前状态是否允许流转，比如已经 CANCELLED 的订单不能再变更为 FINISHED。这层校验能挡住很多脏数据。

4. 核心功能模块实现细节

功能模块的代码实现，是项目从设计图变成可运行系统最关键的部分。我挑四个最核心的模块来讲实现思路和关键代码，分别是登录与拦截器、点餐下单、后厨出品桌台管理、菜品管理与库存联动。这些模块覆盖了三个角色的全部核心操作。

4.1 登录认证与拦截器校验

登录认证有几种方案：传统 Session、JWT、Spring Security/Shiro。毕业设计级别，我推荐用 Session + 拦截器，理由是实现简单、答辩好讲、知识体系经典。如果你的项目需要支持小程序端或者前后端分离，那你直接上 JWT 也不难，把 session 换成 token 就行。

登录接口的逻辑：

java复制@PostMapping("/login")
public Result login(@RequestBody LoginRequest request, HttpSession session) {
    SysUser user = userService.findByUsername(request.getUsername());
    if (user == null || !passwordEncoder.matches(request.getPassword(), user.getPassword())) {
        return Result.error("用户名或密码错误");
    }
    if (user.getStatus() == 0) {
        return Result.error("账号已被禁用");
    }
    session.setAttribute("loginUser", user);
    session.setAttribute("roleCode", user.getRoleCode());
    return Result.success(user);
}

密码一定要加密存储，不要用明文。Spring Security 的 BCryptPasswordEncoder 是首选，或者 MyBatis 项目里常用 MD5 加盐。BCrypt 的好处在于同一密码生成的两个密文不同，且自带盐值，安全性远高于裸 MD5。

拦截器实现权限控制：

java复制public class LoginInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        HttpSession session = request.getSession();
        SysUser user = (SysUser) session.getAttribute("loginUser");
        if (user == null) {
            response.sendRedirect("/login");
            return false;
        }
        String uri = request.getRequestURI();
        if (uri.startsWith("/admin/") && !"ADMIN".equals(user.getRoleCode())) {
            response.setStatus(403);
            return false;
        }
        return true;
    }
}

注意一个问题：静态资源（CSS、JS、图片）也要放行，否则页面样式全挂。在 WebMvcConfigurer 里配置：

java复制registry.addInterceptor(new LoginInterceptor())
        .addPathPatterns("/**")
        .excludePathPatterns("/login", "/register", "/css/**", "/js/**", "/images/**", "/error");

热词里出现过“springboot拦截器验证token”，如果你的系统采用 JWT，拦截器就不从 session 里取用户，而是从请求头 Authorization 里取 token，解析后把用户信息放进 ThreadLocal 或请求上下文里。校验逻辑和 session 版本大同小异，只是多了一步解析和过期判断。

4.2 点餐下单与事务控制

点餐下单是整张订单链路的起点，涉及订单主表、订单明细表、桌台状态三个地方的变更。这一串操作必须在一个事务里完成，否则很容易出现“订单创建了但明细丢失”的脏数据。

我写一下核心的 Service 逻辑：

java复制@Transactional(rollbackFor = Exception.class)
public Order createOrder(CreateOrderRequest request) {
    // 1. 生成订单主表记录
    Order order = new Order();
    order.setOrderNo(generateOrderNo());
    order.setTableId(request.getTableId());
    order.setUserId(request.getUserId());
    order.setStatus(OrderStatus.CREATED);
    order.setCreateTime(new Date());
    orderMapper.insert(order);

    // 2. 插入订单明细
    List<OrderItemRequest> items = request.getItems();
    BigDecimal totalAmount = BigDecimal.ZERO;
    for (OrderItemRequest item : items) {
        Dish dish = dishMapper.selectById(item.getDishId());
        if (dish == null || dish.getStatus() != 1) {
            throw new RuntimeException("菜品不存在或已下架");
        }
        OrderDetail detail = new OrderDetail();
        detail.setOrderId(order.getId());
        detail.setDishId(dish.getId());
        detail.setDishName(dish.getName());
        detail.setPrice(dish.getPrice());
        detail.setQuantity(item.getQuantity());
        detail.setSubtotal(dish.getPrice().multiply(BigDecimal.valueOf(item.getQuantity())));
        orderDetailMapper.insert(detail);
        totalAmount = totalAmount.add(detail.getSubtotal());
    }

    // 3. 更新订单总金额和桌台状态
    order.setTotalAmount(totalAmount);
    orderMapper.updateAmount(order.getId(), totalAmount);
    tableMapper.updateStatus(request.getTableId(), TableStatus.OCCUPIED);
    return order;
}

几个容易忽略的细节：

• 金额计算一定要用 BigDecimal，不能使用 double 或 float，否则会出现精度丢失，比如 0.1 + 0.2 不等于 0.3。
• 生成订单号时，可以用时间戳加随机数，也可以查库用自增 ID 再拼接，不管哪种方式，订单号字段必须唯一，数据库层面加上唯一索引。
• 下单时要把菜品的当前价格冗余进明细表，而不是查表动态计算，这在前面表结构设计时已经强调过。

关于 @Transactional 的潜在坑，我这里先提醒一句：createOrder 方法不能在同一个类里被另一个方法用 this 调用。比如你在 Controller 里调用 Service 的方法没问题，但如果在 Service 内部通过 this.createOrder() 调用，事务拦截器不会生效。一定要通过注入自身的代理对象或者把方法拆到不同类里。

4.3 后厨出品与桌台状态管理

三个角色里，员工的使用场景是最频繁的。点餐不只是“下单”这一个动作，还包括开台、加菜、退菜、出品、结账这一系列流程。后厨出品的核心逻辑就是按桌号和订单号拉取出餐任务。

后厨端的接口通常有两个：

java复制// 查询当前待出餐菜品
@GetMapping("/staff/tasks")
public Result getPendingTasks() {
    List<OrderDetailVO> tasks = orderDetailMapper.selectPendingItems();
    return Result.success(tasks);
}

// 标记某道菜已出品
@PostMapping("/staff/finishItem")
public Result finishItem(@RequestParam Long detailId) {
    orderDetailMapper.updateItemStatus(detailId, ItemStatus.SERVED);
    return Result.success();
}

这里有一个业务判断：当一道菜被标记为已出品后，要不要同步更新订单主表的状态？答案是不要。订单主表和明细状态要解耦。

举例说明：一桌点了 3 道菜，后厨先出了 2 道，只有第 3 道还欠着。此时你不能把订单主表状态改成“已完成”，因为顾客还在等菜。只有所有明细的 item_status 都变为 SERVED，才能把订单主表状态置为 SERVING，表示“菜品已齐”。结账时再把订单状态从 SERVING 改为 FINISHED。这个状态机的逻辑在答辩时很加分，说明你有真实业务思考。

桌台状态的管理同样重要。开台（将桌台从空闲改为占用）和结账（从占用改回空闲）是一对对称操作，如果其中任何一步漏掉，桌台状态就会错乱。更麻烦的是，如果服务员忘了结账就清台，后续数据统计也会出问题。所以结账时，不仅要更新订单状态和桌台状态，最好再做一次校验：该桌当前是否存在未结账的订单。

4.4 菜品管理与库存联动的补充思路

菜品管理模块相对常规，就是分类和菜品信息的增删改查。但有一个问题值得展开：菜品要不要管库存？

餐厅点餐系统的库存管理，和电商类系统不太一样。大多数菜品的原材料不是按“份”来记录的，比如一份“鱼香肉丝”消耗多少肉、多少配料，属于后厨精细化管理的范畴。做毕业设计时，我建议不要把库存建模得太复杂，一个折中做法是给菜品表加一个 stock 字段，表示当日可售份数。

下单时做库存扣减：

java复制int updated = dishMapper.reduceStock(dishId, quantity);
if (updated == 0) {
    throw new RuntimeException("菜品库存不足");
}

reduceStock 的 SQL 写成这样：

xml复制<update id="reduceStock">
    UPDATE dish
    SET stock = stock - #{quantity}
    WHERE id = #{dishId} AND stock >= #{quantity}
</update>

这个写法的好处是，利用数据库的行锁和条件更新，天然避免超卖问题。如果库存不足，updated 等于 0，代码里直接抛异常回滚事务。不用自己去 SELECT stock 再判断再 UPDATE，那两步操作在并发场景下会有数据竞争。

菜品图片上传也是常见需求。Spring Boot 里可以用 MultipartFile 接收文件，保存到本地磁盘的某个目录，然后把访问路径存入数据库，再通过一个资源映射配置把 URL 映射到磁盘目录。注意 Windows 和 Linux 的路径分隔符不一样，绝对路径不要写死，用配置文件维护一个 upload.path 变量，部署到哪台机器改配置就行，不用改代码。

5. 开发期高频问题与排查实录

这个项目看着简单，实际开发过程中会遇到不少问题。这些问题在网上零零散散都能搜到，但很少有人集中整理出来。我把自己遇到过和学生群里高频出现的问题做个合集，按问题现象、原因、解决方案三个维度来写，方便你排查时直接对照。

5.1 Spring Boot 版本太高导致的一系列兼容性问题

如果你用 IDEA 新建 Spring Boot 项目时，默认选择的 3.x 版本又搭配上了 JDK 1.8，启动时大概率会出现类似这样的报错：

text复制Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.UnsupportedClassVersionError: org/springframework/boot/loader/Launcher has been compiled by a more recent version of the Java Runtime

原因就是 Spring Boot 3.x 编译时基于更高版本的 JDK，而你的运行环境是 JDK 8，字节码版本不兼容。解决办法也很直接：创建项目时把 Spring Boot 版本手动改成 2.7.18，对应的 Maven 仓库会下载适配版本。如果你用的 Spring Initializr 默认只提供 3.x，可以去 Spring 官方 GitHub 上找个 2.7.18 的示例配置，或者用阿里云镜像创建项目时指定版本。

还有一类情况是：Spring Boot 3.x 项目里引用了旧版 javax 包，比如 javax.annotation 或 javax.validation，编译时提示包不存在。这是包名从 javax 迁移到 jakarta 导致的。如果非得用 Spring Boot 3，把依赖统一换成 jakarta.* 的对应包就行，但这个改动对于新手来说还是挺容易遗漏的。

5.2 MyBatis Mapper 接口不被扫描导致启动失败

报错文案一般是：

text复制Field orderMapper in com.example.service.impl.OrderServiceImpl required a bean of type 'com.example.mapper.OrderMapper' that could not be found.

这个问题的根本原因是 Mapper 接口没有被 Spring 扫描进容器。如果你在启动类上使用了 @MapperScan，但包路径写错了，扫描不到对应的 Mapper 接口；或者你用了 @Mapper 注解标注了接口，但是该接口所在的包没有在 @ComponentScan 的扫描范围内，同样会报错。

解决方案有两种：

1. 在启动类上加 @MapperScan("com.example.mapper")，把 Mapper 接口所在的包路径写准确。
2. 在每个 Mapper 接口上单独加 @Mapper 注解。

我个人的习惯是使用 @MapperScan，因为一个注解搞定所有 Mapper，不用在每张表对应的接口上重复标注。另外注意，@MapperScan 的扫描路径要与 @SpringBootApplication 所在类的包结构呼应，原则上 Mapper 接口应该放在主类所在包的子包下。

5.3 PageHelper 分页数据错乱或 total 为 0

这类问题非常常见，现象是明明有 100 条数据，分页查询后 total 只有 1 页，或者查出来的是全表数据。

第一种原因是 startPage 和查询之间夹了其他 SQL 操作。PageHelper 的原理是拦截下一条即将执行的查询语句，如果你在 startPage 之后又执行了一个别的查询，比如查菜品分类，PageHelper 就会把分页参数套到这个查询上，导致业务数据完全不对。

第二种原因是查询后做了集合转换，比如用了 BeanUtils.copyList()，把 Page 对象转成了一个普通的 ArrayList，total 信息就丢了。PageHelper 提供的 PageInfo 类在构造时会从底层 Page 对象中提取 total、pageNum、pageSize 等分页信息，所以用 new PageInfo<>(list) 包装后返回给前端才是最稳的。

还有一点容易被忽略：如果查询 SQL 里有 GROUP BY 等聚合操作，PageHelper 计算 count 时可能会出错。这种情况建议自己写一个 count 查询，分页就用手动方式，不要依赖插件。

5.4 事务不生效，数据一半成功一半失败

同样是在 Service 层加了 @Transactional，下单时菜品明细插入成功了，但是订单主表更新失败，导致数据不完整。很多人遇到这种问题就怀疑事务注解是不是写错了，其实大部分原因是自调用。

java复制@Service
public class OrderService {
    public void createOrder() {
        this.doSave(); // 自调用，事务失效
    }

    @Transactional
    public void doSave() {
        // 数据库操作
    }
}

@Transactional 的原理是 Spring AOP 代理。外部调用 orderService.createOrder() 时，Spring 返回的是代理对象，代理对象在方法执行前后包裹了事务逻辑；但 this.doSave() 中的 this 是当前对象本身，不是代理对象，所以事务管理逻辑完全没有机会介入。

解决方式有三种：

1. 把 doSave 方法定义到另一个 Service 类中，通过注入调用。
2. 在类中注入自身代理，如 @Autowired 或 @Resource，但 Spring 目前对循环依赖默认不支持，可以借助 @Lazy 解决。
3. 使用 TransactionTemplate 手动控制事务，代码会变得直白：

java复制@Autowired
private TransactionTemplate transactionTemplate;

public void createOrder() {
    transactionTemplate.execute(status -> {
        // 数据库操作
        return null;
    });
}

从可读性角度，我推荐第 1 种，把下单的数据库操作拆分到一个独立的事务 Service 类里，职责清晰，事务边界也容易把控。

5.5 前端上传的图片无法访问

菜品图片上传成功，数据库里也存了 /upload/xxx.jpg，但在浏览器里访问返回 404。这个问题在本地开发时最容易出现。

原因是 Spring Boot 默认不会把本地磁盘的任意目录映射成可访问的静态资源路径。你需要写一个配置类：

java复制@Configuration
public class WebMvcConfig implements WebMvcConfigurer {
    @Override
    public void addResourceHandlers(ResourceHandlerRegistry registry) {
        String uploadPath = System.getProperty("user.dir") + "/upload/";
        registry.addResourceHandler("/upload/**")
                .addResourceLocations("file:" + uploadPath);
    }
}

注意两点：addResourceLocations 参数必须以 file: 开头，Windows 下路径结束要有 /；上传文件时不要直接用原文件名保存，容易重复和引起安全问题，建议用 UUID 重命名：

java复制String ext = originalFilename.substring(originalFilename.lastIndexOf("."));
String newFilename = UUID.randomUUID().toString().replace("-", "") + ext;

6. 打包部署与后续扩展建议

开发调试完，项目总要能打包上线。别小看这一步，我在帮别人排查问题时，发现不少项目在 IDEA 里跑得好好的，一打包部署就各种奇怪问题。

6.1 打包部署的关键步骤

Spring Boot 项目默认用 Maven 打包，常规操作是：

bash复制mvn clean package

如果你想跳过测试再打包：

bash复制mvn clean package -DskipTests

打包完成后，target 目录下会生成一个可执行的 JAR 文件，直接运行：

bash复制java -jar springboot_ssm841-0.0.1-SNAPSHOT.jar

需要注意几个常见问题：

第一，打包时如果用了自定义的本地 JAR 包，Maven 默认不会把它们打进最终包里。解决方式要么把本地 JAR 安装到本地仓库，要么在 pom.xml 里把本地 JAR 的 scope 设置为 system 并把路径指向本地目录。

第二，application.yml 里配置的数据库连接地址、账号密码，在打包后统一写在外部配置文件中会更好，部署到服务器时不改 JAR 内容只改配置，操作起来更灵活。你可以用启动参数指定：

bash复制java -jar app.jar --spring.config.location=/opt/config/application.yml

第三，Linux 服务器上部署时，数据库连接 URL 里的 localhost 要改成实际的数据库地址，否则本地测试正常、服务器上一启动就报连不上数据库。

6.2 启动顺序和日志排查

Spring Boot 项目启动时，建议先确认几个信息，再决定是否排查问题：

1. 启动日志里有没有 Tomcat started on port(s): 8080，说明 Web 服务启动成功。
2. 日志里有没有报数据库连接异常，比如 Access denied for user 或 Communications link failure。
3. 有没有 Mapper 相关的警告或明确的 BeanCreationException。

服务器上跑项目，最重要的习惯是看日志。不要直接关掉窗口就跑 java -jar，不然日志全打在控制台里，一旦你退出登录，进程可能被挂掉或者日志丢失。建议用 nohup 或者直接部署成 systemd 服务：

bash复制nohup java -jar app.jar > Log.out 2>&1 &

部署到生产环境后，如果页面静态资源或图片是绝对路径引用，也会出现 404。开发时如果写死了 http://localhost:8080/upload/xxx.jpg，部署地址一变就全挂。千万不要在业务代码里拼绝对路径，用 request.getScheme() + "://" + request.getServerName() 动态拼，或者前端直接用相对路径，会更安全。

6.3 后续可以扩展的方向

把这套餐厅点餐管理系统作为课程设计或毕业设计，做完基础版本后，完全可以再往下面几个方向扩展，既增加项目的深度，也能在答辩或简历里加点真实亮点。

第一个方向是引入 Redis。比如用 Redis 缓存菜品分类和菜品列表，减少数据库压力；用 Redis 存储登录 Token 实现分布式会话；甚至用 Redis 的过期特性实现购物车自动清理。技术含量比纯数据库查询高一个台阶，而且不需要改动太多代码。

第二个方向是做数据可视化。现在只是简单的表格展示订单和营业额，你可以接入 ECharts，把每日营收走势、热销菜品排行榜、桌台使用率等指标用图表展示出来。这部分前端工作量不大，但视觉效果很加分。

第三个方向是做手机端点餐。现在很多餐厅用微信小程序或扫码点餐，你可以把顾客端做成一个轻量的 H5 页面，顾客扫码打开，选菜下单，后厨同步打印小票或弹屏提醒。这就会把前后端交互、接口安全性、订单推送等知识点全串起来。

对于这个智慧餐厅点餐项目，我的真实体会是：它真正的价值不在于代码量多大、用了多新的技术，而在于你能不能在有限的功能里把业务逻辑想清楚、把权限边界理清楚、把状态流转搞明白。在我经手的多个类似项目中，凡是数据库设计清晰、事务边界明确的项目，哪怕页面上稍微朴素一点，也很容易在学校答辩或面试讲解中拿到高分。反过来，如果只是堆功能，代码结构混乱，讲也讲不清楚，那最后只能靠截图撑场面。

最后再分享一个小技巧。写这类管理系统，不用一上来就急着写代码。先把每个角色进入系统后能看到的页面列出来，再把每个页面的按钮对应到后端接口，最后画出数据库表关系。这个流程看着慢，实际上能帮你少走很多弯路。我后面做这个餐厅系统的时候，光数据库设计就改了三次，就是因为最初的低着写代码导致反复。等你把这些问题想透了，写代码其实是最快的一步。