SpringBoot+Vue预定点餐系统：从数据库设计到毕业设计答辩全攻略

1. 选题思路与技术架构选型

先说结论：这个题目是Java全栈方向里稳妥又不容易撞车的经典选题之一。你在某高校或者某培训机构的毕设清单里大概率见过"基于SpringBoot+Vue的点餐系统"，如果把关键字换成"预定"，整个系统的复杂度、业务逻辑和论文工作量立刻上了一个台阶，这也正是它适合做课程设计和毕业设计的原因——既有足够的技术覆盖面，又不至于难到做不完。

1.1 为什么是"预定"而不是普通"点餐"

市面上绝大多数点餐系统做的是门店扫码点单、购物车直接下单、即时支付，核心逻辑是"选菜—下单—出单"。而带有"预定"属性的点餐系统，在时间维度上多了一层业务语义：用户不是立刻要吃饭，而是先选中某个日期、某个时间段，甚至某个就餐场次，提前把菜品锁下来。这个设定非常关键，因为它带来了一系列普通点餐系统没有的技术问题：

• 菜品和预定时段的关系（节假日、周末的预定配额怎么处理）
• 订单状态机的复杂度（待确认、已确认、已完成、已取消）
• 日期和时段的库存校验（某天某个时段只剩3个名额，你下单时怎么保证并发下不超）
• 管理端需要处理预定审核、时段排班、备餐计划

从课设评分角度来说，这些点都可以在论文的"系统分析"和"系统设计"章节里展开写，比单纯写"实现了增删改查"有内容得多。从技术面试角度来说，你在项目描述里写上"多条件预定查询与状态流转"，也比"简单的CRUD系统"更能引出话题。

1.2 技术栈为什么选SpringBoot+Vue

这个组合现在已经是JavaWeb课的默认答案，原因是它解决问题的路径最短：

• SpringBoot：不需要像SSH（Struts+Spring+Hibernate）时代那样写大量XML配置，一个启动类加几个注解就能把Web服务跑起来。内嵌Tomcat，打包成jar直接运行，部署环境不折腾。对于课设答辩演示，启动项目就一个命令。
• Vue：比JSP时代的模板渲染方式清爽太多。前后端分离之后，前端专注页面交互，后端只出接口，调试的时候后端用Swagger测，前端用自己的Mock数据，互不阻塞。
• MySQL：免费、资料多、可视化工具成熟（Navicat、DataGrip），网上随便一搜都是案例，遇到问题容易排查。

我在实际开发中的体会是，毕设项目的技术栈不一定要求最新，但要满足三点：自己讲得清楚、社区资料足够、出了问题能快速找到答案。SpringBoot+Vue恰好全都满足。

注意：如果你所在学校要求必须用某个指定框架（比如某些学校JavaWeb课指定SpringMVC+JSP），那你得先满足课程要求，再考虑扩展成前后端分离。搞清楚评分标准里技术路线占多少分，别因为炫技反丢了基础分。

2. 功能模块拆解与数据库建模

2.1 用户端和管理端的功能边界

一套完整的预定点餐系统，按角色划分通常包含两类终端：

用户端（前端页面）

• 注册与登录：用户名+密码，加上角色区分（管理员/普通用户）
• 菜品浏览：分类展示、菜品详情、价格和余量显示
• 预定点餐：选择就餐日期和时段，把菜品加入预定单，确认提交
• 预定记录：查看自己的预定历史、取消未开始的预定
• 个人中心：修改密码、查看个人信息

管理端（后台管理）

• 菜品管理：添加、修改、删除、上下架菜品，上传菜品图片
• 分类管理：维护菜品的分类（热菜、凉菜、汤品、主食等）
• 预定管理：查看所有预定单，按日期过滤，确认或取消预定
• 时段管理：配置每天有几个就餐时段（午市、晚市），每个时段最大预定单数
• 基础统计：按日期统计预定数量、菜品被预定次数

