预约小程序开发：我踩过的坑和最终方案

去年接了个活，给一家做家政的公司做预约小程序。对方一开始说“简单，就一个下单页面”，结果聊到第三轮需求，排班、服务人员选择、时间冲突校验、退款规则全冒出来了。这篇文章不吹概念，就按我实际做下来的顺序，把预约小程序开发里真正容易卡住的地方讲清楚。

先想清楚：预约的本质是“时间资源”的分配

很多人把预约小程序当成普通电商来做，商品换成服务就完事。真做起来会发现不对。商品库存是数字，减一就行；时间资源是区间，一个师傅上午9点到11点被占了，10点半就不能再排。所以数据模型上，我建议一开始就把“可预约时段”单独建表，而不是在订单表里塞一个时间字符串。

• 服务项表：名称、时长、价格、是否支持多人
• 资源表：师傅/房间/设备，以及对应的营业时间
• 时段表：按天生成，带状态（可约/已约/锁定）
• 订单表：只存时段ID，不存具体时间

这么拆的好处是，改营业时间、临时加钟、跨天排班都不用动订单逻辑。我第一版偷懒把时间写死在订单里，后来客户要加“午休不接单”，改了两天。

时间冲突校验要放在服务端

前端选时间只是体验，真正的校验必须在云函数或后端做。用户手快连点两下、两个用户同时抢同一个时段，这些前端拦不住。我的做法是用云开发的数据库事务，下单时先查时段状态再更新，失败就返回“该时段刚被约走”。

const db = cloud.database()
const _ = db.command

exports.main = async (event) => {
  const { slotId, userId } = event
  const res = await db.collection('slots')
    .where({ _id: slotId, status: 'free' })
    .update({ data: { status: 'locked', userId, lockTime: Date.now() } })
  if (res.stats.updated === 0) {
    return { ok: false, msg: '手慢了，换个时间吧' }
  }
  return { ok: true }
}

注意加个锁定超时，比如15分钟没支付就释放，不然用户下了单不付，时段一直占着，商家会来找你。

预约小程序开发里最容易被低估的部分

1. 消息通知

用户约完就忘，到点不来，商家最烦这个。微信小程序的订阅消息是必须做的，下单成功、服务前一天、服务前两小时各推一次。订阅消息要用户主动点授权，所以按钮文案别写“允许通知”，写“提醒我到点别忘”，通过率高不少。

2. 取消和改期规则

这块需求方往往说不清。我的经验是做成配置项：提前多少小时可免费取消、超时扣多少、改期算不算新单。规则写死在代码里，后面每次调整都要发版，很痛苦。

3. 商家端的管理

预约小程序开发不只是给用户看的。商家要能看今天的排班、手动锁时段、标记到店、处理退款。这部分我一般做成同一个小程序里的隐藏入口，用手机号白名单控制，省得再开发一个端。

用云开发还是自己搭后端

单店、预约量一天几十单的，云开发足够，数据库、云函数、存储一套下来，省掉服务器运维。但要注意两点：云开发的定时触发器有数量限制，释放超时锁定时段别一个时段一个触发器，用一个定时任务扫全表；另外查询有单次条数限制，排班列表记得分页。

如果是连锁、多门店、要对接自己的ERP，那就老老实实写后端接口，云开发当不了这个家。这个判断在报价前就要做，不然做到一半发现架构撑不住，返工的钱只能自己吞。

上线前一定要自己走一遍

我现在的习惯是，提审前用两个微信号互相抢同一个时段，用弱网模拟支付回调延迟，把取消、改期、退款各走一遍。预约类小程序出问题，基本都是并发和状态流转，功能页面反而最不容易错。

总的来说，预约小程序开发不难，难的是把时间资源、状态流转和商家实际操作习惯想全。前期多花半天画清楚时段和订单的关系，后面能省好几天。