上海大学 2026 届毕业设计

点点餐 · BiteGo

面向中小餐饮商户与连锁品牌的多人协同扫码点餐系统 从「扫码 → 同桌一起点 → 后厨实时收单 → 后台经营」打通完整链路。

  • 桌台多人协同
  • 三层规格 / SKU
  • 三层多租户
  • 分层缓存与实时性
+
实时同步 · 同桌 3 人
¥订单 #T03-007 已提交

为什么做这件事

堂食扫码点餐,被现有方案漏掉的三件事

美团 / 饿了么主打外卖配送,对中小餐饮的堂食场景覆盖薄;通用模板能跑,但跑不出协同与连锁这两个真实需求。

核心亮点

四个工程级实现,把堂食扫码点餐做到能交付

每张卡都对应一篇核心实现文档,配论文里同款的手绘流程图。

  1. 01 同桌多人实时一致性

    桌台多人协同购物车

    WebSocket 桌台共享购物车 + cart.version 乐观并发 + opId 幂等键,弱网与同桌并发写入不会重复扣减或丢失变更。

    • 进程内 Map<tableId, Set<Client>> + Redis Pub/Sub 跨进程广播
    • opId 幂等键去重 / cart.version 乐观锁解决并发覆盖
    • 订单广播 ORDER_CREATED / 维护态 MAINTENANCE_CHANGED 分别覆盖不同时序
    多人协同点餐时序图
  2. 02 电商类目级的复杂规格

    规格 / 价格 / 库存三层商品模型

    库存规格组按笛卡尔积自动生成 SKU;非库存规格通过 priceItemKey 在购物车与订单中独立计费、合并同款,支持电商级规格组合。

    • 库存规格组 → SKU 笛卡尔积 + 行级悲观写锁防超卖
    • 非库存规格 → priceItemKey 合并同款,免膨胀
    • 价格全链路存 cents (bigint) + priceTransform 中间件双向转换
    三层规格模型
  3. 03 独立门店与连锁经营统一抽象

    平台 / 租户 / 门店三层多租户

    AdminScope 多对多授权 + 角色 rank 比较 + canManageSharedCatalog 动态计算位,实现「角色层级 + 共享菜单写权限」语义;连锁租户共享菜单、分店独立维护库存。

    • SUPER_ADMIN / TENANT_ADMIN / STORE_ADMIN 三级角色层级
    • SINGLE 与 CHAIN 两类租户共用同一套授权模型
    • 客户端 X-Tenant-Id / X-Store-Id / X-Board 仅声明意图,服务端实时核对 AdminScope
    多租户三层模型
  4. 04 五层缓存 + 推拉结合

    分层缓存与梯度实时性

    浏览器 / CDN / 进程内 / Redis / WebSocket 五层缓存按数据热度与时效性分级;读多写少走 ETag 协商缓存,必须即时感知的购物车与维护态改走 WS 主动推送,绕开缓存滞后。

    • 静态资源 COS + CDN + 浏览器 Cache-Control 三层联动,命中即免回源
    • 微信 access_token / 维护态走进程内 Map + Redis 双层,分布式锁防击穿
    • 桌台购物车 / 订单 / 维护态变化以 WS 推代拉,绕开 ETag 与 CDN 滞后
    分层缓存架构

实机截图

三端真实运行:小程序 / H5 顾客端、Web 管理后台

小程序双屏拼图呈现一段交互,Web 管理后台覆盖平台 / 租户 / 门店三视角。点击任一张可放大查看;左右键切换、Esc 关闭。

小程序 / H5 顾客端

每张图为左前右后两屏拼接,呈现一段完整交互(如菜品详情 → 规格选择)。

首页与历史订单
首页 + 跨桌台历史订单
首页扫码入桌 + 历史订单跨桌台聚合
入桌与点餐主页
入桌二次确认 + 点餐主页
入桌前展示桌位 / 同桌人数 / 维护态
菜品详情与规格选择
菜品详情 + 规格选择
规格组合实时计算价格与库存
协同购物车与提单
桌台协同购物车 + 提单确认
同桌成员实时同步购物车 / 提单分摊
本桌订单与详情
本桌订单 + 订单详情
上菜进度实时推送 / 申请退款流程

Web 管理端:平台 / 租户 / 门店三视角

同一套界面通过 X-Board 头切换视角,权限由后端实时核对 AdminScope 决定。

