医院挂号微信小程序源码包解析：排班支付与就诊记录全流程

简介：微信小程序作为一种轻量级应用形态，在医疗场景中承担着连接患者与医院服务的桥梁角色。医院挂号系统的核心原理在于数据模型设计——科室、医生、排班、订单、就诊记录五张表串联起完整链路，其中排班模板与实例分离是避免节假日错乱的关键。技术价值体现在支付回调验签、订单状态机、号源并发扣减等工程实践，直接决定了系统能否稳定上线。在应用场景中，独立开发者和小型医疗机构常通过源码包快速搭建闭环，但资质审核、回调补偿、数据脱敏等细节往往成为真正的瓶颈。本文从源码包的技术栈选型出发，深入拆解排班模块、微信支付接入与就诊记录权限控制，并给出上线前必须自查的五个避坑项，帮助开发者将“可运行”的代码打磨成“可上线”的产品。

1. 可直接上线的医院挂号微信小程序：源码包里到底有什么，值不值得改

某医疗机构的信息科只有两个人，却要应付护士长天天问“今天还有没有号”、财务催“线上支付什么时候能通”、患者投诉“看完病查不到记录”——这是大多数想上挂号系统的人的真实起点。标题这套源码包把医生排班、预约支付、就诊记录串成一条完整链路，本质上就是患者从“找医生”到“看诊后查记录”的最小闭环。对独立开发者和小团队来说，它的价值不是替你写代码，而是替你省掉设计数据模型和理解业务规则的时间；反直觉的是，真正拖后腿的常常在代码之外——资质审核、支付回调地址、号源并发扣减。适合谁：想在一两周内跑通门诊挂号闭环，并且有一定后端基础的人。

2. 先看懂源码包再动手：技术栈判断、目录结构与数据主线

拿到所谓“可直接上线”的源码包，第一反应别急着改页面。先花半天把技术栈、目录、数据表这三件事摸清楚，否则你很可能在改一个自己不熟悉的黑匣子，后面每加一个功能都在踩坑。

2.1 技术栈选型：云开发还是一台云服务器

这类挂号小程序源码包常见形态有两种：一种是原生微信小程序加云开发，前端调云函数、数据存云数据库，不需要自己买服务器；另一种是小程序前端加自建后端，后端用 Node.js 或 Java，数据库用 MySQL。判断源码包到底是哪种，看两处就行：

• 小程序代码里有没有wx.cloud.init。有则是云开发形态。
• 项目里有没有独立的server或backend目录。有则是自建后端形态。

两种形态各有适用场景，不能只听“可直接上线”这四个字就选型。我整理了一份对比，拿到包之后按这个表对号入座：

我的习惯是：只要源码包用的是云开发，先确认它是不是新版云开发（微信云托管）。老版云函数在支付回调上有不少限制；如果代码里还是cloudPay.unifiedOrder这种老接口，注意看运行环境是否已经被平台标记为维护状态。自建后端形态坑少一些，但你要多扛一台机器和一个域名的备案周期。

2.2 目录结构：前端页面与后端接口怎么对应

不管源码包是哪种形态，目录结构都大同小异。以最常见的原生小程序加 Node 后端为例，典型布局是这样的：

hospital-appoint/ ├── miniprogram/ # 小程序前端 │ ├── pages/ │ │ ├── index/ # 首页：科室列表、医生列表 │ │ ├── schedule/ # 排班日历页 │ │ ├── order/ # 预约确认页 + 支付 │ │ ├── records/ # 就诊记录列表 │ │ └── mine/ # 我的页面 │ ├── utils/ │ │ ├── request.js # 封装 wx.request，带 token │ │ └── auth.js # 登录、获取用户信息 │ └── app.js └── server/ # 自建后端 ├── routes/ │ ├── dept.js # 科室接口 │ ├── schedule.js # 排班接口 │ ├── order.js # 下单、支付、取消 │ └── record.js # 就诊记录接口 ├── models/ # 数据表模型 └── utils/ ├── pay.js # 微信支付封装 └── auth.js # token 校验

