奶茶店小程序开发落地方案

奶茶店的小程序需求非常集中：点单、支付、取餐提醒、会员积分。看似简单，但真正落地时会遇到高峰期并发、规格组合爆炸、门店多端同步等问题。本文给出一套可以直接复用的落地方案，适合个人开发者或小团队快速交付。

一、先明确业务边界

不要一上来就做“万能餐饮系统”。奶茶店的真实链路是：

• 用户扫码进入小程序，选择门店
• 浏览菜单，选择杯型、温度、糖度、加料
• 加入购物车，提交订单并支付
• 门店接单制作，用户收到取餐通知
• 完成后发放积分，沉淀会员

把这五步做扎实，比堆功能更重要。建议第一版砍掉预约、拼单、外卖配送，只保留到店自取。

二、技术选型

推荐组合：

• 前端：微信小程序原生 + TDesign 或 Vant Weapp
• 后端：Node.js（NestJS）或 Go，部署在云托管
• 数据库：MySQL + Redis
• 支付：微信支付 JSAPI
• 消息：微信订阅消息推送取餐提醒

如果预算有限，直接用微信云开发，省掉服务器运维，适合单店起步。

三、核心数据模型

规格组合是奶茶店最容易踩坑的地方。建议用“商品 + 规格组 + 选项”三层结构，而不是给每个组合建一条 SKU。

// 商品
{
  id: 1001,
  name: "招牌珍珠奶茶",
  basePrice: 1200, // 单位：分
  specGroups: ["cup", "temperature", "sugar", "topping"]
}

// 规格组
{
  id: "sugar",
  name: "糖度",
  required: true,
  options: [
    { id: "s0", name: "无糖", priceDelta: 0 },
    { id: "s1", name: "三分糖", priceDelta: 0 },
    { id: "s2", name: "七分糖", priceDelta: 0 }
  ]
}

// 加料
{
  id: "topping",
  name: "加料",
  required: false,
  multiple: true,
  options: [
    { id: "t1", name: "珍珠", priceDelta: 200 },
    { id: "t2", name: "椰果", priceDelta: 200 }
  ]
}

下单时前端把选中的选项 id 数组传给后端，后端根据 basePrice 加所有 priceDelta 计算最终价格，避免前端篡改。

四、下单与支付流程

1. 前端提交订单，携带门店 id、商品快照、规格快照
2. 后端校验库存与营业状态，生成订单号，状态为“待支付”
3. 调用微信统一下单，返回 prepay_id
4. 小程序调起支付，成功后微信回调后端
5. 后端更新订单为“已支付”，推送到门店接单队列

关键点：订单商品必须存快照，包括名称、单价、规格文案。否则菜单改价后历史订单会错乱。

五、取餐提醒与并发

高峰期同一时间可能有几十单。建议用 Redis 做取餐号发号器，保证号码递增且不重复：

const key = `shop:${shopId}:queue`;
const no = await redis.incr(key);
// 每天零点重置
await redis.expireat(key, nextMidnightTimestamp);

制作完成后，调用订阅消息接口推送“您的第 23 号饮品已就绪”。注意订阅消息需要用户在下单时授权，且一次授权只能推送一次，要在下单页做好引导。

六、会员与积分

积分体系不用复杂，按实付金额 1 元 = 1 积分即可。积分可抵扣、可换券。用一张 user_points_log 表记录每次变动，避免直接改余额导致对账困难。

七、上线前检查清单

• 菜单图片是否压缩到 200KB 以内
• 支付回调是否做了幂等
• 订单超时未支付是否自动关闭
• 门店打烊后是否禁止下单
• 是否配置了订阅消息模板 id
• 是否有简单的后台用于改价、上下架

八、成本与周期

单店版本，一个人两周可以完成 MVP。云开发费用每月几十元，微信支付费率 0.6%。如果要做多门店，需要增加门店管理、员工权限、分账逻辑，周期会翻倍。

总结一句：奶茶店小程序的核心不是功能多，而是点单快、支付稳、出餐准。把规格组合和订单快照这两件事做对，项目就成功了一半。