扫码点餐总卡，问题常在后厨那一端

扫码点餐卡住，多数不是手机慢，也不是小程序做得差。卡点常在最后一段：收银台在等打印机回话。先量出这一段的秒数，再谈改哪里。

这像在外卖平台下单。你点了确认，单子还停在平台上，等商家接单打出来，后厨才知道要做哪道菜。中间断一环，你就一直看到「提交中」。

扫码点餐的链路有四段，每段各有各的耗时，也各有各的负责人。

前三段加起来通常不到一秒。真正拖时间的是第四段。因为它不是「发出去就算完」，而是「等对方回话」。

用后厨屏的店还有一层：屏本身也是个小系统，要连店里的网、要按点刷新。屏掉线时，前端收到的是「已送达」，后厨看到的是一片黑，两边都以为对方知道。

打印机关机、缺纸、网线松、后厨屏休眠，任何一样都能让这一等没有尽头。而代码里最常见的写法，是等打印成功，才告诉顾客下单成功。

微信官方文档里有两条默认值，正好解释顾客为什么觉得是「卡死」。小程序发请求的默认超时是一分钟（文档写明默认 60000 毫秒）。打印机不回话，顾客就要盯着转圈满一分钟，才看到一个失败提示。

同一份文档还写着：小程序切到后台后，5 秒内没结束的请求会被打断。顾客点完切回微信聊两句，再回来，这一单可能已经断了，界面上什么都没留下。

还有一条限制：同时发出的请求最多 10 个。午市高峰一桌一单，十桌同时点，第十一单就在排队。它不是主因，但会让卡在高峰时更明显。

所以别问「为什么卡」，去要三个时间：顾客点确认的时间、服务端存下这一单的时间、打印机回执的时间。三个数一对，责任就分出去了。

• 只有第一个有，后两个没有：网络或服务端没收到，查店里宽带。
• 前两个有，第三个没有或很晚：卡在打印这一段，就是本文说的情况。
• 三个都有，但第一个到第二个隔了很久：服务端慢，查数据库和并发。

多数店是第二种。一行「等打印成功再返回」的写法，把一台几百块的打印机变成了全店的下单开关。

改法三条，按性价比排。第一条常常当天就能改完。

先把单落下。顾客点确认，服务端立刻存下这一单，回一句「已收到」，打印另开一条路去跑。顾客看到的是「已下单，正在通知后厨」，不是转圈。这一步把「下单」和「打印」解开了。

再让没打出来的单自己重试。打印失败的单进一个待打印队列，每隔几秒重试一次，打成功就出队。打印机开机、换纸、网络恢复，队列自己补上，不用服务员跑去问这桌到底点了没。

重试要有上限。同一单试过十次还打不出来，就把这一行标红推到收银台屏幕上，让服务员拿手机补打。没有提醒的重试最危险：单子在队列里躺着，谁也不知道它没打出来。

最后加一个单号防重。每单生成一个唯一编号，服务端见到同一个编号只认一次。重试、顾客连点两下、网络抖动后重发，都只算一单。

第三条的道理不复杂。同一个请求发两次，如果每次都新建一单，后厨就多做一份。前端开发里管这叫幂等：发一次和发多次，对服务端的效果一样（MDN 的解释）。所以重试必须配单号，否则修好了卡顿，换来重单。

def 下单(单号, 菜品):
    单 = 查单号(单号)
    if 单: return 单          # 同一单号直接返回，不新建
    新建(单号, 菜品)
    放进打印队列(单号)         # 打印慢，也不挡下单

本地先落单，还有一层意思：手机这边也存一份。小程序本地缓存单个 key 能存 1MB（官方文档），存几十张单足够。店里断网时，顾客照常点，网一回来就补传。

不想看代码，也能判断自家系统改没改过，问服务商三句话：打印机关了还能不能下单成功；打印失败的单会不会自己重打；顾客连点两下确认，后厨会不会出两张票。每句只要「能」或「不能」。

三个都答「能」，说明已经改过。有一个答不上来，就还没改，这时换界面、换打印机都白花钱。

四条验收，都能在现场做，不用看代码。

拔掉后厨网线 30 秒，收银台仍能收单，界面提示「已记录，稍后打印」。网线插回，两分钟内自动补打，小票张数和订单条数对得上。

把打印机关机 10 分钟再开，补打不重单。最后抽 20 单，逐张对一遍小票。这四条过了，才算真的解耦。

还有一处容易漏：「下单成功」这四个字，合同里要写清定义。是「服务器收到」，还是「小票打出来」？

这笔账算下来也不只是一分钟。一桌多等一分钟，午市二十桌就是二十分钟的翻台时间，客人还站在门口等位。

写成前者，打印机坏了顾客照常点单，服务员拿手机看单、口头报菜。写成后者，一台打印机就能让全店停摆，而且没人说得清是谁的责任。

也有不该改的情况。只有一台收银机、后厨两个人、打印机就摆在收银台边上，同步等打印没什么问题，改它反而多一层要维护。这套改法，是给高峰会排队的店准备的。

四个常见误判，值得先排除：换更大的宽带，打印这一段根本不在公网；换小程序界面，前端只管发出去；换打印机，换了还是串行等；升级服务器，服务端本来只花几十毫秒。四个都做过还是卡，说明没量过那三个时间。

一张纸的办法：让开发在订单记录里加两个时间字段，一个记「服务端收到」，一个记「打印回执」。以后每次说卡，先看这两个数差多少，不用再猜。

后厨那一端不归小程序管，但它决定顾客等多久。把「等打印」换成「先落单、再补打」，通常比换一套点餐系统便宜，也更快见效。