拿到任何包，我建议按顺序做三件事：先看app.json里注册了哪些页面，确认页面路径和目录一致；再看utils/request.js里封装的请求对象，确认 baseURL 和 token 注入逻辑；最后找数据库初始化脚本或者models目录，确认核心表结构。这三步走完，你对这套代码的熟悉程度就超过了一大半只看过 README 的人。

前端页面和后端接口的对应关系，核心在一个规律：一个页面通常只依赖一两个接口。比如排班页主要调schedule接口，支付流程依赖order接口。改页面之前先顺着接口找数据来源，能少走很多弯路。

2.3 数据主线：科室、医生、排班、订单、记录五张核心表

挂号系统的数据模型，说穿了就是五张表串一条线：科室 → 医生 → 排班 → 订单 → 就诊记录。源码包质量高不高，看这五张表的字段设计就能判断。我简化出一个核心结构：

CREATE TABLE dept ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, intro VARCHAR(255) DEFAULT '' ); CREATE TABLE doctor ( id INT PRIMARY KEY AUTO_INCREMENT, dept_id INT NOT NULL, name VARCHAR(50) NOT NULL, title VARCHAR(20), -- 职称：主任医师/副主任医师 avatar VARCHAR(255) DEFAULT '' ); CREATE TABLE schedule ( id INT PRIMARY KEY AUTO_INCREMENT, doctor_id INT NOT NULL, work_date DATE NOT NULL, -- 具体出诊日期 period TINYINT NOT NULL, -- 时段：1上午 2下午 total_slots INT NOT NULL, -- 总号源 booked_slots INT DEFAULT 0, -- 已约号源 status TINYINT DEFAULT 1, -- 1正常 0停诊 UNIQUE KEY uk_doctor_date (doctor_id, work_date, period) ); CREATE TABLE orders ( id INT PRIMARY KEY AUTO_INCREMENT, out_trade_no VARCHAR(32) NOT NULL UNIQUE, -- 商户订单号 schedule_id INT NOT NULL, patient_id INT NOT NULL, doctor_id INT NOT NULL, visit_date DATE NOT NULL, visit_period TINYINT NOT NULL, fee INT NOT NULL, -- 单位：分 status TINYINT NOT NULL, -- 0待支付 1已支付 2已取消 3已完成 pay_time DATETIME, cancel_time DATETIME ); CREATE TABLE record ( id INT PRIMARY KEY AUTO_INCREMENT, patient_id INT NOT NULL, order_id INT NOT NULL, doctor_id INT NOT NULL, diagnosis VARCHAR(500), prescription TEXT, record_date DATETIME DEFAULT CURRENT_TIMESTAMP );

核心设计思路是：schedule是排班实例，orders通过schedule_id关联具体排班，同时冗余doctor_id、visit_date、period方便查询；record通过order_id和就诊记录挂钩。注意orders里的金额fee我用了整数单位“分”，这是支付系统的惯例，避免浮点误差。

拿到源码包先核对这几点：schedule有没有唯一键防止同一医生同一天同一时段重复排班；orders有没有out_trade_no唯一索引；recor有没有冗余患者 ID 而不是只靠order_id反查。缺任何一个，上线后都会变成半夜把你叫醒的隐患。

3. 医生排班模块：排期表设计对了，后面所有功能都顺

排班是挂号系统的地基。这块没想清楚，预约、支付、就诊记录全都跟着歪。很多源码包的排班逻辑看着能用，实际上用“周几出诊”直接写死，一到节假日就翻车。

3.1 为什么不能把“周几出诊”写死：模板与实例要分离

排班最容易犯的错，是在医生表里直接存available_weekdays = '1,3,5'，表示这位医生周一三五出诊。听起来没问题，但真运营起来会遇到三个坎：法定节假日门诊调休、医生临时停诊、临时加半天号。如果只用星期，每次都只能改代码或者手工改数据库，完全谈不上“可直接上线”。

成熟的排班设计是模板与实例分离。模板描述“这个医生常规周几出诊、放多少号”，实例才是“某年某月某日上午实际有号”。源码包里至少应该有这两张表：

