SpringBoot+MyBatis-Plus高校餐饮档口管理系统实战

1. 项目整体设计与思路拆解

1.1 为什么是SpringBoot + MyBatis-Plus这套组合

高校餐饮档口管理系统这个题目，如果你去搜一遍市面上的开源项目和毕设论文，会发现十有八九都是SpringBoot打底。这并非跟风，而是这套技术栈在“中小型管理系统”这个场景下的确是最优解。

先看开发效率：SpringBoot的自动配置机制把过去SSH时代那些繁琐的XML配置砍掉了大半，一个内嵌Tomcat，mvn spring-boot:run就能起服务，这对时间极其宝贵的毕业设计阶段来说太重要了。再看维护成本：Spring生态的文档和社区问答几乎覆盖了你能遇到的所有报错场景，哪怕是凌晨三点遇到一个诡异的依赖冲突，搜一下也能找到解决方案。

持久层选MyBatis-Plus而不是纯MyBatis，原因也很实在：档口管理、菜品管理这类模块本质上就是单表CRUD，MyBatis-Plus的BaseMapper直接帮你把增删改查写好了，分页插件、条件构造器也都是现成的。我见过不少项目用纯MyBatis写，一个简单的档口列表页要手写XML映射、拼动态SQL、再手动封装分页，投入产出比太低了。当然，遇到多表联查的复杂报表，MyBatis-Plus也能退回去写自定义SQL，既有ORM的便捷，又不丧失灵活性。

前端这块多说一句。如果你拿到的项目是前后端分离版本，通常是Vue + Element UI（或者Vue3 + Element Plus）；如果是不分离的，往往是Thymeleaf模板渲染。两种我都跑过，前后端分离版更贴近真实企业开发，适合写在简历里；Thymeleaf版胜在部署简单，无需额外启动前端服务。无论哪种，后端接口的设计思路是一致的，后面我会专门讲。

1.2 三种角色与RBAC权限模型的底层逻辑

高校餐饮场景下，使用者天然分成三类：学生（普通用户）、档口老板（商户）、后勤管理员（平台方）。这个系统的核心难点也在于此——同一套系统要服务三种诉求完全不同的用户，权限设计做不好，整个项目就散了。

我拆解这套项目时，权限模型用的是经典的RBAC（基于角色的访问控制），但实现上做了简化：没有把权限细分到菜单按钮级，而是停留在角色级。原因很简单，学术项目讲求“设计合理但不过度设计”，一个高校食堂管理系统，管理员和档口老板权限边界清晰，学生权限单一，用角色 -> 菜单 -> 接口三级控制已经足够。你在源码里看到的通常是自定义拦截器或Spring Security做了@PreAuthorize注解控制，核心就一句话：登录后拿到当前用户角色，接口方法上标注允许访问的角色，不匹配直接抛401。

三种角色的业务闭环也值得讲清楚：

• 学生：登录 -> 浏览档口和菜品 -> 下单 -> 支付（一般是模拟支付） -> 取餐 -> 评价
• 档口老板：登录 -> 管理菜品（上架/下架/改价） -> 处理订单（接单/完成） -> 查看本档口当日营收
• 管理员：入驻审核 -> 档口启停用 -> 全局数据统计 -> 投诉处理 -> 公告发布

这套模型真正的价值在于：它把业务角色和技术模型一一对应，开发时Controller层按角色拆分组装，数据库层通过role字段区分，整个代码结构非常清爽。我看过一些失败的项目，把角色判断散落在Service各个方法里，if(user.getRole == 1)到处飞，后期改需求能改到怀疑人生。这个项目的分层方式值得你写论文时重点描述。

1.3 从下单到结算的完整业务链路

理解一个管理系统，最快的方式是跟一遍核心业务链路。我拿到这套源码的第一件事，不是看代码，而是对着数据库表结构和接口文档，把“学生下单”这条线走通。

流程是这样的：学生在前端点开某个档口，看到菜品列表，加购后提交订单，系统生成一条主订单记录（状态为“待支付”），同时生成订单明细记录（每个菜品一行）。学生点击“模拟支付”，订单状态变为“待制作”，档口老板在后台看到新订单，点击“接单”，状态变为“制作中”，出餐后点击“完成”，订单状态变为“待取餐”，学生取餐后可以选择“确认收货”，最后可以对本次用餐进行评价。

