酒吧扫码点单系统：业务建模、弱网处理与高可用落地

酒吧这个场景，我前前后后跟过几个项目，从最早的"扫码跳 H5、吧台拿本子记"的半手工模式，到后来正经做小程序点单系统，中间踩的坑比想象中多得多。很多人一上来就问"用哪个框架""后端选 Go 还是 Node"，但真正决定这套系统能不能在店里活下来的，往往不是这些。酒吧点单和餐厅扫码点餐看起来像同一件事，实际业务模型差得远：桌台会并、会转、会存酒，客人会分单、会挂账、会临时加一轮；营业高峰集中在晚上十点到凌晨一点这四个小时，流量不是平的，是尖的；现场灯光暗、音乐吵、Wi-Fi 拥挤，用户耐心极低，一次转圈超过五秒就会喊服务员。

所以这篇东西我打算按真实的推进顺序讲：先把业务模型掰开，再谈技术选型和数据建模，最后落到现场部署、弱网处理、硬件对接和上线保障。适合正在评估要不要自研一套点单系统的小团队、准备接手这类项目的开发者，也适合店里已经有系统但天天被投诉"下单慢""漏单""打不出小票"的运营方对照排查。代码和配置我会给到能直接抄的程度，但更想讲清楚每一步为什么这么选。

1. 先把业务模型掰开，再谈技术选型

技术选型错了可以重写，业务模型错了要推倒重来。我见过一个团队花了两个月把扫码点单做得挺漂亮，结果上线第一周就被店里否了，原因特别朴素：他们的系统里一张桌子对应一个订单，而这家店的实际玩法是两桌客人拼一个大卡座，要求分开结账。这一条就把订单表的主键设计全推翻了。

1.1 三个把预算拖垮的差异点

桌台不是静态资源，是会流动的。餐厅的桌号基本固定，一桌一单，吃完清台。酒吧不一样：开台、并台、转台、拆台、清台，中间还夹着"存酒"——客人今晚喝不完的整瓶酒存在店里，下次来凭手机号或者会员码取。这意味着桌台需要一套状态机，而不是一个 is_occupied 布尔字段。并台的时候两个桌台的账单要合并，转台的时候订单要跟着人走，存酒的时候库存要从"已出"变成"寄存"。

结账时机不固定。餐厅大多餐后一次结账。酒吧有三种主流模式：开台先付押金、边点边付、全部挂账最后一起结。有些店还会做"卡座最低消费"，比如卡座开台费 800，实际消费不满 800 按 800 收，超了按实际收。这个规则如果不在下单时就记录下来，最后对账会非常痛苦，因为价格在营业期间可能被临时调整过。

SKU 的复杂度在"做法"上，不在品类上。一杯威士忌可乐，可能是单杯、可能是整瓶、可能加冰不加冰、可能换无糖可乐。一份果盘有小份大份。更麻烦的是套餐和赠品：开台送果盘、消费满额送小吃、会员日第二杯半价。这些如果用"商品 + 属性"的简单结构存，后期加活动会改到崩溃。

我的建议是：动手写第一行代码之前，拿一张纸把这家店一周的真实小票全部摊开，按"桌台动作"和"金额动作"两类去归类。归类完你会发现，需要抽象的东西就那么七八个，剩下的都是配置。

1.2 谁在用这套系统，决定接口怎么切

一套酒吧点单系统至少有四类使用者，权限和诉求完全不同：

很多项目死在"一套界面打天下"上。顾客端追求极简，服务员端追求功能全，这两者放一个页面里必然互相拖累。我一般的做法是拆成两个小程序入口（顾客端 + 员工端），或者顾客端小程序加一个隐藏的员工模式入口，用角色和门店绑定来控制可见菜单。员工端还必须有代下单能力，因为现场一定会有客人说"我懒得点，你帮我点"，这时候如果系统只支持顾客自助，服务员就得拿纸记，那这套系统就白做了。

2. 端、服务、实时通道：三道选型关口

选型这件事，我判断的标准只有一条：这套系统的维护者是谁，能维护多久。一个只有两个开发、上线后还要兼顾店里运营的小团队，上一套需要 K8s 编排的微服务架构，纯粹是给自己挖坑。下面分三块讲我的实际取舍。

2.1 小程序端：原生框架和跨端框架怎么选