CREATE TABLE schedule_template ( id INT PRIMARY KEY AUTO_INCREMENT, doctor_id INT NOT NULL, week_day TINYINT NOT NULL, -- 1-7，对应周一到周日 period TINYINT NOT NULL, -- 1上午 2下午 total_slots INT NOT NULL, UNIQUE KEY uk_template (doctor_id, week_day, period) ); CREATE TABLE schedule ( id INT PRIMARY KEY AUTO_INCREMENT, doctor_id INT NOT NULL, work_date DATE NOT NULL, period TINYINT NOT NULL, total_slots INT NOT NULL, booked_slots INT DEFAULT 0, status TINYINT DEFAULT 1, UNIQUE KEY uk_schedule (doctor_id, work_date, period) );

关键逻辑是：管理员设定模板后，系统按自然日生成未来一个月的schedule实例；遇到节假日或调休，只调整实例，不动模板。这样患者看到的永远是具体日期，而不是抽象的一周规律。

模板和实例分离还有一个好处：统计医生出诊率时，按模板算应出诊天数，按实例算实际出诊天数，停诊记录一查便知，不会把临时加号算成缺勤。

3.2 排班查询接口：按科室和日期拉出医生列表

前端排班页一般长这样：顶部切换日期，下面显示当天的科室，点科室展开医生列表，每个医生后面跟号源余量。后端接口要解决的核心问题是“某一天，有哪些医生有号，还剩多少”。

// routes/schedule.js - 查询某日某科室的排班 router.get('/list', async (req, res) => { const { deptId, date } = req.query; // 参数校验：date 必须是 YYYY-MM-DD 格式 if (!date || !/^\d{4}-\d{2}-\d{2}$/.test(date)) { return res.status(400).json({ code: 1, message: '日期格式不正确' }); } const sql = ` SELECT d.id AS doctor_id, d.name, d.title, s.id AS schedule_id, s.period, s.total_slots, s.total_slots - s.booked_slots AS remain_slots, s.status FROM schedule s JOIN doctor d ON s.doctor_id = d.id WHERE d.dept_id = ? AND s.work_date = ? ORDER BY s.period, d.id `; const list = await db.query(sql, [deptId, date]); // 余量为0或停诊的医生，前端置灰但保留展示 res.json({ code: 0, data: list }); });

这段代码有四个要点。第一，日期格式必须严格校验，否则 SQL 可能被注入，这类源码包最常见的问题就是接口裸奔。第二，余量用total_slots - booked_slots实时算，不要在表里单独存remain_slots字段，否则并发下单时这个字段极难维护。第三，停诊的和约满的医生不要从结果里过滤掉，前端要展示出来，不然患者会以为没有这个医生。第四，排序先按时段再按医生 ID，保证上午下午分组清晰。

前端拿到数据后，渲染逻辑通常是：余量大于 0 且状态正常，按钮可点；余量等于 0 显示“约满”；状态为 0 显示“停诊”。注意停诊的医生余量可能还是正的，前端判断时要把status放在remain_slots前面判断。

3.3 停诊与加号：两个最容易翻车的边界

停诊的处理，新手最容易踩的坑是直接删除当天的schedule记录。删了之后，已预约的患者订单还挂着这条排班 ID，查询就变成空引用，患者端显示不出医生是谁，简直是最差的产品体验。

正确的做法是给schedule加status字段，停诊只置为 0。前端展示“停诊”状态，后端要额外跑一个通知任务：查当天所有status = 0的排班，再查关联的已支付订单，给患者发订阅消息或短信，告知停诊并引导进入退款流程。这一步源码包不一定有现成实现，但直接决定“可直接上线”这句话成不成立——没有停诊通知的挂号系统，上线第一周就会被投诉淹没。

加号则是另一个极端：医生临时说下午加 10 个号。实现方式不建议去改schedule.total_slots，因为你不知道已经有多少人挂了号，改总数容易导致超卖。更稳的方式是新增一张additional_slots表，把加号作为独立号源叠加，或者干脆新建一个period = 3的“加号”时段。我一般用独立时段，逻辑最简单，对账也清楚。

4. 预约下单与微信支付：状态机写完，对账才能睡得着觉

预约支付是整个系统里最不能“跑通就行”的部分。支付涉及真金白银，状态机写不好，对账对不上，退款退错，比排班错乱麻烦十倍。

