从零构建餐饮管理系统：全栈技术选型与高并发实践

简介本资源是一套面向餐饮企业管理者与Java/前端开发学习者的全栈实战项目聚焦解决门店数字化运营中的菜单管理、订单流转、员工协同与消费者点餐体验等核心问题。采用Vue.js构建响应式移动端界面Spring Boot搭建高可用后台服务结合Redis缓存提升高频数据访问性能并以MyBatis-plus简化数据库CRUD操作技术栈覆盖前后端主流框架与中间件适合中高级开发者学习企业级应用分层设计与集成实践。压缩包共384个文件含69个Java后端逻辑类、45个JavaScript前端组件、44个HTML页面模板、41个CSS样式文件及89个PNG图标资源另有db_reggie.sql数据库脚本与pom.xml依赖配置结构清晰、开箱即用。目前已有156人学习下载提供完整可运行源码、标准化目录组织及典型业务控制器如DishController、SetmealController、EmployeeController实现便于快速理解餐饮SaaS系统的核心模块划分与数据交互流程。 做过餐饮行业项目的朋友应该都有体会这类系统看着不复杂真正落地的时候却全是细节——午市高峰一过点餐、后厨、结账、库存全部压在一起哪个环节慢了都会直接影响门店翻台率。这段时间我完整做了一套面向中小餐饮门店的定制化管理系统技术栈选的是Vue Spring Boot Redis MyBatis-plus这一套前端负责点餐收银、后厨大屏和后台管理后端负责订单、菜品、会员、库存和报表Redis专职扛并发和做缓存MyBatis-plus把那些重复的CRUD从日常开发里解放出来。源码整体是前后端分离结构非常适合正在学习全栈开发的读者参考对于想快速给餐饮商家交付系统的团队也有直接复用的价值。1. 项目定位与整体设计思路1.1 餐饮软件的核心痛点与需求拆解餐饮管理系统和普通的后台管理系统有个很大的差别——它的核心场景是高峰期的并发服务能力。你想象一下一家中等规模的门店午市11点到13点之间可能同时有几十桌客人在点餐、加菜、催菜、结账。如果系统的接口响应超过2秒收银员和客人都能明显感觉到卡顿这对门店运营的影响是直接的。我做完需求调研后发现中小餐饮商家的需求其实集中在几块桌台状态管理开台、换桌、并桌、清台、扫码点餐和收银结算、后厨订单联动、会员储值和积分、菜品估清和库存预警以及每日营业报表。在这个范围里系统要做到功能够用、操作简单、高峰期不崩而不是堆一堆大而全的模块。基于这些需求我把项目拆成了前台和后台两套界面。前台是给服务员和顾客用的点餐收银界面后台是给店长管理员用的菜品、库存、会员、报表管理界面。前后端分离的设计天然适合这种多端场景Vue负责界面交互Spring Boot提供统一API职责清晰后续扩展小程序或者平板端都比较从容。1.2 技术栈选型为什么是Vue Spring Boot Redis MyBatis-plus这套技术栈选型坦白说没有什么特别冷门的地方但它恰好是这个项目最合适的组合。前端选Vue主要是考虑到餐饮门店的点餐界面状态变化特别频繁选菜、加购、改规格、计算总价如果要用原生JS手写DOM更新代码量和出错的概率都会翻倍。Vue的响应式机制加上computed计算属性做购物车这种场景非常顺手。而且Vue的社区生态和中文资料足够多后续门店要加一个微信小程序点餐用uni-app这类跨端框架也能复用大部分Vue语法迁移成本低。后端选Spring Boot理由更直接。Java生态在中小型企业管理类软件里依然是主流选择Spring Boot把Spring的配置简化了一大截内嵌Tomcat之后打包即跑部署很省事。Spring Boot 2.6.x这个版本相当稳定配合JDK 8或11都合适网上资料多遇到问题比较容易搜到解决方案。Redis在这个项目里不是装饰品它承担了三件具体的事缓存高频读取的菜品数据、通过分布式锁解决并发下单问题、利用过期机制处理未支付订单的超时取消。这三个场景在餐饮系统里都非常典型所以Redis不是可选项而是刚需。MyBatis-plus的选择就更好理解了。项目里大量的是单表CRUD操作如果用原生MyBatis每张表都要写mapper接口、mapper XML、SQL语句工作量集中在毫无技术含量的重复劳动上。MyBatis-plus把BaseMapper里通用的增删改查做好了还带了分页插件、逻辑删除、字段自动填充、乐观锁这些实用功能开发效率能提升一个档次。在项目已经确定用Java的情况下MyBatis-plus是性价比最高的ORM增强方案。1.3 系统功能模块划分与源码结构项目在功能层面大概可以分成六个模块桌台与点餐模块桌台状态管理、扫码/手动开台、点餐、加菜、退菜、下单后厨联动模块新订单实时推送到后厨屏、菜品制作状态流转待制作/制作中/已出餐收银结算模块订单计算、折扣、多种支付方式、结账/清台菜品与库存模块菜品分类、菜品管理、规格/口味配置、估清操作、原料库存预警会员模块会员开卡、储值、积分累计、积分抵现数据报表模块营业日报、时段流水、菜品销量排行、会员消费统计源码结构方面前端按api、router、store、views、components、utils分目录后端按controller、service、mapper、entity、common分包。这样分的好处是新同事接手或者自己隔几个月回来看都能很快定位到某个功能对应的代码位置。我见过不少项目表结构设计不错但代码放得乱七八糟修改一个需求要翻半天文件所以分包规范这件事我比较坚持。2. 数据库设计与MyBatis-plus落地细节2.1 核心表结构设计餐饮系统的表结构最关键的是订单相关的一组表。我采用的是订单主表 订单明细表的标准设计。订单主表order_master保存一次消费的汇总信息包括订单号、桌台ID、会员ID、菜品总金额、优惠金额、实付金额、支付方式、订单状态、创建时间、支付时间。订单明细表order_detail保存每一条菜品记录包括菜品ID、菜品名称、单价、数量、规格、口味备注。这样拆分的好处是分析客单价翻台率菜品销量这些报表指标时可以按不同维度去聚合而不用在同一个表里做复杂的关联。菜品表dish我额外设计了一个description字段用来存规格和口味的JSON数组因为不同门店的菜品规格差异很大单独建一张规格表虽然更规范但开发和使用成本都高出一截。JSON存储的方式虽然被一些数据库洁癖诟病但在这个业务里确实灵活很多代价是统计规格维度时稍微麻烦一点权衡下来是合算的。基础表还有桌台表、菜品分类表、会员表、库存表、系统用户表。每张表我都加了create_time、update_time、is_deleted三个通用字段。is_deleted用逻辑删除而不是物理删除是因为餐饮系统的订单和菜品数据有对账和审计需求删错了要能追溯这一点千万别省。2.2 Spring Boot环境搭建与MyBatis-plus集成环境搭建这部分网上教程很多我挑几个特别容易踩坑的点说一下。Spring Boot用的2.6.13JDK用的1.8Maven用的3.6.3这三个版本配合非常稳定。MyBatis-plus用的是3.5.x版本注意要和Spring Boot版本匹配否则可能出现自动配置失效的问题。pom.xml里核心依赖大概是这样的dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-extension/artifactId version3.5.3.1/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version /dependency然后需要在application.yml里配置数据源和MyBatis-plus的参数。mybatis-plus的配置里有几个容易被忽略的点map-underscore-to-camel-case默认就是true所以数据库字段下划线命名、Java属性驼峰命名不需要额外写转换logic-delete-field需要指定全局逻辑删除字段log-impl推荐用StdOutImpl开发阶段能看到完整的SQL输出排查问题方便。注册MyBatis-plus分页插件的时候我习惯把拦截器单独放在一个配置类里顺便把乐观锁插件也一起注册因为后面做库存扣减和订单状态流转时可能用到。分页插件一定要注册不然Page对象不会生效这个坑新手遇到的特别多。2.3 MyBatis-plus的高频实用功能详解MyBatis-plus最核心的用法就是通过继承BaseMapper直接获得单表CRUD能力。菜品Mapper接口一行代码public interface DishMapper extends BaseMapperDish { }然后ServiceImpl继承ServiceImpl类Controller里直接调service的方法。基础的增删改查就全部有了不需要写一行SQL。这种做法的价值在项目里是实打实的几十张表的CRUD能省下大量时间。三个功能我觉得特别值得列出来说。第一个是字段自动填充。我在实体类上给create_time和update_time加TableField(fill FieldFill.INSERT)和TableField(fill FieldFill.INSERT_UPDATE)注解然后实现一个MetaObjectHandler在insertFill和updateFill里自动写入当前时间。这样新增和修改的时候时间字段完全不用手动管避免出现因为忘记赋值导致的时间为空问题。第二个是逻辑删除。在实体类字段上加TableLogic注解或者在yml里全局配置logic-delete-fieldMyBatis-plus执行delete方法时就自动变成update语句把is_deleted置为1。查询时也自动带上is_deleted0的条件。这个功能保证业务数据不物理消失对报表和账目追溯非常重要。第三个是条件构造器LambdaQueryWrapper。普通查询我基本不写SQL直接用LambdaQueryWrapper拼条件它最大的好处是编译期就能校验字段名不会出现手写SQL时那种字段名打错运行才发现的问题。比如按分类查菜品LambdaQueryWrapperDish wrapper new LambdaQueryWrapper(); wrapper.eq(Dish::getCategoryId, categoryId) .eq(Dish::getStatus, 1) .orderByDesc(Dish::getSort); ListDish dishList dishMapper.selectList(wrapper);2.4 一个高频问题updateById能更新字段为null吗这个问题如果去搜可以看到很多人问。结论先说默认情况下不能。MyBatis-plus的默认更新策略是NOT_NULL也就是只更新实体类中值不为null的字段值为null的字段会自动跳过。这样做其实是故意的是为了避免你更新某个实体时不小心把不想动的字段置空。但实际业务里确实会有需要把字段置空的场景。比如点餐时给订单加了一个备注客人又取消了这个备注这时候就需要把备注字段更新为null。解决方式有几种。第一种是字段级指定更新策略在实体类字段上加注解TableField(updateStrategy FieldStrategy.IGNORED) private String remark;这样这个字段无论是否为null都会被更新。要注意的是这种方式的语义是这个字段始终愿意被更新为null并不是只对某一次操作生效所以要用在确定需要这种行为的字段上。第二种是用LambdaUpdateWrapper在不需要实体类改注解的情况下单独对某一次操作强制set字段比如LambdaUpdateWrapperOrderMaster wrapper new LambdaUpdateWrapper(); wrapper.eq(OrderMaster::getId, orderId) .set(OrderMaster::getRemark, null); orderMasterMapper.update(null, wrapper);这种方式更灵活我实际项目里大多数时候用的是这种因为不用去动实体类语义也清晰。第三种是全局修改update策略在yml里配置field-strategy。全局配置的粒度太粗会影响所有表和所有字段我一般不推荐。3. Redis在餐饮系统中的关键应用3.1 菜品缓存设计缓存Key和更新策略餐饮系统的点餐首页是后端接口压力最大的地方因为每个客人打开菜单都要拉一次菜品分类和全部菜品列表。这个数据的特点是读取频率极高、写入频率低只有管理员在后台改菜品时才会变化完全是典型的缓存场景。我的设计是分两个Key缓存category:list缓存全部分类dish:list:{categoryId}按分类缓存菜品列表。缓存的value用JSON数组点餐页面一次请求把两个数据都拿回来组合成菜单树。这样设计的好处是更新粒度精细后台修改某一个分类下的菜品时只需要删除对应的dish:list:该分类的缓存其他分类的缓存还能继续命中。更新策略我采用的是先更新数据库再删除缓存。为什么不直接更新缓存因为菜品数据可能包含分类联动、口味规格、图片地址等多处关联信息重新生成缓存逻辑复杂而删除缓存让下次请求重新加载简单且不会出错。这个策略在绝大多数场景下够用只有极端情况下存在缓存删除失败导致的短暂脏数据解决方式可以加一个重试机制或者延迟双删但对餐饮系统来说删除失败的概率实在太低不值得为此引入消息队列之类的重量级方案。3.2 缓存穿透、击穿与雪崩的防范用Redis做缓存有三个经典问题必须提前想到不然一遇到高流量就出问题。缓存穿透是指查询一个必然不存在的数据比如一个已经被物理删除的菜品ID请求会绕过缓存直接打到数据库。解决方式比较简单查询结果为空也缓存一个空值设置较短的过期时间比如30秒这样大概率能挡住重复查询。缓存击穿是指某个热点Key过期瞬间大量请求同时打到数据库。餐饮系统的今日推荐菜品就是这种热点Key。解决方式可以用互斥锁但更简单的思路是让这个热点Key的过期时间错开或者干脆给它设置较长的过期时间靠后台任务主动刷新。缓存雪崩是指大量Key在同一时间集中过期导致数据库压力瞬间暴涨。解决方式是给过期时间加一个随机扰动比如基础过期时间30分钟再随机加0到300秒避免大批量缓存同时失效。Redis内存本身有限设置过期时间是必须的不然一下存几万道菜品的缓存内存会扛不住。3.3 用Redis分布式锁解决并发下单问题餐饮系统遇到并发问题最多的地方就是同一个桌台重复提交订单、会员储值卡同时消费、限时优惠券抢购这类场景。我在这套项目里用Redis分布式锁来处理。Redis分布式锁的核心是SET命令的NX和EX参数原子地实现不存在才设置同时设置过期时间public boolean tryLock(String lockKey, String requestId, long expireTime) { return redisTemplate.opsForValue() .setIfAbsent(lockKey, requestId, expireTime, TimeUnit.SECONDS); } public boolean releaseLock(String lockKey, String requestId) { String script if redis.call(get,KEYS[1]) ARGV[1] then return redis.call(del,KEYS[1]) else return 0 end; return redisTemplate.execute( new DefaultRedisScript(script, Long.class), Collections.singletonList(lockKey), requestId) ! 0L; }这里有两个细节很重要。第一加锁时要设置过期时间否则如果持有锁的线程崩溃锁永远不会释放其他请求会被卡死。第二释放锁时校验持有者身份用Lua脚本保证判断删除的原子性防止释放了别人的锁。为什么不能先get判断再delete因为这个两步操作之间有竞态窗口线程A判断是自己的锁还没删锁过期了线程B抢到了锁线程A再执行删除就把B的锁删掉了。Lua脚本把两步合成一步才能避免这个问题。实际开发中我更推荐直接用Redisson组件它的lock方法内置了看门狗自动续期、可重入锁等能力比自己手写SETNX更省心。但如果项目比较轻量手写版本也完全够用重点是把上面那两个细节处理好。3.4 订单超时未支付自动关闭的实现扫码点餐的场景里客人下单后如果不支付订单会一直挂着既占桌台又影响统计。处理这个问题的方案有好几种我在项目里先用的是Redis过期时间方案简单直接。下单时把订单ID写入Redis设置过期时间比如15分钟redisTemplate.opsForValue().set(order:timeout: orderId, orderId, 15, TimeUnit.MINUTES);然后开启Redis的过期事件监听通过Spring Boot的事件监听机制处理过期事件在回调里检查订单状态如果还是待支付就更新为已取消并释放桌台。这个方案的优点是代码量少不依赖额外组件符合中小项目的定位。但这里要提醒大家一个坑Redis的过期事件并不是严格准时的它是基于惰性删除和定期删除机制触发的所以订单取消时间可能延迟几秒甚至更久。另外如果Redis服务器重启期间过期的Key事件会丢失。所以这个方案适合对时间精度要求不高的场景。如果要做严格的延迟任务可以换成Redisson的延迟队列但复杂度会高一些餐饮系统一般用不上那么严格。3.5 Redis的安装、配置与可视化工具项目开发时自己电脑上的Redis环境怎么搞不少人会卡在这一步。Redis官方其实不提供Windows版本所以Windows下开发用的比较多的是Memurai兼容Redis协议或者WSL里跑Linux版Redis。个人建议有Docker的话直接用Docker最省心docker run -d --name redis -p 6379:6379 -v /mydata/redis/conf:/conf redis:7.0线上需要部署主从模式时用docker-compose编排一主一从读多写少的餐饮系统里主从分离能让报表查询这类读操作打到从库上减轻主库压力。Spring Boot配置Redis也很简单就是设置host、port、password、databasedatabase建议订单相关功能用db0缓存相关用db1避免两类数据混在一起过期策略不好设置。可视化工具方面我比较推荐Another Redis Desktop Manager免费开源且跨平台比起老牌的Redis Desktop Manager在响应速度和内存占用上都好一些。日常看Key列表、检查过期时间、手动删除脏缓存都非常方便属于开发调试的必备工具。4. 前端Vue的实现要点4.1 项目搭建、环境配置与路由设计前端项目用Vue CLI还是Vite可以按自己团队习惯来。如果对Vite构建不熟悉用Vue CLI反而稳一些。创建项目之后我习惯先把目录结构搭好api目录放接口封装router目录放路由配置store目录放状态管理views目录按页面模块分文件夹components目录放公共组件utils目录放axios实例和通用工具函数。这个结构几乎不需要过度设计但能让团队协作时少踩很多不必要的坑。路由设计上餐饮系统可以分成三类路由。第一类是登录页和公共页面第二类是点餐收银这类需要登录但不需要管理权限的页面第三类是菜品管理、报表这类需要管理员权限的页面。通过Vue Router的路由守卫beforeEach做权限控制没有登录就统一跳转登录页没有权限就跳转403页面。这样一个简单的设计方案在真实项目中已经能覆盖大多数需求。Vue环境配置上要注意.env.development和.env.production分别配开发和生产环境的API地址开发环境下vue.config.js里用devServer.proxy做代理解决跨域问题不要在后端强行打开CORS那样生产环境会有安全隐患。4.2 点餐购物车computed和watch的最佳实践点餐页面是前端最核心的部分左侧是菜单分类和菜品列表右侧是已选菜品购物车。购物车的状态管理我用Vuex/Pinia来做为什么不用组件本地状态因为这个购物车数据在多个组件里要用点餐页要展示结账弹窗要展示下单接口要提交如果每个组件各自维护一份同步起来非常痛苦。用全局状态管理数据流是单向的调试起来清晰很多。计算总金额这种场景用computed是最佳实践。它依赖的数据没有变化时计算结果会缓存不会反复执行。我见过不少人在methods里定义getTotalPrice方法然后到处调用每次渲染页面都会重新算一遍消费性能是小事更容易出问题的是模板里多处调用时结果不一致。用computed就不会有这个困扰const totalAmount computed(() { return cartItems.value.reduce( (sum, item) sum item.price * item.quantity, 0 ); });watch的典型场景是监听购物车变化自动缓存到localStorage防止顾客误刷新页面导致已选菜品丢失。这个体验细节虽然不起眼但真实门店里顾客经常会误触刷新有了本地缓存体验会好很多。watch注意要设置deep: true因为购物车项里面的数量变化是深层属性的修改否则监听不到。4.3 axios封装与后端接口联调Vue项目里axios必须封装一次不能每个页面直接调axios.get。我在utils/request.js里创建一个axios实例配好baseURL、超时时间、请求头然后在请求拦截器里统一加token在响应拦截器里统一处理后端返回的code。比如后端返回401表示登录过期拦截器直接清空本地登录状态并跳转登录页各个页面就不用自己处理这种公共逻辑了。接口层面的设计上我习惯和后端约定一个统一的返回体结构code本文还有配套的精品资源点击获取