顾客端要的是打开快、支付顺、扫码直达。这几个诉求下，原生小程序框架的包体积和首屏表现确实更好，尤其是冷启动。但如果这家店后续还想做 H5 预约、做平板点单、做员工端 App，那跨端方案（uni-app、Taro 这类）的复用价值就出来了。

我的经验分界线是这样的：只有小程序一个端，选原生；两个端以上，选跨端；三个端以上且对性能敏感，跨端 + 关键页面原生重写。

这里有个细节特别容易被忽略：扫码进小程序时，桌号怎么传。常见的做法是把桌号编码进二维码的 scene 参数，或者拼在普通链接的 query 里。scene 参数有长度限制，通常 32 个字符以内，只允许特定字符集。如果你的门店编码 + 桌号 + 校验位超了长度，就得自己做一个短码映射表，扫码后在服务端换回真实桌号。这一步不做，后期门店一多，二维码就会失效。

// 扫码落地页：把 scene 短码换成真实桌台上下文 Page({ onLoad(query) { const scene = decodeURIComponent(query.scene || ''); // 不要在这里直接下单，只做上下文绑定 wx.request({ url: `${API}/table/resolve`, method: 'POST', data: { shortCode: scene }, success: (res) => { if (res.data.code !== 0) { // 二维码过期或桌台已停用，引导手动输入桌号 this.setData({ needManual: true }); return; } const { tableId, storeId, sessionId } = res.data.data; this.setData({ tableId, storeId, sessionId }); }, }); }, });

注意：桌台上下文一定要在服务端校验并下发，别信客户端传上来的 tableId。有人拿旧二维码截图在店外下单，或者换个桌号参数想看看别人的账单，这类情况真实发生过。

2.2 服务端：别为了"高并发"三个字上微服务

酒吧的并发峰值其实没那么可怕。一家中型店 40 个桌台，同时在线顾客 200 人，高峰期每分钟下单 30 单左右，换算下来写入 QPS 个位数到十几。这个量级，一台 4 核 8G 的机器跑单体服务绰绰有余。真正难的不是吞吐，是一致性：库存不能超卖，账单不能算错，打印不能重复也不能遗漏。

所以我的一般配置是：

用 Node 的好处是和小程序端共用一套 TS 类型定义，接口契约不容易走偏；用 Go 的好处是打印代理、本地服务这类需要在店里跑的小程序二进制分发方便。别纠结，这层不是瓶颈。

真正要在意的是事务边界。一次下单要干四件事：写订单主表、写订单明细、扣库存、发打印指令。前三件必须在一个事务里，第四个必须异步且可重试。我见过有人把打印放在事务里同步调用云打印机接口，网络抖一下，整个下单接口超时，顾客看到"下单失败"，其实订单已经落库了，最后变成重复下单。

2.3 实时通道：长连接和轮询各自的适用面

顾客端不需要实时，他下完单看到"已下单"就行。需要实时的是吧台出品屏和服务员端：新单要在两秒内出现，退单要立刻消失，催单要能弹提醒。

这里的选型比较：

• WebSocket 长连接：延迟最低，适合固定工位的出品屏（有电源、网络稳定）。
• SSE（服务端推送）：实现简单，断线自动重连，适合只读场景。
• 轮询：最土但最稳，服务员端用手机在店里走来走去，网络频繁切换，轮询反而比长连接更抗造。

我的组合方案是：出品屏用 WebSocket，服务员端用 3 秒轮询 + 本地缓存。别觉得轮询丢人，一个店几十个服务员，3 秒一次请求打到一台机器上完全扛得住，而且省掉了一大堆断线重连、心跳、消息去重的代码。

如果确实上 WebSocket，心跳和重连必须做对：客户端 25 秒发一次 ping，服务端 60 秒没收到就断开；重连采用指数退避（1s、2s、4s、8s，上限 30s）；每条推送消息带自增 seq，客户端发现 seq 跳号就主动拉一次全量补齐。这三件事缺一件，出品屏就会出现"停在半小时前"的假在线状态。

3. 数据建模：桌台状态机是整个系统的心脏

前面说了桌台会流动，那具体怎么建。我的做法是物理桌台和营业会话分离：table表存物理桌号、区域、容量、二维码短码；table_session表存一次开台到清台的完整过程。订单挂在 session 上，不直接挂桌台。

这么设计的好处是并台、转台都变成了 session 的操作，不动订单本身。并台就是把 session A 的订单批量改挂到 session B，然后关闭 A。转台就是把 session 的 table_id 换掉。拆台就是新建一个 session，把部分订单挪过去。

