连锁餐饮点单小程序：把高峰期收银压力搬到顾客手机上

#背景

品牌方有 28 家直营门店，点单依赖收银台：高峰期顾客排队点单，店员一边收银一边记单，出错与流失都集中在最忙的两小时。会员数据散落在三个渠道（线下卡、外卖平台、公众号），总部看不到统一的复购情况。

#挑战

• 多门店数据隔离：门店只能看自己，总部要能看全部，权限粒度到"门店 + 角色"；
• 高峰期并发：午市 12:00–13:00 的下单量约占全天 40%，必须在收银台不成为瓶颈的前提下承接；
• 门店网络不稳定：后厨打印机断网时不能让订单凭空消失。

#方案

• 顾客侧：扫码进店 → 桌台识别 → 点单 → 支付，全流程不超过 4 步；菜单与门店库存同源，售罄自动置灰；
• 员工端：桌台状态看板（空闲/用餐/待清台），订单变更通过长轮询同步，断网时本地排队、恢复后重放；
• 总部端：统一菜单与价格下发、门店维度经营报表（营业额/客单/翻台），每日 9 点前自动汇总推送；
• 工程细节：列表与图片懒加载、菜单图片走 WebP、包体控制在 2MB 内（首屏 1.2 秒），门店间数据按 store_id 在查询层强隔离而非仅靠前端隐藏。

#结果

• 点单页首屏 1.2 秒，小程序包体 1.8MB；
• 午市高峰下单失败率 0‰（含打印机断网场景，订单进本地队列后重放）；
• 总部报表从"人工汇总两天"变成次日 9 点前自动推送；
• 会员从三套渠道合并为一套，复购数据首次可看全。

#取舍

• 不做外卖平台对接：平台侧接口变更频繁，维护成本高且规则不受控，第一期只做堂食与自提；
• 不做自研支付通道：直接用微信支付，合规与对账成本都更低；
• 看板用长轮询而非 WebSocket：门店并发量不大，长轮询在弱网下更稳、nginx 配置更简单，代价是秒级延迟——对堂食场景完全够用。