4.1 订单状态机：不要只存“已支付/未支付”两个值

我见过不少源码包把订单状态设计成0 未支付 / 1 已支付两个值，然后就没了。这在小规模演示里够用，一旦上线，你会发现还缺五种状态：已取消、待退款、已退款、已完成、支付超时。下面是建议的状态定义：

状态流转的硬规则只有三条：待支付能转已支付或已取消；已支付能转已完成或退款中；退款中只能转已退款。禁止从已支付直接改成已取消，也禁止状态倒流。代码里要写成状态机函数，而不是到处散落order.status = 2这种赋值，否则三个月后你自己都不知道哪些分支漏了。

// utils/orderStatus.js const TRANSITIONS = { 0: [1, 2], // 待支付 -> 已支付 / 已取消 1: [3, 4], // 已支付 -> 已完成 / 退款中 4: [5], // 退款中 -> 已退款 }; function canTransit(from, to) { return TRANSITIONS[from]?.includes(to) || false; }

在写更新订单的 SQL 时，把状态机检查直接写进条件里，这是防并发最重要的一招：

UPDATE orders SET status = 2, cancel_time = NOW() WHERE id = ? AND status = 0;

这条 SQL 的关键在于AND status = 0。如果两个请求同时取消同一笔订单，只有第一个能把status从 0 改成 2，第二个因为条件不满足影响行数为 0，接口直接返回“订单状态已变化”。这种数据库层面的乐观锁，比先查再改稳妥得多。

4.2 微信支付接入：下单、验签回调、主动查单三个关键点

源码包一般已经封装好了支付参数，但你要自己验证三个环节。第一是统一下单，前端拿到paySign才能调起支付；第二是回调验签，平台发到你的notify_url的通知必须验签；第三是主动查单，因为回调可能丢，必须有定时任务补单。

// routes/order.js - 微信支付统一下单（Node.js 版） const crypto = require('crypto'); router.post('/pay', async (req, res) => { const { orderId } = req.body; const order = await db.query('SELECT * FROM orders WHERE id = ?', [orderId]); if (!order || order.status !== 0) { return res.json({ code: 1, message: '订单不存在或已支付' }); } // 微信支付 V3 接口：POST /v3/pay/transactions/jsapi const payParams = { appid: config.appId, mchid: config.mchId, description: `挂号费-${order.doctor_name}`, out_trade_no: order.out_trade_no, notify_url: config.notifyUrl, // 必须是公网可访问的 HTTPS 地址 amount: { total: order.fee }, // 单位是分 payer: { openid: req.user.openid }, }; const result = await requestPay(payParams); // 返回给前端 wx.requestPayment 所需参数 res.json({ code: 0, data: { timeStamp: result.timeStamp, nonceStr: result.nonceStr, package: result.package, signType: 'RSA', paySign: result.paySign, }, }); });

回调处理是重中之重，按这个顺序写绝对没错：先验签，再解包，再查订单，再更新状态，最后返回成功应答。验签失败和订单不存在都要记录日志。

// routes/payNotify.js - 支付回调处理 router.post('/notify', async (req, res) => { const { headers, body } = req; // 第一步：验签，防止伪造回调 const valid = verifyPaySign(headers, body); if (!valid) { return res.status(401).send('FAIL'); } const { out_trade_no, trade_state } = body; if (trade_state !== 'SUCCESS') { return res.status(200).send('FAIL'); } // 第二步：幂等更新，status=1 且要求原状态是 0 const result = await db.query( `UPDATE orders SET status = 1, pay_time = NOW() WHERE out_trade_no = ? AND status = 0`, [out_trade_no] ); if (result.affectedRows === 1) { // 第三步：扣减号源，这里用原子 SQL，避免超卖 await db.query( `UPDATE schedule SET booked_slots = booked_slots + 1 WHERE id = ? AND booked_slots < total_slots`, [order.schedule_id] ); } res.status(200).send('SUCCESS'); });

