likeshop连锁点餐系统的扫码点餐与履约方式设计——从桌台二维码到门店自提的完整链路

likeshop连锁点餐系统支持三种履约方式：堂食（店内就餐或打包带走）、外卖（同城配送）、自提（到店取货） 。这三种方式在订单中通过订单类型字段进行区分，堂食和自提的订单不需要物流配送，外卖订单需要选择配送方式。

扫码点餐是堂食场景的核心入口。顾客通过扫描桌台二维码，系统自动识别桌号、进入对应门店、加载菜单数据并创建订单。后端通常建立桌台管理数据表，包含桌号、二维码地址、桌台状态等字段。顾客扫码后，小程序解析二维码内容，向后端发起桌台验证请求，后端校验签名有效性后返回桌台信息和菜单数据。菜单系统配合Redis缓存使用，减少数据库压力，购物车支持加减数量、多规格、套餐组合、用户备注和实时价格计算等功能。

门店自提是连锁点餐系统中重要的履约方式。核心流程为：用户下单时选择“门店自提”→从门店列表中选择具体门店→支付后生成提货码→用户到店出示提货码→核销员核销→订单状态由待发货变更为已完成 。门店列表按地理位置由近到远显示，提货码有两种状态：待核销和已核销。自提订单不能多次核销。

当用户选择“到店自提”时，系统需要根据用户LBS位置推荐最近的门店，并且自提订单的核销要和门店的POS系统打通 。二开时遵循“扩展优先”原则，不修改核心的核销逻辑，而是新建扩展Logic，在核销成功后调用。这一设计思路值得开发者在进行类似定制时参考。

订单状态管理是履约链路中的核心。扫码点餐的订单状态包括待确认、已确认、制作中、已出餐、已完成、已取消。每个状态变更都需要触发相应的业务逻辑——状态变更为“制作中”时推送通知到厨房，变更为“已出餐”时通知服务员取餐，变更为“已完成”时释放桌台资源。WebSocket是实现订单状态实时推送的常用技术方案，用户端和商户端通过WebSocket长连接接收状态变更通知，避免轮询带来的服务器压力。

外卖配送场景中，部分门店没有自配送能力，需要接入达达或美团配送。订单发货后自动推送配送单，配送状态回调实时更新订单状态 。第三方配送对接的技术实现路径包括配送单创建、配送状态回调和异常处理等环节，需要在订单模型中增加配送状态字段并定义相应的状态流转规则。