这里有个容易忽略的细节：订单状态流转不是随便写的，每一步都有对应的状态值和触发条件。源码里通常用OrderStatusEnum枚举管理：0待支付、1待制作、2制作中、3待取餐、4已完成、5已取消、6退款中。我在代码评审时特别留意枚举的编写质量，好的枚举应当把code和description放一起，而不是散落多个魔法数字。

结算链路是另一个展示系统设计能力的点。档口老板看到的“今日营收”，不是傻乎乎去订单表里SUM(amount)，而是经过状态过滤——只有“已完成”的订单才计入实际营收，因为待支付订单可能超时取消，已取消和退款订单更不能算进来。这种细节写进论文里，评审老师一眼就能看出你确实理解了业务，而不是只会调接口。

2. 核心功能模块与操作要点

2.1 档口入驻与菜品上下架：审核流的设计示范

档口管理模块是管理员端最重要的功能，设计上模仿了真实的平台入驻流程。

第一阶段是入驻申请，档口老板注册账号后填写档口信息（名称、位置、窗口号、联系电话、营业执照号、负责人），系统初始角色为“待审核”。管理员进入审核列表，查看申请信息，通过后档口状态变为“营业中”，学生端立刻能看到该档口。如果驳回，需要填写驳回理由，档口老板端会收到提示。

这里有个实操要点：审核流最忌讳“死审核”——审核后没有任何通知机制。优秀的实现会在审核结果变更时写一条消息记录，档口老板登录后未读消息有红点提示。虽然这不算核心功能，但能体现系统设计的完善度，答辩时很容易加分。

第二阶段是菜品管理。档口老板登录后，进入“我的菜品”页面，可以新增菜品，填写菜品名称、分类（荤菜/素菜/汤品/主食）、价格、图片、描述、每日限量。上架菜品后，学生端可见；如果某个菜当日售罄，老板直接点“下架”，前端就不会再展示。

实际操作中我建议你重点关注两个细节：一是菜品分类建议做成字典表管理，而不是写死在代码里，这样后期新增一个“清真窗口”之类的分类不需要改代码；二是价格字段必须用BigDecimal而不是double或float，这个问题我后面专门展开讲，因为几乎所有新手都会在这里栽跟头。

2.2 订单与结算对账：系统能不能用的关键评判标准

订单模块是整套系统的“心脏”，也是评审老师重点考查的部分。我见过的失败案例中，有不少是“能下单但算不清账”，这远比“页面丑”致命。

学生端的下单逻辑：选档口 -> 选菜品 -> 加入购物车 -> 提交订单 -> 模拟支付。这里的购物车我多说一嘴，不少初学者喜欢把购物车存数据库，但高校食堂场景下单频次高、单品数量少，用Redis或者前端LocalStorage存即可，没必要为了购物车开一张表。当然如果你的课程设计要求必须存数据库，那也未尝不可，但写论文时要能自圆其说。

订单编号的生成也是个值得写的细节。直接用数据库自增ID当订单号会暴露当日订单量，而且不利于多表关联时的人眼识别。比较好做法是：年月日时分秒 + 随机数（或用户ID后四位），比如20250607153012 + 0012，这样既保证一定程度的唯一性，又方便追溯。

档口端的订单处理与结算：老板进入“订单管理”，默认看到当日全部订单，按状态分为待制作/制作中/待取餐/已完成。接单 -> 制作 -> 出餐，三步操作对应三个按钮。所有“已完成”订单自动进入结算池，档口老板看到的是“今日营收 = 已完成订单金额合计”。

管理员端的全局结算看板则要有宏观视野：总订单数、总营收、各档口营收排行、菜品销量排行、时段热度分析。这些统计用SQL的GROUP BY和DATE_FORMAT就能完成，难点在于聚合查询要按照时间范围做参数化处理，而不是写死日期。

2.3 评价与投诉：闭环处理提升系统完整度

评价和投诉功能在很多初学者的项目里是“摆设”——用户能提交，但之后没有任何人处理，数据就躺在那里。这套系统让我比较满意的一点是，它把评价和投诉都做成了闭环。

学生端评价：订单完成后，学生可以对该档口评分（1-5星），填写评价内容。评价展示在档口详情页，其他学生选餐时可见。档口老板可以回复评价，管理员可以删除违规评价。

