企业官网建设流程全解析

1. 项目梳理：这套酒店点餐系统到底解决什么问题

这几年我经手过好几个餐饮类管理系统，从街边小馆的扫码点餐到连锁酒店的内部餐饮服务都接触过。后台私信里也一直有人问：酒店里的点餐系统和普通餐厅的点餐系统到底有什么区别？为什么有些项目看着功能齐全，上线后却没人愿意用？

趁着这次整理一个基于 Spring Boot + Vue 的酒店点餐管理系统，我把自己做这类项目的完整思路、踩过的坑、值得复用的套路一次讲清楚。这套系统不算复杂，但覆盖了一个典型的餐饮后台全链路：菜品管理、桌台管理、用户点餐、订单流转、支付对接、数据统计。它解决的痛点也很明确——酒店客房送餐和餐厅就餐长期依赖人工喊单、手写小票、口头传菜，高峰期漏单错单频发，月底对账全靠翻单据。用系统替换纸质流程，让前台、后厨、财务三端的数据打通，这个价值但凡在酒店餐饮干过的人都懂。

适合谁参考？如果你是正在做毕业设计、个人项目，需要一套结构清晰、能跑通前后端完整流程的餐饮系统代码，这篇文章能帮你省不少找方向的精力；如果你是刚转行做全栈开发、想了解 Spring Boot+Vue 这类主流组合在业务系统里怎么落地，可以重点看技术选型那一节；哪怕你只是想让代码更规范一点，后面关于接口设计、异常处理、状态机、JWT 鉴权的经验同样通用。

下面我把这套系统的设计骨架、核心模块实现、参数计算思路以及我实际测试中遇到过的问题全部展开。这不是教科书式的流程复述，而是我一个字一个字敲过、调试过、上线后还被运营提过需求的经验总结。

2. 系统设计与技术选型：为什么是 Spring Boot + Vue

2.1 业务建模先行，别急着写代码

很多人在做这类系统时第一反应是建表、写接口。我的习惯是先做业务建模，把酒店点餐的完整场景在纸上画一遍。酒店点餐和独立餐饮店有一个显著区别：住客既有在餐厅堂食的场景，也有在客房内打电话或扫码点餐的场景。这意味着用户的身份体系不能只围绕“到店顾客”设计，还要兼容“住客”这个角色。

我在设计这套系统时，把所有用户抽象成三类：管理员（酒店餐饮管理方）、收银/服务员（门店运营角色）、顾客（住客或到店散客）。桌台状态、订单状态、支付状态这三套状态机是系统的心脏，必须先定义清楚再动手。桌台我设计了空闲、占用、待清洁三个状态；订单从待支付、已支付/制作中、待配送/待上菜、已完成、已取消、退款中等状态流转；支付状态则单独维护，避免和订单状态强耦合。

为什么支付要单独拆开？因为实际业务里存在“先用餐后结账”“挂房账”“部分退款”这些场景，如果把支付和订单绑死，后面每次支付渠道调整都要改订单主流程，维护成本很高。这是我在第一个版本踩过的坑，这里先提醒你。

2.2 后端选型：Spring Boot 不是唯一答案，但确实最稳

这个项目最终采用 Spring Boot 2.7 + MyBatis-Plus + MySQL，理由很直接：Spring Boot 的生态成熟度、自动配置机制和社区资料量，对一个需要快速落地、后续可能增加功能的业务系统来说，学习成本和维护成本最平衡。

可能有人会问：为什么不直接用 Spring Cloud？单体应用阶段引入微服务是典型的过度设计。这套系统的并发量级，在酒店场景下通常在几十到几百人同时点餐，单体架构配合数据库连接池和 Redis 缓存完全能撑住。我见过太多个人项目因为追求“架构完美”，把 Nacos、Gateway、Feign 全套搬上来，结果部署时光修配置就花了两天，业务功能却没写几个。技术选型的核心逻辑是：先满足核心业务，再考虑极端扩展性。

MyBatis-Plus 的选择也同样务实。它把单表 CRUD、分页查询、逻辑删除这些高频操作封得很舒服，同时保留了手写 SQL 的能力——报表统计那块我照样用自定义 XML 写复杂 SQL，没有任何障碍。JPA 我也用过，但国内团队和多数开源项目对 MyBatis 系列的熟悉度更高，出问题好排查。

