开发点餐系统这类前后台项目，我一直觉得难点不在代码量，而在需求颗粒度的把控。表面看就是顾客点菜、商家接单，但实际落地时，角色权限、订单状态流转、菜品库存扣减、支付回调幂等、图片文件存储，随便一个环节没想透，都能让系统在试运营阶段就翻车。这篇文章我把整个项目的拆解过程和实现思路完整写出来，重点讲清楚每一步“为什么这么做”，而不是只给一堆代码片段。适合正在做毕业设计、接私活，或者想用 Spring Boot 完整走一遍点餐业务闭环的开发者参考。
1. 立项前的需求梳理：到底谁在用点餐系统，核心要解决什么
接手点餐系统项目，最容易犯的错就是直接打开工程开始建表写接口。技术只是实现手段，真正决定系统好坏的是需求理解。我通常拿到需求会先花一两天和商户实际使用者聊清楚：谁在什么场景下用这个系统，操作频率多高，哪些功能是刚需，哪些只是“看着好看”。
1.1 顾客侧：操作路径必须极短
顾客打开点餐入口，心理预期是“10秒能看到菜单，30秒能完成下单”。没人愿意在点餐这件事上研究交互逻辑。所以顾客侧的功能设计要尽量扁平化：首页直接是分类导航加菜品列表，菜品卡片上同时展示图片、价格、月售和口味标签，点击“加购”按钮不需要二次确认弹窗，购物车小图标常驻底部且实时显示数量。
顾客侧的技术接口也就四个核心：获取菜单分类、获取菜品列表、提交购物车、创建订单。再加上订单查询和微信登录授权。不要做社区、评价、分享这类锦上添花的功能，第一版务必克制。登录流程也要极简，扫码进入后优先尝试静默微信授权，拿不到手机号就让用户输一次手机号加验证码，别整注册密码那套。
1.2 商家侧：订单流转和统计口径比功能丰富度更重要
商家实际使用者分成两拨人。店员和后厨关心的是怎样高效出餐，店长关心的是每天的营收情况。给后厨的订单列表只保留待制作状态，每条订单突出菜品名称、数量、备注和桌号，做完点一下“出餐”按钮即可。给店长的界面才需要展示营收汇总、订单趋势、菜品销量排行这些统计分析。
这里就引出一个重要的设计决策：统计口径必须提前定义清楚。比如“今日营收”到底是已支付金额，还是已支付且未退款的净收入？如果同时存在堂食和外带，订单状态是否统一归纳？这些问题拖到开发后期再讨论，返工成本很高。我通常在系统设计文档里专门写一节“统计口径说明”，把每个指标的算法、数据来源、排除条件写明。
1.3 角色权限边界决定工程分包方式
点餐系统的权限模型并不复杂，但边界要干脆。顾客手机端走单独的开放接口，不经过后台管理权限体系；收银员能处理订单，但不能改菜品价格；店长能维护菜品和分类，但不能创建后台账号；系统管理员才拥有全部权限。这个角色矩阵想清楚后，后台模块可以按功能分包，每个写操作接口上再做一次角色校验，避免只靠前端隐藏按钮。
我见过一些项目把所有用户塞进一张 user 表，用 type 字段区分顾客和店员，结果调接口时到处判断 type，非常混乱。正确做法是拆成 customer 和 staff 两张表，staff 表挂 role_id 指向角色表。身份认证体系用 JWT 做，顾客端和后台端各自配置拦截器，互不干扰。
2. 数据模型设计：如何用一套表结构撑起点餐全流程
点餐系统虽然不算复杂，但表与表之间的关系、字段冗余、状态取值，每一个决定都会影响后续开发效率和数据准确性。这一节把核心表结构的设计逻辑讲清楚。
2.1 核心表的层次关系与最小字段集
我把点餐系统的数据表分成四组：基础资料、交易数据、支付数据、系统数据。
基础资料包括分类表、菜品表。分类表只有 id、名称、排序三个字段，菜品表则要包含名称、分类 id、主图、描述、价格、口味标签、启用状态、库存。
交易数据是订单表和订单明细表。订单表存订单编号、顾客 id、订单类型（堂食/外带）、订单状态、支付状态、总金额、优惠金额、实付金额、桌号、备注、创建时间、支付时间。订单明细表存订单 id、菜品 id、菜品名称、单价、数量、小计金额、口味备注。明细表里必须冗余菜品名称和单价，不能只存菜品 id，理由很简单：菜品价格菜单会调整，如果订单明细不冗余，三个月后翻历史订单，计算出的金额和当时顾客实付对不上。
支付数据直接复用常见做法：支付流水表记录支付方式、支付平台单号、支付金额、支付状态、回调时间。它和订单表解耦，订单表只通过自身 pay_status 字段表达支付进度。
2.2 状态机先行：订单状态和支付状态分开维护
订单状态和支付状态是两个概念，很多新手容易混。支付状态只描述“钱到没到”，订单状态描述“餐做到哪了”。我建议这样定枚举：
支付状态：0 未支付、1 已支付、2 已退款。
订单状态：0 待支付、1 已支付待接单、2 制作中、3 已完成、4 已取消、5 退款中。
为什么退款要单独拆出来？因为餐饮场景经常出现顾客吃完发现菜品有问题，要求部分退款。如果退款状态和订单状态混在一起，统计会非常痛苦。订单状态流转我只允许特定的路径：0 可以转 1 或 4，1 可以转 2 或 4，2 可以转 3，已完成的订单不允许任何操作。这个状态转移矩阵在代码里统一管理，而不是散落在各个 Controller 里随意 set。
2.3 库存扣减的两种思路
如果点餐系统涉及“售罄”或限量菜品，库存字段放在菜品表里即可。但扣减逻辑要注意并发问题。我的做法是使用条件更新：
UPDATE dish SET stock = stock - 1 WHERE id = ? AND stock > 0执行后通过受影响行数判断是否扣减成功，等于 0 说明库存不足或菜品不存在。这种乐观锁思路够用且简单。
如果后续要做秒杀或高峰限流，可以把库存预加载到 Redis，用 Lua 脚本原子扣减，再异步同步到数据库。但第一版我不建议上 Redis 库存，除非有明确的高并发需求，否则会增加一致性的排查成本。
3. 用户点餐链路：从菜单浏览到支付回调的完整实现
菜单浏览、购物车、下单、支付，这条链路是顾客直接感知的部分，稳定性和响应速度都在这条链路里验证。
3.1 菜单接口的高频读取与缓存策略
菜单列表是典型的读多写少接口。店里更新菜品的频率很低，但顾客刷菜单的频率很高。我的缓存策略是：菜品分类放缓存，Key 固定为 menu:category，菜品按分类维度设置列表缓存，Key 为 menu:category:{id}。
菜品数据变更时必须显式删除相关缓存，我采用一个简单的方案：所有菜品写操作统一经过一个服务方法，操作成功后自动清理相关缓存 Key。避免直接在 Controller 里操作 Redis，那样很容易出现漏删。
3.2 购物车选型：本地存储、数据库表还是 Redis
购物车实现方案，我排过优先级。纯前端本地存储不推荐，因为跨设备不同步，而且数据不受控，商家拿不到用户购物车信息做“挽回”动作。数据库购物车表稳定但频繁读写账目压力大，点餐场景购物车是临时数据，没必要长期持久化。
最合适的是 Redis Hash 实现。以 user:cart:{userId} 为 Key，field 是菜品 id，value 是数量。加购时执行 HSET 累加，减购时 HINCRBY 递减，数量归零则删除 field。查询购物车直接 HGETALL，还可以附带过期时间防止僵尸数据堆积。购物车金额只是参考，真正结算金额在下单接口里重新计算，前端传金额一律不信任。
3.3 下单事务：一次要保证的原子操作
下单接口是整个系统事务最重的地方，必须在一个数据库事务里完成的动作包括：校验菜品状态和库存、按当前价格重新计算订单金额、生成订单主记录、批量生成订单明细、扣减库存、清空购物车。Transactional 注解标注在服务方法上，异常则整体回滚。
这里还要提防重复提交。最稳妥的方案是前端在创建订单时生成一个唯一的请求流水号，后端在订单表里给 order_no 加唯一索引，重复提交时捕获唯一约束冲突，直接返回“订单已提交”，而不是报错。幂等设计在点餐系统里一定要做，否则弱网环境下的重试请求会生成重复订单。
3.4 支付环节：回调通知与主动查询双保险
支付虽然开发时常常用模拟支付代替，但架构上要按真实微信支付来设计。流程是：后端调用统一下单接口拿到预支付交易标识，返回给前端拉起收银台；用户支付成功后，微信平台异步通知后端支付结果；后端处理回调时验签、核对金额、更新支付状态和订单状态。
回调接口必须处理重复通知，我的方案是使用支付平台单号做唯一约束，重复通知捕获冲突直接返回成功应答，不再重复处理。同时我还设计了主动查询兜底：前端在待支付状态下每隔几秒调用订单查询接口，后端根据情况向支付平台发起主动查单，确保回调丢失时订单状态也能正确收敛。这个兜底逻辑在真实项目里至少能挽回百分之几的异常订单。
4. 后台管理端：菜品维护、订单状态机与轻量统计报表
后台管理端是店长每天要用的工具，操作要顺手。菜品管理、订单处理、基础统计是三大板块。
4.1 菜品管理里的图片与分类问题
菜品录入时，分类必须支持两级结构，比如“热菜-川菜”“饮品-奶茶”，一级分类是饮品，二级分类是具体子类。菜品上传图片时需要校验文件类型和大小，图片文件名不直接用中文名，要重命名为 UUID 加后缀。存储路径上，我建议开发环境存本地目录，生产环境切换到对象存储，用配置项切换存储实现类，前端始终通过附件访问的统一映射获取图片。
分类调整有个容易忽略的坑：删除分类前必须先检查该分类下是否有菜品，有则禁止删除或改为禁用状态。否则菜品流落到无主分类，前台菜单直接空白。
4.2 订单处理的状态流转实现
订单列表页的按钮要随状态变化。我习惯用一个状态机配置来决定当前状态下可执行的操作，例如：
- 待接单状态显示“接单”按钮
- 制作中状态显示“出餐”按钮
- 待支付订单倒计时超时后由定时任务批量修改为已取消
状态变更都会记录到订单操作日志里，方便后续对账和问题排查。日志表字段很简单：订单号、操作人、动作描述、操作前状态、操作后状态、操作时间。
4.3 统计报表：先聚合再缓存
店长页面的统计我通常只给三个核心指标：今日营收、今日订单数、菜品销量 Top10。数据量不大时直接在 SQL 里用聚合函数算。为了提升查询速度，我增加了每日汇总表，定时任务每天凌晨把前一天的全部订单聚合成一条汇总记录。白天查统计只扫当日数据和汇总表前几天的数据，响应速度基本在毫秒级。
5. 上线前的关键细节：文件存储统一、接口幂等、实时通知
这部分属于“我做完一期点餐系统的踩坑复盘”性质的干货，每一项都是真实环境里摔过跟头才总结出来的。
5.1 文件存储路径的一次性约定
所有上传文件如果散落在不同目录，后期换服务器就是灾难。我现在的项目约定：所有持久化内容统一请求存储服务，临时文件走本地目录。开发环境和生产环境通过配置文件切换存储根路径。前端访问菜品图片时统一走附件访问地址拼接，后端返回图片存储的相对路径，访问时再拼完整域名。这样系统换域名或迁移节点，图片地址不会碎。
5.2 接口幂等和重复提交防护
点餐场景最容易出现重复提交的就是下单和支付回调这两个接口。下单接口用 order_no 唯一索引挡住，支付回调用支付平台单号唯一约束挡住，其他操作型接口比如改订单状态、退菜、加菜，统一加请求序列号校验。序列号由前端生成，后端在 Redis 里短暂缓存，重复请求直接拒绝。这个习惯改了以后，我再也没有接到过“我怎么下了两单”的客诉。
5.3 WebSocket的消息推送与断线兜底
顾客下单后商家端最好能实时听到一声提示，商家接单后顾客端也能及时看到状态变化。我通常在项目里集成 WebSocket 做双向消息推送。但这里有个前提：WebSocket 并不保证消息可靠，断线重连期间的消息一定会丢。所以我在推送接口后面加了缓冲机制，客户端重连成功后主动向服务端查询最近未读消息。这就是“推送优先、查询兜底”的组合策略。只依赖 WebSocket 的项目，迟早会碰到收不到通知的投诉。
6. 常见坑盘点与后续迭代方向
最后把几个容易踩坑的细节列出来，再给一个后续扩展的优先级参考。
6.1 数据类型与序列化的三处硬伤
第一处硬伤是价格用浮点类型。商品价格、订单金额一律用 decimal，禁止用 float 和 double。浮点计算会出现 0.1 加 0.2 不等于 0.3 的问题，累计统计时误差会明显放大。第二处硬伤是时间字段用 timestamp，跨时区部署会出现订单时间错乱。我统一使用 datetime 存储业务时间，前端展示再转换本地时区。第三处硬伤是缓存对象的序列化配置。用 Redis 缓存 Java 对象时，如果不统一配置 JSON 序列化器，重启服务后缓存里的 Java 原生序列化数据无法直接转回对象，必须整个缓存删除才能恢复。这个坑排查起来特别花时间，建议开始写缓存时就统一序列化配置。
6.2 点餐系统的下一步扩展顺序
做完基础的“菜单、下单、支付、接单、出餐”闭环后，我建议按以下顺序迭代：先加优惠券系统，能直接提升客单价；再加会员积分，提升复购黏性；后面如果经营多个门店，再扩展多门店维度，把门店 id 加进菜品、订单、员工权限这些核心表中。每一步都小步快跑，在现有业务链路里验证后再做下一步，不要一次性铺开做大型功能，那样既容易失控，也不容易得到真实的业务反馈。
做点餐前后台系统，技术本身并不高深，真正的价值在于把订单状态、金额计算、库存扣减、文件存储这些基础环节做扎实。每个字段、每个状态、每个异常分支都提前想清楚，系统上线后才会少一些深夜被叫起来修 bug 的经历。