投诉处理流程则更复杂一些：学生提交投诉工单（类型：食品安全/服务态度/卫生问题/价格争议） -> 管理员收到工单 -> 调查处理 -> 填写处理结果 -> 状态变为“已处理” -> 学生可对处理结果进行满意度确认。

从技术实现上来看，投诉表需要比评价表多几个字段：status（待处理/处理中/已处理）、handle_result（处理结果）、handle_time（处理时间）。页面展示上，管理员端要能看到“待处理工单数”的醒目提示，理论上这类数据可以用消息通知推送，但作为管理后台，列表页的统计卡片已经够用。

2.4 数据看板与统计分析：让项目有“数据价值”

我强烈建议你在论文里单独写一节“统计分析功能”，哪怕代码量不大，但它把系统从“工具型”拉升到了“数据型”，这是答辩的加分项。这套项目里，管理员端的统计看板通常包含三块内容：

• 基础指标卡：今日订单数、今日营收、今日新增用户、总档口数
• 趋势图：近7日订单量趋势、近7日营收趋势（通常用ECharts折线图渲染）
• 排行表：档口营收TOP5、菜品销量TOP10

实现这类统计，后端接口一般会提供两个维度：startDate和endDate，前端切换时间范围时重新请求。SQL里用到最多的就是SUM、COUNT、GROUP BY、ORDER BY，配合DATE(create_time)做天维度分组。

这里我提醒一个容易踩的坑：日期范围查询别用between，尤其是当天数据的场景。因为你数据库里存的是datetime类型（2025-06-07 14:30:00），如果你传的结束时间是2025-06-07，隐含的时间是00:00:00，那当天14:30的订单就查不出来了。稳妥的做法是结束时间加一天，然后用<比较，或者前端直接传2025-06-07 23:59:59。这个坑，网上随便一搜全是血泪史。

3. 数据库设计与后端实现的关键细节

3.1 表结构设计：一张核心表如何撑起整个业务

我先给你梳理这套系统最核心的几张表，了解表结构是理解源码的第一步，也是写论文、画ER图的必经之路。

用户体系：

• sys_user：主键id、用户名、密码（BCrypt加密存储）、昵称、手机号、角色（0学生/1档口/2管理员）、头像、状态（启用/禁用）
• tb_stall：档口表，关联用户表，包含档口名称、窗口号、位置、简介、营业执照号、入驻审核状态、评分（冗余统计字段）

业务体系：

• tb_dish：菜品表，关联档口id，包含菜品名称、分类、价格、图片、描述、月销量（冗余）、状态（上架/下架）
• tb_cart：购物车表（可选，看实现方式）
• tb_order：主订单表，包含订单号、学生id、档口id、总金额、状态、支付时间、完成时间
• tb_order_item：订单明细表，包含订单id、菜品id、菜品名称（冗余）、单价、数量、小计金额
• tb_comment：评价表，关联订单id、学生id、档口id、评分、内容、回复内容
• tb_complaint：投诉表，类型、描述、状态、处理结果、处理时间

运营体系：

• tb_announcement：公告
• tb_settlement：结算流水表（可选，记录档口某段时间的结算明细）

这套设计最大的特点是用冗余字段换查询效率，比如tb_order_item里冗余了菜品名称，哪怕菜品后来改名或删除，历史订单依然能正确展示。再比如tb_stall里冗余了评分，评价表里每次新增评价时同步更新这个字段，前端展示档口列表时就不需要实时AVG聚合评分，性能好得多。

3.2 后端分层架构与接口设计规范

源码的包结构，通常是标准的Controller-Service-Mapper三层：

bash复制com.example.canteen
├── controller        # 接口层
├── service           # 业务层（接口 + impl）
├── mapper            # 数据访问层（MyBatis-Plus）
├── entity            # 实体类
├── dto               # 数据传输对象（前端传参）
├── vo                # 视图对象（返回前端的数据）
├── config            # 配置类（跨域、MyBatis-Plus分页、WebMvc拦截器）
├── common            # 通用类（统一返回结果、异常处理、枚举）
└── utils             # 工具类

接口设计上要遵循RESTful风格，统一返回结果我建议使用Result<T>包装，包含code（状态码）、msg（提示信息）、data（数据体）。前端拿到code = 200就取值渲染，code = 401就跳到登录页，逻辑清晰，排错容易。

