我不止一次在复盘这个项目的时候感慨：连锁餐饮点餐系统是那种看起来“不就是CRUD吗”，实际做起来却能逼着你把分布式、并发、权限、状态机全部过一遍的典型项目。尤其是当点餐系统从单店版本扩展到连锁场景后，很多单店模式下"跑得通就行"的设计会被直接击穿。这篇文章我会把整个系统的设计与实现路线完整整理出来，包括需求拆解、技术选型逻辑、后端核心建模、前端工程化落地、以及部署后的真实调优经历，希望给正在做类似系统或者准备拿这个方向做项目的朋友一些能直接落地的参考。
这套系统基于Spring Boot提供后端服务，前端采用Vue.js构建，覆盖了顾客扫码点餐、收银端核销、后厨出品管理、总部数据看板这几条核心业务线。它不是那种"能用就行"的演示系统，而是按照可上线标准去设计的。无论你是技术选型阶段还是已经写了一半代码卡在某个模块，这篇内容都值得看完。
1. 连锁场景下的需求边界：为什么点餐系统不等于简单的增删改查
很多人拿到"点餐系统"第一反应就是：菜品表、订单表、购物车，三个表一套CRUD完事。这个思路在单店模式下勉强成立，但放到"连锁"两个字面前，几乎所有的基础假设都要重构。
1.1 连锁餐饮的真实痛点：门店隔离与数据归属
连锁品牌和单店最大的区别在于：同一套系统要服务多个门店，而每一个门店的数据严格隔离，但总部又需要全局视角。这个需求会直接引导你设计出"门店维度"这条贯穿所有表的主线。
我刚设计这个模拟项目X的时候，第一版数据库里订单表根本没有store_id字段，当时想着"反正就一个店"。后来需求一扩展，所有SQL都要加上按门店过滤的条件，订单查询、库存扣减、营收统计全部乱套。教训就是：在连锁系统里，门店ID宁可一开始就加上，也不要等表建完了再补。门店隔离不是一个可有可无的字段，它是连锁系统数据架构的地基。
再往细了说，连锁场景还包括"门店-菜品-价格"的关联关系：同一个菜品，不同门店的售价可能不同；同一个菜品在不同门店的上架状态也可能不同；区域门店有区域限定菜品。如果只做一张"菜品表"配一个"统一价格字段"，就完全无法应对这种需求。实际项目中我把菜品拆成了两层：菜品档案层（菜品名称、分类、图片、口味标签）和门店菜品配置层（门店ID、售价、上架状态、每日沽清数量）。前端看到的每一个菜品项，其实是两层数据join之后的产物。
1.2 五类角色的权限矩阵设计
连锁点餐系统的角色显然不是"用户"和"管理员"这么简单。我梳理下来至少有五类：顾客（小程序/平板点餐）、收银员（堂食核销、现金收款）、后厨窗口（查看订单、标记出品）、店长（门店报表、菜品管理）、总部运营（跨门店经营分析、菜品统一管理）。
这五类角色对同一份数据的操作权限差异很大，而且存在层级关系。顾客不能看到成本价，收银员不能改菜品价格，店长不能跨门店看数据，总部则应该看到全部门店的汇总。权限这块我建议不要自己写死几十个if else，而是基于RBAC模型去设计：用户-角色-权限三级映射。后端的拦截器里统一校验角色对应的接口权限，而不是在各个Controller里零散地判断。
这里有个细节值得注意：连锁系统的数据权限和功能权限都要做。功能权限决定"能不能点这个按钮"，数据权限决定"能看到哪些门店的数据"。我做法是在每次查询入口包一层门店范围解析逻辑，从登录态里取出当前用户的可见门店ID列表，然后作为强制过滤条件拼进SQL，绝不信任前端传来的store_id参数，防止横向越权。
1.3 需求收敛：首版系统到底该做哪些模块
做项目最怕的是需求无限膨胀。第一版我建议把范围收敛到"顾客能完成一次完整点餐、门店能完成一次完整出餐、总部能看到各店实时营业汇总"这三条主链路。核心模块拆成五个：门店管理、菜品管理、订单管理、会员与优惠、数据看板。
像预订桌位、员工排班、供应链进销存、外卖平台对接，这些虽然也是连锁餐饮的真实需求，但放进第一版会让系统变得臃肿而且难以做完。我在模拟项目X中第一版明确砍掉了库存管理和对接第三方外卖，把精力集中在点餐与订单这条主链路上，后期再以迭代的方式补充。事实证明这个收敛是对的，先跑通主链，再谈扩展。
2. 技术选型的取舍逻辑：Spring Boot与Vue.js为什么是这套组合
技术选型没有绝对的对错，只有合不合适的区别。选型这部分我给完整的技术对比和理由，方便你在答辩或项目评审时有理有据地说清楚"为什么用它"。
2.1 后端基座：Spring Boot的稳妥体现在哪里
我最终选了 Spring Boot 3.x + JDK 17。理由有几个层面。第一，Spring Boot的自动配置机制让项目启动成本非常低，一个空项目几分钟就能跑起来，这对需要快速验证业务模型的阶段特别友好。第二，生态足够成熟，Spring Security做认证授权、Spring Data JPA或MyBatis做持久层、Redis做缓存和分布式锁，这些都是经过大规模生产验证的组件，遇到问题能搜索到的解决方案最多。
第三，也是我觉得最关键的一点：Spring Boot的模块化能力契合连锁系统的扩展需求。连锁系统天然有"总部服务端"、"门店客户端"、"顾客点餐端"这样的多端场景，而Spring Boot可以按模块拆分，也可以按服务拆分。首版用单体+模块化，后续流量上来后可以直接把订单服务、用户服务拆出去。这个演进路径比一开始就上微服务要务实得多。
和 Node.js 的 Express/NestJS 对比，NestJS在做大型TS项目时其实也很顺，但如果你的团队更熟悉Java生态、部署环境也更习惯JVM体系，那Spring Boot的长期维护成本会更低。和 PHP 系的 Laravel 比，Spring Boot在强类型约束、事务管理、并发处理上的表现更适合订单这种对数据一致性要求高的场景。
2.2 前端框架：Vue.js为什么和这套后端最搭
前端我选了 Vue 3 + Vite + Pinia + Element Plus。选Vue的核心原因是它的渐进式设计和中文生态友好，对团队技术栈平滑迁移非常有利。Vue 3的Composition API在实际开发中明显比Options API更适合复杂业务逻辑的复用，比如购物车逻辑、金额计算逻辑，在多个页面组件之间共享时，写成一个组合式函数（composable）非常自然。
Vite作为构建工具相比Webpack最大的体感优势就一个字：快。本地开发时模块热更新几乎秒开，这在频繁调整菜品分类、购物车交互时能节省大量等待时间。Pinia做状态管理比Vuex的样板代码少很多，而且对TypeScript的支持更好。Element Plus提供的表格、表单、弹窗组件，能覆盖管理后台90%以上的界面需求，菜品管理、订单列表这些页面基本不需要从零写UI。
选择Vue而不是React，还有一个很现实的原因：国内招聘市场上Vue开发者基数大，项目后续要找人维护也容易。React当然也很好，但在这个模拟项目X的语境下，Vue和Element Plus的组合可以让团队把精力集中在业务逻辑而不是造轮子上。
2.3 数据存储与中间件：关系型为主，缓存为辅
数据库我用的 MySQL 8.x，InnoDB引擎。点餐系统是典型的高一致性、强事务场景：下单要扣库存、算金额、生成订单明细，任何一个步骤失败都不能让用户下出一个残缺的订单。这些都依赖关系型数据库的事务特性。订单表、订单明细表、菜品表、门店表、会员表，全部用MySQL存储。
Redis的角色是"加速器"而不是"主存储"。它承担了三类工作：门店菜品缓存、用户会话Token、下单防重的分布式锁。比如菜品列表这种读多写少的数据，缓存命中后接口响应时间能从几十毫秒降到个位数毫秒。订单号生成也用到Redis的自增特性，避免数据库自增ID在并发量上来后出现瓶颈。
还有一点容易被忽略的是文件存储。菜品图片如果直接存在应用服务器本地，后续扩展集群时会非常麻烦。我采用的是独立存储路径加反向代理访问的方式，开发环境用本地目录，生产环境可以平滑切到云对象存储。这一点在后端代码里要做成配置项，而不是写死路径。
3. 后端核心模型与订单状态机的落地细节
这部分是整个系统设计的重中之重。我在做模拟项目X时，很多细节问题都是在这里暴露的。
3.1 数据库表设计的核心表结构
我实际建表的思路可以总结为"两张档案表、一张关系表、一组业务表"。门店表和菜品档案表是基础数据，门店菜品表维护门店和菜品之间的多对多关系（带价格和上架状态）。订单这块拆成两张表：订单主表和订单明细表。主表存订单号、门店ID、桌号/渠道、订单状态、应收金额、实收金额、优惠金额、创建时间等；明细表存每一道菜的菜品ID、菜品名称（冗余存储，防止菜品改名后历史订单显示错乱）、数量、单价、小计。
这里点名一个新手经常踩的坑：订单明细里必须冗余菜品名称和单价快照。如果订单明细只存菜品ID，等菜品下架或改名后，历史订单的展示就完全错乱了。我在模拟项目X早期版本就吃过这个亏，收银台历史订单菜单里有的菜显示"已删除菜品"，后来加上名称和价格快照字段才解决。
库存字段我做得比较轻量，采用"每日沽清数"的方式，在门店菜品配置表里加字段remaining_quantity，每次下单成功后扣减。不做复杂的进销存是因为第一版范围收敛，但这个字段为后续扩展库存管理预留了很好的基础。核心表结构大致如下：
- 门店表（store）：门店ID、名称、地址、联系电话、状态
- 菜品档案表（dish）：菜品ID、名称、分类ID、图片URL、描述、口味标签
- 门店菜品表（store_dish）：门店ID、菜品ID、售价、上架状态、每日剩余份数
- 会员表（member）：会员ID、手机号、昵称、积分余额、等级
- 订单主表（orders）：订单ID、订单号、门店ID、渠道（堂食/扫码/自取）、状态、总金额、优惠金额、实付金额
- 订单明细表（order_item）：明细ID、订单ID、菜品ID、菜品名称快照、单价快照、数量、小计
3.2 订单状态机的设计：从待支付到已完成的状态流转
订单状态如果只用一个字段存数字"0、1、2"然后代码里if判断，后期一定会乱成一团。我在设计时直接用了个枚举类去约束状态流转，前台状态包括：待支付、已支付/待出餐、制作中、待取餐/待上菜、已完成、已取消。
出餐环节其实还有更细的状态拆分，比如后厨接单、开始制作、制作完成，但对于第一版系统，我合并成"制作中"和"待取餐"两个状态。后厨每完成一个菜品，系统自动检查该订单下所有菜品是否都已出品，如果全部完成，订单状态自动流转到待取餐。这个"自动判定完成"的逻辑在代码里是每次出品操作后的一个checkAndComplete方法，业务合同非常清晰。
支付环节也值得一提。支付宝/微信支付申请流程较长，模拟项目X中我采用"模拟支付"的方式：前端调起支付确认弹窗，后端直接修改订单状态为已支付。但在代码架构上我预留了支付回调接口，未来接真实支付时只需要替换支付通道实现，不影响订单主流程。这个抽象设计让项目在展示时既能跑通全流程，又不会被第三方支付资质卡住。
3.3 购物车与下单接口的事务边界
下单接口是系统中最不能出错的部分，我用一个Transaction注解包住了整个方法，从前置校验、金额计算、库存扣减到订单生成，全部在一个事务里。任何一个环节抛异常，整单回滚，不会出现"钱扣了但库存没减"这种灵异事件。
事务的边界设计有一个容易被忽视的点：不要把远程调用或者消息发送放在事务里。如果我在事务里直接调Redis或发WebSocket通知，一旦事务回滚，通知却发出去了，会造成前端状态和数据库不一致。正确处理是：事务内只做数据库操作，事务提交成功后，再在方法外层发送通知、清理缓存。我用Spring的TransactionSynchronizationManager注册了事务提交后的回调（afterCommit），在这个回调里做缓存删除和WebSocket推送。
购物车本身我建议以Redis存储为主，用户ID作为key，菜品ID作为hash field，数量作为value。这样做的优势是购物车不落库，用户下次进店能恢复，也不需要建一堆购物车表。顾客端和收银端的购物车共用同一套结构，逻辑完全复用。
3.4 优惠计算怎么做得不恶心
优惠模块看起来简单，做起来最容易出bug。满减、折扣券、会员折扣、首单立减，如果在一个方法里用if else堆，代码很快就会腐烂。我参考了设计模式里的策略模式，定义了一个DiscountStrategy接口，每种优惠类型一个实现类，然后通过一个工厂根据优惠类型编码获取对应的策略实现。
计算顺序也很有讲究。我的顺序是：会员折扣优先级最高，先计算折扣价；然后在折扣价基础上判断是否满足满减条件；最后叠加优惠券（如果有）。每一步计算的结果都记录到订单的优惠明细字段里，方便对账。金额计算全程用BigDecimal，绝不用double或float。这一条是经验之谈，浮点数在金额计算上的精度问题会把你折磨疯掉。
支付金额的校验要做到前后端双重校验。前端算一遍给用户看，后端必须基于数据库里的实时价格再算一遍，以服务端计算结果为准。我在模拟项目X中就遇到过一个问题：用户把商品加入购物车后，后台改了价格，前端购物车还显示旧价格，后端下单时直接按最新价格计算并返回"价格已更新"提示，让用户确认后再下单。
3.5 接口鉴权与防止横向越权
接口鉴权我选用了JWT + Spring Security的组合。用户登录成功后签发Token，前端存储在本地并每次请求放在Authorization头里。Spring Security的过滤器链里配置了白名单路径（比如菜品浏览、门店查询），其他接口都要经过身份认证。
但光有JWT还不够，横向越权是连锁系统必须防住的点。所谓横向越权就是A门店的收银员通过改请求参数拿到了B门店的订单数据。我在服务端做了一个数据范围解析器，从当前登录用户的角色和归属门店信息中解析出"允许访问的门店ID列表"，任何查询请求都必须经过这个列表的过滤。
这个设计在代码实现上并没有想象中复杂。核心是做一个@RequireStore注解加一个AOP切面，进入Controller方法前自动注入门店权限上下文，Service层只要从上下文取门店ID列表查询即可。同时，在Spring Security的UserDetails里就带上门店归属和角色编码，避免每次请求都查一遍数据库。
4. 前端工程化实践：从项目骨架到核心业务页面
前端部分虽然不像后端那样有复杂的事务和状态机，但工程化的规范和组件抽象做得好不好，直接决定开发效率和后期维护成本。
4.1 前端项目骨架与目录约定
我使用的是Vue 3 + Vite的组合，项目结构采用基于功能的模块化划分，而不是把所有组件都堆在src/components下面。具体目录大致是这样：
src/ api/ # 按模块拆分的接口请求封装 assets/ # 静态资源 components/ # 通用业务组件（菜品卡片、订单列表项等） composables/ # 组合式函数（useCart、useOrder、useAuth） layouts/ # 布局组件（顾客端布局、管理端布局） router/ # 路由配置，包含权限守卫 stores/ # Pinia 状态库 views/ # 页面级组件 customer/ # 顾客点餐端页面 admin/ # 管理后台页面 kitchen/ # 后厨端页面每新增一个业务模块，直接在对应目录下创建文件，路由和菜单配置分开维护。我在项目初期就坚持了这个结构，当系统从20个页面扩展到40个页面时，没有出现"找不到文件"的混乱。对于团队协作而言，清晰的目录约定比短暂的"赶工速度"重要得多。
路由守卫是前端权限控制的第一道关卡。我在router.beforeEach里做了两件事：第一检查Token是否存在，不存在则跳转登录；第二从Pinia中读取用户角色信息，校验当前路由是否在该角色的可访问列表中。后端做最终鉴权，前端做友好拦截，两者配合体验最好。
4.2 顾客端点餐流程：从选菜到支付的核心交互
顾客端页面我按照"选择门店-浏览菜单-加入购物车-确认下单-支付-查看订单"这条链路来设计。底部Tab栏设置三个主模块：点餐、订单、我的。点餐页面上半部分是可横向滚动的菜品分类，下半部分是菜品列表流。
菜品卡片组件是一个复用度很高的组件，包含菜品图、名称、月售数量、价格，以及右上角的加号按钮。加入购物车时有一个动画交互：加号点击后图标飞入底部购物车栏。这个动画本质上就是生成一个绝对定位的clone节点，做贝塞尔曲线位移，技术难度不高，但对点餐体验的提升非常明显。
购物车UI是一个底部弹出的抽屉组件，支持按菜品分类查看、修改数量、清空购物车。与实际业务绑定最紧密的是：售罄菜品在购物车中置灰显示，数量置为剩余可售份数。用户在下单前就能感知库存情况，避免"提交订单时才被告知菜品售罄"的挫败感。门店切换的逻辑也很重要：切换门店后购物车自动清空，因为每个门店的菜品和价格是隔离的。
4.3 管理后台菜品管理与订单处理
管理后台面向店长和总部运营。菜品管理页的核心是门店菜品配置表：选中某个门店后，可以看到该门店所有的菜品列表，支持单独设置上架状态、销售价格、每日库存。这个页面批量配置功能我建议一定要做，否则几十家门店挨个点开设置会把运营逼疯。
订单处理页是所有门店订单的实时列表。收银员处理堂食订单的流程是：查看待支付订单列表、点击"确认收款"、输入实收金额（支持现金/扫码）、订单状态变更为已支付。后厨端是一个独立页面，布局适配大屏展示。后厨看到的是按时间排序的"待制作"订单，每点击一个"完成"按钮，订单状态就向后推进。我用了WebSocket推送来实现订单状态的实时更新，后厨标记出品后，顾客端订单详情页上的状态会实时变化。
WebSocket的接入方式我选择的是Spring Boot内置的WebSocket + STOMP协议。后端定义一个消息推送服务，在订单状态变更时向指定门店频道推送通知。前端顾客端和管理端分别订阅各自关心的频道，收到消息后刷新对应数据。这个方案比前端定时轮询更实时也更省资源。需要注意的是，WebSocket连接要处理断线重连机制，否则用户锁屏一段时间后连接断了，订单状态就不再实时更新。
4.4 Pinia状态管理在购物车和用户信息中的应用
购物车状态我用Pinia管理，核心是一个reactive对象，以菜品ID为key，值为{dish, quantity, selected}。购物车的所有操作都封装在store的action里，比如addToCart、removeFromCart、updateQuantity、clearCart。这样做的好处是：页面组件只需要调用action，不需要关心状态内部怎么变化。
用户信息和门店选择也放在Pinia里。用户在进入点餐页前先选择门店，门店信息存到store里，后续所有页面和接口调用都从store读取当前门店ID。用户状态和门店状态分开管理，避免因为切换门店导致用户登录态丢失。这个分离设计虽然简单，但对体验的影响很大。
代码层面，我用computed做购物车合计金额的派生状态，只要购物车里的菜品数据或数量变化，合计金额自动更新。优惠金额的计算在前端也做了一部分，用于实时展示，但最终金额以后端返回为准。为了防止用户篡改请求金额，前端提交订单时只传菜品ID和数量，后端负责计算金额，前端展示的金额仅作为参考。
5. 部署与性能调优：从开发环境到可上线状态的跨越
写完系统只是第一步，真正让我头大的反而是部署和调优阶段。这一部分我整理从编码完成到系统稳定运行的完整过程。
5.1 初始化部署：从裸机到系统跑起来的关键步骤
我在模拟项目X的部署阶段采用了最简单的单体部署方案：打包后的Spring Boot Jar包部署在一台Linux服务器上，前端通过Nginx部署静态文件并反向代理后端接口。
后端部署有几个关键配置：数据库地址和账号、Redis连接信息、JWT密钥、文件存储路径。这些我全部放到独立的配置文件里，生产环境用application-prod.yml，通过启动参数--spring.profiles.active=prod指定。启动用systemd管理服务，配置了开机自启和崩溃自动重启。这一步很重要，服务器一重启服务起不来，是线上事故最常见的起因之一。
前端部署相对简单，npm run build后把dist目录上传到Nginx的html目录，配置反向代理：/api前缀的请求转发到后端服务的端口。Nginx同时也要开启client_max_body_size的配置，否则菜品图片上传会被默认的1MB限制挡住。
5.2 冷链环节：数据库连接池和缓存策略调优
系统上线后我做的第一轮调优集中在数据库连接池。Spring Boot默认的HikariCP配置已经比较合理，但在连锁场景下，每个门店的收银端和顾客端都在不断请求，连接池满导致接口报错的情况还是会出现。我把连接池大小从默认的10调到了20，同时设置了connection-timeout: 30000，避免连接获取超时直接抛异常。
菜品列表接口是访问频率最高的接口，也是最值得做缓存的。我把门店菜品列表接口加了Redis缓存，key设计成dish:list:{storeId}，后台修改菜品配置时主动删除对应门店的缓存。这样做的效果非常显著：菜品接口的响应时间从平均80ms降到了10ms左右。缓存更新策略我选的是更新数据库后主动删缓存而不是更新缓存，因为"删"比"更新"更简单可靠，下次请求自然会把新数据写回缓存，还能避免并发更新时出现的数据不一致。
还有一个性能细节是SQL层面的。订单列表页如果直接按时间倒序全量查询，门店订单一多就会变慢。我给订单表和订单明细表的关键查询字段加了联合索引，比如门店ID加创建时间。索引设计一定要结合实际的查询模式来设计，不能随便加，否则反而拖慢写入速度。
5.3 高峰时段的并发控制与订单防重
餐饮行业的订单峰值集中在午晚市两个时段，短时间内的下单请求可能是平时的几十倍。这种情况下最怕的不是慢，而是重复下单。用户因为网络原因多点了几次提交按钮，结果产生了多个重复订单。
这个问题我用Redis分布式锁做了防重。用户在提交订单时，后端以"用户ID+门店ID+时间段"作为锁的key，尝试加锁，如果当前key已存在，说明上一次订单还在处理中，直接提示"订单处理中，请勿重复提交"。锁的有效期设成10秒，正常下单操作在几秒内完成，到期后自然释放。这个方案实现成本很低，但非常有效。
另一个并发场景是库存扣减。两个用户同时下单抢最后一份菜，如果直接"先查库存再更新"会出现超卖。我用的是乐观锁方案：更新语句里加上remaining_quantity大于等于购买数量的条件，update store_dish set remaining_quantity = remaining_quantity - ? where dish_id = ? and remaining_quantity >= ?，如果更新影响行数为0说明库存不足，直接返回售罄。这个写法在数据库层面就避免了并发扣减的问题，不需要引入复杂的分布式事务。
5.4 线上问题排查：订单状态不推送的真实案例
调优阶段我还遇到过一个典型的线上问题：收银端和后厨端有时候收不到订单状态更新的实时推送，但数据库里的订单状态已经变了。排查路径很有代表性，值得记录下来。
我先在后端日志里确认了推送方法有被调用，说明问题出在推送链路而不是业务逻辑。再检查WebSocket的连接日志，发现收银端浏览器在长时间无操作后WebSocket连接已经被服务器主动断开，而前端的断线重连机制没有生效。这里有两个坑：一是Spring的WebSocket默认有session空闲超时时间，连接空闲超过一定时间会被服务端关闭；二是前端只做了连接成功的初始化，没有监听onclose事件做自动重连。
修复方案是双管齐下：后端配置WebSocket心跳检测和会话超时时间，前端在onclose和onerror事件里加入指数退避的重连逻辑。同时，为了避免WebSocket断开期间遗漏消息，我在后端推送时增加了一层兜底：推送失败时把待推送的事件写入本地队列，客户端重新建立连接后主动拉取未读通知。这套"推送+拉取"的双通道机制，最终彻底解决了消息丢失的问题。
写在最后的几条实在建议
项目做完之后复盘，有几条经验我觉得对正在做类似系统的朋友特别有价值。第一，先定数据边界，再写业务代码，门店ID这个维度几乎贯穿所有表，越早设计好后面越省心。第二，订单状态一定要用状态机和枚举约束，别让状态字符串散落在代码里到处判断，不然后期加需求一定改到崩溃。第三，接口权限不能只靠前端隐藏按钮，后端必须做数据范围过滤，连锁系统的横向越权问题是真实存在的高危风险。
另外建议把订单金额相关的计算集中在一个独立的Service里，所有入口都要走这一套金额计算逻辑。这样做既方便加优惠规则，也方便排查对账问题。如果你正在写这个类型的系统，欢迎把遇到的问题在评论里抛出来，很多坑我大概率也踩过。
