用云开发搭一套「预约排队 + 到号通知 + 到店核销」的核心思路
你想要的其实就三件事：用户拿号、系统叫号、到店核销。用微信小程序云开发做，优势是不用自建服务器，数据库、云函数、定时任务、鉴权都能一把梭。
举个小案例：一家奶茶店高峰期每小时 60 人排队。你把“到号通知”做成订阅消息，店员用“核销码/订单号”一扫就完事，能把柜台解释时间从 15 秒压到 3 秒，队伍体验会明显好很多。
数据表（集合）怎么设计：少而稳，字段要为「排队状态」服务
建议 4 个集合就够跑起来，后面再加扩展表：
- stores：_id、name、address、openTime、closeTime、queueRule（如每批放号数量）、status
- queue_orders：_id、storeId、userOpenid、phone、peopleCount、bizDate（如 2026-05-10）、queueNo（如 A032）、status（WAIT/CALLING/ARRIVED/CANCELED/EXPIRED）、calledAt、arrivedAt、verifyCode（6 位或 8 位）、createdAt
- staff：_id、storeId、openid、role（ADMIN/CLERK）、name、enabled
- verify_logs：_id、orderId、storeId、staffOpenid、action（VERIFY/CANCEL）、createdAt、remark
关键点：queueNo 要按门店 + 当天递增，别用全局自增。status 只用一套枚举，后台、前台、云函数都按它来。
云函数实操：拿号、叫号、通知、核销怎么写得顺
1）拿号/预约：takeNumber
流程很直：校验门店营业时间 → 查今天最大号 → +1 生成 queueNo 和 verifyCode → 写入 queue_orders。并发时用事务或把“当日计数”单独放一个集合做原子更新，避免两个人拿到同一个 A032。
2）到号通知：notifyNext（手动触发 + 定时兜底）
叫号建议两种触发：
- 店员后台点“叫下一个”：把下一单 status 改为 CALLING，写 calledAt，然后用云函数调 subscribeMessage.send 发订阅消息
- 用云开发定时触发器每 1 分钟扫一遍：CALLING 超过 10 分钟未到店就改 EXPIRED，并自动叫下一位（看你业务要不要这么激进）
注意：订阅消息必须让用户在拿号时勾选授权，不然 2026-05-10 这种高峰日会出现“叫号了但发不出去”的尴尬。
3）到店核销：checkinVerify
核销就一句话：只允许 staff 角色操作。云函数里校验：订单是否属于该门店、是否 WAIT/CALLING、verifyCode 是否匹配；通过后把 status 改 ARRIVED，写 arrivedAt，并写一条 verify_logs。任何重复核销直接拒绝。
后台管理端怎么做：少页面也能很好用
后台别整太重，3 个页面就能跑：
- 排队看板：按 WAIT/CALLING 分组，支持“一键叫号”“作废/过号”
- 核销页：输入订单号/验证码，或接扫码枪（H5 管理端也能用）
- 门店设置：营业时间、过号规则、订阅消息模板选择
权限用云开发的 openid 鉴权：staff 集合里没这人就不让进。数据库权限规则要卡死：queue_orders 普通用户只读自己的，写也只能新增自己的。
给你一套能落地的执行建议（今天就能开干）
- 把status 流转图先画出来（WAIT→CALLING→ARRIVED，辅以 CANCELED/EXPIRED），所有页面和云函数都按这套走
- 拿号时强制弹订阅授权，把“到号通知”做成必选项，别指望用户回头再开
- 先按单门店日 300 单做容量预估：索引至少建 storeId+bizDate、storeId+status、userOpenid+bizDate
- 上线前用 10 个测试号模拟排队，重点测：并发拿号是否重复、过号策略是否误伤、核销是否能防重复