举几个核心接口例子：

bash复制POST /api/user/login                      # 登录
GET  /api/stall/list                      # 档口列表（学生端）
POST /api/stall/audit                     # 管理员审核入驻
GET  /api/dish/list?stallId=1             # 按档口查菜品
POST /api/order/submit                    # 提交订单
POST /api/order/pay                       # 模拟支付
GET  /api/order/stall/list                # 档口老板查订单
POST /api/order/status                    # 更新订单状态
GET  /api/admin/statistics/overview       # 管理员看板统计

写Controller时要注意：Controller不写业务逻辑，只做参数接收和结果返回，所有业务逻辑下沉到Service。这样做的理由很实际：一旦后续需要加事务、加缓存、加消息队列，你只需改Service层，接口层不需要动。我从这套源码的注释和提交记录看，它的作者应该也是遵循了这个习惯。

3.3 订单状态机：用枚举管理状态流转

订单状态是这个项目里最容易写乱的逻辑。很多初学者用散落的数字判断状态，比如if(order.getStatus() == 1)，后期一旦想调整流程，到处都要改。这套项目里提供了很好的示范——用枚举类集中管理。

java复制public enum OrderStatusEnum {

    WAIT_PAY(0, "待支付"),
    WAIT_MAKE(1, "待制作"),
    MAKING(2, "制作中"),
    WAIT_TAKE(3, "待取餐"),
    FINISHED(4, "已完成"),
    CANCELLED(5, "已取消"),
    REFUNDING(6, "退款中");

    private final Integer code;
    private final String desc;

    OrderStatusEnum(Integer code, String desc) {
        this.code = code;
        this.desc = desc;
    }

    public Integer getCode() {
        return code;
    }

    public String getDesc() {
        return desc;
    }
}

在此基础上，建议再加一个状态流转校验方法：

java复制public static boolean canChange(Integer from, Integer to) {
    // 待支付可以取消；待制作可以接单；制作中可以完成；待取餐可以确认收货
}

这么做的好处是：订单状态更新只走一个统一入口，非法流转直接抛业务异常，不会出现“从待支付直接跳到已完成”这种脏数据。想象一下，如果学生还没付款，订单就被标记成已完成，结算时账就对不上了，这是非常严重的bug。

3.4 金额计算：BigDecimal与精度陷阱

这一段我每次讲都格外强调，因为几乎所有带着课设来找我看代码的同学，多少都在金额上踩过坑。

Java的float和double是二进制浮点数，很多十进制小数无法精确表示（比如0.1在浮点数里是无限循环小数）。如果你用double做金额加减，7.9 + 1.1 得到的结果可能是9.000000000000002，虽然只差一点点，但累计下来财务数据就没法看了。

正确做法是全程使用BigDecimal，并且使用字符串构造器，而不是直接传double：

java复制// 正确
BigDecimal price = new BigDecimal("12.50");

// 错误，仍然存在精度问题
BigDecimal price = new BigDecimal(12.50);

在算订单总金额时，应该遍历购物车明细，将每项price.multiply(new BigDecimal(quantity))再累加：

java复制BigDecimal totalAmount = BigDecimal.ZERO;
for (CartItemDTO item : cartItems) {
    BigDecimal subtotal = item.getPrice().multiply(BigDecimal.valueOf(item.getQuantity()));
    totalAmount = totalAmount.add(subtotal);
}

数据库层面也要配套，金额字段用DECIMAL(10, 2)，而不是FLOAT或DOUBLE。这一套组合拳打下来，金额精度才说得上安全。论文里可以专门起一个小节论证这个设计的合理性，属于“理论研究与实际结合”的加分点。

4. 本地部署全流程实录

4.1 环境准备与版本兼容性排查

源码+文档+部署+讲解是这类项目交付的“四件套”。我第一次拿到这类项目时，最先做的不是读代码，而是把运行环境跑通。环境和项目对不上，代码再好也是废纸。

我的建议配置如下：

这里我特别想聊一下“SpringBoot版本太高”这个坑。如果你拿到手的项目的pom.xml写的是SpringBoot 2.7.x，而你自己本机的JDK是17甚至21，大概率会启动报错。SpringBoot 2.x系列基于JDK8设计，虽然可以跑在更高版本JDK上，但部分反射操作和字节码库（如旧版CGLIB）会出现兼容问题。反过来，如果你新建项目直接选了SpringBoot 3.x，它要求JDK17起步，而你的项目代码还是按旧API写的，一样跑不起来。所以先检查JDK版本和SpringBoot版本的匹配关系，再做任何配置，能省你一整晚的时间。

