又到了毕业设计旺季，每年这个时候后台问得最多的就是"Java做什么课题好""SpringBoot项目怎么快速搭起来"。今天这篇就聊聊我做过的餐厅点餐与预订一体化平台——一个能同时覆盖点餐、预订、桌台管理、订单流转、后厨联动的完整JavaWeb项目。如果你正打算拿这个方向做毕设，或者单纯想学一下SpringBoot项目的完整落地思路，这篇内容应该能帮你少走不少弯路。
先说这个系统到底能干什么。站在顾客角度，打开小程序或浏览器就能扫码点餐、选桌预订、查看菜品、在线结账。站在商家角度，后台能管菜品上下架、桌台状态、订单进度、预订排期，后厨大屏实时收到新订单提醒。说白了就是把传统餐厅的"叫服务员-看菜单-手写单-厨房做菜"这条链路全部搬到了线上，用一套订单数据贯穿起来。
我用了SpringBoot作为后端基础框架，前端管理端用Vue+Element Plus，小程序端用uni-app，数据库MySQL，权限认证走JWT，实时通知走WebSocket。整篇文章我会从方案选型、模块拆解、核心实现、踩坑实录四个维度往下讲，很多细节是实践过程中摸出来的，不是看两篇文档就能知道的。
1. 项目整体设计与技术选型思路
1.1 技术栈选型：为什么是SpringBoot + Vue + MySQL
很多同学在选技术栈时犯的毛病是贪多求新，把自己听过没听过的全都堆进项目里。一个毕设项目，核心要解决的是"能跑、完整、有亮点"，不是给面试官炫技。我选SpringBoot，原因只有三条。
第一，SpringBoot的生态足够成熟，几乎所有你想得到的业务场景都有现成的starter，比如操作数据库有mybatis-plus-boot-starter，权限安全有spring-boot-starter-security，接口文档有springdoc-openapi，这些组件之间配合起来不用自己造轮子。
第二，SpringBoot的自动配置机制极大降低了整合成本。传统SSM项目里一个applicationContext.xml能堆五六百行，SpringBoot用注解和配置文件就把大部分事情搞定了。这对毕设来说尤其重要——你的精力应该放在业务逻辑上，而不是花两周时间解决配置文件拼写错误。
第三，市场上Java岗位的JD里SpringBoot基本是标配，拿这个做毕设对找工作是正向加分。我见过不少人用SSH（Struts2+Hibernate+Spring）做毕设，技术上没大错，但面试官看到会直接问你"为什么不用SpringBoot"，这个解释成本太高了。
前端选Vue是因为它和SpringBoot的配合方式最省心。开发阶段用vite代理解决跨域，部署阶段直接npm run build把静态文件扔进SpringBoot的src/main/resources/static目录下，一个jar包搞定前后端，连Nginx都不用单独配。这种方式在毕设答辩演示时特别实用——你只需要在一个端口上跑起来，评委不会纠结什么反向代理、静态资源分离这些运维细节。
数据库选MySQL没什么悬念，单机部署、性能够用、网上资料多，出了问题随便一搜就有答案。我见过有人用MongoDB做这个系统的，不是不行，但餐厅管理天然是强事务场景，一个订单要同时扣库存、更新桌台状态、生成明细，SQL数据库的事务能力能帮你省掉大量数据一致性的麻烦。
1.2 功能模块划分与角色权限设计
我见过很多失败的毕设，失败原因不在代码写得差，而是功能模块一团乱麻。餐厅管理系统这种课题，功能看着简单，真拆解起来涉及的实体和关联比想象中多。你至少要处理用户、菜品、分类、桌台、订单、订单明细、预订、支付流水、评价、日志这几类核心数据。
我的建议是先把角色理清，因为角色决定权限，权限决定接口设计。这个系统我规划了四种角色：
- 顾客：前端小程序用户，能浏览菜品、加购、下单、预订、支付、查看订单状态。
- 服务员：管理端用户，能开台、下单、协助结账、处理预订登记。
- 后厨：管理端用户，能查看订单详情、更新制作状态。
- 管理员：管理端用户，拥有全部权限，负责菜品管理、分类管理、桌台管理、数据统计。
角色权限这里有一个容易踩的坑：很多人把权限控制做成前端根据角色显示或隐藏按钮，后端接口完全不设防。这是不对的，前端控制只是优化体验，真正的权限校验必须在后端做。我这个项目用Spring Security + JWT实现了RBAC（基于角色的访问控制）模型，后端接口用@PreAuthorize注解来标注访问权限，比如修改菜品价格只能由管理员操作，普通服务员请求这个接口会直接返回403。
模块划分也值得说一下，我按照业务边界拆成了六个模块：
- 系统管理模块：用户管理、角色管理、菜单管理、操作日志。
- 菜品管理模块：菜品分类、菜品信息维护、图片上传、上下架管理。
- 桌台管理模块：桌台区域、桌台编号、座位数、状态管理（空闲/占用/清洁/预订）。
- 点餐模块：购物车、订单创建、订单明细、菜品规格选择。
- 预订模块：预订时段设置、预订桌台分配、预订记录管理。
- 统计报表模块：营业额统计、菜品销量排行、订单量趋势。
这个拆分方式的好处是每个人可以独立负责一个模块，而且模块之间的交互全部通过接口和数据表完成，边界很清晰。
1.3 数据库设计：六张核心表的关系与约束
数据库设计我一直强调一个原则：先画ER图再建表，不要边写代码边拍脑袋加字段。这个系统的表我最终设计了十几张，但核心的主链路就六张。我用最简单的语言把这六张表的关系缕一下。
用户表（sys_user）是所有角色的基础表，通过role字段区分角色类型。菜品表（dish）存菜品基础信息，比如名称、价格、图片、描述、状态，通过category_id关联分类表。桌台表（table_info）存桌台编号和座位数，status字段标识当前状态。
订单表（orders）是整个系统的心脏，它记录了一单交易的所有核心信息：订单编号、顾客ID、桌台ID、订单状态、订单金额、下单时间、支付状态。订单明细表（order_detail）存的是某一笔订单下具体点了哪些菜，一份订单对应多份明细，通过order_id做外键关联。预订表（reservation）记录顾客预订哪个桌台、哪天来、什么时段到。
约束设计有两个细节特别容易忽视。第一个是订单金额字段，我用的是DECIMAL(10,2)，不是普通的DOUBLE。为什么？因为浮点数在计算0.1+0.2这类场景会出精度问题，钱有关的字段一定要用定点数存。第二个是订单编号，不要用自增ID直接给顾客看，顾客能看到的是唯一业务编号，我这边用时间戳加随机数生成，保证并发场景下不重复。
另外，我在关键表上都加了deleted逻辑删除字段。你要记住，餐厅系统的数据是有分析价值的，比如月度营业统计要回溯历史订单，如果你在删除菜品时物理删除，统计报表的数据就对不上了。逻辑删除用MyBatis Plus的@TableLogic注解就能实现，成本非常低，但很多新手不知道这个功能。
2. 核心功能点拆解与实现要点
2.1 点餐流程与订单状态机的设计
点餐是整个系统最核心的链路。从顾客视角来看流程很简单：扫码或者在小程序里选菜品，加入购物车，提交订单，然后等餐上桌。但站在后端开发角度，这背后是一串需要严谨设计的状态流转。
我用了状态机来管理订单生命周期。你如果不做状态控制，订单状态就会在代码里到处被随意赋值，最后根本无从排查"为什么这个订单变成了已退款"。我把订单状态定义为六种：待支付、已支付（制作中）、制作完成待上菜、已上菜、已完成、已取消。
状态流转的规则我写在代码里，用枚举加状态机校验。比如已取消状态只能从待支付状态跳转而来，如果你已经支付了，就不会允许用户自己取消。这种约束用大量if判断很难维护，我建议在实际项目里把状态流转抽到一个统一处理方法里，本质上就是一张状态流转表，代码里对应一个Map或者Switch结构。
购物车这块也有细节。餐厅点餐场景下购物车不像电商那样只属于用户，它属于一次会话。顾客扫码进来先落桌，然后把自己这桌所有加购的菜放到同一个购物车里，这个购物车还要支持菜品规格选择，比如选"微辣""去冰"这种口味备注。我实现的方式是用Redis缓存购物车，key就是桌台ID，这样后厨看到的订单备注也能和桌台关联上。
订单创建时有一个并发问题需要特别处理：同一个桌台两个顾客同时提交订单，不能产生两个不同桌台的订单。我这边用了MySQL的行级锁，对桌台记录进行SELECT FOR UPDATE，保证同一时刻只有一个订单创建事务在执行。这个技巧在面试里也算一个可以展开讲的亮点：你在业务中应用了悲观锁解决并发冲突。
2.2 桌台状态管理与预订时段控制
桌台状态管理听着不复杂，实现起来却容易乱。我定义了四类桌台状态：空闲、占用、清洁、已预订。状态之间不是随意切换的，比如占用状态结束必须进入清洁，不能直接从占用跳到空闲，这是为了符合餐厅实际工作流——客人走后服务员得收拾桌子才能安排下一波客人。
预订这个功能比想象中复杂。顾客要选"哪天来、哪个时间段"预订某个桌台，核心是避免已被预订的时间和桌台冲突。我的做法是把每个桌台一天的时间片拆成预定时间段，比如午餐段（11:00-14:00）和晚餐段（17:00-21:00），预订记录落在具体日期和时段上。校验冲突时，查询条件是"同一桌台 + 同一日期 + 时段有重叠"，满足就返回桌台已占用提示。
这个设计从业务上讲是合理的，因为餐厅不可能精确到分钟给顾客预留桌台，这个粒度太细反而不可控。我见过有人把时段拆成半小时一个槽位，结果光是时段表就建了几万条数据，纯属给自己挖坑。另一个预订常见问题就是超时未到店的处理，我在实现中规定预订保留十五分钟，超过时刻状态自动置为"已过期"，桌台释放回空闲池，避免空等。
桌台的分配还有一个策略问题：顾客预订时是直接锁定具体桌台编号，还是到店后再由服务员分配？我的方案是顾客可以指定桌台，同时也提供"任意空闲桌台"的选项，更灵活一些。
2.3 后厨消息推送：WebSocket从理论到落地
餐厅系统里有一个特别提升"智慧感"的功能：顾客下单后，后厨大屏能实时收到新订单提醒。这背后用的是WebSocket，服务器主动推送消息，而不是顾客刷新页面反复轮询。
我当时的实现思路是：顾客提交订单成功后，后端在订单状态变为"已支付"的那一刻，向特定主题推送一条消息，内容包含订单编号和菜品明细。后厨的工作台上通过WebSocket客户端接收消息并弹出提醒动画。
具体到SpringBoot里的实现，你可以用spring-boot-starter-websocket封装好的注解开发一套WebSocket服务。核心是三个环节：客户端建立连接、后端向客户端发送消息、客户端断开时做资源清理。
这块开发中有一个坑需要专门提醒：SpringBoot内置Tomcat对WebSocket连接的默认空闲超时时间有两个配置，一个是WebSocket容器层面的超时，一个是SpringMVC异步请求超时。如果后厨大屏长时间挂着没有消息来往，连接会被自动断开，前端需要在底层监听close事件并做断线重连。我在前端加了一个定时器，每三十秒向后端发送一个ping消息保持连接活跃，同时检测到连接断开后自动重连，这个细节不处理，演示当天连接掉线会非常尴尬。
2.4 菜品管理：文件上传与图片存储方案
菜品管理模块最容易被忽略的技术点是图片上传。我做菜品的时候需要上传菜品图片，这块的方案选择要考虑后续部署环境。我当时没有用FastDFS这类分布式文件系统，原因是毕设项目部署在不同服务器上，分布式文件系统的运维成本太高。我的做法是本地磁盘存储，图片保存到服务器指定目录，访问时通过配置的映射路径将请求转发到该目录。
SpringBoot配置静态资源映射很简单，实现WebMvcConfigurer接口后重写addResourceHandlers方法，把/web/**路径映射到本地磁盘路径。
需要注意的坑是，在开发环境里Windows下路径写法是file:D:/upload/，而部署环境如果是Linux服务器则是file:/usr/local/upload/。这个路径变量我直接放在application.yml里配置，部署时改配置就行，不要写死在代码里。另外，上传图片之前必须做文件类型校验，限制jpg、png、webp等常见格式，后端不要信任前端传过来的文件名，都要重新生成统一的随机名称。我在项目里用的是UUID作为新文件名，避免出现中文、特殊符号造成的乱码和路径错误。
菜品上下架和排序也值得提一下。我采用了sort字段做排序，置顶就是把sort改成比当前所有记录都大的值。软删除挺好用，但查询时需要注意连带处理——菜品被逻辑删除后，如果用户购物车中还有这个菜品，下单时一定要做一次有效性校验，否则就会出现"顾客买了一道已下架菜"的尴尬。
3. 实操过程与关键环节实现
3.1 环境准备与项目初始化
下面这部分是构建操作副本，你可以照着敲。
环境版本要提前对齐。我推荐JDK 1.8或11，这两个版本在Java生态里兼容性最好，很多中间件和IDE插件对JDK 17的支持多多少少还有些问题。Maven用3.6以上版本，ide建议用IntelliJ IDEA。MySQL我用的8.0，注意8.0的连接驱动类名和依赖坐标和5.x不一样，网上很多旧教程还在用com.mysql.jdbc.Driver，这个驱动类在8.0里已经改名了，沿用会报错。
创建项目的标准姿势是登录Spring Initializr网站，选好Maven项目、Java版本、SpringBoot版本后勾选依赖。你这个项目必选的依赖有：
- Spring Web（提供MVC和内置Tomcat）
- MyBatis Framework（数据访问层）
- MySQL Driver（数据库驱动）
- Lombok（简化实体类代码）
- Validation（参数校验）
SpringBoot版本不要盲目选最新版，我实测过3.2版本以后某些starter和旧教程的配置方式差异很大，比如javax.包整体改成jakarta.，很多代码照着2.x教程写会直接报编译错误。建议选2.7.x系列，这个版本生态最成熟，遇到的问题在网上一搜就有现成回答。
项目初始化后先把目录结构梳理清楚，我习惯按功能分层：controller放接口、service放业务逻辑、mapper放数据访问、entity放数据库实体、dto放传输对象、vo放视图返回对象、config放配置类。很多新手把几百行业务逻辑怼在controller里，这会让答辩时"项目架构设计"这个问题变得很难看。controller应该薄，只做参数接收和结果封装，业务判断放service层，数据访问放mapper层，职责清晰才能谈可维护性。
3.2 JWT登录认证与拦截器的配置细节
管理系统不同于公开的展示网站，它必须做登录认证。这块我一开始用的是Session方式，但前后端分离架构下Session的跨域携带parallel麻烦，后面直接改成JWT方案，前后端交互状态全部通过Token来处理。
JWT的引入流程分三步。第一步是登录接口，校验用户名密码成功后，生成一个Token返回给前端。Token里面我塞了用户ID、用户名和角色信息。密码存储这一步要强调：绝对不能明文保存，我用的是BCrypt加密算法，Spring Security自带这个工具，同样的密码每次加密结果不同，安全性足够。
第二步是配置拦截器，写一个JwtInterceptor继承HandlerInterceptor，在preHandle方法里从请求头取出Token做校验。注意两个细节：一是Token过期时间我设为两小时，前端每次收到401状态码就跳转登录页；二是白名单路径要放行，比如登录接口、菜品列表这些非必要权限的接口，否则拦截器会拦截登录请求，导致死循环。
第三步是在WebMvcConfigurer里注册拦截器，指定拦截路径和排除路径。这一步原理上不难，但很考验细心程度，我最初调试时忘记排除静态资源路径，导致前端页面引用的JS和CSS也被拦截，整页白屏。
3.3 订单分页查询与多条件检索的实现
餐厅管理系统的后台订单页是服务员高频使用的页面，需要列表显示订单，还要支持按状态、按时间段、按桌台号筛选。实现方案就是典型的条件分页查询，MyBatis Plus提供分页插件，传一个Page对象就能拿到分页结果。
这里我建议把查询条件单独封装成一个DTO对象，不要直接在Controller上用多个参数传递。原因很简单：条件多了接口签名会变得冗长，而且以后加一个新筛选条件还要改方法签名和前端调用参数。用DTO对象传参，增加条件只改对象字段，对接口调用方友好得多。
时间范围查询有一个需要注意的细节：前端传来的日期字符串通常是"2024-05-20"这种格式，后端如果直接拿这个字符串做数据库比较，查询结果可能不包含当天全部订单。正确做法是把结束日期补上23:59:59，或者直接用LocalDate解析后处理。我在代码里统一把时间条件转成LocalDateTime范围，避免遗漏当天晚些时候的订单数据。
筛选时还要区分角色。管理员能查全部门店订单，服务员倾向于查自己当前负责的桌台，这个条件不能靠前端传参控制，而是在后端从Token里解析出当前用户信息后再附加查询条件，避免越权问题。
3.4 支付流程的模拟实现与订单超时处理
很多同学做到支付环节容易卡住，原因是自己没有真实商户号，接微信支付API要走复杂的申请流程。我的建议是模拟支付流程：在开发阶段，后台提供一个"确认收款"操作，模拟支付成功回调。这就够完成业务闭环了。
但有一个环节是模拟支付不能省略的：订单超时自动取消。餐厅场景下，顾客扫码点餐后迟迟不支付，桌台被白白占着，必须有超时机制释放资源。我用了两种方法配合。第一种是在生成订单时，通过Redis的setnx命令写入一个带过期时间的key，比如十五分钟后过期。第二种方案是写一个定时任务，每隔一分钟扫描数据库中待支付且创建时间超过十五分钟的订单，把这些订单状态改为已取消，同时释放对应桌台。
定时任务用Spring自带@Scheduled注解就能实现，只需在启动类加上@EnableScheduling开启调度支持。需要注意分布式场景下多实例部署时，同一个定时任务会在每个实例上都跑一遍，重复扫描和重复更新状态会造成数据不一致。但毕设项目通常单实例部署，用@Scheduled足够。如果你想把这块作为优化亮点去讲，可以提一下引入分布式锁来保证同一时刻只有一个机器在执行任务。
4. 常见问题与排查技巧实录
4.1 SpringBoot版本过高导致的项目启动失败
先讲一个频率最高的问题：启动报错，但错误信息看起来毫无头绪。我排查过很多次后总结出一条经验——先检查SpringBoot版本和JDK版本是否匹配。
比如SpringBoot 3.x强制要求JDK 17及以上，如果你的机器上装的是JDK 8，启动时就会报UnsupportedClassVersionError。这问题在毕设里特别常见，因为很多学校的教学环境仍然停留在JDK 8。排查方法不是看启动日志的长篇堆栈，而是看错误信息最前面的几行，如果出现"java.lang.UnsupportedClassVersionError"字样，基本就是版本不匹配。
另外Spring Boot 2.7.x版本有一个关于循环依赖检查的变更，如果你的代码里面存在循环依赖（两个Service互相注入），启动时会直接报错。这个问题的排查信号是启动日志中出现"BeanCurrentlyInCreationException"。解决办法是把互相依赖的逻辑拆开，或者用@Lazy注解延迟加载打破循环。
4.2 前后端联调时的跨域与Cookie问题
做前后端分离项目时，跨域几乎是人人都会遇到的拦路虎。开发阶段前端跑在5173端口，后端跑在8080端口，前端请求后端接口就会被浏览器的同源策略拦截。最直观的表现就是：前端Console面板报"Access-Control-Allow-Origin"错误。
解决方式有两种主流的。第一种是后端配置CORS跨域过滤器，在响应头中加入允许跨域的字段。SpringBoot里写一个WebMvcConfigurer配置类，重写addCorsMappings方法就行。第二种是前端用Vite的代理功能，把/api开头的请求转发到后端，这样浏览器看到的是同源请求，不会触发跨域拦截。
两种方案我实际体验后更推荐后者。因为CORS跨域配置生效后，前端请求时会先发一个OPTIONS预检请求，后端必须对预检请求返回合适的响应头，有时候配置得不完整，预检就卡住了。而Vite代理只需要在vite.config.js加几行配置，让后端完全感知不到跨域操作，开发体验更爽。
如果你用的是Cookie方式保存登录状态，跨域带来的问题还有一层：Set-Cookie在跨域场景下默认不被浏览器接受，需要在请求里设置withCredentials: true，同时后端CORS配置中不能再用*号通配来源地址，必须指定准确的域名。这块牵连细节多，所以我在这个项目里直接弃用Cookie，全部走JWT加请求头传递，省心很多。
4.3 数据库时间字段的时区问题与JSON序列化
这个坑比较隐蔽：你存数据库的时间明明正确，后端查出来往JSON里一塞，返回给前端发现少了八个小时。这不是数据错了，而是JSON序列化时默认使用UTC时区导致的。
解决方式有两种。一种是在数据库连接串上直接加上serverTimezone=Asia/Shanghai参数，保证JDBC读写时区的正确性。另一种是统一使用LocalDateTime类型，并在配置里指定JSON序列化的格式和时区。我的做法是两个都上：连接串和序列化配置分别加时区指定，双重保险。
同时我推荐所有实体类的时间字段都声明为LocalDateTime而不是java.util.Date，因为LocalDateTime在Java 8时间API里天然支持时区处理，而Date的默认toString结果是一个英文格式的字符串，前端JS解析起来很费劲，LocalDateTime配合Jackson序列化后输出的是"yyyy-MM-dd HH:mm:ss"直接能给前端用。还要注意前端传时间值过来时，可能传的是"2024-05-20T10:30:00"这个带T的ISO格式，后端要用@JsonFormat注解指定接收格式，否则解析直接报错。
4.4 Maven依赖冲突和MyBatis扫描问题
Maven依赖冲突是另一个高频问题。最典型的表现是项目编译时找不到类，或者运行时报NoSuchMethodError。排查技巧是用idea的Maven面板打开依赖关系图，找到红色冲突标记的地方。我遇到最多的是fastjson和jackson同时存在时，两者对同一个类的序列化处理有冲突，解决办法是统一使用Jackson这一个JSON处理库，删除不必要的依赖。
还有个问题是只属于MyBatis的：明明Mapper接口里的方法写了，启动时也报找不到方法的实现。这种情况大概率是Mapper接口没有被扫描到。SpringBoot的启动类默认扫描当前包及子包，如果你的Mapper接口放在了启动类所在包之外，又没有加@MapperScan注解，那接口就注册不进去。建议在主启动类上显式添加@MapperScan("com.xxx.xxx.mapper")，指明扫描路径，一劳永逸。
4.5 性能优化的几个实际策略
毕设项目虽然不至于承受高并发，但答辩论证时如果你能讲清楚性能优化思路，是明显的加分项。我在项目中做了三层优化。
第一层是索引优化。订单表数据量大了以后，按下单时间筛选会变得很慢，我在orders表的create_time字段上加了普通索引，在order_status字段也加了索引。这里有个小技巧：联合查询条件如果同时涉及时间和状态，联合索引比两个独立索引效率更高，但要确保最左前缀原则。
第二层是Redis缓存菜品数据。菜品列表在点餐页面高频读取，但不经常变更，完全适合缓存。缓存键设计成"dish:category:{分类ID}"，缓存时间设置为三十分钟。当管理员修改菜品信息时，通过删除相关缓存键达到主动失效的效果，下次查询自动回填新数据。
第三层是静态资源的处理。如果前端资源直接放在SpringBoot的classpath下访问，每次请求都由SpringMVC处理，性能会受影响。部署时我把项目打成jar包运行，静态资源配置了较长的浏览器缓存时间，减少重复请求。注意开发环境和部署环境的缓存策略要分开配置，开发环境缓存设置太长时间，前端改了代码看不到效果时会非常困惑。
5. 写在最后的真心话
做完这个项目之后我最大的体会是：毕设项目的价值不在功能多炫酷，而在整个从零到一的完整链路是否走通了。你能把用户从登录、点餐、下单、支付、后厨通知、结算、统计这一整条数据贯通下来，你对一个业务系统的理解就远超只做几个CRUD接口的皮毛水平。
如果在开发过程中遇到问题，不要死磕，先看控制台报错的前三行，那是定位问题最快的线索。多学会用debug打断点，不要靠println猜数据流向。项目结束后，把这个系统的架构图、数据库设计文档和核心流程图整理成一份答辩讲稿，这个过程本身就是一次从写代码到讲业务的复盘。
这套系统后面还能往哪些方向扩展？我建议可以做数据分析驾驶舱，比如每日营业额曲线、菜品销量预测、顾客复购分析。也可以接入真实支付API，对接微信支付和支付宝的沙箱环境。这些扩展足够让答辩更有厚度，也能当面试项目实打实地讲清楚。
最后送你一句话：写代码别怕慢，先把一个模块跑通跑顺，再往前推下一个，你很快就会发现，餐厅管理系统这个题目选得对、做得值。
