简介这是一款面向计算机专业学生的微信小程序毕业设计项目实现医院预约挂号全流程采用微信小程序开发工具、Java、MySQL与B/S架构适合毕业设计或课程设计参考。压缩包共1922个文件、约120.5MB主要包含后端Java源码、小程序前端页面、管理端HTML页面、SQL脚本、XML与JSON配置以及大量GIF演示图等结构清晰便于按模块查阅。系统分为后台管理与小程序端后台支持医生与科室信息管理、公告发布、预约查看审核小程序端支持医生详情查看、在线预约、基础信息浏览及他人评价参考。随包附有部署说明与演示视频可辅助快速搭建环境并理解完整业务流程已有3484人学习/浏览适合需要完整项目案例的开发者参考。1. 微信小程序医院预约挂号毕设这份资源包能帮你解决哪些实际问题A同学选了“基于微信小程序的医院预约挂号”当毕业设计原以为小程序只是搭界面结果卡在登录授权和号源扣减上磨了一周。这个题目看着简单实际是一条完整业务闭环微信授权登录、科室医生排班、余号变更、预约状态流转、后台数据重置任何一环断了整个系统都跑不通。这套源码包把链路做成了可直接复现的项目实例后端接口、小程序页面、数据库脚本都齐备还附部署说明和演示视频。适合拿它完成毕业设计或课程设计的同学也适合想快速上手小程序前后端联调的开发者以及需要一个完整开发实例照着改的入门者。2. 预约挂号业务闭环登录、排班、预约的数据流向与表设计拆这套资源的时候我习惯先不看代码把业务链路画出来。预约挂号和小程序商城、点餐这类项目最大的区别在于它有两个核心状态需要在不同端同步维护一个是排班号源另一个是预约单状态。两个状态一旦脱节就会出现“明明约满了还能下单”“医生排班改了旧预约还挂在上面”这种让答辩老师追着问的硬伤。后端我按最常见的 Java Spring Boot MySQL 方案来讲不管源码里用的是 Node 还是 PHP表结构和接口逻辑基本都是同一套思路。理解数据怎么流比背接口更重要。2.1 数据流四段链路登录、科室、排班、预约分别处理什么小程序端和后端的交互可以从四次核心请求来看。第一次是登录小程序通过wx.login拿到临时 code后端拿这个 code 换 openid再生成业务 token 返回给前端。第二次是拉科室列表一个 GET 请求返回所有科室。第三次是按科室或医生查排班这里返回的不只是排班记录还要带出医生姓名、职称、时段、余号这些展示信息。第四次是创建预约前端把排班 id、患者姓名、手机号等提交上去后端校验余量、扣号源、写订单一气呵成。为什么登录要单独拎出来讲因为大部分小程序毕设的“翻车位”就在这。后端换 openid 依赖小程序的 AppID 和 AppSecret很多同学用的是开发者工具里的测试号后端的配置却还是另一个应用的信息于是数据流根本走不通。排班查询的返回结构一般是下面这样{ scheduleId: 101, doctorName: 王某, title: 副主任医师, deptName: 心内科, workDate: 2025-12-20, period: 上午, totalCount: 30, bookedCount: 18, remainCount: 12 }这里的关键参数是remainCount前端要拿它控制按钮状态余号小于等于 0 时禁用“预约”按钮。但要注意前端禁用只是体验优化后端必须再做一次余号校验否则绕过小程序直接调接口就能超卖。这也是后面避坑章节里会展开的重点。2.2 排班表与号源表预约系统最核心的建模方式预约挂号系统的核心表通常就两张一张是排班表一张是预约记录表。排班表记录“某医生某天某个时段一共放了多少号、已经约掉多少”预约记录表记录“谁约了哪个排班的号、状态如何”。两张表通过schedule_id关联每次预约下单就是一次“给排班表加已约数同时插入一条预约记录”的过程。排班表常见的建表语句长这样CREATE TABLE schedule ( id INT NOT NULL AUTO_INCREMENT, doctor_id INT NOT NULL COMMENT 医生ID, work_date DATE NOT NULL COMMENT 出诊日期, period TINYINT NOT NULL COMMENT 1-上午 2-下午, total INT NOT NULL DEFAULT 30 COMMENT 总号源数, booked INT NOT NULL DEFAULT 0 COMMENT 已预约数, PRIMARY KEY (id), UNIQUE KEY uk_doctor_date_period (doctor_id, work_date, period) ) ENGINE InnoDB DEFAULT CHARSET utf8mb4;预约记录表核心字段如下CREATE TABLE appointment ( id INT NOT NULL AUTO_INCREMENT, schedule_id INT NOT NULL COMMENT 排班ID, user_id INT NOT NULL COMMENT 用户ID, patient_name VARCHAR(50) NOT NULL COMMENT 就诊人姓名, patient_phone VARCHAR(20) NOT NULL COMMENT 联系电话, status TINYINT NOT NULL DEFAULT 0 COMMENT 0-待就诊 1-已完成 2-已取消, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id) ) ENGINE InnoDB DEFAULT CHARSET utf8mb4;几个容易忽略的设计点。排班表上的唯一键很有价值它保证同一医生同一天同一时段只能有一条排班记录避免数据重复。预约表不直接存total和booked因为这两个值属于排班预约单只需要关心“约了哪个排班”即可。status字段用数字而不是字符串是因为后续统计“今日就诊人数”“取消率”时要对状态做聚合统计数字状态更利于 SQL 编写。预约记录采用“只改状态不删记录”的策略也是因为答辩时老师很可能会问“用户取消预约之后数据怎么处理”保留记录并置为已取消是最容易被接受的方案。余号不需要单独设计一个字段去存total - booked就是实时余号。这样每次预约只更新booked不用担心两个字段被改得不一致。3. 本地复现流程环境配对、建库命令和小程序端配置拿到资源包之后我最建议的顺序是先按部署说明把环境对齐再建库导数据最后改小程序端的请求地址。很多同学上来就双击打开小程序项目看到白屏报错就开始怀疑源码有问题其实九成是后端没起来或者数据库没连上。3.1 环境准备几个版本怎么搭配最省事拆过的毕设资源里这套项目最常见的后端组合是 JDK 8 Spring Boot 2.x MySQL 5.7 或 8.0。小程序端用微信开发者工具开一个“小程序”类型的空项目然后把源码里的miniprogram目录导入进去。数据库工具我习惯用 Navicat但命令行也完全可以。环境版本上有个经验Spring Boot 2.x 搭配 JDK 8 最稳Spring Boot 3.x 强制要求 JDK 17如果部署说明里写的是 2.x你硬装 JDK 17 反而可能因为依赖兼容问题起不来。MySQL 用 5.7 或 8.0 都可以但连接串里的驱动版本要匹配8.0 建议用com.mysql.cj.jdbc.Driver。下面是一张常见的版本搭配表照着配能少走弯路组件建议版本备注JDK1.8Spring Boot 2.x 项目最稳MySQL5.7 / 8.0建库必须指定 utf8mb4Maven3.6用来拉后端依赖微信开发者工具稳定版即可调试时勾选“不校验合法域名”后端 IDE任意能改 yml 和启动类即可3.2 建库导数据三步把数据库准备好打开 MySQL 客户端先建库再导入项目自带的 SQL 脚本。注意必须先建库再use否则source脚本时如果脚本里没写库名表会建到默认库里。mysql -uroot -p CREATE DATABASE hospital_db DEFAULT CHARACTER SET utf8mb4; USE hospital_db; SOURCE /your/project/path/sql/hospital_db.sql;这段命令做的事情很直白创建hospital_db数据库指定utf8mb4字符集然后执行项目里的建表脚本。utf8mb4不是可选项医院预约系统里就诊人姓名、科室名称都会有中文用这个字符集才能避免乱码。导入完成后用SHOW TABLES;查看一下有没有生成doctor、schedule、appointment这几张核心表。接着改后端配置。资源包里的部署说明一般会把application.yml的位置标出来你要做的是把数据库账号密码改成自己本机的server: port: 8080 spring: datasource: url: jdbc:mysql://127.0.0.1:3306/hospital_db?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver这里最容易踩坑的是serverTimezone。不加这个参数高版本 MySQL 驱动连接时会直接报时间区错误。characterEncodingutf8配合建库时的utf8mb4双保险防乱码。改完后端配置后启动项目看到 Tomcat 端口 8080 的日志说明后端已经起来了。3.3 小程序端配置请求地址指向哪里小程序端需要改的核心文件就是app.js或一个独立的请求封装工具类。通常项目会把接口根地址放在globalData里方便全局引用。App({ globalData: { // 后端服务地址真机调试时改成电脑的局域网IP baseUrl: http://127.0.0.1:8080/api } });baseUrl这个参数决定小程序所有请求打到哪台服务器。模拟器调试时用127.0.0.1没问题因为模拟器和开发电脑共享网络。真机预览时必须把它改成电脑在局域网里的 IP否则手机访问不到电脑上的后端。改完请求地址后还要确认一件事在微信开发者工具的“详情-本地设置”里勾选“不校验合法域名、web-view业务域名、TLS 版本以及 HTTPS 证书”。不勾这个选项请求本地 HTTP 接口会被拦截。这个配置只影响开发调试真正发布上线时必须配置合法域名并走 HTTPS这又是另一个话题了。4. 核心接口与事务排班聚合查询、预约下单与取消的状态处理环境跑通之后剩下的主要工作是读懂核心接口。我在拆这个项目时会把注意力集中在三个接口上排班查询、创建预约、取消预约。这三个接口的好坏直接决定项目答辩时的说服力。4.1 排班聚合查询一次查出医生、时段、余号排班列表页需要展示的信息分散在两张表里排班表有日期和余号医生表有姓名和职称科室表有科室名。如果前端先查排班再逐个查医生就会出现 N1 查询数据量小的时候看不出来演示时翻页快了就会明显卡顿。常见做法是在后端做一次 JOIN 查询把结果装进一个聚合 VO。public ScheduleVO getScheduleDetail(Long scheduleId) { Schedule schedule scheduleMapper.selectById(scheduleId); Doctor doctor doctorMapper.selectById(schedule.getDoctorId()); ScheduleVO vo new ScheduleVO(); vo.setScheduleId(schedule.getId()); vo.setDoctorName(doctor.getName()); vo.setTitle(doctor.getTitle()); vo.setWorkDate(schedule.getWorkDate()); vo.setPeriod(schedule.getPeriod()); vo.setTotalCount(schedule.getTotal()); vo.setBookedCount(schedule.getBooked()); vo.setRemainCount(schedule.getTotal() - schedule.getBooked()); return vo; }这段代码的核心逻辑是组装视图对象remainCount由total - booked实时算出。为什么不把余号存成字段原因前面提过存成字段就要在预约下单时维护两个数一旦更新逻辑漏了某一处界面显示的余号和真实号源就对不上。ScheduleVO的作用是把前端要展示的字段一次性给全前端拿到后直接渲染不需要再做二次关联查询。4.2 创建预约与取消预约状态更新顺序的讲究创建预约是这套系统的事务核心。正确顺序是先扣减排班号源再插入预约记录两步放在同一个事务里。如果先插预约记录再更新号源一旦第二步失败就会出现“预约单存在但号源没扣”的脏数据。Transactional public boolean createAppointment(AppointmentReq req) { // 条件更新被影响行数为0说明号源已满或排班不存在 int rows scheduleMapper.decreaseRemain(req.getScheduleId()); if (rows 0) { return false; } Appointment appointment new Appointment(); appointment.setScheduleId(req.getScheduleId()); appointment.setUserId(req.getUserId()); appointment.setPatientName(req.getPatientName()); appointment.setPatientPhone(req.getPatientPhone()); appointment.setStatus(0); // 待就诊 appointmentMapper.insert(appointment); return true; }scheduleMapper.decreaseRemain对应的 SQL 是预约系统里最值得看的一行UPDATE schedule SET booked booked 1 WHERE id #{scheduleId} AND booked total;这个更新语句做了两件事把已约数加一同时利用booked total条件判断是否还有号源。total是排班总数booked是已约数只有booked小于total时更新才生效。rows是受影响行数等于 0 说明没有匹配的行可更新也就是号已经约满此时整个事务回滚appointment不会插入。这比“先查询余号再判断再更新”安全得多因为查询和更新之间有时间差两个并发请求同时进来就可能双双通过检查也就是所谓的超卖。取消预约则是反向操作先把预约状态改成已取消再把排班的booked减回去Transactional public boolean cancelAppointment(Long appointmentId) { Appointment appointment appointmentMapper.selectById(appointmentId); if (appointment null || appointment.getStatus() ! 0) { return false; } appointmentMapper.updateStatus(appointmentId, 2); // 已取消 // 号源释放booked 不能减成负数 int rows scheduleMapper.increaseRemain(appointment.getScheduleId()); return rows 0; }取消预约的 SQL 也要加保护条件booked必须大于 0 才能减UPDATE schedule SET booked booked - 1 WHERE id #{scheduleId} AND booked 0;这个保护条件平时用不上但演示时如果手动改数据库把booked改成 0 再去取消没有这个条件就会出现负数余号看起来非常不专业。5. 部署避坑预约挂号项目最常见的五个翻车点与修法这个资源包附了演示视频和部署说明但环境差异导致的问题说明文档未必全覆盖。下面是拆这类毕设项目时反复遇到的五个问题按“现象、原因、解决”的思路整理出来每条都是可以直接照做的修法。5.1 登录失败微信登录始终提示“invalid code”现象模拟器里点击微信登录后端一直返回invalid code换一个账号也不行。最让人头疼的是项目和部署说明分明是配套的。原因小程序端使用的 AppID 和后端配置文件里的 AppSecret 不是同一套应用的信息。很多人用开发者工具自动生成的测试号而后端配置里写的是资源作者自己应用的信息两边对不上。解决到小程序后台申请自己的 AppID把project.config.json里的appid换成自己的同时把后端的appsecret换成对应应用的值。如果只是为了本机跑通演示用测试号也行但后端配置要同步替换成测试号对应的密钥两边必须保持一致。替换后重新编译小程序再拉一次 code 重新走登录流程。5.2 请求后端报错开发者工具提示“url not in domain list”现象小程序页面能渲染但只要一调接口就报url not in domain list或者直接提示网络错误后端的日志里看不到任何请求进来。原因小程序默认只允许向配置好的合法域名发请求而本地开发时后端是http://127.0.0.1:8080既不是合法域名也不是 HTTPS所以被拦住了。解决在微信开发者工具里点击“详情-本地设置”勾选“不校验合法域名、web-view业务域名、TLS 版本以及 HTTPS 证书”。这个选项只对开发工具有效真机预览时同样要开启调试模式否则真机上也会拦截。上线的合规配置是在小程序后台把后端 HTTPS 域名加到 request 合法域名列表里本地复现阶段不用管这些。5.3 页面中文乱码科室名称和患者姓名变成问号现象后端启动正常接口也返回了数据但小程序页面上的中文全是?或者乱码。原因MySQL 数据库默认字符集不是utf8mb4或者 JDBC 连接串里没有加characterEncodingutf8。乱码问题几乎都是字符集不一致导致的数据库、连接串、页面编码三个环节只要有一处不是 UTF-8中文就会出问题。解决建库时显式指定字符集CREATE DATABASE hospital_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;然后检查application.yml里的 JDBC 连接串有没有useUnicodetruecharacterEncodingutf8这两个参数。改完重启后端重新导入一次数据脚本乱码大概率能消失。5.4 号源超卖两个人同时预约只剩 1 个号的排班都成功现象排班余号只剩 1 个用两个微信号同时操作两端都提示预约成功后台数据里两条预约记录并存余号变成负数。原因代码里先查余号再判断是否大于 0最后才更新号源。查询和更新之间有一个时间窗口两个请求都读到余号是 1都认为自己有资格预约于是双双写入。解决把“判断余号”和“扣减号源”合并成一条条件更新语句也就是第 4 章里的做法UPDATE schedule SET booked booked 1 WHERE id #{scheduleId} AND booked total;受影响行数为 0 时返回预约失败。这个写法把判断和更新放在同一条 SQL 里数据库的行锁天然保证同一时刻只有一个事务能更新成功另一个请求会因booked total不成立而更新 0 行。5.5 后端起不来端口被占用或数据库密码配置不一致现象按部署说明启动后端控制台报Port 8080 was already in use或者Access denied for user rootlocalhost。原因端口占用一般是本机已经有其他服务占用了 8080数据库密码报错则是application.yml里的账号密码和本地 MySQL 实际密码不一致。这类问题不算项目 bug纯粹是环境差异。解决先查端口占用情况在命令行执行netstat -ano | findstr 8080找到占用 8080 的进程 PID确认可以结束后用任务管理器结束进程或者直接改application.yml里的server.port为 8081。数据库连接失败时逐项核对url、username、password三个配置。如果本机 MySQL 密码为空就把 password 留空或写成password: 。提示改完配置文件必须重启后端很多同学改了application.yml之后只刷新页面请求当然还是老配置。6. 验收与答辩技巧把项目从“能跑”讲到“能讲清”项目跑起来之后离“能答辩”还有一步把演示过程变成一条有逻辑的主线而不是零散地展示页面。6.1 演示前必须走完的三项自检第一项自检是清空演示数据。反复测试会留下大量预约记录和过期排班演示前把预约表清空把排班的booked改回 0保证从首页开始就是干净状态DELETE FROM appointment; UPDATE schedule SET booked 0;第二项自检是完整走一遍核心链路登录授权、进科室列表、选医生、看排班、预约、我的预约列表、取消预约。每一步都要确认页面状态和数据库记录对应得上。第三项自检是准备一个失败场景把某个排班的booked改成等于total演示时点预约按钮前端要提示号源已满给老师展示你对边界条件的处理。6.2 值得加的一个小亮点号源余量即时展示如果项目本身没有做这个功能可以加一个“余号不足提醒”排班详情页展示“仅剩 N 个号”当余号少于 5 时显示提醒。这个改动很小却能让答辩老师直观看到前端和后端数据是联动的。实现方式是在 4.1 的ScheduleVO里加一个布尔字段lowStock余号小于 5 时置为 true前端根据这个字段切换提示样式。后端完成计算前端只负责展示逻辑闭环清晰。从那以后我拆任何小程序毕设包都会先跑通一条完整的预约主链路确认号源扣减和状态流转都对得上再去研究页面样式和附加功能。先把主链路验证扎实再谈锦上添花这是最省时间的项目落地方式。希望帮到你。本文还有配套的精品资源点击获取