功能模块划分的原则是"每个角色只看到自己需要的东西"。用户端不暴露管理入口，管理端不发散太多业务（比如不要强行做财务对账），控制在课程设计合理范围内。这样做的原因是：你的论文篇幅、开发时间和答辩演示时间都有限，功能做深比做广更有价值。

2.2 数据表设计：五张核心表

数据库是这个项目的地基，表结构设计得好，后面写代码会非常顺利。这里给出我在做这类系统时用的核心表清单，字段可以根据自己的需求增删：

用户表（sys_user）

菜品分类表（category）

菜品表（dish）

预定单表（reservation_order）

预定单明细表（reservation_order_item）

表之间的关系很清楚：一个用户有多张预定单，一张预定单有多条明细。明细表冗余字段（dish_name、price）是刻意的，这样即使菜品被删了，历史预定单的展示也不受影响，这在订单类系统中是非常常见的做法。

2.3 状态字段和逻辑删除的设计细节

数据库设计有两个细节我需要单独提出来，因为很多初学者会在这些地方踩坑。

状态字段用tinyint而不是varchar。订单状态如果用"待确认""已确认"这种中文字符串，读起来直观，但扩展和维护很麻烦。用整数加枚举类对应，代码里语义清晰，数据库里存储也高效。比如我在Java里写一个订单状态枚举：

java复制public enum OrderStatus {
    PENDING(1, "待确认"),
    CONFIRMED(2, "已确认"),
    FINISHED(3, "已完成"),
    CANCELLED(4, "已取消");

    private final int value;
    private final String desc;

    OrderStatus(int value, String desc) {
        this.value = value;
        this.desc = desc;
    }
    // getter...
}

逻辑删除 vs 物理删除。管理端删除菜品时，别直接执行DELETE语句，而是在表里加一个deleted字段，删除操作只是把deleted置为1。好处有三个：一是用户历史预定单里的菜品关联还在，避免级联查不到；二是误删之后可以快速恢复；三是MyBatis-Plus自带逻辑删除插件，在application.yml里配置一行，查询时它自动帮你过滤deleted=0的数据，不用每次手写条件。

3. 核心功能实现细节：从登录到预定落地

3.1 鉴权方案：JWT + 拦截器

这个项目我用的是JWT做登录令牌，没有引入Spring Security，原因很简单：课设项目里Spring Security的配置复杂度不值当，很多同学配了一遍过滤器链、UserDetailsService、密码加密器，结果因为某个配置不对卡了两三天，最后答辩时还讲不清楚原理。

我的做法是：

登录接口（UserController）校验用户名密码通过后，生成JWT返回给前端：

java复制@PostMapping("/login")
public Result login(@RequestBody LoginDTO loginDTO) {
    User user = userService.login(loginDTO.getUsername(), loginDTO.getPassword());
    String token = JwtUtil.createToken(user.getId(), user.getUsername(), user.getRole());
    return Result.success(token);
}

拦截器（JwtInterceptor）统一验证Token：

java复制public class JwtInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        String token = request.getHeader("Authorization");
        if (token == null || !JwtUtil.verify(token)) {
            response.setStatus(401);
            return false;
        }
        return true;
    }
}

放行配置：注册拦截器的时候，放行登录接口、注册接口、菜品浏览和菜品详情查询（这些接口用户未登录也能看）。

java复制registry.addInterceptor(new JwtInterceptor())
        .addPathPatterns("/**")
        .excludePathPatterns("/api/user/login", "/api/user/register", "/api/dish/list", "/api/dish/detail");

