1. 项目概述与设计思路

1.1 这个餐饮管理系统到底做什么

整套系统面向的是一个典型的餐饮门店线上化场景：顾客进店扫码或者在前台点餐，后厨接单出餐，收银台结算。开发这个项目的动机很直接——传统餐饮门店靠纸质菜单、口头传达，高峰期容易漏单错菜，账目也容易乱。用一套系统把“点餐、下单、出餐、结账、菜品管理、桌台管理”串起来，数据实时同步，门店运营效率明显提升。

标题里那串技术名词其实已经说明了方案：SpringBoot负责后端接口和业务逻辑，Vue负责浏览器端的页面交互，MySQL存数据，MyBatis做数据库操作。整套项目很适合做过Java基础、想尝试前后端分离开发的读者，也适合需要交课程设计或毕业设计的同学。完整源码的好处是可以直接跑起来，再基于它改造成自己的项目。

1.2 为什么是SpringBoot+Vue这套组合

这个选型几乎是当前Java全栈入门项目的主流答案，原因很实际。SpringBoot让后端开发省去了大量XML配置，内嵌Tomcat，写一个可运行工程比传统SSH框架快得多；Vue的前后端分离开发模式又天然贴合真实工作场景——前端团队和后端团队可以并行开发，只要事先约定好接口格式（一般用JSON）。

再来说MyBatis，它比JPA更直观的地方在于SQL是自己写的，对于餐饮系统这种有很多自定义查询（比如按时间统计营业额、多条件筛选菜品）的业务，手写SQL反而精准可控。小型系统里MyBatis不会有性能问题，但排查SQL问题时非常清晰。

选型时要避免的坑是过度设计。有些同学一上来就加Redis缓存、RabbitMQ消息队列，反而把核心业务逻辑淹没在中间件里。这个项目的数据量和并发量用单库单表完全够用，先把点餐、结算这条主链路做扎实，比堆技术栈更能体现工程能力。

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

2.1 表结构设计原则与关系拆解

餐饮管理系统的数据模型核心就是“菜品、订单、桌台、用户”四个维度。设计表的时候，遵循一个原则：尽量减少冗余字段，但也不能为了极致范式把业务搞得太绕。最典型的是订单表，很多人直接把菜品名称、价格、数量都塞进订单表，这样查起来方便，但菜品改了价格后，历史订单金额也跟着受污染。

所以这里拆成两张表：订单主表orders记录一笔订单的整体信息（桌台号、总金额、状态、下单时间），订单明细表order_detail记录每道菜的单价、数量和当时的菜品名称。这种设计叫“快照”，菜品价格可以随便改，历史订单仍然保持不变。

表之间大致是这样关联的：

• user表（id, username, password, role, phone），role区分管理员和普通员工。
• category表（id, name, sort），菜品分类。
• dish表（id, name, category_id, price, image, description, status），菜品。
• table_info表（id, table_number, capacity, status），桌台。
• cart表（id, user_id, dish_id, quantity），临时购物车。
• orders表（id, order_no, table_id, user_id, total_amount, status, create_time），订单主表。
• order_detail表（id, order_id, dish_id, dish_name, price, quantity），订单明细。

2.2 关键字段的类型选择与约束

金额字段必须用decimal(10,2)，不能用double或float。这个细节特别容易被初学者忽略，二进制浮点数是无法精确表示十进制的，累加账单时会出现0.30000000000000004这种误差。用户和订单表的关联字段，统一用bigint类型，索引效果也更好。

状态字段要预留扩展空间。订单状态我建议用int类型而不是字符串，0表示待支付、1表示已支付待出餐、2表示出餐中、3表示已完成、4表示已取消。这样在Java代码里定义几个常量就行，后续要接入退款状态只需要继续往后排数字编号。

创建时间字段直接用datetime，默认值设为CURRENT_TIMESTAMP。后面做营业统计报表时，这个字段要按日期分组，所以在create_time上建索引很关键，否则数据量上来后统计接口会越查越慢。

3. 后端核心模块的实现要点

3.1 登录鉴权与拦截器设计

登录模块是我见过很多项目里写得最随意、也是被攻击最多的部分。这个项目用JWT做无状态鉴权，流程不复杂：用户提交用户名和密码，后端校验通过后生成一个token返回给前端；前端把token存在localStorage里，每次请求都在Header里带上；后端写一个拦截器，对需要登录的接口做token校验。

密码存储一定要用BCrypt加密，不要用MD5。MD5虽然是摘要算法，但彩虹表攻击让常见密码很容易被还原。Spring Security里自带的BCryptPasswordEncoder就可以直接拿来用，生成出来的密文是带随机盐的，同样密码每次加密结果都不一样，安全性好很多。

拦截器里有两个常见的坑：一是放行路径要把登录接口、静态资源、前端页面排除掉，否则前端连登录页都访问不了；二是token过期后要给前端一个明确的错误码，比如401，前端收到后跳转登录页，而不是返回一堆看不懂的异常堆栈。

