简介一套开箱即用的医院预约挂号微信小程序源码面向需要快速上线或二次开发的开发者、产品经理与相关专业学生。项目覆盖患者在线选择科室、医生与就诊时间段完成实名挂号及微信支付的全流程同时内置医生信息管理、号源时间配置、预约成功页、缴费凭证、就诊状态标识、个人中心、家庭成员添加等完整业务模块前端基于原生小程序框架实现后端对接示意清晰底部导航分为首页、挂号、我的三栏视觉资源齐备。资源压缩包共374个文件包含89个js逻辑文件、86个json配置、85个wxss样式、85个wxml页面结构以及png、jpg等图片素材整体大小831KB已配置微信开发者工具所需项目文件便于快速部署调试。目前已有18人学习浏览适合作为预约挂号类小程序从0到1的参考模板可直接在此基础上扩展科室排班、支付对账等个性化功能。 直接说结论我拿这套源码包在测试环境里跑通全流程只花了一个下午但真正够到“可直接上线”这个标准我前后补了大概一周的坑。这篇文章就把我从解压源码到联调支付、再到真机预览、最后部署上线的完整过程写出来包括那些源码里没写、文档里也没提、但上线前一定会踩的雷区。这套源码包的核心是三个模块医生排班、预约支付、就诊记录。表面看是三个独立功能实际上它们共用同一套数据链路——用户从选科室、看排班、锁定号源、支付、生成预约单、到院就诊、最后沉淀为就诊记录每一步都在操作同一份订单数据和医生排班数据。所以我不打算按“功能清单”平铺直叙地介绍而是按“一次完整挂号流程”的视角来拆解这套代码顺带把支付、排班冲突、号源释放这几个最容易出事的环节单独拎出来细讲。1. 解压源码之后我建议你先做这三件事而不是急着跑起来拿到压缩包先别急着npm install然后微信开发者工具里直接打开。这套源码的解构比较典型——前端是原生微信小程序后端是 Node.jsExpress 框架数据库用的 MySQLRedis 承担排班号源的临时锁和支付回调的幂等处理。如果你直接打开小程序目录会发现请求地址是写死的localhost:3000而开发者工具默认不校验合法域名所以本地跑通很容易但你一旦换成真机预览所有请求都会因为域名校验失败被拦下来。我的建议是解压后先做三件事。第一理清目录结构。miniprogram/目录下是页面文件cloudfunctions/或者server/目录下是后端接口sql/目录下是数据库初始化脚本。先打开sql/hospital.sql看一遍表结构设计尤其是doctor_schedule医生排班表、appointment_order预约订单表、medical_record就诊记录表这三张表——这三张表是整个系统的地基它们的字段设计决定了你后面改功能时要动多少代码。第二检查配置文件。server/config.js或.env文件里通常有数据库连接、微信小程序 AppID、商户号、支付密钥等配置。源码包里一般会留占位符比如your_appid_here、your_mchid_here需要你去微信公众平台和小程序后台完善。第三确认 Node 版本和依赖。这套后端代码用了 ES6 语法和 async/awaitNode 版本建议 12 以上低于 10 会直接报语法错误。依赖安装完成后先单独启动后端服务再用 Postman 调一下健康检查接口确认服务正常再打开小程序前端这样能把前后端联调的问题隔离成两个独立问题维度排查起来快得多。注意这套源码兼容的是微信基础库 2.10.0 以上版本如果你的开发者工具太老建议先升级否则wx.login和requestPayment都可能出现莫名奇妙的兼容问题。2. 医生排班模块的数据模型设计为什么必须用“时段模板 号源数量”而不是排一个时间点列表排班模块是整个挂号的入口也是最容易设计烂的地方。这套源码的思路是医生先在后台配置一周内的出诊模板比如“周一上午 8:00-12:00每 30 分钟一个号共 8 个号”然后根据模板批量生成某一天的具体排班记录。核心是doctor_schedule表。它包含doctor_id、schedule_date、time_slot_start、time_slot_end、total_slots、booked_slots、status等字段。这个设计有几个关键点值得学习。第一时刻用time_slot_start和time_slot_end表示单个时段而不是存一个时间点数组。普通挂号平台之所以复杂是因为医生出诊时段不固定有的 20 分钟一个号有的 1 小时一个号如果直接用 JSON 数组存时间点查询排班时就要把整个 JSON 拉出来解析没法用 SQL 直接做区间查询。而这套源码用“起止时间 可约总数”的方式天然支持灵活的时段控制通过total_slots和booked_slots相减就能实时算剩余号源。第二排班是预生成的不是实时计算的。后端有个定时任务每天凌晨会为未来 7 天的医生生成排班记录生成时根据医生的周模板批量插入。这样做的好处是查询排班时直接查表无需临时计算性能好缺点是如果医生临时调整出诊时间需要先删除后插入对应日期的排班记录。源码里没有提供“临时停诊”的接口需要自己补一个update状态字段的操作——这个字段建议加因为实际运营中医生停诊太常见了。第三号源锁定用的是 Redis 而不是 MySQL 行锁。预约操作时先DECR booked_slots判断返回值如果小于 0 说明号源已满直接返回“无号”否则生成预约单。这个做法降低了数据库压力但极端并发下可能出现 Redis 扣减成功、数据库事务回滚导致号源丢失的问题。源码里对这种情况处理得比较粗糙我建议你在预约接口的事务里加一个UPDATE doctor_schedule SET booked_slots booked_slots 1 WHERE id ? AND booked_slots total_slots作为兜底形成“Redis 预扣 MySQL 兜底”的双保险。3. 预约支付的完整链路拆解统一下单、二次签名、回调验签、订单状态机支付是这套源码包最能“唬人”也最容易翻车的地方。用户的预期是“我点支付就能付钱”但实际上支付集成包含至少五个环节小程序端调起支付、后端统一下单、接收支付回调、修改订单状态、处理退款。每一个环节都有历史包袱和坑。3.1 统一下单为什么需要“二次签名”小程序端调起wx.requestPayment需要五个参数timeStamp、nonceStr、package、signType、paySign。这五个人参数中前四个好拿关键是paySign的生成规则。大部分新手会直接拿package里的预支付交易会话标识prepay_id去签名但实际上微信支付要求用第二次签名生成paySign而不是下单接口返回的sign字段。这个签名串的格式是appIdxxxnonceStrxxxpackageprepay_idxxxsignTypeRSAtimeStampxxx然后使用商户私钥进行 RSA-SHA256 签名。源码里有一段buildPaySign函数就是干这个的。请务必检查这段代码用的是paySign还是sign——我用sign直接传参时真机调试一直报 “支付验证签名失败”换成paySign后立刻通过。3.2 支付回调必须做的三件事微信支付回调是一个典型的“通知-响应”机制。用户支付成功后微信服务器会向notify_url发送一个 POST 请求携带完整的支付结果数据。源码里payment/notify这个接口表面上看起来正常但有一个致命短板没有做回调幂等处理。所谓幂等就是同一条支付通知可能被微信发送多次网络抖动、回调超时重试后端必须保证对同一条回调的处理只生效一次。怎么做很简单在appointment_order表中增加一个transaction_id字段处理回调前先查询该字段是否已存在存在则直接返回success。如果不做幂等用户支付成功后可能出现订单状态被重复修改、甚至被错误地再次判定为“待支付”的情况。另外还有两个细节值得留意。一是回调验签。微信支付回调会对请求体进行签名必须用微信支付平台证书验签防止伪造回调。源码里用到了wechatpay-node-v3这个 SDK里面的verifySign就是干这个的。如果你发现 SDK 版本比较老建议升级到最新版因为微信支付平台证书的获取方式从 2023 年起有了调整。二是回调响应的格式。微信要求返回特定 XML 格式的success或fail字符串注意不是 JSON。我在源码里见过有人返回{code: 0}导致微信每隔 15 秒就重复推送回调持续 15 分钟非常闹心。3.3 订单状态机的设计别让“已支付”和“已取消”同时出现在一张表里这套源码的订单表有一个status字段取值包括0待支付、1已支付、2已取消、3已就诊、4已退款。逻辑很清晰但它没有做状态流转校验也就是说任何接口都可以把任意状态改成任意状态这在正常业务中不会出问题但在并发或异常场景下就可能出现“已取消的订单被标记为已支付”的情况。建议的强化方案是在下单、支付回调、取消预约、退款这几个操作中都加一句类似UPDATE appointment_order SET status ? WHERE order_no ? AND status ?的条件更新用数据库自身的行锁来保证状态变更的幂等性。这既是给系统打补丁也是给后续维护者留一种“状态机”的思想。4. 就诊记录模块从预约到记录的闭环以及用户授权体系的整体设计就诊记录不是独立的它是整个预约流程的“最后一公里”。medical_record表通过appointment_id关联预约订单通过patient_id关联患者档案再通过doctor_id关联医生信息。用户能看到的就诊记录其实是“预约单 诊断/处方 医嘱”的组合视图。这里有一个关键的隐性设计——就诊记录必须在用户完成就诊后由医生端生成而不是用户端提交。源码里提供了一个最简单的医生端操作入口医生登录后进入“待就诊列表”选择某条预约记录填写主诉、诊断和开药信息然后保存生成就诊记录。这个流程用户体验比较顺畅因为用户端不需要额外录入任何东西只要等待医生操作完成后在“我的就诊记录”里刷新即可看到。用户授权体系也值得一提。这套源码用的是微信官方建议的wx.logincode2Session方案没有做用户名密码体系这是非常符合小程序生态的——大多数医院患者不愿意在小程序里注册账号直接授权微信登录再绑定就诊卡即可。但这里要注意一个问题wx.login拿到的code是一次性的有效期只有 5 分钟且后端必须调用微信接口换取openid这个openid是用户在这个小程序里的唯一标识。源码里把openid和用户档案的union_id分开存储union_id需要绑定开放平台才能获取如果只是单小程序运营用openid就够了。另一个高频问题用户删除微信重装后openid会变吗答案是不会openid由 AppID 用户微信号唯一确定重装不改变。除非用户注销了微信再重新注册那才会变——这种极端情况建议在用户端增加一个“解绑/换绑”入口源码里没做需要补。5. 微信支付的商户配置与开发者工具里的“三个打开”支付跑通后下一步是配置小程序后台和商户平台。这部分才是把源码从“本地能跑”变成“线上能用”的关键。第一开发者工具里“不校验合法域名”这个开关只能用于开发调试真机预览时必须关闭否则请求会被拦截。上线前需在小程序后台将后端接口的域名添加到request合法域名将支付回调域名添加到webview业务域名。第二微信支付商户平台需要配置 APIv3 密钥、商户证书和 AppID 绑定。这三个缺一不可。APIv3 密钥是一个 32 字节的随机字符串用于回调解密商户证书是.pem格式的私钥文件用于请求签名AppID 绑定则是让小程序能够拉起该商户号的支付能力。源码里这三处都留了占位符请逐一填入。第三支付回调接口必须是 HTTPS且不能用 IP 地址。微信支付官方要求notify_url必须是公网可访问的 HTTPS 地址端口固定为 443。很多新手会图方便用内网穿透工具跑 https但微信服务器无法访问内网所以上线前一定要部署到云服务器并配置好 Nginx 的 HTTPS 证书。调试过程中还有一个高频报错requestPayment:fail banned。这个报错一般是微信对当前支付环境的风控拦截常见原因有三个商户号没有开通对应的支付产品权限、AppID 没有绑定商户号、或者调试的微信号不是该小程序的体验成员。逐一排查即可。6. 部署上线前的最后检查清单我把每一个碰过的坑都列给你最后把源码跑到生产环境之前建议逐一核对以下检查项这些都是实际运营中会直接影响用户体验的问题。排班模板与停诊操作源码里没有“停诊”按钮如果医生临时停诊只能在数据库里改状态。我建议在后端加一个简单的停诊接口把对应日期的排班记录status改为不可预约否则患者到院发现医生不在体验极差。退号与退款逻辑源码的“取消预约”接口只支持未支付订单。如果患者支付后要退号需要走退款流程。这里需要调用微信支付的退款接口并同步更新订单状态。源码没有实现退款这是一个必须补的缺口。订单超时自动释放号源源码里没有定时任务来关闭超时未支付的订单这意味着用户锁定号源 30 分钟后不支付号源仍然被占用。我建议在 Redis 存订单号时设置过期时间并配合定时任务扫描超时订单释放号源——否则热门医生的号源很快就会被“占着茅坑不拉屎”的请求耗尽。隐私协议与用户授权弹窗小程序后台审核时强制要求用户隐私保护指引包括收集用户微信昵称、手机号等个人信息。源码里没有这个弹窗需要你自己接wx.requirePrivacyAuthorize接口并在用户首次登录时弹出隐私协议。多端环境与页面分享如果患者把挂号页分享给家人家人打开时是重新登录还是沿用分享者的登录态源码没有主动处理建议在分享参数里带上share_from标记并确保每个页面在onLoad时都执行登录态检查否则会出现 “登录后无法跳转” 的诡异问题。调试微信支付回调时的小技巧微信支付商户平台的“支付回调通知”里可以手动点击“重发通知”用来验证你的回调接口是否已经正确处理了幂等逻辑。我用这个功能测出过自己的回调存在重复处理 bug非常实用。个人实操体会这套源码包的核心价值在于它把医院挂号最经典的三种业务形态——按医生排班选号、预支付锁号、就诊后留痕——做成了完整闭环而且代码结构相对清爽后端接口的命名也规范容易被二次开发。如果你只是想快速搭一个 Demo那它开箱即用但如果你打算投入真实运营一定要把上面提到的几个缺口补上尤其是退款和超时释放号源这两个功能在没有处理干净之前系统不能算“可直接上线”。我个人的建议是先拿这套源码把支付链路完整跑通当作对微信支付 API 的一次真实训练然后再花一天时间把退款和超时释放补上最后再提交审核。这样你交出去的版本才真正对得起“可直接上线”这四个字。本文还有配套的精品资源点击获取