这里有一个常见的权限细化需求：管理端接口（比如菜品新增、预定单确认）只允许管理员调用。我的做法是在拦截器里解析Token后，把当前用户信息存入ThreadLocal，然后管理端接口再加一层简单的角色判断，或者直接在拦截器里检查请求路径前缀，比如/api/admin/**要求role=1。

注意：JWT的密钥不要硬编码写在代码里被人提走，课设项目允许写在配置文件里，但至少用环境变量或者application.yml中的jwt.secret配置项，答辩时可以说"生产环境通常会放到配置中心或环境变量中"。

3.2 预定下单的核心业务流程

预定下单是整个系统的核心，流程比普通点餐多几个步骤。我用一张状态流转来描述它：

1. 用户选择要预定的日期和时段
2. 前端展示该时段内可预定的菜品列表和余量
3. 用户选择菜品、填写数量、提交预定单
4. 后端校验：菜品是否上架、预定日期是否在今天之后、该时段余量是否充足
5. 创建预定单和明细数据，扣减该时段余量
6. 返回预定单号，提示用户等待管理员确认

后端Service层的核心方法大概是这样的思路：

java复制@Transactional
public ReservationOrder createReservation(ReservationCreateDTO dto, Long userId) {
    // 1. 校验预定日期
    LocalDate reserveDate = dto.getReserveDate();
    if (reserveDate.isBefore(LocalDate.now())) {
        throw new BusinessException("预定日期不能早于今天");
    }
    // 2. 校验时段余量（这里用简单的count数量来做校验）
    Long count = reservationOrderMapper.countByDateAndSlot(reserveDate, dto.getTimeSlot());
    if (count >= MAX_ORDER_LIMIT) {
        throw new BusinessException("该时段预定已满");
    }
    // 3. 计算总金额并批量插入明细
    List<Dish> dishList = dishService.listByIds(dto.getDishIds());
    // ... 金额计算、订单和明细插入
    return order;
}

在@Transactional上加事务注解，是为了保证"创建订单"和"扣减余量"这两个操作要么都成功，要么都失败。我见过有同学把这两步拆成两个独立方法，结果订单创建成功了，余量扣减因为异常没执行，导致超卖，这就是事务边界没划好。

并发控制的进阶方案：如果按上面的代码用count来判断余量，在并发请求下会有超卖风险。课设和毕设阶段，用数据库唯一约束或者加一个乐观锁版本号字段，就能过度到"我考虑了并发安全"这个讨论点。比如在预订记录表加一个version字段，更新时校验version，答辩时你可以主动提这个设计，很加分。

3.3 管理端菜品管理与订单处理

管理端的功能实现难度不大，但要注意交互上的完整性。以菜品管理为例：

• 新增/编辑菜品时，用表单校验确保价格大于0、名称不能为空
• 菜品图片上传用本地存储就行，把文件存到项目的/upload目录，返回相对路径/img/xxx.jpg，前端拼上服务地址就能访问。上传接口注意限制文件大小（Spring Boot里配置spring.servlet.multipart.max-file-size=5MB），避免有人传一个大图把服务器拖垮
• 下架操作不直接删除，而是修改status，并且在下架后，新预定单里不能再选择这个菜；已经生成的预定单不受影响

订单处理这边，管理员的动作主要是查询和状态修改。查询支持按日期筛选，比如"查看今天有哪些预定""查看2025年5月1日的预定"。状态修改就是待确认变成已确认、已完成或者已取消。

java复制@PutMapping("/api/admin/order/{id}/status")
public Result updateOrderStatus(@PathVariable Long id, @RequestParam Integer status) {
    ReservationOrder order = orderMapper.selectById(id);
    if (order == null) {
        throw new BusinessException("订单不存在");
    }
    order.setStatus(status);
    orderMapper.updateById(order);
    return Result.success();
}

代码简单，但有一个容易忽略的问题：状态流转必须合法。比如已取消的订单不能直接变成已完成。我建议写一个状态校验的小方法，非法流转直接抛异常。

3.4 前端Vue部分的关键实现

前端我用Vue3 + Element-Plus + Axios + Pinia（也可以用Vue2 + Element-UI，看自己熟悉程度）。按功能拆成几个核心的组件和页面文件：

路由和权限控制：通过路由守卫判断用户是否登录，未登录跳登录页；管理端路由额外校验当前用户角色。实现方式：

javascript复制// router/index.js
router.beforeEach((to, from, next) => {
    const token = localStorage.getItem('token');
    if (to.meta.requiresAuth && !token) {
        next('/login');
    } else if (to.meta.requiresAdmin && userStore.role !== 1) {
        next('/');
    } else {
        next();
    }
});

Axios封装：全局拦截器在请求头加Token，在响应拦截器里统一处理401状态码跳登录页，以及后端返回的业务错误提示。前端不做登录状态判断的散装逻辑，统一在拦截器里管。

javascript复制// request.js
service.interceptors.request.use(config => {
    const token = localStorage.getItem('token');
    if (token) {
        config.headers['Authorization'] = token;
    }
    return config;
});

service.interceptors.response.use(
    response => {
        return response.data;
    },
    error => {
        if (error.response && error.response.status === 401) {
            router.push('/login');
        }
        return Promise.reject(error);
    }
);

预定下单页：这是交互最复杂的页面。我的做法是分三步走：

1. 第一步选日期和时段，日期选择器限制今天之后
2. 第二步展示菜品列表，每个菜品有加入预定按钮，已选菜品在右侧的购物车里累加
3. 第三步确认明细和总金额，点击提交按钮调用后端预定接口

购物车部分用Pinia管理选中的菜品和数量，跨组件共享状态比Props传递省心很多。

4. 实际开发中的坑与排查技巧

写项目的时候，真正花时间的往往不是写新功能，而是排查一些莫名其妙的Bug。我把几类高频问题整理成一个速查表，都是我实际操作中踩过的坑，也基本是所有前后端分离项目都会遇到的问题。

除了这些，还有两个很实际的建议。

第一，MySQL的时区问题。如果项目里用LocalDateTime存时间，连接数据库时URL里加上serverTimezone=Asia/Shanghai，否则可能出现插入时间和实际时间相差8小时的问题。这个问题在答辩演示时特别容易暴露出来，你明明刚下的单，时间显示不对，观感很差。

第二，接口返回结果要统一格式。我在项目里定义了一个Result<T>类，包含code（200代表成功）、message、data三个字段。所有接口统一返回这个格式，前端的响应拦截器处理起来非常舒服，而不是有的接口直接返回对象、有的返回Map，前端代码写一套一套的兼容逻辑。

4.2 前后端联调与开发节奏

很多同学卡在这个环节是因为“全部写完再联调”。第一次做前后端分离项目，最忌讳的就是后端接口写完了不测，前端把页面全写完了才去对接，然后一次性冒出几十个Bug，根本不知道从哪个开始排查。

我推荐的做法是分模块联调：

• 第一步，先把登录注册模块完全调通。这个时候前端能拿到Token，后端能验证Token，整个请求链路就验证了一大部分。
• 第二步，做菜品浏览。这个模块不涉及复杂权限，前端能显示列表和详情，就说明跨域、图片访问、数据格式这些基础问题都解决了。
• 第三步，做预定下单。这是核心模块，要花最多时间调，重点验证同一个时间段能否重复预定、菜品余量扣减是否准确、取消预定后是否恢复余量。
• 第四步，做管理端。管理端用到的接口大多数和用户端的菜品、订单是同一套基础数据，主要是把表单提交、状态流转调通。

每个模块调通后再进入下一个，出了问题能快速定位到是前端的锅还是后端的锅。

4.3 时间分配建议

按两周时间来做这个项目，我有过一份比较顺手的时间分配方案：

• 第1-2天：搭框架。创建SpringBoot项目、初始化数据库、搭建Vue工程、配置路由和Axios、跑通Hello World。
• 第3-5天：做登录注册和用户管理，然后把菜品表的CRUD做出来，先不做图片上传，用固定URL测试。
• 第6-9天：做预定单模块，这是核心。先做后端接口，再做前端的下单页面。
• 第10天：做管理端的订单确认和统计功能。
• 第11-12天：联调、修Bug、完善细节（图片上传、分页、空状态提示）。
• 第13-14天：写文档、准备答辩PPT、录演示视频。

当然如果你时间更紧，可以把统计功能和图片上传砍了，数据库表也可以减少两张，但要保证主线流程完整：登录、浏览、预定、管理端确认。

5. 文档撰写与答辩准备

很多同学项目做完了，最后栽在文档上。其实课程设计的评分里，文档占的比重不小。这个项目的"万字文档"整理下来，大致结构是这样的：

• 绪论：项目背景、国内外研究现状（这里可以写餐饮行业的数字化趋势，但不要编造数据，引用来源要真实）
• 需求分析：功能需求和非功能需求，附用例图、用例描述
• 系统设计：总体架构图（前后端分离架构）、功能模块划分、数据库ER图、表结构说明
• 系统实现：按模块贴核心代码，配上运行界面截图，截图一定要是真实跑出来的，不要贴网上找的图
• 系统测试：设计测试用例，写测试结果
• 总结与展望：写开发过程中遇到的困难和心得

文档写作有两点我特别想强调。

第一，数据库表结构说明不要复制建表语句就完事，要把每张表每个字段是干什么用的写清楚，比如"status为1表示已确认"，这样答辩时老师问起来你能对答如流。

第二，截图要在项目真正运行起来之后截图，最好是带数据的状态。比如说用户端页面有菜品列表、预定成功的跳转、管理端有订单状态修改的前后对比。图文并茂的文档看起来工作量多不少，但老师印象分会高不少。

5.2 答辩高频问题

答辩环节老师常问的问题其实高度集中在几个方向。你可以提前准备：

• 为什么选择预定点餐而不是即时点餐？
  答：预定点餐增加了时间维度和状态流转，能体现更完整的业务设计和系统设计能力，同时和真实餐饮场景中"高峰期预约"的需求贴合。

• 预定时段余量怎么控制的？如果两个人同时预定最后一个名额怎么办？
  答：我们通过数据库事务和条件更新保证原子性（update ... set stock = stock - 1 where stock > 0），高并发场景可以考虑引入Redis分布式锁或乐观锁，这里老师追问就能展开。

• 为什么用JWT而不用Session？
  答：前后端分离场景下Session需要处理跨域Cookie、CSRF等问题，JWT无状态、易扩展，适合这种接口型项目。

• 菜品下架之后历史订单怎么显示？
  答：明细表中冗余了菜品名称和价格快照，即使菜品被删除或下架，历史预定单依旧能完整展示。

• 数据库表之间怎么保证数据一致性？
  答：通过外键逻辑关联（代码层面维护）+事务控制，这里的重点是创建预定单时同时插入主表和明细表，@Transactional保证要么都成功，要么都回滚。

• 项目部署在哪里？
  答：本地跑的话后端打包成jar（mvn clean package -DskipTests），前端npm run build生成dist目录，可以放到Nginx或者直接放到SpringBoot的static目录下，最简单的方式是把dist目录复制到SpringBoot的resources/static，一个jar包就能跑起来。

最后再分享一个我实际操作中的个人体会：这种课设项目，最重要的不是把所有功能做得又多又全，而是把"预定下单"这条核心链路从头到尾走通，并且你对每一个环节都理解到位。前端页面可以简化一点，代码风格可以朴素一点，但只要核心流程稳、数据库设计合理、答辩时能讲清楚每个表每个字段的用途，这个项目基本就是优秀档。别看我前面列了这么多细节，真正动手做起来，按节奏一步步走，两周时间是完全能拿下的。遇到问题不要慌，先看控制台报错，再查后端日志，再检查SQL语句，大多数Bug都能沿着这条线定位到。祝各位项目顺利。