预约小程序开发：多场景落地实战

做了三年预约类小程序，我发现一个规律：客户最初的需求几乎都是「做个能选时间、能下单的预约功能」，但真正上线后，决定成败的从来不是预约表单本身，而是不同场景下的业务闭环。咨询师、律师、医美、健身、维修……表面上都是「选时间 + 填信息」，底层逻辑却千差万别。这篇文章结合我实际交付过的几个项目，聊聊多场景预约小程序的设计与开发要点。

一、为什么预约小程序不能「一套模板打天下」

很多人以为预约就是日历控件加个提交按钮。但真正落地时会遇到这些问题：

• 咨询师场景：一个咨询师可能同时提供线上视频、线下面谈两种形式，时长不同、价格不同，还要考虑连续排期和缓冲时间。
• 法律咨询场景：用户提交的往往是敏感案情，需要脱敏、加密存储，甚至要求律师接单前看不到完整内容。
• 到店服务场景：涉及门店、工位、设备等资源占用，一个时间段可能被多个资源维度约束。

如果一开始就用「时间段 + 服务项目」的万能模型硬套，后期一定会被业务方追着改。我的建议是：先抽象出「资源—时段—订单」三层模型，再按场景做扩展字段。

二、核心数据模型设计

无论什么场景，预约系统的骨架都可以收敛成三张核心表：

// 资源表：咨询师 / 律师 / 工位 / 设备
{
  _id: "res_001",
  type: "consultant",      // 资源类型
  name: "张老师",
  tags: ["情感咨询", "线上"],
  bufferMinutes: 15,        // 前后缓冲
  meta: { title: "国家二级心理咨询师" }
}

// 时段表：由排班规则动态生成
{
  resourceId: "res_001",
  startAt: 1735689600000,
  endAt: 1735693200000,
  status: "available",     // available / locked / booked
  price: 300
}

// 订单表
{
  _id: "ord_1001",
  resourceId: "res_001",
  slotId: "slot_88",
  userId: "u_9527",
  formData: { /* 场景自定义字段 */ },
  status: "paid"
}

关键点在于 meta 和 formData 两个 JSON 字段。它们让同一套表结构能承载咨询师、律师、医美等不同场景的个性化信息，而不必为每个行业单独建表。

三、多场景差异化的三个关键处理

1. 排班规则的引擎化

咨询师通常是「每周固定时段 + 临时调整」，律师则更多是「按案件排期，随时可约」。我一般把排班抽象成规则表达式，由后端定时任务提前生成未来 30 天的时段记录：

// 排班规则示例
{
  resourceId: "res_001",
  rule: "FREQ=WEEKLY;BYDAY=MO,WE,FR;BYHOUR=14,15,16",
  duration: 60,
  validFrom: "2025-01-01",
  validTo: "2025-06-30"
}

这样运营改排班只需要改规则，不用手动一条条录入时段，也方便处理节假日例外。

2. 敏感信息的隔离

法律咨询场景最怕信息泄露。我的做法是：用户提交的案情描述先加密落库，律师端在「接单」动作发生前只能看到脱敏摘要，接单后才解密完整内容，并且所有查看行为写审计日志。这一步在小程序端要配合 wx.getStorageSync 的清理策略，避免本地缓存残留。

3. 并发锁与超卖

预约最典型的 bug 就是两个人同时抢到同一个时段。不要依赖前端置灰，一定要在后端用原子操作锁时段：

// 伪代码：原子锁定时段
const result = await db.collection('slots').updateOne(
  { _id: slotId, status: 'available' },
  { $set: { status: 'locked', lockUntil: Date.now() + 5 * 60 * 1000 } }
);
if (result.modifiedCount === 0) {
  throw new Error('该时段已被预约，请重新选择');
}

锁定后给用户 5 分钟支付时间，超时由定时任务释放，兼顾体验和资源利用率。

四、小程序端的体验细节

• 日历要能一眼看出可约性：不要只标「有/无」，用颜色区分「可约」「紧张」「已满」，减少无效点击。
• 表单字段按场景动态渲染：咨询师要问「咨询方向」，律师要问「案件类型」，用配置化的 schema 驱动表单，避免为每个场景改代码。
• 订阅消息必做：预约成功、开始前 1 小时、改期提醒，用 wx.requestSubscribeMessage 一次授权，能显著降低爽约率。

五、上线后的运营思考

预约小程序不是上线就结束。我服务过的咨询师客户，上线后最常提的需求是「能不能让老客户优先约」和「能不能自动候补」。这两个功能本质上都是把资源分配策略产品化。建议一开始就在订单表预留 priority 和 waitlist 字段，后期扩展会轻松很多。

一句话总结：预约小程序的难点不在日历控件，而在「资源、时段、订单」的抽象，以及针对咨询师、法律等场景做差异化处理。把模型设计对了，多场景就是配置问题，而不是重写问题。