点餐小程序开发，我踩过的坑和最终方案

去年秋天接了个活，本地一家做煲仔饭的老板找我，说店里扫码点餐用的那套系统每年要交三千多服务费，还动不动卡顿，问我能不能自己搞一个。我说能，于是就开始了这段点餐小程序开发的折腾。今天把过程里踩的坑和最后落地的方案写下来，给同样想自己做点餐小程序的同行参考。

先想清楚：真需要那么多功能吗

很多外包报价单上来就是会员体系、积分商城、拼团、直播带货，一套下来报价两三万。但这家店就八个桌位，高峰期一天六十单，老板真正需要的只有三件事：

• 顾客扫码能看到菜单、加菜、下单
• 后厨能实时收到订单，最好带个提示音
• 老板能看当天卖了多少钱

功能砍到这三条，开发量直接少一半。我见过太多点餐小程序开发项目死在“功能太多做不完”上，先做最小可用版本，跑起来再迭代，这个原则在小餐饮场景里特别管用。

技术选型：云开发省了我不少事

我平时主要写前端，后端只会点 Node，要是自己搭服务器、配数据库、搞 HTTPS 证书，光运维就够喝一壶。所以这次直接用微信小程序的云开发，数据库、云函数、存储、静态托管一条龙，省掉服务器成本，前期也不用备案域名。

菜单数据放云数据库，结构很简单：

// 菜品集合 dishes
{
  _id: "xxx",
  name: "腊味煲仔饭",
  price: 28,
  category: "主食",
  image: "cloud://xxx.jpg",
  onSale: true,
  sort: 10
}

// 订单集合 orders
{
  _id: "xxx",
  tableNo: "A3",
  items: [{ dishId: "xxx", name: "腊味煲仔饭", count: 1, price: 28 }],
  total: 28,
  status: "pending", // pending / cooking / done
  createTime: Date.now()
}

下单走云函数，主要是为了做价格校验。客户端传上来的金额不能信，得在云函数里按 dishId 重新查一遍价格再算总价，不然有人改个请求就能一块钱吃一顿。

后厨端那个提示音，折腾最久

这是整个点餐小程序开发里最烦的一块。老板要求新订单来了必须响，声音还得大。问题在于微信小程序在后台或者锁屏状态下，没法可靠地播放自定义音频。

我试过几个方案：

1. 用 WebSocket 长连接推消息，前台时能响，切后台就哑了——不行。
2. 订阅消息推给老板微信，但订阅消息一次授权只能收一条，得反复引导授权，体验很差。
3. 最后妥协成：后厨放一台旧平板，页面常亮，轮询云数据库查新订单，配合 wx.setKeepScreenOn 保持亮屏，来单就播提示音。

这个方案土是土了点，但稳定，成本就是一台闲置平板。后来我又加了个兜底：新订单同时往老板微信发订阅消息，平板万一断网也不至于漏单。做点餐小程序开发，很多时候不是技术多先进，而是怎么在平台限制里找到能用的组合。

扫码进桌的逻辑别写死

一开始我把桌号写死在页面参数里，二维码是 pages/index/index?table=A3。结果老板换了个桌子布局，A3 变成 B3，所有二维码全得重打。后来改成每个桌位生成一个短码存数据库，扫码后云函数反查桌号，老板在小程序后台就能改，不用重印。这种小细节看着不起眼，但能少挨不少骂。

上线和成本

整个项目前后花了大概三周，云开发免费额度对这家店的量级完全够用，超了也就几十块一个月。小程序认证费三百，这是硬成本。相比每年三千的服务费，老板第二年就回本了。

说句实在话，点餐小程序开发的技术门槛真不高，难的是把需求砍到刚好、把平台限制摸清楚。如果你也想自己做，建议先拿一家店的真实场景跑通，别一上来就想着做成 SaaS 卖给一百家店。

现在这套东西跑了小半年，中间修过两次 bug，都是订单状态并发更新导致的重复提示，加了个状态机判断就解决了。有类似需求的同行，欢迎交流。