3.2 菜品管理与分页查询

菜品管理是后台管理的核心功能，主要包含菜品的增删改查、上下架操作。列表页一定要做分页。MyBatis里一般用PageHelper插件，一行代码PageHelper.startPage(pageNum, pageSize)就能搞定分页查询，它对底层的处理是拦截SQL并自动拼接LIMIT语句，非常方便。

菜品查询往往会带多个条件：按名称模糊查询、按分类筛选、按价格区间筛选。这种动态SQL就是MyBatis最擅长处理的事情。用 标签配合 标签动态拼接条件，比Java代码里拼String字符串要清晰得多，也能避免SQL注入问题。

菜品上下架要单独设计接口，而不是直接调删除接口。实际运营中菜品可以暂时停售，但历史订单里还要显示这道菜的名字和价格，如果直接删除记录，历史数据的引用完整性就被破坏了。所以dish表里必须有status字段，0表示停售，1表示在售。

3.3 下单流程的事务控制

下单是整个系统最考验细节的部分。从购物车提交订单开始，至少涉及这些操作：读取购物车明细、核对菜品是否还在售、计算总金额、生成订单主表记录、生成订单明细记录、清空购物车。任何一个步骤失败，都不能让数据处于半成品状态，所以整个过程必须加@Transactional事务。

需要注意，计算金额时要以dish表里的当前价格为准，不能直接使用购物车里缓存的价格，因为加入购物车和最终下单之间可能会跨很长时间，这期间菜品完全有可能调价。订单明细里记录的price字段是折扣后实际成交价，展示“已优惠金额”时就用原始价格减去这个字段。

事务还有个边界问题，生成订单号时如果用了数据库自增ID，并发场景下容易被猜到业务量。这里可以自己生成订单号，用时间戳加随机数，格式类似“20250101123000123456”。虽然不参与计算，但后续对账和客服查单时作用很大。

3.4 购物车的实现逻辑

购物车最直接的实现方案是为每个用户维护cart记录。菜品加入购物车时，先查一下这个用户是否已经有这道菜，如果有就累加数量，没有就新增记录。这个“先查再加”的逻辑是典型的并发安全问题，解决方式是给用户和菜品建唯一索引，然后用数据库的唯一约束兜底。

从购物车下单后，记得把对应的购物车记录清掉。很多项目在这一步会遗漏，导致用户买完菜，购物车里还留着旧数据，体验极差。还有一个小优化：用户把菜品加入购物车后，前端应该联动显示购物车总价，这需要后端返回最新的购物车数量与金额给前端，而不是只返回“添加成功”这种提示。

4. 前端Vue页面的搭建与联调

4.1 项目结构和路由设计

前端我见过两种做法：Vue2搭配Element UI，或者Vue3搭配Element Plus。这个项目选择Vue2加Element UI更稳妥，资料多、组件稳定，问题也好查。用Vue CLI初始化工程后，src目录下按views、components、router、api、utils分层。

路由设计要区分顾客端和管理端。顾客端入口是菜单展示页、购物车、我的订单，管理端是菜品管理、分类管理、桌台管理、订单管理、营业统计。两种角色的路由要分开，通过路由守卫（beforeEach）判断用户角色，不是管理员就拦截进入后台管理的页面。这个拦截必须在路由守卫做，不能只靠按钮隐藏，因为Vue的路由是前端控制的，懂技术的用户能直接改路由跳转。

4.2 Axios封装与接口联调

前端所有请求都建议走统一封装的Axios实例。封装时做三件事：基础URL配置、请求拦截器自动附加token、响应拦截器统一处理错误状态码。这样一来，每个业务页面里只需要写api调用方法，不用重复处理token和异常。

后端接口地址需要配置代理解决跨域，开发环境下在vue.config.js里配置devServer的proxy，把/api开头的请求转发到localhost:8080。比后端配CORS更优雅，因为CORS配置一旦写错或被绕过，开发环境没问题，生产环境却要排查半天。

联调阶段最费时间的往往不是接口逻辑本身，而是字段名对不上。后端返回的是userName，前端定义的是username，一查就报undefined。我的经验是前期先花半天时间整理一份接口文档，每个字段都标注清楚含义，写Mock数据让前端先跑起来，前后端并行开发效率会高很多。

4.3 页面交互的核心场景

顾客点餐页是一个高频操作页面。左侧菜单分类Tab，右侧菜品卡片列表，点击菜品弹出规格选择或直接加入购物车。这个页面需要注意的状态有两个：菜品是否停售（停售的要置灰且不可点击）、菜品库存量（如果做了库存字段，加入购物车数量不能超过库存）。

购物车页面要用Vuex或Pinia管理全局状态，因为购物车数据在点餐页、购物车页、结算页多个组件之间共享。每加入一个菜品、修改一次数量，购物车徽标和总金额都要实时更新。这里的交互关键是用计算属性（computed）派生购物车总数和总价，而不是在每次操作时手动拼字符串。