这里有个容易翻车的顺序问题：必须先改订单状态，再扣号源，并且两部分要保证最终一致。如果先扣号源再改订单，回调重试时号源被重复扣；如果只改订单不扣号源，库存和订单就会对不上。我建议整个回调逻辑放在数据库事务里执行，或者用消息队列异步处理扣库存；最简单的做法是两步都写在同一个事务里，出错回滚，回调平台会自动重试。

4.3 支付超时与主动查单：不能让死单躺一晚上

回调丢单是支付系统最经典的玄学问题。表现为用户明明付了钱，订单还停在“待支付”。原因通常是：回调通知网络超时、本地调试时notify_url用的内网穿透工具失效、或者回调处理代码抛了异常。解决思路是加一个定时查单任务，每 5 分钟扫一遍状态为 0 且创建超过 30 分钟的订单，调用微信支付查单接口确认真实状态。

如果平台返回已支付，就直接走一遍和回调一样的更新逻辑；如果返回未支付，而且订单已经超时，就关单并把库存释放。这个兜底任务建议上线第一天就开着，别等丢单了再加。

5. 就诊记录模块：列表好做，权限和脱敏才是难点

就诊记录是患者使用频率最高的功能之一。很多人觉得这就是一个列表查询，实际上这里藏着隐私合规、数据脱敏、身份绑定三个问题，处理不好容易吃投诉，甚至被平台下架功能。

5.1 就诊记录的字段与来源：先想清楚数据从哪来

就诊记录表不能只存“医生说了什么”。要给患者看，至少要包含：就诊时间、就诊科室、医生姓名和职称、诊断结果、处方内容、本次费用。再看一遍第 2 章的表结构，record里的diagnosis和prescription是文本字段，这里存的是医生填写的结构化结论，不是病历全文。

数据来源是这块最大的坑。源码包所谓“就诊记录功能”，如果配套了医生端录入，那来源就解决了；如果没有，记录表永远空着，患者点进去一片空白。我常见的做法是：先在小程序里加一个简易医生端，医生看诊后在手机上勾选诊断、填处方、提交，数据直接入record表。走通之后再考虑对接院内 HIS 系统，把历史就诊记录批量导入。

不建议一开始就追求对接 HIS，那是一个独立的大工程。先让医生在小程序里把记录填起来，患者端立刻有东西看，这个功能才算“上线”。

5.2 患者端查询：分页、脱敏、空态

患者端接口要处理三件事：分页、脱敏、只查询自己。分页是老生常谈，脱敏是很多人忽略的：医生在记录里可能填了患者手机号、地址等敏感信息，展示给患者自己看问题不大，但要防止接口被恶意遍历时泄露他人数据。

// routes/record.js - 患者查询就诊记录 router.get('/my', async (req, res) => { const { page = 1, pageSize = 10 } = req.query; const patientId = req.user.patientId; // 来自登录态，不是前端传参 // 必须用 patient_id = ? 过滤，禁止返回全表 const list = await db.query( `SELECT id, doctor_name, dept_name, diagnosis, prescription, DATE_FORMAT(record_date, '%Y-%m-%d %H:%i') AS record_time, fee FROM record WHERE patient_id = ? ORDER BY record_date DESC LIMIT ? OFFSET ?`, [patientId, pageSize, (page - 1) * pageSize] ); // 脱敏：医生填写的联系方式打码 const safeList = list.map((item) => ({ ...item, prescription: item.prescription ? item.prescription.replace(/(1\d{2})\d{4}(\d{4})/g, '$1****$2') : '', })); res.json({ code: 0, data: { list: safeList, hasMore: list.length === pageSize } }); });

关键点有三个。第一，patientId必须从登录态 token 解析，绝不能相信前端传过来的参数，否则用?patientId=3就能看任意患者的记录。第二，LIMIT 的OFFSET要自己算，直接用页号和页大小拼 SQL，注意LIMIT ? OFFSET ?在大多数数据库方言里就是LIMIT 10 OFFSET 0，别把参数顺序搞反。第三，脱敏正则只处理了手机号一种格式，如果医生填了座机或身份证，需要补更多规则。

前端列表页的核心交互只有两个：下拉刷新和触底加载。空态文案要写清楚——“暂无就诊记录”，引导用户去预约挂号，而不是白屏。

5.3 权限边界：患者身份绑定与医生端隔离