2.3 前端选型：Vue 3 组合式 API + Element Plus 的平衡点

前端我选的是 Vue 3 + Vite + Element Plus。为什么不是 Vue 2？Element Plus 和 Vue 3 目前生态已经完全成熟，组合式 API 对状态管理的组织方式比 Options API 清晰得多，特别是订单列表、购物车这种多组件共享状态的场景，用 ref/reactive 配合 Pinia 管理，比在 Vue 2 里写 mixin 舒服太多。

有人用 vue-element-admin 这类后台模板直接改，我不反对，但建议你先想清楚：这类模板自带权限体系、多标签页、动态路由，对个人项目来说一半功能你都用不上，但它们的复杂度会拖慢你的理解速度。我的做法是手搭一个轻量级后台框架，只保留路由、布局、Axios 封装、Token 管理、权限指令这几个核心模块。代码量不大，但是每一行都是自己写的，出了问题你能马上定位，而不是在一个几千星的模板源码里大海捞针。

Vite 的选型不用多解释，冷启动速度和热更新体验比 Webpack 时代强了一个量级。开发依赖和构建配置简单，还能对 Node 版本的要求极高，这一点后面部署章节我会单独说。

3. 数据库设计与核心模块拆分

3.1 表结构设计思路与关键字段

数据库我拆了这么几张核心表：用户表、菜品分类表、菜品表、桌台表、订单表、订单明细表、购物车表、支付记录表。另外为了报表统计方便，加了一张每日销售汇总表，由定时任务生成快照。

一张值得说的表是订单明细表。它不能只存菜品名称和数量，还要冗余下单时的单价、折扣价、备注，甚至菜品快照（JSON 字段）。为什么冗余这么多？因为菜品价格、名称会变，如果订单明细不保存快照，一个月后查历史订单时，看到的价格可能已经被最新菜品价格覆盖了，财务对账会对不上。这是餐饮系统里最经典的“历史数据一致性”问题，靠关联菜品表是解决不了的。

订单号我采用日期+自增序列+随机数的组合方案，比如20250614153000012345，前8位日期、6位时间和4位随机数。这个设计能避免并发下的重复订单号，同时方便按时间段模糊查询。很多人喜欢直接用自增 ID 当订单号，但只要订单号泄露，你的当日单量就暴露了，而且商品系统里自增 ID 很容易被爬虫遍历，所以我强烈建议业务主键和自增主键分离。

菜品表里我保留了一个 sort 字段用于排序，还有一个 status 字段控制上下架状态。这个简单设计在运营侧非常实用：套餐调整、时令菜品下架，不需要删数据，一个 update 就搞定，还保留了历史数据。逻辑删除配置在 MyBatis-Plus 里通过@TableLogic实现，所有查询默认过滤已删除记录。

3.2 接口模块划分：从 Controller 到 Service 的职责边界

后端接口我按业务域拆成了几个大模块：用户认证、菜品管理、桌台管理、点餐流程、订单管理、支付回调、数据统计。

每个模块的职责边界遵循一个原则：Controller 只做参数接收和结果封装，不写业务逻辑；Service 里放业务规则，事务边界划在 Service 方法上；Mapper 只做数据访问。这个三层结构听起来基础，但我确实见过不少项目在 Controller 里直接查库的写法，前期图快，后期维护哭都来不及。

举一个具体接口设计：POST /api/order/create创建订单接口。它的入参包含桌台ID、就餐人数、订单明细列表（菜品ID、数量、备注）、支付方式。Service 层的逻辑依次是：校验桌台状态、校验菜品是否在售、计算订单金额（含折扣规则）、生成订单主记录和明细记录、更新桌台状态。这四步必须放在同一个事务里，任何一个失败都要回滚，不能出现“订单创建了但桌台还是空闲”的状态不一致。

并发场景下的库存或菜品可用量怎么处理？我在菜品表加了一个 daily_limit 字段（每日限量），创建订单时使用UPDATE t_dish SET daily_limit = daily_limit - 1 WHERE id = ? AND daily_limit > 0这种带条件更新的写法，而不是先 select 再 update。这个操作利用数据库行锁天然避免了超卖问题，比 Java 层加锁靠谱得多。实测下来，即便几十个用户同时点同一道限量菜，也不会出现超卖。