3.1 开台、并台、转台、清台的状态流转

idle（空闲） └─ 开台 → open（营业中） ├─ 下单 → open（状态不变，只增订单） ├─ 并台 → merged（被并入方，只读） ├─ 转台 → open（table_id 变更，记流水） ├─ 结账 → settling（结算中） └─ 清台 → closed（已关闭，只读）

几个容易出错的点，我一条条说。

状态变更必须走服务层，不能直接 update。每次变更写一条table_op_log，记录操作人、操作类型、前后状态、时间。出问题时这是唯一能复盘的东西。有一次店里投诉"客人跑了没结账"，查日志发现是服务员点错了桌号把 A 桌的单结到了 B 桌，如果没这个日志，扯皮能扯一晚上。

并台时的金额处理要考虑最低消费。两个卡座合并，最低消费是按两个算还是按一个算，各家规则不同。我的做法是把最低消费规则配置在桌台类型上，并台时重新计算合并后的最低消费，并在结算页明确列出"最低消费合计"。这个数字不摊开给服务员看，收银的时候一定会吵。

清台不是删除。清台只是把 session 状态置为 closed，并且解除桌台占用。历史 session 永久保留，因为要做营业报表、要做复购分析、要对账。删除数据的系统，三个月后一定有人来找你要数据。

3.2 酒水 SKU 的规格与做法：选项组怎么存

商品建模我推荐三层：商品 → 规格（SKU）→ 选项组。

• 商品层：名称、分类、图片、是否上架、是否参与活动。
• 规格层：单杯 / 整瓶 / 小份 / 大份，各自独立定价和库存。
• 选项组：加冰/去冰、甜度、是否加柠檬，组内可选单选或多选，可以设必选，可以加价。

选项组的关键是价格归属。加价项要记在订单明细的选项快照里，不能只记一个总价，否则退款、对账、报表都会算不清。