就诊记录是敏感数据，权限设计至少要有两层。第一层是患者自己：小程序登录用wx.login拿到 openid，首次使用时要求绑定就诊人手机号，绑定关系存在patient表里，之后所有查询都以这个patient_id为准。绑定要做成可解绑的，否则换手机号的患者会永远卡在这一步。

第二层是医生端：医生登录后只能查看自己名下的患者记录，不能查全科室。接口查询条件必须带doctor_id = req.user.doctorId。如果源码包给了医生端，重点验这条隔离；如果没给，宁可不做医生端，也不能让医生账号能拉全量数据。

隐私这块还有个合规细节：不要在前端日志里打印完整的身份证号、手机号，数据库里敏感字段建议加密存储。上线前的隐私声明里要写明收集了哪些信息、用于什么目的，否则小程序审核时容易被驳回。

6. 上线前避坑：审核、回调、排班、超卖，五个必查项

最后的这章是直接决定你“能不能上线”的关卡。代码跑通只是第一步，下面这五个问题是过去反复出现的翻车点，按“现象 → 原因 → 解决”列给你，照着自查一遍再点交付。

6.1 现象：小程序审核被驳回，理由是服务类目与资质不符。原因：挂号涉及医疗服务，需要用医疗相关类目，而且部分类目要求提供医疗机构执业许可证等资质；独立个人开发者通常过不了这类类目。解决：确认自己的主体是公司或医疗机构；在公众平台选择正确的服务类目，上传对应资质；如果主体是个人，先把小程序挂靠到有资质的机构名下，或改用服务号加 H5 的方式过渡。这个流程至少预留 1~2 周，别把它算进开发排期里。

6.2 现象：用户支付成功后订单还是“待支付”，钱也没到账记录。原因：回调通知没收到，或者回调处理代码抛异常后没有正确应答，平台判断通知失败会停止重试。解决：第一步保证notify_url是公网 HTTPS 地址，且防火墙放行；第二步在回调入口加日志，记录请求头和原始报文；第三步按 4.3 节加定时查单任务，每 5 分钟扫一遍超时订单调用查单接口补单；最后留着人工对账入口，财务每天核对平台账单和本地订单数。

6.3 现象：排班跨月时，月底最后一周的号源显示错乱，或直接消失。原因：生成排班实例时用了“本周日期加 7 天”的循环方式，遇到跨月时没有按自然月边界截断；比如 6 月 30 日加 7 天算到 7 月 7 日，而排班查询只查 6 月，导致排班显示不完整。解决：生成排班统一按自然日递增：startDate + N逐日生成，循环终止条件是日期到达月底；生成后做一次完整性校验，统计每个医生应出诊天数和实际排班天数，不一致就告警。

6.4 现象：同一时段最后一个号被两个用户同时约到，订单都显示成功。原因：下单时先查booked_slots < total_slots，再插入订单，两个请求同时通过检查，造成超卖。解决：下单时用乐观锁更新排班表，SQL 里带WHERE booked_slots < total_slots，影响行数为 0 就返回“号源不足”；订单表和排班表的更新必须放在同一事务里。如果并发量大，再用 Redis 对schedule_id加分布式锁，但基础依然是数据库这层原子更新兜底。

6.5 现象：就诊记录接口上线第二天被打爆，服务器 CPU 飙高。原因：接口没做登录校验、没限流，攻击者用一个有效 token 遍历patient_id拉取数据，或者恶意高频调用。解决：所有查询接口强制鉴权，患者只能查自己；加一层缓存，同一个患者 5 分钟内的重复查询直接命中缓存；在网关或中间件里对单个 openid 的接口频率做限制，超限返回 429。

上线前，我会把这些场景全部走一遍：预约支付成功、支付后主动取消并退款、停诊触发退款、同一个号源并发抢最后的号、患者只看得到自己的记录。这一套流程走完，我才会把源码包交付出去。特别是回调补单那个定时任务，头一个星期每天对一次账，对数没问题再放手。这套源码包的核心不在代码本身，而在于你把上面这些边界都兜住了——兜住了，它才是真的“可直接上线”。希望帮到你。

本文还有配套的精品资源，点击获取