口腔诊所小程序：从0到1开发实战

去年帮一家连锁口腔诊所做了个预约小程序，上线三个月后线上预约占比从8%涨到41%，前台电话量直接砍半。这篇文章把开发过程中的关键决策和踩过的坑整理出来，希望能帮到准备做同类项目的开发者。

为什么口腔诊所需要一个独立小程序

很多诊所老板第一反应是“我有公众号就够了”，但实际用下来会发现几个硬伤：

• 公众号菜单层级深，患者找预约入口要点三四次
• 无法保存患者就诊记录，每次都要重新问一遍
• 医生排班靠微信群里发Excel，患者看不到实时号源
• 复诊提醒只能人工打电话，漏打率极高

小程序的优势在于：即用即走、可绑定手机号、能调用微信支付、支持订阅消息推送。对口腔这种低频但强复诊属性的场景，简直是量身定做。

核心功能模块拆解

1. 预约挂号模块

这是整个小程序的心脏。设计时要考虑三个维度：医生、时间段、治疗项目。

数据结构建议这样设计：

{
  doctorId: "D001",
  date: "2025-03-15",
  slots: [
    { time: "09:00", status: "available" },
    { time: "09:30", status: "booked" },
    { time: "10:00", status: "locked" }
  ],
  serviceType: "洗牙"
}

注意 locked 状态，用于处理“用户点了但没付款”的临时占位，建议锁定15分钟。

2. 患者档案模块

口腔治疗周期长，患者档案必须包含：

• 基础信息（姓名、手机、过敏史）
• 就诊记录（每次治疗的项目、医生、费用）
• 影像资料（X光片、口内照，建议存OSS返回临时链接）
• 复诊计划（下次复诊时间、治疗阶段）

这里有个坑：不要在小程序端直接存图片，小程序包体积限制2MB，一定要走云存储或自建OSS。

3. 消息通知模块

微信订阅消息是刚需，但要用户主动授权。建议在三个节点触发：

1. 预约成功后立即请求授权
2. 就诊前一天推送提醒
3. 复诊到期前三天推送

代码示例：

wx.requestSubscribeMessage({
  tmplIds: ['TEMPLATE_ID_1', 'TEMPLATE_ID_2'],
  success(res) {
    if (res[TEMPLATE_ID_1] === 'accept') {
      // 上报到服务端记录授权状态
    }
  }
})

技术选型建议

如果你是小团队或个人开发者，推荐这套组合：

• 前端：原生小程序 + TDesign 组件库，别上 uni-app，医疗场景对性能敏感
• 后端：Node.js + Koa 或 NestJS，轻量够用
• 数据库：MySQL 存业务数据，Redis 做号源锁
• 存储：腾讯云 COS 或阿里云 OSS
• 部署：轻量服务器 + Docker，别一上来就上K8s

开发中容易忽略的细节

号源并发问题

两个患者同时抢同一个号，如果不做锁，会出现超卖。用 Redis 的 SETNX 做分布式锁，key 设计为 slot:{doctorId}:{date}:{time}，过期时间设15分钟。

隐私合规

医疗数据属于敏感信息，必须做：

• 手机号加密存储（AES-256）
• 传输层强制 HTTPS
• 小程序隐私协议弹窗，明确告知数据用途
• 患者可申请删除个人数据

医生排班冲突

医生可能临时请假，要有后台一键“停诊”功能，同时自动触发已预约患者的通知和改约引导。

上线后的运营小技巧

小程序做完只是开始，真正拉开差距的是运营：

• 首次预约送一张“免费口腔检查券”，拉新转化率能提升30%以上
• 设置“老带新”分享奖励，口腔患者信任熟人推荐
• 在候诊区放小程序码，扫码可查看排队进度，减少焦虑
• 每月导出复诊未到店名单，人工回访

总结

口腔诊所小程序的技术难度不算高，难点在于对医疗业务流程的理解。建议开发前先去诊所蹲两天，看看前台怎么接电话、医生怎么看排班、患者最常问什么问题。把这些真实场景映射到功能设计上，做出来的产品才有人用。

如果你也在做类似项目，欢迎交流踩坑经验。