订单结算页要展示完整的订单信息，包括菜品明细、单价、数量、小计、总金额，还需要选择支付方式。开发时如果没接真实支付，就用模拟支付，点击确认支付后直接调用后端的支付确认接口把订单置为已支付即可。后端接口设计时要把支付动作和订单创建分开，这样以后接入微信支付或支付宝时不用改动下单主流程。

5. 从源码到本地跑通的操作步骤

5.1 环境准备与初始化配置

本地跑通这套源码，需要预先准备的环境有：JDK 1.8或以上版本、Maven 3.6+、MySQL 5.7或8.0、Node.js 14+。先创建数据库，执行项目里自带的sql脚本，把表结构和初始数据导进去。初始数据里默认管理员账号一般都在脚本注释里写清楚，登录后第一件事就是改密码。

后端配置文件application.yml里重点检查三处：数据库连接地址（localhost和端口号是否匹配）、数据库用户名密码、MyBatis的mapper-locations路径。如果后端启动时报找不到mapper文件，十有八九是扫描路径写错了，检查mapper.xml是否放在resources/mapper目录下。

前端工程在package.json同级目录下执行npm install安装依赖。国内网络环境下载慢是常事，可以配置npm淘宝镜像源。安装完成后执行npm run dev启动开发服务器，默认端口一般是8081，浏览器访问localhost:8081就能看到前端页面。

5.2 启动顺序和常见报错分析

后端和前端启动顺序没有硬性要求，但后端必须先于前端完全启动完毕，否则前端页面首次请求就会报网络错误。后端启动成功的标志是控制台出现“Started Application in x.xxx seconds”的行，而不是只看到Spring的banner就以为启动了。

经常会遇到的一个问题是端口冲突。后端默认8080端口被占用时，控制台会报端口已经被占用的异常。处理方式是改application.yml里的server.port，同时记得前端封装的Axios基础URL和代理配置都要同步修改。

还有一个高频报错是数据库连接失败：Access denied for user 'root'@'localhost'。排查思路很简单，先用数据库客户端工具测试账号密码能否连上，排除密码错误后，再看项目里的数据库驱动版本。MySQL 8.0要使用com.mysql.cj.jdbc.Driver，MySQL 5.7用com.mysql.jdbc.Driver，驱动类不对会直接抛异常。

5.3 前端打包部署到后端

开发完成后要打包成可部署的产物，前端的构建命令是npm run build，会在dist目录生成静态文件。部署方式可以把dist目录里的文件直接扔到Nginx下托管，也可以把这些文件复制到SpringBoot项目的src/main/resources/static目录下，重新打包成一个JAR，这样只用启动一个Java进程就同时提供了前端页面和后端接口。

第二种方式在课程设计和毕业设计里更常见，因为部署简单，拷个JAR包传到服务器就能跑。要注意的是，前端页面请求的API地址如果写死成localhost，部署到服务器后就要改成服务器IP或域名，否则浏览器请求还是发回本机去。把这个地址提取到环境变量里管理，能省掉不少部署时改代码的麻烦。

6. 常见问题排查与避坑记录

6.1 排查实录与解决方案

我在实际跑这个项目时整理过一个高频问题表，基本覆盖了初学者会踩的坑。

6.2 开发中的独家避坑心得

第一个想分享的是关于联调时修改接口字段的问题。我见过很多同学在开发时发现字段名不一致，第一反应是改前端代码去适配后端。这个习惯不好，正确的做法是把后端接口当成契约，字段设计不合理就改后端并同步更新接口文档，不要让前端逻辑跟着别扭的字段走，否则后期维护成本会持续累积。

第二个经验是关于日志的。开发阶段不要吝啬打印日志，尤其是下单这种多步骤操作。每个关键节点用log.info输出实参和结果，排查线上问题时节省的时间远超写日志消耗的时间。到生产环境再把日志级别调到warn，不影响性能。

第三个心得是：无论需求是否提到，都建议在菜品管理页面加上批量停售的功能。餐饮门店常常会遇到食材短缺的情况，需要快速把一批菜品下架。这个功能实现起来很简单，就是在Mapper里写一条UPDATE语句配合IN条件，但实际使用频率非常高，能体现设计者对业务场景的理解。

搜索功能是另一个容易做差的地方。菜品搜索建议同时匹配菜名和分类名，用户搜“辣”的时候，既能找到包含“辣”字的菜品，也能找到“川菜”分类下的相关菜品。这种细节对用户体验的提升非常明显，但代码量只是多加一个关联查询而已。

最后再分享一个小技巧。改造这个项目时，如果不想动复杂的前端页面，只做后端接口改造，可以先用Postman把后端接口全部测一遍，确认数据返回正常后再动前端。定好接口边界，前后端各测各的，能省去大量联调时互相扯皮的时间。我第一次改造一个旧版餐饮项目时就是先整理接口清单，带着这份清单去改代码，整个过程思路非常清晰，后面的同学可以试试这个方法。