平台概览
平台概览
跨租户运营卡片 / 维护态总控
门店概览
门店概览
桌台总览 + 活跃订单 + 全量订单
菜品管理
菜品管理
列表 + SKU 行展开 / 库存状态联动
编辑菜品
编辑菜品
基础信息 + Markdown 详情双栏
桌台管理
桌台管理
小程序码 + H5 二维码 + 强制清台
租户管理
租户管理
单店 / 连锁两类租户切换
分类管理
分类管理
拖拽排序 / 共享分类下放
订单管理
订单管理
订单状态机 / 退款审核

更多截图(规格管理、租户概览、平台门店列表等)见 完整截图集 →

系统架构

四层逻辑、四条信任边界,业务真相收口在数据库

前后端分离的三端架构:所有重要的写入都收口在数据库事务里;Redis 把锁、广播、缓存抽出来做公共逻辑;客户端声明的租户与门店信息仅作为意图,授权由服务端实时核对。

BiteGo 系统总体架构图
L1

客户端层

微信小程序 / H5 + Web 管理端

Taro 4 + React 双端编译;MUI + Vite 后台

L2

接口层

Express REST + 两路 WebSocket

公共中间件链统一收口鉴权、幂等、维护态、价格转换

L3

业务逻辑层

目录 / 订单 / 桌台 / 同步 / 维护 / 微信

以「能力」聚合,通过 TypeORM 事务 + Redis 总线解耦

L4

数据持久层

MySQL 8 + Redis 6.2 + COS

MySQL 业务真相源;Redis 仅承载可重建状态;COS 承载图片与导出快照

技术栈

三个子项目 + 基础设施,技术栈按职责分组。

后端服务

projects/backend
Node.js 20TypeScript 5Express 4TypeORMMySQL 8Redis 6.2ws · WebSocketJWT

Web 管理端

projects/web-admin
React 18TypeScript 5Vite 5Material UIReact Router 6TanStack QueryZustandAxios

顾客端(双发)

projects/miniprogram
Taro 4React 18TypeScript 5SassZustandVitestPlaywright (H5)

基础设施 / 部署

ci/ + .github/workflows/
Docker ComposeGitHub Actions腾讯云 LighthouseCOS + CDNTCRc8 · 覆盖率门禁

工程证据

「能跑」做到「能交付」的几个硬指标

后端集成测试为主的质量门禁、三端独立流水线、五层缓存的梯度实时性 — 把「能跑」做到「能交付」。

0
后端集成用例
node --test 真实 HTTP + WS Server + MySQL + Redis 全过
0.00%
后端行覆盖率
行 / 语句 / 函数三个维度 ≥ 90% 阈值
0
端 CI / CD 流水线
backend / web-admin / miniprogram 主干合并自动上线
0
层缓存与实时性梯度
浏览器 / CDN / 进程内存 / Redis / WebSocket

单台轻量云服务器 + CDN/COS,撑起三端运行时

后端 Node.js + MySQL 8 + Redis 6.2 全部在一台腾讯云 Lighthouse 上由 docker-compose 起;小程序 H5、Web 管理端、Landing 三套静态产物直接发到腾讯云 COS,由 CDN 做边缘缓存与回源;图片、二维码、论文 PDF 也走同一套 COS。

  • 前端纯静态走 CDN,命中后零回源、毫秒级响应
  • 后端镜像推到腾讯 TCR,远端 SSH 拉取后蓝绿重启
  • 数据库与缓存与后端同机部署,省去跨机延迟与公网带宽
BiteGo 部署拓扑图
CI/CD 流水线

三端独立流水线,一次主干合并即上线

后端:Docker 镜像 → TCR → SSH 远程拉镜像 + 蓝绿重启;Web 管理端 / 小程序 H5:dist 推 COS + CDN 刷新;论文:Typst 编译 → 上传 latest.json 指针。后端集成测试 + 90% 覆盖率门禁与 lint 一并卡在 CI。

  • 真实 MySQL + Redis + HTTP / WS Server 起集成测试
  • yarn test 自动快照恢复,避免数据污染
  • lint --max-warnings 0、行 / 语句 / 函数覆盖率 ≥ 90%

资源

想看得更深?这些是入口

从论文 PDF、18 篇技术与产品文档、实机截图集到 GitHub 源码,每一条入口都可以独立打开。