4.2 数据库初始化与配置文件调整

数据库部分，项目文档里一般有sql文件夹，里面放着建表语句和初始数据。我的习惯是先建库、再依次执行SQL脚本：

bash复制mysql -u root -p < canteen_db.sql

执行成功后，用SHOW TABLES;确认表是否齐全。如果提示编码问题，记得在MySQL连接串上加上useUnicode=true&characterEncoding=utf8，否则前端页面显示中文乱码。

接下来是后端配置文件，以application.yml为例，核心改动集中在数据源：

yaml复制server:
  port: 8080

spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://localhost:3306/canteen_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai
    username: root
    password: 123456
  servlet:
    multipart:
      max-file-size: 10MB
      max-request-size: 10MB

mybatis-plus:
  configuration:
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl
  global-config:
    db-config:
      logic-delete-field: deleted
      logic-delete-value: 1
      logic-not-delete-value: 0

注意serverTimezone这个参数，MySQL 8.0默认时区和中国差8小时，不加这个配置，所有时间字段查出来都可能偏移，网上这个报错出现的频率仅次于端口冲突。

4.3 启动项目与功能验证

后端启动步骤非常标准：IDEA导入Maven项目 -> 等待依赖下载（首次可能需要5-15分钟，取决于网络） -> 运行启动类CanteenApplication -> 看到Spring Boot启动日志和Tomcat started on port(s): 8080说明成功。

如果项目是前后端分离版，还需要启动前端：

bash复制# 进入前端目录
cd frontend
# 安装依赖
npm install
# 启动开发服务
npm run serve

前端默认跑在localhost:8081（或配置的端口），通过vite/webpack的proxy代理把/api请求转发到后端8080，解决跨域问题。启动后建议按这个顺序验证功能：

1. 用管理员账号登录，进档口审核页面，看入驻申请列表
2. 用档口老板账号登录，新增一个菜品，设置价格
3. 用学生账号登录，进入档口页，看到刚才新增的菜品，下单支付
4. 回到档口老板账号，处理这笔订单
5. 管理员看板页面，确认统计数据有变化

这一步走通，说明整套系统的核心链路没问题。后续的二次开发和Bug修复，都是在这个基础上进行的。

4.4 “源码+文档+部署+讲解”四件套的价值与使用方法

我觉得有必要聊聊为什么这类项目要把“讲解”单独列为交付物。代码可以照抄，但只有理解了设计思路，你才能在答辩时对答如流。拿到项目后我强烈建议按这个顺序学习：

看文档：先读需求分析和系统设计章节，搞清楚系统的角色划分、功能模块、业务流程。这部分相当于是“上帝视角”，让你知道每个功能为什么要做、为什么这么设计。

看数据库：打开SQL脚本，对着ER图逐表理解字段含义，重点关注订单、菜品、用户三张核心表之间的外键关联关系。数据库是系统的地基，理解表结构就能推断出大部分业务逻辑。

看代码：按Controller -> Service -> Mapper的顺序逐层深入。Controller告诉你有哪些接口，Service告诉你业务规则，Mapper告诉你数据怎么查。

动手改：这是最关键的。挑一个小功能自己改一改，比如给菜品新增一个“今日推荐”字段，或者给订单列表增加一个状态筛选。只有亲手改过代码，你才算真正掌握这个项目，答辩时老师随便追问一个细节你都能接得住。

5. 常见问题排查与避坑实录

5.1 高频报错速查表

部署这套项目过程中，我自己踩过不少坑，也帮很多同学排查过类似问题。这里整理一份高频报错速查表，每个问题都是实际见过的，不是网上抄来的理论。

5.2 几个我印象深刻的坑

第一个坑是Maven依赖下载慢。用默认中央仓库下载SpringBoot全家桶，遇到网络波动能卡半小时。我的习惯是直接改settings.xml，换成阿里云镜像。改完以后依赖下载速度和坐火箭一样，这个经验在处理任何Maven项目时都通用。