CREATE TABLE order_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id BIGINT NOT NULL, sku_id BIGINT NOT NULL, sku_name VARCHAR(64) NOT NULL, -- 名称快照 unit_price DECIMAL(10,2) NOT NULL, -- 成交单价快照 quantity INT NOT NULL, options_json JSON NOT NULL, -- 选项快照，含加价明细 amount DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0, -- 0待出品 1已出品 2已退 created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_order (order_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

注意sku_name和unit_price都是快照字段。这是我在一个项目里吃过亏之后加的：当时明细表只存 sku_id，价格实时 join 商品表取。结果店里做活动把某个酒的价格从 88 改成 68，第二天看前一天的营业额，全变了。这种问题在财务对账时是致命的。

4. 现场才是真正的敌人：弱网、断网与重复提交

技术方案在办公室里跑通只是开始。酒吧现场的网络环境有多差，我形容一下：金属装修、上百人手机连着同一个 AP、DJ 台旁边有强干扰、地下室卡座信号一格。在这种环境下，下单链路的每一次请求都可能超时、可能重复、可能半途断掉。

4.1 从扫码到下单，一条链路上的四次失败

我把顾客下单链路拆成四段，每段都有典型的失败模式：

第二段特别重要。菜单数据变更频率很低，完全可以缓存在本地，加上版本号，有更新就后台拉。这样即使网络很差，顾客也能看到菜单、能加购物车，只是提交的时候才需要网络。体验上的差别非常大——能看不能下单，比什么都看不到要好。

第四段是投诉重灾区。支付成功但订单状态没更新，顾客会认为"钱扣了东西没点"。解决办法是双保险：客户端支付成功后主动轮询订单状态（间隔 1s、2s、3s、5s，最多 30 秒），同时服务端有定时任务扫描"支付中"超过 2 分钟的订单，主动去支付渠道查单并修正状态。两条路任意一条通了就正常。

4.2 幂等：不是加个唯一索引就完事

重复提交的原因有很多：用户手抖点两次、网络超时客户端重试、消息队列重投、支付回调重复通知。每一种都要单独防。

我的标准配置是客户端幂等键 + 服务端唯一索引 + 状态机保护三层：

// 下单接口：三层幂等 async function createOrder(payload) { const { requestId, tableId, items } = payload; // 第一层：Redis 占位，防止同一请求并发打进来 const lockKey = `order:req:${requestId}`; const locked = await redis.set(lockKey, '1', 'NX', 'EX', 30); if (!locked) { // 已经在处理，直接返回处理中，让客户端轮询 return { code: 1001, msg: 'processing' }; } try { // 第二层：数据库唯一索引兜底（request_id 建 UNIQUE） const exist = await db.query( 'SELECT id, status FROM `order` WHERE request_id = ?', [requestId] ); if (exist.length) return { code: 0, data: exist[0] }; // 第三层：事务内落库 + 扣库存 return await db.transaction(async (trx) => { const orderId = await insertOrder(trx, payload); await insertItems(trx, orderId, items); await deductStock(trx, items); // 用 UPDATE ... WHERE stock >= ? 乐观扣减 return { code: 0, data: { orderId } }; }); } finally { await redis.del(lockKey); } }

库存扣减那句 SQL 我单独说：别用"先查再减"，高并发下必超卖。正确地写法是UPDATE sku SET stock = stock - ? WHERE id = ? AND stock >= ?，看影响行数判断是否成功，失败就整单回滚并提示"该商品库存不足"。这个写法在单机 MySQL 下足够应付酒吧的量级，不需要上分布式锁。

还有一条容易被忘掉：幂等键要有生命周期。requestId 用 UUID 生成没问题，但服务端别永久存。我一般把幂等记录存 24 小时，超过就清理。不然表会越来越大，唯一索引的写入性能也会受影响。

5. 硬件与吧台协同：小票机和出品屏的真实脾气

软件跑得再顺，小票打不出来，吧台就不认这套系统。硬件这块是最容易被低估的部分，因为它涉及的变量太多：打印机的品牌型号、纸张宽度、字符集、网络稳定性、驱动兼容性。

5.1 云打印和本地打印，各有各的坑

我倾向本地代理方案，原因很直接：酒吧的公网断了，生意还得做。本地代理是一个跑在店内小主机上的常驻程序，通过内网访问打印机，通过公网和云端服务通信。断网时它把打印任务存在本地队列，网络恢复后按序补打。这个"断网续打"的能力，是本地方案最大的价值。

打印代理的关键设计：

• 任务队列持久化到本地 SQLite，进程重启不丢单。
• 每个任务带唯一 ID，打印前先查本地已完成记录，防止重复打。
• 打印失败重试 3 次，间隔 2 秒，仍失败则标记为"需人工处理"并在出品屏高亮。
• 心跳上报，云端超过 90 秒没收到心跳就告警。

小票模板这块有个细节很多人踩：中文对齐不能按字符数算，要按显示宽度算。58mm 纸一行大约 32 个半角字符，一个汉字占 2 个。你按padEnd(32)去补空格，中文一多就全歪了。正确做法是算显示宽度，汉字算 2，ASCII 算 1。

5.2 出品屏：新单强提醒和超时升级

出品屏的使用者是吧台小哥，双手在忙，眼睛不能一直盯着屏幕。所以新单提醒必须做到"不看也知道"：整屏闪一下 + 声音 + 单号高亮，三选二以上。

更关键的是超时升级。一张单从下单到出品，超过 5 分钟标黄，超过 10 分钟标红并推到服务员端，超过 15 分钟进店长看板。这个机制能显著减少"客人催了才发现漏单"的情况。

出品屏还有个必须做的功能：一键退单和缺货标记。酒卖完了，吧台要能立刻把这单标成"缺货"，系统自动通知服务员去跟客人沟通并退款。如果这个动作要在收银台电脑上做，那吧台永远不会去做，最后就是服务员跑过去喊，效率归零。

6. 上线前的压测模型和上线当天的保障清单

很多系统在测试环境跑得好好的，一进店就崩。不是代码问题，是压测模型不对——用均匀的 100 QPS 压测，和真实的"平时 2 QPS、峰值瞬间 30 QPS、连续四小时"完全是两回事。

6.1 按真实营业曲线造压测脚本

我的做法是先要一周的真实营业数据（下单时间分布），按 15 分钟粒度统计出下单量，然后把这个曲线做成压测的到达率模型。用 k6 写起来很直接：

import http from 'k6/http'; import { check, sleep } from 'k6'; export const options = { scenarios: { peak_night: { executor: 'ramping-arrival-rate', startRate: 2, timeUnit: '1s', preAllocatedVUs: 50, maxVUs: 300, stages: [ { target: 3, duration: '5m' }, // 20:00 开始上人 { target: 12, duration: '30m' }, // 21:00 进入高峰 { target: 30, duration: '60m' }, // 22:00-23:00 峰值 { target: 15, duration: '60m' }, { target: 2, duration: '30m' }, // 00:30 回落 ], }, }, thresholds: { 'http_req_duration{name:createOrder}': ['p(95)<800'], 'http_req_failed': ['rate<0.01'], }, }; export default function () { const payload = JSON.stringify({ requestId: `${__VU}-${__ITER}-${Date.now()}`, tableId: Math.floor(Math.random() * 40) + 1, items: [{ skuId: 1001, quantity: 2 }], }); const res = http.post(`${__ENV.API}/order`, payload, { headers: { 'Content-Type': 'application/json' }, tags: { name: 'createOrder' }, }); check(res, { 'order ok': (r) => r.status === 200 }); sleep(Math.random() * 2); }

压测时重点看三个指标，不只是响应时间：

1. 下单成功率，低于 99.5% 就要查。
2. 库存扣减的准确性，压测结束后对账，看有没有超卖。
3. 数据库连接池打满次数，这个指标比 QPS 更能反映系统是不是在硬撑。

6.2 上线当天的现场保障清单

我一般会在上线日提前三小时到店，按这个顺序过一遍：

• 店里每个区域的二维码贴好，用三台不同型号手机各扫一次，确认进入的是同一个桌台。
• 打印代理程序开机自启、断网重连各测一次，打一张测试单看格式。
• 出品屏屏幕常亮、自动亮度关闭、声音调到能听清。
• 所有服务员账号登录，走一遍代下单、退单、转台、并台。
• 支付链路用真实小额订单跑通，包括退款。
• 准备应急方案：纸笔 + 后续手工补单的入口，并且提前告诉服务员怎么用。

最后一条特别重要。任何系统都要有降级方案，而且降级方案必须在平时演练过。真出事那天，服务员不会去翻你写的操作手册。

7. 三个真实踩过的坑

这一段我想单独拿出来讲，因为这些问题在文档里都找不到，都是被店里投诉到怀疑人生之后改出来的。

7.1 二维码被撕掉之后

开业第一个月，日均三张二维码消失——客人抠、酒水泡、清洁擦。那时候每张二维码是唯一的短码，撕了就得重新生成、重新打印、重新贴，还要在后台改映射。后来改成"门店级前缀 + 桌号可读码"：二维码内容里带一个固定的门店标识和一个桌号明文，再加上一个短的校验串。扫码后服务端校验门店标识和校验串，桌号直接读，不需要查映射表。好处是任何一张码丢了，用通用工具重新生成一张就行，不用后台操作。

7.2 价格改了，历史订单跟着变了

这个前面提过一次，但当时的情况更麻烦：不只是明细表，连一些报表查询也是 join 商品表算金额的。改完价格之后，前一天的对账数据和实际收款对不上，财务查了一整天。最终的修复方案是把所有涉及金额的查询全部改成读快照字段，商品表只用于展示当前售价。改完之后我做了一次全量校验：随机抽 200 笔历史订单，用快照金额求和，和收款流水逐笔对，差一分都算 bug。

7.3 凌晨两点的一次"全店下单失败"

那天接到电话说全店下不了单，我远程连上去看，接口全部超时。查了十几分钟才发现，是数据库连接池被打满了，原因是一个没加索引的查询：退款时按手机号查会员积分记录，表里有几十万行，全表扫描，十几个退款请求就把连接池占光了。加索引解决之后，我顺手做了两件事：一是把所有慢查询日志打开，超过 200ms 的全部上报；二是给连接池加了一个等待超时（3 秒），超时直接返回"系统繁忙",而不是无限期挂住。

顺手分享一个小技巧：给每个关键接口埋一个"业务耗时"的打点，不要只看 HTTP 层的响应时间。因为很多慢是慢在中间某个 RPC 调用或者某条 SQL 上，光看接口总耗时定位不到。我们后来在日志里给每个请求打了 traceId，把 SQL 耗时、打印下发耗时、支付调用耗时都串起来，排查效率提升了不止一倍。

这套系统做到后面，我越来越觉得技术选型只占三成，剩下七成是对酒吧这个场景的理解：什么时候该让服务员代点，什么时候该允许挂账，什么情况下必须允许"先出酒、后补单"。这些东西想清楚了，代码写起来其实不难；想不清楚，写得再漂亮店里也用不起来。