yshop点餐系统实战：多租户架构与扫码点餐部署全指南

简介yshop意象点餐系统是一套基于Java与uniapp(Vue3)的前后端分离扫码点餐解决方案覆盖外卖与自取、多门店、SaaS多租户等常见餐饮场景适合企业快速上线点餐小程序或开发者进行二次开发。系统采用SpringBoot、Spring Security OAuth2、MybatisPlus、Redis等主流技术栈前端支持H5与微信小程序业务功能涵盖商品多规格SKU、店铺管理、云小票打印、订单管理、积分与充值、优惠券、拼团、分销商、会员卡等模块比较完整。资源包共2005个文件压缩后约17.63MB其中Java源码约1324个对应后端业务逻辑Vue文件257个用于管理端和移动端页面另有JS脚本、HTML/CSS、SQL初始化脚本、Markdown说明文档等便于按模块阅读和改造。当前已有149人学习下载适合具备一定Java基础、需要餐饮电商系统参考实现或希望快速搭建多门店点餐平台的开发者使用。1. yshop意象点餐到底是个什么项目一次说清它能帮你省掉哪些自研成本如果你的客户是中小餐饮老板需求就三句话顾客扫桌码下单、后厨自动接单、支持自取和外卖。这套流程看起来简单但从零自研后端要管门店、菜品、桌台、订单、支付、打印机对接前端还要出一套能在微信里跑的扫码点餐小程序没有一两个月的开发量下不来。yshop意象点餐正是把这个闭环打包好的开源方案Spring Boot 后端 uni-app 小程序端内置外卖与自取两种履约模式数据模型同时支持多门店和 SaaS 多租户。对想快速交付的接单开发者或准备做餐饮 SaaS 的创业团队它最大的价值不是省掉写代码的时间而是把“订单状态机、支付回调、桌台二维码”这些容易出错的地基提前铺好了。这篇笔记按我实际部署和二次开发的顺序从数据模型讲到支付回调再给你一份我踩过的坑清单。2. 拿下多租户与多门店数据模型和权限隔离才是这套系统的地基很多点餐项目做到后面翻车不是功能不够而是订单和门店数据混成一锅粥。yshop 这类系统能撑起 SaaS 模式核心在于它把“谁家的数据”和“哪个门店的数据”做了两层区分。这一章先讲清楚多租户的常见落地方式再给出一套可以直接抄的数据模型和拦截配置。2.1 多租户的三种落地方式为什么共享表租户ID最常见多租户在业界有三种做法独立数据库、共享数据库独立 Schema、共享表加租户字段。独立数据库隔离最彻底但一套系统要维护几十套库表结构升级迁移都是体力活共享 Schema 在 MySQL 上运维成本也不低。真正让 SaaS 点餐系统跑得轻快的是第三种所有商户共用一套表每张业务表加一个tenant_id字段查询时由框架自动把当前登录租户的 ID 拼进 SQL。这套方案的优势很直接新增租户不需要建库建表部署一套就能服务几百个商户代价是必须保证“每条 SQL 都带租户条件”漏一条就是越权事故。常见做法是在项目里引入 MyBatis-Plus 的TenantLineInnerInterceptor由统一拦截器在解析 SQL 时自动追加tenant_id ?条件而不是靠每个开发人员手写 where。拦截器配置我习惯这样写Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new TenantLineInnerInterceptor(new TenantLineHandler() { Override public Expression getTenantId() { // 从当前请求上下文中取租户ID没有则抛异常 Long tenantId TenantContext.getTenantId(); if (tenantId null) { throw new RuntimeException(未获取到租户ID); } return new LongValue(tenantId); } Override public boolean ignoreTable(String tableName) { // 系统配置表、字典表等全局表不追加租户条件 return ignoreTables.contains(tableName); } })); return interceptor; } }这段配置里TenantContext是自定义的 ThreadLocal 持有者登录成功后由拦截器把租户 ID 写入请求结束再清理避免线程池复用导致串号。ignoreTable里我一般放sys_user、sys_dict、tenant这类本身就是全局配置的表。注意不要为了让“省事”把所有表都加进忽略清单那就等于没做隔离。配置完成后每次改动业务代码我都会打开 SQL 日志确认真正执行的条件这个习惯后面避坑章还会再提。2.2 多门店如何挂进租户体系门店表、桌台表与数据权限拦截多租户解决的是“商户 A 看不到商户 B”多门店解决的是“同一个商户下门店 1 的订单不能出现在门店 2 的报表里”。yshop 的数据模型把这层关系做成两级tenant_id标识数据归属哪个商户shop_id标识归属哪个门店。菜品、订单、桌台这些表同时携带两个字段查询时用数据权限拦截器按当前操作人的门店范围追加条件。门店与桌台的表结构我一般这样设计tenant租户表记录商户名、套餐类型、到期时间。shop门店表归属租户、门店名、联系电话、营业时间、经纬度。shop_table桌台表归属门店、桌号、二维码内容、座位数、当前状态。product菜品表归属门店含分类、名称、价格、图片、是否上架。order_info订单表归属租户和门店含就餐方式、支付状态、履约状态。操作员与门店的关系走关联表一个管理员可以管多个门店。数据权限拦截我用 MyBatis-Plus 的DataPermissionInterceptor处理跟租户拦截器叠加使用核心规则是如果当前用户不是总部管理员SQL 里自动追加shop_id IN (用户管辖的门店集合)。private DataPermissionInterceptor dataPermissionInterceptor() { DataPermissionInterceptor interceptor new DataPermissionInterceptor(); interceptor.setDataPermissionHandler(new DataPermissionHandler() { Override public Expression getSqlSegment(Table table, Expression where, String mappedStatementId) { if (skipTable(table.getName())) { return where; } if (!StaffContext.isAdmin()) { // 非管理员只能看自己门店的数据 return new AndCondition(where, new InExpression( new Column(shop_id), staffManagedShopIds())); } return where; } }); return interceptor; }这里的关键是staffManagedShopIds()不要每次查询都查一遍库我一般在用户登录后把管辖门店 ID 集合缓存到 Redis拦截器直接从缓存取避免高频接口产生额外 DB 压力。扫码点餐的入口也依赖这张门店表桌台二维码内容通常是?shopId17tableNo8小程序扫码后解析出这两个参数请求菜单接口时带上后端就能锁定是哪个门店的哪张桌。订单归属自然落到门店上报表按门店维度汇总不会乱。3. 本地部署第一个点餐小程序从拉代码到小程序端能点单的完整参数配置光看架构还不够你大概率是想先把它跑起来。这一步我建议别急着改业务代码先按最小链路走通后端启动 → 小程序跑起来 → 扫码点单提交成功。全程大约需要一小时但前提是配置别踩坑。3.1 后端启动前需要配好的 application.yml数据源、缓存、文件与微信支付yshop 这类 Spring Boot 项目启动前的配置集中在application.yml。按我的习惯必改的就四处MySQL 数据源、Redis 缓存、文件存储、微信支付参数。spring: datasource: url: jdbc:mysql://127.0.0.1:3306/yshop?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: yshop password: your_password driver-class-name: com.mysql.cj.jdbc.Driver redis: host: 127.0.0.1 port: 6379 database: 0 password: # 文件存储本地路径即可生产环境建议换成 OSS 或 MinIO file: upload-dir: /data/yshop/upload access-prefix: http://127.0.0.1:8080/files # 微信小程序与支付配置 wx: appid: wx你的小程序appid secret: 你的小程序secret mch-id: 微信支付商户号 mch-serial-no: 商户证书序列号 api-v3-key: APIv3密钥 notify-url: https://你的域名/api/wx/notify数据源里serverTimezone一定要设否则高版本 MySQL 驱动会在时间字段上报错。Redis 没配密码时password留空即可但生产环境必须设。文件上传路径建议用绝对路径不要用相对路径否则服务重启后目录漂移小程序端图片全部裂掉。微信支付参数最容易抄错的是mch-serial-no它不是商户号是商户证书的序列号在微信支付商户平台的 API 安全里能找到。如果只做扫码点餐不做在线支付也可以先不配支付用“先下单后付款”的流程联调。3.2 小程序端 uni-app 的 3 处关键配置请求地址、appid 与安全域名小程序端基于 uni-app 开发能同时编译到微信小程序。跑起来之前必须改三处请求接口的baseUrl、manifest.json里的微信 appid、微信公众平台的合法域名。请求地址封装我一般放config/index.js不要散落在每个页面里export const BASE_URL http://127.0.0.1:8080/api; // 开发环境 // export const BASE_URL https://your-domain.com/api; // 生产环境 export function request(path, method GET, data {}) { return new Promise((resolve, reject) { uni.request({ url: BASE_URL path, method, data, header: { X-Tenant-Id: uni.getStorageSync(tenantId) || , X-Token: uni.getStorageSync(token) || }, success: (res) resolve(res.data), fail: reject }); }); }X-Tenant-Id这个 header 建议一开始就预留。你在本地单租户模式下可能用不到但后期上 SaaS 模式小程序端需要知道自己属于哪个租户微信登录返回时后端会把租户 ID 带给前端。提前在请求封装里加好省得后面四处改代码。manifest.json里填mp-weixin.appid这是小程序能在开发者工具里正常启动的前提。第三处是合法域名微信开发者工具里可以勾选“不校验合法域名”来绕过联调限制但真机预览和正式上架必须在微信公众平台后台把 HTTPS 接口域名加进 request 合法域名。这里提醒一句本地 HTTP 地址真机上是调不通的想真机测必须用 HTTPS常见做法是用 Nginx 反代理到本地后端配一张证书。3.3 扫码点餐的完整链路先让一张桌台在小程序里可点单配置完成后我习惯先在数据库里手工插入一张测试桌台而不是直接走后台管理界面。为什么因为后台的桌台管理界面往往依赖门店和员工权限初次跑通时容易混入权限问题手工插入能更快定位到扫码链路本身。-- 先建一个测试租户、门店和桌台 INSERT INTO tenant (id, name, status) VALUES (1, 演示商户, 1); INSERT INTO shop (id, tenant_id, name, address) VALUES (1, 1, 意象测试店, 测试路1号); INSERT INTO shop_table (id, shop_id, table_no, qr_content, status) VALUES (1, 1, A01, ?shopId1tableNoA01, 0);小程序端拿到扫码参数后把shopId和tableNo传给菜单接口后端根据这两个参数找到门店和桌台再返回门店下的上架菜品列表。这一步能通说明数据库连接、租户拦截器、门店查询三层都没问题。菜单接口返回的数据结构建议保持“分类 菜品”的嵌套格式小程序端点餐页直接按分类切换可以减少一次查询。菜品数据结构大致是{ categoryId: 10, categoryName: 招牌菜, products: [ { productId: 1001, name: 口水鸡, price: 32.00, stock: 50, imageUrl: /files/2024/01/chicken.png } ] }如果小程序端图片加载不出来先检查file.access-prefix是否和 Nginx 静态资源路径一致IMG 标签拼出的完整 URL 直接在浏览器里打开看能通就说明是缓存问题简单换个时间戳参数就好。这一步跑通后你的本地开发环境已经具备完整的点餐闭环。4. 让订单真正跑起来堂食/自取/外卖三条履约链路和支付回调设计扫码下单只是第一步真正容易出问题的是下单之后的履约流转。堂食要通知后厨出餐自取要算好取餐时间外卖要走配送逻辑。这三条链路在数据模型上必须从一开始就分清楚否则后面越改越乱。4.1 订单来源与履约状态机设计yshop 的订单表核心字段包括order_source、order_status、table_no、expected_time。order_source我建议用数字枚举而不是字符串查询和索引都更快推荐这样定义枚举值含义履约要点10堂食扫码绑定桌台随时加菜20自取记录预计取餐时间30外卖记录配送地址与配送方式堂食订单的用户体验重点在“加菜”和“结账”。一桌顾客可能分多次下单订单要以桌台为主键聚合而不是扫码一次生成一单。常见做法是桌台首次下单生成主订单后续加菜挂到同一订单下后厨打印机按“桌台 批次”出单。自取和外卖的核心是时间管理。自取需要前端选择取餐时间后端校验不能选过去的时间点外卖则要记录收货地址和联系方式。我见过不少项目把这三个状态混在一个remark字段里后续统计分拣全凭运气。正确做法是建一个独立的delivery_address关联表只在外卖单时写入堂食和自取不落这个数据避免表里大量空字段。订单状态机我这样流转所有状态变更走同一个事务方法public void changeOrderStatus(Long orderId, Integer targetStatus) { OrderInfo order getById(orderId); // 校验非法流转已完成的订单不允许改到待支付 if (!canTransit(order.getStatus(), targetStatus)) { throw new BizException(订单状态不允许从 order.getStatus() 变更为 targetStatus); } // 实际更新加乐观锁版本号防止并发重复提交 boolean updated lambdaUpdate() .eq(OrderInfo::getId, orderId) .eq(OrderInfo::getVersion, order.getVersion()) .set(OrderInfo::getStatus, targetStatus) .set(OrderInfo::getVersion, order.getVersion() 1) .update(); if (!updated) { throw new BizException(订单状态已变更请刷新); } }状态机判断表建议单独维护不要散落在业务代码的if-else里。状态机至少定义这些节点待支付 → 已支付/待接单 → 制作中 → 待取餐/待配送 → 已完成外加一个“已取消”旁路。每一步的触发方不同比如“支付回调”触发待支付到已支付“后厨出餐”触发制作中到待取餐“顾客取走”触发待取餐到已完成。4.2 支付与回调的幂等设计支付回调和网络重试是点餐系统最常翻车的地方。微信支付的回调可能因为网络原因推送多次且顺序不一定如果回调处理不做幂等会出现订单被重复置为已支付甚至库存被扣两次的问题。幂等的关键在数据库层加唯一约束而不是靠业务判断。回调处理的推荐逻辑分三步先验签再查单最后状态机变更。代码如下public String handleWxPayNotify(PayNotifyVO notifyVO) { // 1. 验签失败直接返回失败微信会重试 if (!wxPayService.verifyNotifySign(notifyVO)) { return FAIL; } // 2. 以微信支付单号查本地订单保证同一次支付只处理一次 OrderInfo order findOrderByTransactionId(notifyVO.getTransactionId()); if (order null) { return FAIL; } // 3. 幂等处理只有待支付状态才允许变更为已支付 boolean success changeOrderStatus(order.getId(), OrderStatus.PAID); return success ? SUCCESS : SUCCESS; }这段代码有个容易被忽略的点第 3 步如果订单已经是“已支付”状态机校验会抛异常但回调返回还是SUCCESS。因为微信只需要知道“你的业务处理成功”不需要知道“这个单子被重复通知了”。不这样处理微信会一直重试回调日志里全是异常告警。回调里的transaction_id必须在订单表建唯一索引这是防重复处理的底线。我见过有人只在代码里判断订单状态结果两台应用服务器同时收到回调都认为订单是“待支付”都去更新最终出现重复支付退款纠纷。加了唯一索引后第二次更新直接报错异常处理里捕获后照样返回SUCCESS问题就被数据库挡住了。5. 避坑清单从租户越权到支付回调的 5 个实战踩坑记录5.1 租户 ID 没拼进 SQL商户 A 看到了商户 B 的订单现象商户 A 登录后订单列表里混入了其他商户的数据甚至能直接对不属于自己的订单操作。原因多租户拦截器只对 XML 里mybatis-plus自动生成的 SQL 生效手写的Select注解 SQL 或自定义 Mapper XML 没带tenant_id条件。我排查过一次发现开发在 Mapper 里手写了一条关联订单和菜品的 join漏了租户条件。解决改造分两步。第一步排查所有手写 SQL逐条确认拦截器是否覆盖拦截器无法覆盖的在 SQL 末尾手动拼AND tenant_id #{tenantId}。第二步把排查规则固化到代码评审清单里并在本地环境开启 SQL 日志打印每次测试后肉眼确认关键 SQL 都带租户条件。学到最深刻的一招不要相信任何人的自觉只相信日志和唯一索引。5.2 扫码点餐的桌台状态成了黑匣子现象堂食用户扫码后显示桌台已被占用或者明明没人买单后台永远显示占用中。原因桌台状态被前端维护在本地没有随着订单状态同步更新。顾客下单后前端把桌台置为“占用”但顾客没正常结账直接走人状态就一直停在占用。解决把桌台状态改成由后端根据订单实时计算核心是“活跃订单 桌台状态”双写。订单完成或取消时事务内同步更新桌台状态为“空闲”。管理员在后台看到“占用中”的时间超过某个阈值比如 3 小时允许手动重置桌台重置时先校验该桌台没有未完成订单防止误操作导致后续下单混乱。5.3 自取单的“预计取餐时间”跨天就崩现象顾客在 23:50 下单自取选了第二天 00:30 取餐结果系统报错“取餐时间不能早于当前时间”。原因前端传入的时间格式只有HH:mm没有带日期后端统一用当天日期拼接过了零点自然变成过去时间。解决小程序的自取时间选择器必须提交完整的日期时间戳yyyy-MM-dd HH:mm:ss不要只传时分。后端校验时和前端的取值逻辑保持一致取操作里还有另一类坑LocalDateTime.now()在服务器时区与用户时区不一致时会导致明明合理的预约时间被判定为过去时间。上线前把服务器时区统一设置为Asia/Shanghai并在 JVM 启动参数里显式指定。5.4 支付回调里订单状态重复流转现象用户支付成功后后厨打印了两张相同的订单小票或者库存扣了两次。原因回调处理方法和用户手动刷新订单状态的接口同时触发两个请求同时读到“待支付”都向状态机发起了变更为“已支付”的操作兜底的异常处理把第二条请求也当成了成功。解决状态机的乐观锁版本号在这里只是第一道防线最终以数据库唯一索引为准。给订单表加一个transaction_id唯一索引第二次更新直接报DuplicateKeyException事务回滚不产生脏数据。另外把“后厨打印”的动作从订单状态变更的同步逻辑里挪到事务提交之后的异步消息队列避免一次打印失败拖住整个状态流转。5.5 小程序端登录态过期后接口静默失效现象用户打开小程序正常点菜单时接口报 401但看不到任何提示页面一直空转。原因微信小程序wx.login获取的 code 换取的 session_key 有有效期过期后后端校验 token 失败返回 401但前端请求封装里没做统一拦截处理。解决request封装里对 HTTP 401 做统一处理清除本地缓存 token跳转引导用户重新授权而不是把错误直接吐给页面。实际开发中我用一个独立的auth.js统一管理wx.login、token 存储和刷新逻辑页面里不直接调用wx.login。开发版小程序过期时微信开发者工具通常会提示重新扫码这是开发环境的正常现象不是代码问题遇到先别慌着查后端。6. 进阶把单店项目改造成 SaaS 多租户的 4 个动作以及上线前必须做的验证如果你拿到的源码是单店版或者你准备基于 yshop 的核心逻辑做一套自己的 SaaS 点餐平台改造思路其实比想象中收敛。核心就是四步加租户字段、加租户拦截器、改造登录链路、隔离套餐能力。第一步所有业务表增加tenant_id字段历史数据统一迁到默认租户下。第二步启动 MyBatis-Plus 的租户拦截器按第 2 章的配置实现TenantLineHandler。第三步登录接口在返回 token 的同时返回租户信息前端把租户 ID 存到本地后续所有请求用 header 带上。第四步套餐能力用一张租户套餐表控制比如“基础版只能开 1 家门店专业版开 10 家”在小程序端和后端接口双重校验。改造完成后强烈建议做一轮隔离验证不要只测“能登录-- 用租户A的token调用订单列表后手动检查执行日志里有没有租户B的ID -- 如果日志里出现说明拦截器漏了 SELECT id, tenant_id, order_no, amount FROM order_info WHERE tenant_id 1; -- 确认索引 SHOW INDEX FROM order_info;我习惯的做法是准备两个测试商户 A 和 B用 A 的 token 调所有核心接口遍历返回数据确保没有一条 BV 的tenant_id出现。接口不多半小时能跑完。这个验证值得做扎实上线后租户数据越权是最高危的事故。压测也别省略。重点测“下单 支付回调”链路用并发 30 个请求同时提交订单观察库存扣减是否准确、订单编号是否重复。数据库层面提前给order_info的订单号字段加唯一索引这是应对高并发重复的唯一底牌。支付回调再压一次看重复回调下订单状态是否仍然只流转一次。最后是我的一个个人习惯每个迭代上线前全局搜索delete from和update语句确认都带租户条件。这不是对同事不信任而是这类 SQL 一旦漏条件影响是跨商户的事后修复成本远高于每次上线前花五分钟检查的成本。做 SaaS 点餐这些年我见过太多项目死在数据隔离和并发幂等这两个问题上yshop 把基础铺好了剩下的续写要看你的工程习惯。希望帮到你。本文还有配套的精品资源点击获取