去年帮朋友看一个餐饮项目，他花八千块找人做的点餐小程序，上线第三天就崩了。顾客扫码点单转圈圈，后厨出单机疯狂吐纸，只能让客人手写菜单应急。那顿饭我吃得五味杂陈——不是菜不好吃，是看着朋友蹲在收银台后面，拿手机一台一台重新下单的样子，实在心酸。

这事儿之后，我自己也跳进去做了两个点餐小程序。从注册账号到版本审核，从数据库设计到并发处理，踩过的坑比吃过的盐都多。今天把这些经验摊开来讲，给正要入坑的朋友当个手电筒。

拿到需求别急着写代码。我见过太多人，老板说"做个能点餐的就行"，然后真就只做了个点餐的。结果上线没两周，老板说"能不能加个会员积分"，又过两周"能不能对接打印机"，再后来"能不能搞个营销活动"。每一次新增需求，都意味着数据库要改、接口要动、前端要调。我第二次做的时候学聪明了，先花一天时间把老板脑子里所有可能的"以后再说"全问出来——堂食还是外卖？要不要预点餐？需不需要多人同时操作？后厨要不要显示排队进度？这些问题当时看着多余，后来全成了救命稻草。

开发工具选型上，别迷信什么"零代码"。市面上那些拖拽生成的小程序，做展示页还行，一旦涉及复杂逻辑——比如菜品规格多选、库存联动、优惠券计算——直接歇菜。我第一版用了个第三方平台，结果发现它连"加辣去葱"这种备注字段都存不进数据库，连夜推翻重写。老老实实基于uni-app或者原生开发，虽然前期慢点，但坑都是明的，网上资料也全。说到数据库设计，这是重灾区中的重灾区。菜品表、订单表、购物车表这些基础表就不说了，关键是那个"规格"字段。我第一次设计时用了字符串存储，比如"大份/中份/小份"，结果后来要按规格统计销量，写SQL写到想砸电脑。正确做法是单独建一张规格表，用ID关联，哪怕前期数据录入麻烦点，后期查询统计能省一百倍力气。

点餐小程序最怕什么？并发。午餐高峰那十分钟，几百人同时点单，后台要是没扛住，轻则卡顿重则白屏。我有个朋友的小程序，上线一个月，最火的那天中午直接服务器宕机，当天营业额损失两万多。后来查日志，发现是数据库连接池设置太小，加上订单表没有做索引。这两个问题都不难解决，但没遇到过根本想不起来。我的建议是，开发阶段就压测，哪怕用JMeter模拟五十个并发请求，也能把大部分性能问题提前炸出来。另外，订单状态机一定要设计严谨——待支付、已支付、制作中、已完成、已取消，每个状态之间的流转条件必须清晰，不然就会出现"用户取消了订单，后厨还在做菜"这种经典事故。

支付回调这块，坑也特别多。微信支付的回调通知是异步的，可能延迟几秒甚至几分钟，而且可能重复推送。我第一次做的时候，没做幂等处理，结果用户付了一次钱，订单却生成了两三条。后来学乖了，在回调处理逻辑里加了个"订单号+支付单号"唯一索引，重复通知直接忽略。还有个小细节——退款接口。很多新手以为退款就是调个接口完事，实际上微信支付要求退款必须关联原订单，而且退款金额不能超过支付金额，这些边界条件都得提前测清楚。

商家后台和用户端要分开设计，这句话我踩了三遍才真正理解。用户端是给顾客用的，界面要简洁，流程要短——扫码、选菜、下单、支付，四步之内搞定。商家后台是给店员用的，功能要全，操作要快——接单、改价、催单、打印，最好一个页面全搞定。我见过有人把这两个揉到一个界面里，结果顾客端操作复杂，店员端又找不到功能。另外，打印机的对接也是个隐形大坑。市面上主流打印机牌子就那几个，但接口协议各不相同，有的用蓝牙有的用WiFi。我建议开发前先确认店里用的是什么型号，直接去拿SDK文档，别自己瞎试，不然光调通打印就得耗掉两三天。

上线前还有一堆杂碎事儿容易被忽略。比如小程序名称审核，有些词是违禁的，比如"最""第一"这种极限词，在简介里出现都会被驳回。再比如图片素材，菜品的照片一定要高清原图，那些模糊带水印的图，不仅影响顾客体验，还可能因为版权问题被投诉。还有隐私协议，现在微信对用户信息收集查得很严，你哪怕只是读取用户头像和昵称，都得在隐私