3.3 用户端 H5 点餐页与后台管理的功能拆分

这个系统实际包含两个前端界面：用户点餐 H5 和后台管理端。H5 面向顾客，核心流程是选择桌台或房间号、浏览菜品、加入购物车、提交订单、支付；后台管理端面向管理员和收银员，核心流程是菜品维护、桌台状态管理、订单审核与派单、接单出餐、数据统计。

两个界面共用同一套 API，但权限边界差异很大。H5 端走的是微信小程序或手机浏览器，我用 JWT 做无状态认证，用户扫码时通过桌台码携带一个临时 token 自动登录，不需要输密码。后台管理端则采用账号密码登录 + RBAC 权限控制，管理员、收银员、后厨角色看到的菜单完全不同。

这里有一个容易被忽略的坑：H5 端如果直接用管理端的接口，会暴露大量敏感接口。所以我把接口按“端”做了隔离，用户端只暴露/api/portal/**前缀下的接口，管理端走/api/admin/**，在网关或拦截器层做白名单校验。这样就算用户篡改 token，也访问不了管理端的数据。

4. 核心流程实现：点餐到出餐的全链路细节

4.1 扫码点餐与桌台绑定的完整链路

用户在酒店餐厅扫码后，前端会解析二维码里的桌台编号，比如T-2F-08，同时向/api/portal/table/info发送请求，后端根据桌台编号查询状态并返回桌台的会话 token。这个 token 和用户 ID 是解耦的，只关联桌台维度，有效期默认2小时——超过2小时用户重新进入点餐页需要再次扫码，这个设计能有效防止占座不点单的情况。

桌台会话 token 我放在 Redis 里，key 是table_token:{tableNo}，value 是桌台信息。为什么要放 Redis？因为桌台状态会被收银员手动调整（比如并桌、换桌），如果把状态只存在 MySQL，那么频繁的写库操作会造成锁竞争；Redis 的原子性更新配合定期落库，性能和一致性都能兼顾。

点餐页的菜单是实时从后端拉取的，前端做了分类 Tab 和滚动加载。有个细节：每次加入购物车我都调用一次/api/portal/cart/add接口，而不是纯前端本地存储。为什么？因为顾客中途可能刷新页面、换设备继续下单，如果购物车数据只存在 localStorage，刷新就丢了。服务端保存购物车，配合用户 token，任何终端都能恢复购物车状态，这个体验提升非常明显，而且实现只多了一张表的事。

4.2 订单价格计算、库存扣减与事务控制

订单提交是整个系统最核心的接口，我把它拆成六个关键步骤，每一步都值得你细看：

1. 校验桌台状态是否空闲（已被占用的桌台不允许新创建订单）；
2. 从购物车读取菜品列表，逐条校验菜品状态、每日限量；
3. 按规则计算总价：单价 × 数量，叠加满减优惠（比如满300减30、会员95折），生成金额明细；
4. 扣减库存（带条件更新），写入订单主表和明细表；
5. 更新桌台状态为占用，记录开台时间；
6. 返回支付参数，前端拉起支付。

我把第2到第5步放在一个@Transactional方法里，传播级别默认 REQUIRED。这里有一个极易错的细节：如果在第4步扣库存时失败抛了异常，前面的校验和计算不会有副作用，但 Redis 里的购物车数据不能跟着回滚——因为 Redis 的操作不在事务管理范围内。所以我在购物车清理上做了补偿逻辑：事务提交成功后，再通过事务同步器（TransactionSynchronizationManager）在 commit 后执行清空购物车操作；如果事务回滚，购物车不清空，用户重新提交即可。这种“数据库事务 + 外部存储补偿”的思路，在分布式系统里到处都用得上。

价格计算时还有一个隐藏问题：浮点数精度。金额计算一定不要用 double/float，Java 后端我用BigDecimal，精度设为两位，运算模式用ROUND_HALF_UP。数据库字段类型用 decimal(10,2)，前端传给后端的金额参数后端一律重新计算，绝不信任前端传来的总价——前端传的总价只做展示参考，这个校验能防住绝大多数恶意刷单。

4.3 支付模块对接：从设计到沙箱实测

支付是这个系统里最容易出“看起来能用、一上线就崩”的模块。我采用对接通用支付网关的方式，之所以不用某一个支付平台的直连，是因为酒店用户可能来自不同渠道：有人用微信、有人用支付宝、还有境外用户可能用银行卡。对接一个支持多渠道的支付网关，把微信、支付宝、银联收拢到一套回调接口里，代码会清爽很多。

支付流程：用户在前端选择支付方式，后端生成预支付单（记录订单号、金额、渠道），调用支付平台下单接口获取支付链接或二维码，用户扫码后平台异步通知后端回调地址。回调接口收到通知后，先验签，再查单确认状态，最后更新订单状态和支付记录。

回调处理有一个必须遵守的原则：接口要做幂等处理。支付平台的回调可能重复推送，如果每次回调都执行“更新订单为已支付”的操作，第二次执行时订单已经是已支付，会造成状态混乱甚至重复发货。我的处理方式是：支付记录表设置唯一约束（订单号+渠道），回调时先尝试插入支付记录，如果插入冲突说明已处理过，直接返回成功响应，不再重复更新订单状态。这个方案比查状态再更新的“check-then-act”更稳，因为数据库唯一索引是强约束，并发下也不会出问题。

沙箱测试时我还特意走了几组异常数据：金额不匹配的回调、签名错误的通知、重复回调、订单号不存在的回调。前两种情况直接拒绝并记日志；重复回调靠幂等处理；订单号不存在说明有人伪造回调，记录风险日志并告警。对接支付平台时，强烈建议你把所有回调日志存全，出了问题拿日志和支付平台对账——这一步能在排查资金问题时帮你节省大量时间。

4.4 后厨出餐、配送状态与异常处理闭环

订单支付成功后，状态变为“已支付/待制作”。这里涉及一个角色分派问题：谁来处理这个订单？我的设计是：后厨大屏轮询“待制作”列表，厨师点击“接单”后状态变为“制作中”，出餐后点击“出餐”，状态变为“待上菜/待配送”，再由服务员或配送机器人送到对应桌台，点击“送达”后订单变为“已完成”。

这个流程里我加了一个超时机制：如果订单支付成功后15分钟内没有厨师接单，系统会自动通知管理员。实现方式不是定时任务，而是通过 Redis 的键过期事件监听——创建订单时设置一个order_timeout:{orderNo}的 key，15秒过期（测试时缩短），订阅 Redis key 过期事件触发检查。为什么不直接用定时任务扫全表？因为全表扫描在高并发下对数据库压力很大，而 Redis 键过期监听是精准触发，只处理“确实超时”的订单，效率高得多。

异常处理闭环是另一个不能省的环节。菜品售罄、后厨拒单、配送异常这些情况，单独改订单状态是不够的，必须给用户一个明确感知。我在订单表加了 cancel_reason 字段，记录取消/异常原因，前端在订单详情页直接展示。用户对“为什么会这样”的感知，直接决定了投诉率。

5. 权限安全与前后端联调细节

5.1 JWT 认证与刷新策略

认证方案我用的是 JWT + Redis 黑名单组合。登录成功后后端生成 access_token（有效期2小时）和 refresh_token（有效期7天）。前端 Axios 拦截器统一在请求头携带 access_token，后端拦截器校验签名和有效期。

这里有个业界常见的坑：JWT 是无状态的，一旦签发，在有效期内无法主动失效。用户改密码、账号被禁用、退出登录，这些场景都要求 token 立即失效。我的方案是把“需要主动失效的 token”的 jti（Token ID）写入 Redis，设置和 token 剩余有效期一致的 TTL。拦截器校验时先查 Redis 里有没有该 jti，有就直接拒绝。这个方案比维护服务端 session 省内存，同时比纯 JWT 更安全。详细解释一下：jti 黑名单放在 Redis 里而不是把整个 token 状态存 Redis，是因为一个用户可能同时存在多个有效 token（多端登录），只把被吊销的 jti 记下来，内存占用小，清理也方便。

5.2 接口权限控制与参数校验

管理端接口我使用自定义注解@RequirePermission("dish:edit")+ AOP 拦截器实现 RBAC 权限控制。用户登录后，后端从数据库查出该角色权限码集合，放入 ThreadLocal 缓存。AOP 拦截器在校验到注解后，从 ThreadLocal 取权限码判断是否放行。为什么用 AOP 而不是在拦截器里每次查库？因为接口调用的高频场景下，每次都查权限表会造成无谓的数据库开销，一次登录查询后缓存，权限变更时清理缓存即可。

参数校验方面，我引入 spring-boot-starter-validation，实体类字段加@NotNull、@Size、@DecimalMin注解，Controller 入参加@Validated。比如创建订单时，tableId不能为空、itemList不能为空且大小不超过50，quantity必须大于0、小于等于99。这些基础校验不要全部写在业务代码里，用注解声明式处理，业务代码重点处理跨字段、跨表的一致性校验，代码会干净很多。

5.3 跨域配置与 Axios 封装的实战细节

前端本地开发是localhost:5173，后端是localhost:8080，必然要处理跨域。后端统一配置 CORS，允许的来源我用白名单方式而非*，并且 credentials 设置为 true。注意：如果你既要跨域又要携带 Cookie，allowCredentials(true)和allowedOrigins("*")不能同时使用，这会被浏览器拒绝。正确的做法是allowedOrigins显式列出前端地址，或者使用allowedOriginPatterns("*")加allowCredentials(true)。

Axios 封装我有几个建议：

• 请求拦截器统一注入 token、添加请求时间戳；
• 响应拦截器统一处理 HTTP 状态码和业务状态码，比如后端约定{ code: 200, message: "success", data: ... }，业务错误 code 非200时，前端直接 ElMessage 提示；
• 401 状态码统一触发刷新 token 逻辑，刷新失败则跳转登录页；
• 下载文件的接口要设置responseType: 'blob'，否则返回的二进制流会被当作 JSON 解析，这是很常见的坑。

5.4 联调中的接口文档维护

前后端联调时，接口文档我选择 Apifox 管理，它支持导出 OpenAPI 规范，还能一键生成 Mock 数据。开发流程是：后端先定义接口文档，前端根据文档类型定义生成 TypeScript 类型，再开始写页面。接口变更时，文档同步更新，前端能立刻感知。这个流程极大减少了“接口字段名不一致”带来的扯皮。

这里分享一个我个人的习惯：每个接口的文档里，我会把异常场景列全。不仅写“成功返回什么”，还要写“菜品不存在返回什么、桌台被占用返回什么、库存不足返回什么”。因为前端真正难处理的不是正常分支，而是各种异常分支的提示文案和交互逻辑。文档里提前列清楚，联调时可以减少沟通成本。

6. 性能优化与部署上线实录

6.1 数据库索引优化与慢查询排查

系统联调后，我在一千多条菜品、三万多条订单的数据量下做了性能测试，发现一个明显问题：订单列表分页查询耗时接近 800ms，无法接受。用慢查询日志定位后，发现是订单状态查询条件status = 0 AND create_time BETWEEN ? AND ?没有走索引。

优化方案有三步：

1. 给order_status和create_time建联合索引idx_status_time(status, create_time)，因为查询条件是等值匹配 + 范围匹配；
2. 把订单明细表的order_id建普通索引，因为明细表的关联查询高频；
3. 报表统计那段 SQL 增加日维度分组，提前按天聚合，避免全表扫描。

优化后同一个页面查询耗时降到 120ms 左右，日常使用完全够。索引不是越多越好，每个索引都会拖慢写入速度，我只为高频查询字段建索引。

6.2 缓存策略：哪些数据适合 Redis

我用 Redis 缓存了三个部分：菜单数据（菜品分类+菜品列表）、桌台状态、token 相关会话。菜单数据几乎是只读的，菜品修改后通过管理端主动删除缓存，下次请求重新回源数据库，这个“Cache Aside”模式最简单可靠。

为什么菜单数据用 Redis 而不是本地缓存？因为这套系统会部署多实例（前端部署在一台、后端可能扩容到两台），本地缓存会导致两台机器数据不一致，用 Redis 集中管理，天然一致。缓存 key 的设计我采用menu:list:{categoryId}，失效时间设置30分钟，商品信息变更时删除对应 key。

6.3 后端打包与前端构建配置文件

部署我采用前后端分离方式。后端 Jar 包用 Maven 打包，关键要处理 application.yml 的环境配置：本地开发用application-dev.yml，生产环境用application-prod.yml，通过启动参数--spring.profiles.active=prod切换。数据库密码等敏感信息放入环境变量，而不是写死在配置文件中。

前端项目构建时，Vite默认构建到dist目录，其中/api开头的请求需要在生产环境通过 Nginx 反向代理转发到后端服务。Nginx 配置里有两个关键点：一是proxy_set_header Host $host，否则后端拿到的 Host 是内网地址，回调地址会错；二是 gzip 压缩开启，静态资源体积能减少 60% 左右。

构建 Vue 项目时有一个常见的 Node 版本兼容问题：Vite 需要 Node 14.18+（Vite 4 需要 16+），如果你机器的 Node 版本过低，安装依赖时会报 ERESOLVE 等错误。建议用 nvm 管理多个 Node 版本，切换到所需版本后再跑npm install。

6.4 Docker Compose 一键部署的实践

为了减少环境差异导致的问题，我写了 Docker Compose 文件，把 MySQL、Redis、后端应用、前端 Nginx 四个容器编排在一起。前端 Nginx 镜像里，我用多阶段构建：第一阶段用 Node 镜像构建静态文件，第二阶段用 Nginx 镜像拷贝 dist 目录并写入 nginx.conf。这样部署只需要在服务器上执行一条docker compose up -d，资源也少占用，非常省心。

需要注意的一个坑：容器内 MySQL 的数据卷要挂载到宿主机，如果容器删了重建，数据不会丢。/var/lib/mysql目录务必映射出来。第一次启动时，数据库初始化和数据导入我放在/docker-entrypoint-initdb.d/目录下，MySQL 容器首次启动会自动执行该目录下的 SQL 脚本，后续启动不会重复执行。

7. 测试要点与常见问题排查

7.1 核心功能测试用例设计

功能测试我按两个维度设计：正常流程和异常流程。正常流程包括：用户选菜加入购物车并下单支付，订单状态按预期流转到已完成；管理员上下架菜品，用户端菜单实时刷新；桌台换桌、并桌后订单关联对应桌台。异常流程包括：库存不足时下单是否被拒绝、桌台已占用时是否还能下单、支付回调重复推送是否幂等、token 过期后访问接口是否返回 401。

测试数据我建议先构造一万条量级的测试数据，用 Jmeter 或 Postman 做并发测试，而不是只用一两条数据验证接口通不通。并发场景下更容易暴露接口的并发安全问题。

7.2 高频问题速查与解决实录

我在联调阶段遇到并解决过这些问题，整理出来供你排雷：

7.3 安全加固与上线前检查清单

上线前我做了一次安全自查，以下几点是你也应当注意的：

• 所有接口在网关层统一做限流，防止恶意刷接口；
• 密码加密使用 BCrypt，不能使用 MD5（MD5 已经被彩虹表攻破）；
• 管理端接口启用操作日志记录，谁改了价格、谁下架了菜品都有记录；
• 前端隐藏敏感字段，如支付回调地址、密钥绝对不进入前端代码；
• 数据库备份脚本每周执行一次，备份文件异地保存。

8. 这版项目做完，我后续想扩展的方向

如果你也想在酒店点餐系统基础上继续完善，有几个方向我提前帮你踩过规划：

接入小程序端可以把客房扫码点餐体验做得更轻，跟公众号打通还能做会员积分；对接酒店 PMS 系统实现挂房账、房态联动，能进一步减少前台操作；出餐单打印、小票自动打印也需要接上热敏打印机协议；后厨 KDS 大屏的排队算法、压单预警也值得深入优化。

从我个人的角度说，做管理系统这类项目，最大的收益不是学会某个框架API，而是把业务规则、状态流转、异常处理这些“看不见的设计”想透彻。功能能跑起来是第一步，能在并发和异常条件下依然不出错，才是系统真正能上线使用的关键。这类经验没有捷径，只能靠一次次测试、排查、复盘才能沉淀下来。希望这篇关于 Spring Boot + Vue 酒店点餐管理系统的分享，能帮你少走几步冤枉路。