第二个坑是MyBatis-Plus的逻辑删除。很多项目会开启全局逻辑删除配置，意味着你执行deleteById时实际上执行的是UPDATE ... SET deleted = 1。这在单表操作时没问题，但如果你做多表联查时没在SQL里加deleted = 0条件，就会把已经删除的订单明细查出来，导致统计数据对不上。排查这类问题，最快的办法是打开MyBatis的SQL日志输出（配置文件里的StdOutImpl），看实际执行的SQL到底长什么样。

第三个坑是前端代理配置。Vue项目的vue.config.js里如果proxy没写对，前端请求发到/api时不会转发到后端，虽然页面能打开，但所有接口都404。我在帮别人排查时，习惯先打开浏览器开发者工具，看Network面板里具体的请求地址——如果是localhost:8081/api/user/login而不是localhost:8080/api/user/login，那就是代理没生效。

5.3 运行性能与安全底线

最后聊聊性能和安全的边界。很多人觉得课设项目不需要考虑这些，做得差不多就行。但答辩时老师问到“你这个系统怎么保证安全”，你要是说不出个所以然，印象分会大打折扣。

密码存储：一定要用BCryptPasswordEncoder加密，明文密码存数据库等于裸奔。Spring Security自带的这个工具是行业标准，用起来也很简单，不会用的话去查一篇博客10分钟就能搞定。

SQL注入：MyBatis-Plus的QueryWrapper自动参数化，天然免疫注入。关键是用自定义SQL时，养成用#{}而不是${}的习惯，后者是直接拼接SQL，高危操作。

会话管理：登录后把用户信息存到Session或Redis里，后续接口通过@RequestAttribute或ThreadLocal获取当前登录用户，不要信任前端传过来的userId。这个细节很多人忽略，但实际攻击者只需要修改请求参数就能冒充他人身份。

接口限流：管理端点（比如登录接口）加上简单的验证码或次数限制，防止暴力破解。不用做得很复杂，登录失败锁定账号5分钟这种基础机制就够了。

5.4 二次开发的三个推荐方向

如果你不满足于“跑通项目”，想进一步把它变成简历上的亮点，我建议你往这三个方向尝试：

引入Redis缓存：把档口列表、菜品列表这类高频查询数据缓存到Redis，设置过期时间，减少数据库压力。这是目前企业开发中的标配，写进简历是实打实的加分项。

引入消息队列：虽然高校食堂档口系统的并发量远达不到需要MQ的程度，但你可以利用这个项目理解异步解耦的思路。比如订单创建成功后，通过MQ发送一条通知给档口老板，或者把订单推送到大屏展示系统。SpringBoot整合ActiveMQ或RabbitMQ的教程很多，而且网络热词里恰好有“springboot整合activemq”，说明这是当前大家关注的热点，学以致用是不错的选择。

补充单元测试：很多毕设项目的测试环节几乎是空白，如果你能给核心Service层写一组单元测试（用Mockito模拟数据库操作，用JUnit断言业务结果），答辩时展示一下绿色通过的测试用例，绝对能拉开和其他同学的差距。SpringBoot的测试支持非常完善，@SpringBootTest + MockMvc可以测Controller接口，@DataJpaTest或H2内嵌数据库可以测持久层逻辑。

写在最后的一个小建议

如果你是为了毕业设计拿到这套源码，我的忠告是：千万别只做一个“代码搬运工”。把项目跑起来只是及格线，你要花时间理清每条业务链路的来龙去脉，理解每个设计决策背后的权衡。答辩时老师抛出“为什么这个字段要冗余”“订单状态为什么这么流转”“这个功能还能怎么优化”这类问题时，你的回答深度，直接决定是拿“优秀”还是“良好”。

我个人在实操中还有一个习惯：拿到任何一套源码，先不急着启动，而是花20分钟读一遍数据库表结构，再花30分钟读一遍Controller层的接口列表，然后在纸上画出系统的功能脑图和核心流程图，做到了然于胸后才动手跑代码。别小看这个准备动作，它能让你的排查效率提高一倍以上。

最后分享一个小技巧：把项目日志级别从INFO调到DEBUG，启动时能看到完整的SQL执行日志和参数绑定信息，这对你理解每个操作的数据库行为帮助极大。配置就一行：logging.level.com.example.canteen.mapper=debug。用完之后再调回来就行。希望这篇文章能帮你少走弯路，把这套系统吃透、用好。