简介微信小程序与SSM后台结合的医院挂号系统毕业设计资源面向计算机及相关专业毕业生、需要快速搭建完整项目的开发者。项目覆盖患者、医生、科室、专家、预约与取消预约申请等核心模块后台基于SSM框架数据库采用MySQL后台管理员可在浏览器中登录管理数据前端使用微信开发者工具整体具备界面清晰、操作简单、功能完整的特点。压缩包共858个文件包含java后台源码、vue前端页面、JavaScript逻辑、SQL脚本与数据库备份、毕业论文文档及mp4视频演示主要文件类型涉及png/svg/jpg图片素材、json/xml/wxml/wxss配置与页面文件等包体约46.83MB。资源已有180人学习下载。下载后可直接对照源码、数据库脚本与论文说明完成环境部署、模块调试和答辩展示适合作为毕业设计选题参考或二次开发基础。1. 医院挂号小程序这套 SSM MySQL 毕业设计到底能跑成什么样医院挂号小程序在毕业设计里出现频率一直很高但多数能找到的源码要么缺数据库脚本要么后端接口是写死的假数据真正能完整跑通的并不多。这套基于微信小程序、SSM 和 MySQL 的项目胜在把「患者—科室—医生—预约—取消申请—审核」这条链路做完整了小程序端承担患者操作SSM 后台负责接口和管理页面MySQL 存业务数据还带一份毕业论文和视频演示适合两类人——准备做医疗类课设的学生以及想快速拿一个前后端闭环练手的 Java 初学者。我按拆包的习惯来写先把技术选型讲透再落到表结构、核心接口和避坑点。2. 技术栈拆解为什么微信小程序、SSM 和 MySQL 能搭起挂号全流程2.1 小程序端为什么是微信小程序而不是 H5 或 App医院挂号这种场景有个特点使用频率低、操作流程短、用户不愿意为它单独装一个 App。微信小程序天然契合这个场景用户扫码或搜索就能进看完号源、预约、取消关掉就走不需要下载安装也不占用桌面空间。从开发角度看微信小程序的技术栈对前端新手也友好。页面由 WXML、WXSS 和 JS 组成写过 Vue 的人几乎零成本迁移组件化思路也一致。登录环节是另一个加分项小程序可以直接调用wx.login()拿 code后端拿 code 换 openid省掉了手机号验证码这套注册逻辑。毕业设计答辩时评委问「用户身份怎么来的」答一句「微信授权 openid」就足够清楚。这套项目里小程序端承担的是患者侧操作包含首页科室列表、专家信息、预约提交、我的预约、取消预约申请几个核心页面。管理后台是另外一套 Web 页面由 Vue 构建后输出静态文件后端用 SSM 提供接口。小程序和后台共用同一套数据库和接口只是角色不同。2.2 后端SSM 这套老组合为什么反而好上手SSM 是 Spring、SpringMVC、MyBatis 三个框架的组合。它不算新但在毕业设计场景里反而是最稳的选择原因有三点。第一Spring 的容器管理和事务控制特别适合预约这类有状态流转的业务。一个预约从提交到就诊、取消、审核中间涉及多次数据库读写用Transactional把几步操作包在一个事务里要么全成功要么全回滚不会出现「号源减了但预约记录没写进去」这种半截数据。第二MyBatis 把 SQL 明明白白写在 Mapper 的 XML 或注解里不像 JPA 那样靠方法名推导。答辩时被问「某个统计怎么查的」直接指 SQL 就能讲清楚。这套项目里患者管理、医生管理、科室管理、预约信息管理这些模块本质都是增删改查MyBatis 写起来最直白。第三SSM 的参考资料最多。Controller、Service、Autowired、Transactional这几个注解的用法网上随便搜都是完整案例真卡住了也容易找到人问。相比之下用 Spring Boot 的人虽然多但毕业设计如果导师指定了 SSM 场景或者论文框架已经按 SSM 搭好临时换框架的成本反而更高。2.3 工程结构的正确认识bat 脚本、Vue 管理后台与备份文件拿到这套源码先别急着找application.yml我一般是先扫一遍文件列表。这类带 Windows 部署脚本的工程文件结构往往比想象中更有信息量。工程里能看到1-install.bat、2-run.bat、3-build.bat三个脚本命名顺序就是部署顺序。按常见约定1-install.bat负责初始化环境包括检查 MySQL 是否启动、导入数据库脚本、把 Maven 依赖拉全2-run.bat启动后端服务和 Tomcat3-build.bat构建管理后台的前端静态文件。实际跑的时候我会先打开脚本看一眼里面的路径写的是绝对路径还是相对路径很多机器上跑不起来都是因为脚本里的盘符和实际解压目录对不上。管理后台是 Vue 工程构建后的产物所以能看到app.26c1910f.css这种带 hash 的静态文件还有一批.bak结尾的备份文件比如main.css.bak、IndexAsideStatic.vue.bak、update-password.vue.bak、BreadCrumbs.vue.bak、IndexHeader.vue.bak。这些.bak是改动前的留底。我的习惯是凡是准备动管理后台的样式或页面逻辑先把对应文件复制一份.bak再动手这个习惯在这套工程里已经替你做好了。MySQL 版本也要提前确认。如果本机装的是 MySQL 8.x连接驱动要配com.mysql.cj.jdbc.DriverURL 还得加serverTimezoneAsia/Shanghai否则一启动就报时区错误。装 5.7 的话用老驱动com.mysql.jdbc.Driver就行这块坑我放在第 5 章细说。3. 数据库设计预约、取消、审核背后要用到的五张核心表3.1 需求拆解从功能列表到实体关系摘要里列的功能是患者管理、医生管理、科室管理、专家信息管理、预约信息管理、取消预约申请管理和系统管理。这七个功能拆到数据库层面可以收敛成五个核心实体。患者和医生都属于用户但角色不同所以放在一张用户表里用角色字段区分还是拆成两张表这是个设计取舍。我拆过的同类项目里毕业设计一般倾向一张用户表加role字段1 管理员、2 医生、3 患者代码里用role控制菜单和接口权限少建一张表论文里也好描述。科室和专家医生是独立实体科室一对多医生。预约记录是核心业务表取消申请则是预约的附属流程表。这五个实体之间的关系很清晰患者选科室科室下有医生患者对医生发起预约预约可以发起取消申请管理员审核取消申请。对应到表就是sys_user、department、doctor_info、appointment、cancel_application五张核心表另外再加一张schedule排班表来约束医生的出诊日期和号源上限。下面先看预约这条主线。3.2 预约表设计状态机、时段字段与唯一索引预约表是全系统最关键的一张表设计好了后面的接口写起来会顺很多。核心字段通常包括患者 ID、医生 ID、预约日期、时段、状态、创建时间。其中三个设计点值得展开说。第一个是时段字段。很多同类项目把「上午 / 下午」直接存成字符串上午、下午这能跑但查询和统计的时候 SQL 写起来别扭。我一般建议存TINYINT0代表上午、1代表下午页面展示时再映射成中文。这样按时段统计号源、判断某个时段是否约满都比字符串匹配快。第二个是状态字段。预约状态不是只有「已预约」和「已取消」两个值完整的流转是这样的患者提交预约后状态为0待就诊医生完成接诊后变为1已完成患者发起取消申请时先变为2待取消管理员审核通过后才变为3已取消。中间那个「待取消」是为了让管理员的审核动作有地方落笔如果患者一点取消就直接变已取消那取消申请表就失去了存在意义。第三个是唯一索引。为了防止同一个患者在同一天重复预约同一时段可以在patient_id appointment_date time_slot上建唯一索引。这个规则一旦定下来代码里就算忘了查重数据库层也能兜底拦截。实际医院里更合理的约束是「同一患者同一天不能挂同一个医生的号」所以唯一索引的字段组合要根据你的业务规则调整答辩时能说清楚这个设计就加分。3.3 建表 SQL 与初始化数据五张核心表的建表 SQL 大致如下字段命名和源码 Mapper 里的映射保持一致直接导入就能用CREATE DATABASE IF NOT EXISTS hospital_booking DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE hospital_booking; CREATE TABLE sys_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL COMMENT 登录账号, password VARCHAR(100) NOT NULL COMMENT MD5加密后的密码, real_name VARCHAR(50) COMMENT 真实姓名, role TINYINT NOT NULL DEFAULT 3 COMMENT 1管理员 2医生 3患者, phone VARCHAR(20) COMMENT 手机号, openid VARCHAR(64) COMMENT 微信openid小程序登录后回填, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表; CREATE TABLE department ( id INT PRIMARY KEY AUTO_INCREMENT, dept_name VARCHAR(50) NOT NULL COMMENT 科室名称, intro VARCHAR(500) COMMENT 科室介绍, sort_order INT DEFAULT 0 COMMENT 排序权重 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT科室表; CREATE TABLE doctor_info ( id INT PRIMARY KEY AUTO_INCREMENT, doctor_name VARCHAR(50) NOT NULL, department_id INT NOT NULL COMMENT 所属科室ID, title VARCHAR(30) COMMENT 职称如主任医师, specialty VARCHAR(200) COMMENT 擅长领域, intro TEXT COMMENT 医生简介, max_appointments INT NOT NULL DEFAULT 20 COMMENT 每时段号源上限 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT专家信息表; CREATE TABLE appointment ( id INT PRIMARY KEY AUTO_INCREMENT, patient_id INT NOT NULL COMMENT 患者用户ID, doctor_id INT NOT NULL COMMENT 医生ID, appointment_date DATE NOT NULL COMMENT 预约日期, time_slot TINYINT NOT NULL DEFAULT 0 COMMENT 0上午 1下午, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待就诊 1已完成 2待取消 3已取消, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_patient_slot (patient_id, appointment_date, time_slot), KEY idx_doctor_date (doctor_id, appointment_date, time_slot) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT预约记录表; CREATE TABLE cancel_application ( id INT PRIMARY KEY AUTO_INCREMENT, appointment_id INT NOT NULL COMMENT 关联的预约ID, patient_id INT NOT NULL COMMENT 发起取消的患者ID, reason VARCHAR(500) COMMENT 取消原因, audit_status TINYINT NOT NULL DEFAULT 0 COMMENT 0待审核 1通过 2驳回, audit_time DATETIME COMMENT 审核时间, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT取消预约申请表;SQL 里有几个值得注意的点。全库统一用utf8mb4不是utf8否则小程序端提交的 emoji 表情和生僻字存入数据库会变成问号这是老生常谈但每次都能踩到。唯一索引uk_patient_slot防重复预约idx_doctor_date是给「按医生和日期查号源」这个高频查询用的没有这个索引预约量一大查询就会慢。max_appointments字段放在doctor_info表里表示这个医生每个时段最多接多少患者这个值决定了余号判断的阈值。初始化数据至少要有一条管理员账号和几个科室记录。管理员账号密码一般用 MD5 加密存储初始密码常见的是123456MD5 值可以直接在 SQL 里写死插入。科室数据按医院常见的几个科室插入几条即可比如内科、外科、儿科、妇产科每个科室再配一两名医生不然小程序端点进去全是空列表演示效果会打折扣。4. SSM 后端接口从登录鉴权到预约状态机核心业务怎么写4.1 Controller 层只做参数校验业务逻辑下沉到 Service看这套后端代码时先抓住分层结构。Controller 层只接收前端传来的参数做最基础的校验非空、格式然后调 Service 层方法拿到结果返回 JSON。业务逻辑一律不写在 Controller 里这是 SSM 项目的基本约定也是答辩时容易被打分老师追问的点。Controller 返回的统一结构一般是这样code表示业务状态码200 成功、401 未登录、500 异常、msg是提示信息、data是业务数据。小程序端和后端约定好这套结构前端封装的wx.request才能统一处理错误。路由设计上患者相关的接口一般放在/patient/**路径下管理端接口放在/admin/**下用拦截器做登录态校验。RequestMapping是 SSM 里最常用的一组注解类上写路径前缀方法上写具体路径和请求方式。拦截器里校验每个请求带不带合法 token不带就返回 401小程序端收到 401 后自动跳登录页这个闭环比在每个 Controller 方法里手动判断要省事得多。4.2 预约的核心逻辑事务、余号检查与状态机流转提交预约是整个系统最核心的一个接口也是答辩时最容易问到的业务点。这个接口要考虑的不只是 insert 一条记录还包括三个前置条件患者存在、医生存在、当前时段有余号。先看 Service 层的核心代码我按这套项目的典型写法整理过Service public class AppointmentService { Autowired private AppointmentMapper appointmentMapper; Autowired private DoctorInfoMapper doctorInfoMapper; Autowired private UserMapper userMapper; Transactional(rollbackFor Exception.class) public AppointmentResult submitAppointment(AppointmentRequest request) { // 1. 校验患者身份role 必须是 3患者 User patient userMapper.selectById(request.getPatientId()); if (patient null || !Objects.equals(patient.getRole(), 3)) { return AppointmentResult.fail(患者账号不存在); } // 2. 校验医生是否存在 DoctorInfo doctor doctorInfoMapper.selectById(request.getDoctorId()); if (doctor null) { return AppointmentResult.fail(所选医生不存在); } // 3. 余号检查统计该医生当天该时段已预约数量 int used appointmentMapper.countByDoctorAndSlot( request.getDoctorId(), request.getAppointmentDate(), request.getTimeSlot()); if (used doctor.getMaxAppointments()) { return AppointmentResult.fail(该时段号源已满请选择其他时段); } // 4. 写预约记录初始状态为 0 待就诊 Appointment appointment new Appointment(); appointment.setPatientId(request.getPatientId()); appointment.setDoctorId(request.getDoctorId()); appointment.setAppointmentDate(request.getAppointmentDate()); appointment.setTimeSlot(request.getTimeSlot()); appointment.setStatus(0); appointmentMapper.insert(appointment); return AppointmentResult.ok(appointment.getId()); } }这段代码的逻辑说明分四步。第一步和第二步是基础校验防止前端传了不存在的 ID 导致外键错误。第三步是余号检查countByDoctorAndSlot这条 SQL 统计的是该医生、该日期、该时段所有状态不是「已取消」的预约数量数量达到max_appointments就返回号源已满。Transactional(rollbackFor Exception.class)的作用是把校验和插入包在同一个事务里。注意rollbackFor指定了只对Exception.class回滚如果不写这个参数Spring 默认只在抛出 RuntimeException 时才回滚checked exception 是不会触发的。很多同学在这个细节上翻过车。这里有个需要认清的边界先查后插这种写法在并发高的时候会有超卖风险两个请求同时查到used 19、max 20然后都走到插入号源就变成 21 个了。毕业设计答辩如果被问到可以如实说这是课设级别的方案生产环境需要加数据库行锁或乐观锁。进阶做法在第 6 章讲。4.3 取消预约和管理员审核的状态推进逻辑取消预约不是直接把状态改成「已取消」而是先进入「待取消」状态等管理员审核。对应的逻辑是患者发起取消申请写入cancel_application表同时把appointment的状态从0改为2。管理员在后台审核审核通过就把预约状态改成3驳回则改回0。Transactional(rollbackFor Exception.class) public AppointmentResult cancelAppointment(CancelRequest request) { // 1. 查预约记录校验归属 Appointment appointment appointmentMapper.selectById(request.getAppointmentId()); if (appointment null) { return AppointmentResult.fail(预约记录不存在); } if (appointment.getPatientId() ! request.getPatientId()) { return AppointmentResult.fail(只能取消自己的预约); } // 2. 判断状态是否允许取消只有待就诊状态才能发起 if (appointment.getStatus() ! 0) { return AppointmentResult.fail(当前状态不允许取消); } // 3. 写入取消申请审核状态为待审核 CancelApplication application new CancelApplication(); application.setAppointmentId(appointment.getId()); application.setPatientId(request.getPatientId()); application.setReason(request.getReason()); cancelApplicationMapper.insert(application); // 4. 预约状态改为 2待取消 appointment.setStatus(2); appointmentMapper.updateById(appointment); return AppointmentResult.ok(); }这个接口的逻辑要点是状态机约束。第 2 步的判断非常关键如果患者已经完成就诊状态 1或已经在待取消状态 2就不能再次发起取消申请。状态机的好处就在这里每一步流转都有前置状态校验数据不会乱跳。管理员的审核接口逻辑类似区别是操作主体是管理员审核通过就把预约状态从2改成3同时记录审核时间到cancel_application表。审核驳回则把预约状态从2改回0让这个号源重新释放给其他患者。接口联调阶段我一般会先用 Postman 把接口逐个跑通再连小程序。Postman 里只需要注意两点一是登录接口拿到的 token 要填在请求头的Authorization字段二是预约接口的日期参数格式要和后端约定一致用yyyy-MM-dd字符串避免前端传时间戳后端解析不了。先跑了接口再回头看小程序端的报错问题定位会快很多。5. 避坑经验从拉取源码到跑通业务流程最常见的四类问题5.1 MySQL 连接与驱动版本启动就报错的两个高频场景现象运行1-install.bat导入数据库时报Communications link failure或者启动后端程序时报The server time zone value Öйú±ê׼ʱ¼ä is unrecognized还有一部分项目报Public Key Retrieval is not allowed。原因这三种报错本质是一个问题——本机装的是 MySQL 8.x但项目配置文件里写的还是 5.x 时代的连接参数。MySQL 8.x 的驱动类改成了com.mysql.cj.jdbc.Driver而且强制要求时区参数。密码加密方式也变了没有allowPublicKeyRetrievaltrue时部分连接工具会拒绝第一次的密钥请求。解决打开后端的 JDBC 配置文件把 URL 改成下面这种写法jdbc.drivercom.mysql.cj.jdbc.Driver jdbc.urljdbc:mysql://127.0.0.1:3306/hospital_booking?useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltruecharacterEncodingutf8 jdbc.usernameroot jdbc.password你自己的密码改完重启服务。如果还想用 5.7那就把 MySQL 版本降回去驱动保持不变。我一般建议直接对着 8.x 调因为新装的机器大概率是 8.x让项目适配新版本比要求评委换环境靠谱。5.2 微信开发者工具的请求问题本地能通、真机不通现象在微信开发者工具里点「编译」小程序能打开页面但所有接口都请求失败控制台报url not in domain list或者request:fail。用开发者工具里的「预览」功能在真机上跑接口照样不通。原因微信小程序有域名白名单校验正式发布的小程序只能请求 HTTPS 且配置在小程序后台的合法域名。本地开发时没有配域名就必须在开发者工具右上角的「详情—本地设置」里勾选「不校验合法域名、web-view业务域名、TLS 版本以及 HTTPS 证书」。这是本地联调的前提。真机预览时还要注意另一个问题127.0.0.1在手机上指向的是手机自己不是你的电脑所以真机调试必须把请求地址改成电脑的局域网 IP。解决本地开发时勾选「不校验合法域名」真机预览时把请求封装里的BASE_URL从127.0.0.1改成电脑在局域网里的 IP比如http://192.168.1.23:8080/hospital手机和电脑连同一个 Wi-Fi 后再预览。这个 IP 我之前改的时候踩过一次坑忘了删掉旧构建缓存结果改了代码没生效确认一下开发者工具是否重新编译了。5.3 日期序列化小程序端显示的预约日期变成一串数字现象小程序端拿到预约记录后日期字段显示成1715673600000这种长数字或者显示时间只有日期没有时分秒跟数据库里存的不一样。原因后端返给前端的是 JSONJava 的Date类型经过 Jackson 序列化时如果没配格式默认输出时间戳。前端拿到时间戳直接渲染在页面上自然就是一串数字。如果之前配置过部分字段的JsonFormat但新加的字段忘了标也会出现部分日期正常、部分不正常的情况。解决在application.yml里配全局日期格式比每个字段单独加注解省事得多spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8如果项目用的不是 Spring Boot而是原生 SSM 配置就在 SpringMVC 的配置文件里加一个全局的 Jackson 格式化器。注意appointmentDate这种只存日期不存时刻的字段可以用yyyy-MM-dd单独格式化否则后端Date类型带出来的00:00:00会一并显示看着别扭。5.4 管理后台改样式不生效改了.vue文件但页面没变化现象管理后台是 Vue 构建后的静态资源直接改了源码里的.vue文件刷新浏览器发现页面还是老样子。原因浏览器加载的是构建产物不是源码。Vue 源码经过 webpack 打包后变成了app.26c1910f.css、app.js这类带 hash 的文件你改的.vue文件根本没参与构建或者构建后没有替换到对应的静态资源目录。解决如果需要改管理后台页面先找到 Vue 源码工程改完跑3-build.bat重新构建构建产物会覆盖旧的静态资源。改之前一定先把要改的文件复制一份.bak——这套工程里已经存在的IndexAsideStatic.vue.bak这类文件就是这么来的。直接改.bak文件是无效的它只是留底浏览器不认识它。另外一个常被忽略的点是浏览器缓存构建后如果页面没变Ctrl Shift R 强刷一次不然很容易误判是构建失败了。6. 部署验证与扩展按一条完整链路跑通后再往里加真实号源整套工程拿到手我建议按顺序做三件事。第一步打开1-install.bat看它初始化了哪些东西确认 MySQL 版本、数据库脚本路径、Maven 仓库路径没问题然后执行。第二步执行2-run.bat启动后端留意 Tomcat 启动日志里有没有报错端口是不是 8080。第三步执行3-build.bat构建管理后台构建完把静态资源部署到后端能访问到的目录。三步走完系统应该是「管理后台浏览器可登录、小程序端可请求接口」的状态。跑通之后手动走一遍完整业务链路来验证系统没有隐藏问题。用患者账号登录小程序从首页选科室、选医生、选日期时段提交预约然后到「我的预约」里看到这条记录发起取消申请再到管理后台的「取消预约申请管理」里审核这条申请。走完这轮核心的状态流转就全部覆盖了。验证完基础流程再考虑把项目往外扩一步。号源管理目前是每个时段一个固定总数实际医院是医生排班后才放号可以加一张排班表让每个医生每周的号源单独配置预约并发的问题可以在appointment表加一个version字段做乐观锁update ... where version ?更新失败就提示用户稍后重试小程序端要正式上线还需要把测试用的 appid 换成自己注册的小程序账号并配置合法域名。这三个方向都是答辩时能讲出深度的加分点工作量也都在可控范围内。从那以后我每次拿到陌生毕设工程都会强制走一遍「看数据库脚本 → 看配置文件 → 看启动脚本」的流程日志打开成 debug 级别再动手跑而不是直接双击 bat 看它转圈。这套流程帮我少踩了大半的坑。希望帮到你。本文还有配套的精品资源点击获取
简介微信小程序与SSM后台结合的医院挂号系统毕业设计资源面向计算机及相关专业毕业生、需要快速搭建完整项目的开发者。项目覆盖患者、医生、科室、专家、预约与取消预约申请等核心模块后台基于SSM框架数据库采用MySQL后台管理员可在浏览器中登录管理数据前端使用微信开发者工具整体具备界面清晰、操作简单、功能完整的特点。压缩包共858个文件包含java后台源码、vue前端页面、JavaScript逻辑、SQL脚本与数据库备份、毕业论文文档及mp4视频演示主要文件类型涉及png/svg/jpg图片素材、json/xml/wxml/wxss配置与页面文件等包体约46.83MB。资源已有180人学习下载。下载后可直接对照源码、数据库脚本与论文说明完成环境部署、模块调试和答辩展示适合作为毕业设计选题参考或二次开发基础。1. 医院挂号小程序这套 SSM MySQL 毕业设计到底能跑成什么样医院挂号小程序在毕业设计里出现频率一直很高但多数能找到的源码要么缺数据库脚本要么后端接口是写死的假数据真正能完整跑通的并不多。这套基于微信小程序、SSM 和 MySQL 的项目胜在把「患者—科室—医生—预约—取消申请—审核」这条链路做完整了小程序端承担患者操作SSM 后台负责接口和管理页面MySQL 存业务数据还带一份毕业论文和视频演示适合两类人——准备做医疗类课设的学生以及想快速拿一个前后端闭环练手的 Java 初学者。我按拆包的习惯来写先把技术选型讲透再落到表结构、核心接口和避坑点。2. 技术栈拆解为什么微信小程序、SSM 和 MySQL 能搭起挂号全流程2.1 小程序端为什么是微信小程序而不是 H5 或 App医院挂号这种场景有个特点使用频率低、操作流程短、用户不愿意为它单独装一个 App。微信小程序天然契合这个场景用户扫码或搜索就能进看完号源、预约、取消关掉就走不需要下载安装也不占用桌面空间。从开发角度看微信小程序的技术栈对前端新手也友好。页面由 WXML、WXSS 和 JS 组成写过 Vue 的人几乎零成本迁移组件化思路也一致。登录环节是另一个加分项小程序可以直接调用wx.login()拿 code后端拿 code 换 openid省掉了手机号验证码这套注册逻辑。毕业设计答辩时评委问「用户身份怎么来的」答一句「微信授权 openid」就足够清楚。这套项目里小程序端承担的是患者侧操作包含首页科室列表、专家信息、预约提交、我的预约、取消预约申请几个核心页面。管理后台是另外一套 Web 页面由 Vue 构建后输出静态文件后端用 SSM 提供接口。小程序和后台共用同一套数据库和接口只是角色不同。2.2 后端SSM 这套老组合为什么反而好上手SSM 是 Spring、SpringMVC、MyBatis 三个框架的组合。它不算新但在毕业设计场景里反而是最稳的选择原因有三点。第一Spring 的容器管理和事务控制特别适合预约这类有状态流转的业务。一个预约从提交到就诊、取消、审核中间涉及多次数据库读写用Transactional把几步操作包在一个事务里要么全成功要么全回滚不会出现「号源减了但预约记录没写进去」这种半截数据。第二MyBatis 把 SQL 明明白白写在 Mapper 的 XML 或注解里不像 JPA 那样靠方法名推导。答辩时被问「某个统计怎么查的」直接指 SQL 就能讲清楚。这套项目里患者管理、医生管理、科室管理、预约信息管理这些模块本质都是增删改查MyBatis 写起来最直白。第三SSM 的参考资料最多。Controller、Service、Autowired、Transactional这几个注解的用法网上随便搜都是完整案例真卡住了也容易找到人问。相比之下用 Spring Boot 的人虽然多但毕业设计如果导师指定了 SSM 场景或者论文框架已经按 SSM 搭好临时换框架的成本反而更高。2.3 工程结构的正确认识bat 脚本、Vue 管理后台与备份文件拿到这套源码先别急着找application.yml我一般是先扫一遍文件列表。这类带 Windows 部署脚本的工程文件结构往往比想象中更有信息量。工程里能看到1-install.bat、2-run.bat、3-build.bat三个脚本命名顺序就是部署顺序。按常见约定1-install.bat负责初始化环境包括检查 MySQL 是否启动、导入数据库脚本、把 Maven 依赖拉全2-run.bat启动后端服务和 Tomcat3-build.bat构建管理后台的前端静态文件。实际跑的时候我会先打开脚本看一眼里面的路径写的是绝对路径还是相对路径很多机器上跑不起来都是因为脚本里的盘符和实际解压目录对不上。管理后台是 Vue 工程构建后的产物所以能看到app.26c1910f.css这种带 hash 的静态文件还有一批.bak结尾的备份文件比如main.css.bak、IndexAsideStatic.vue.bak、update-password.vue.bak、BreadCrumbs.vue.bak、IndexHeader.vue.bak。这些.bak是改动前的留底。我的习惯是凡是准备动管理后台的样式或页面逻辑先把对应文件复制一份.bak再动手这个习惯在这套工程里已经替你做好了。MySQL 版本也要提前确认。如果本机装的是 MySQL 8.x连接驱动要配com.mysql.cj.jdbc.DriverURL 还得加serverTimezoneAsia/Shanghai否则一启动就报时区错误。装 5.7 的话用老驱动com.mysql.jdbc.Driver就行这块坑我放在第 5 章细说。3. 数据库设计预约、取消、审核背后要用到的五张核心表3.1 需求拆解从功能列表到实体关系摘要里列的功能是患者管理、医生管理、科室管理、专家信息管理、预约信息管理、取消预约申请管理和系统管理。这七个功能拆到数据库层面可以收敛成五个核心实体。患者和医生都属于用户但角色不同所以放在一张用户表里用角色字段区分还是拆成两张表这是个设计取舍。我拆过的同类项目里毕业设计一般倾向一张用户表加role字段1 管理员、2 医生、3 患者代码里用role控制菜单和接口权限少建一张表论文里也好描述。科室和专家医生是独立实体科室一对多医生。预约记录是核心业务表取消申请则是预约的附属流程表。这五个实体之间的关系很清晰患者选科室科室下有医生患者对医生发起预约预约可以发起取消申请管理员审核取消申请。对应到表就是sys_user、department、doctor_info、appointment、cancel_application五张核心表另外再加一张schedule排班表来约束医生的出诊日期和号源上限。下面先看预约这条主线。3.2 预约表设计状态机、时段字段与唯一索引预约表是全系统最关键的一张表设计好了后面的接口写起来会顺很多。核心字段通常包括患者 ID、医生 ID、预约日期、时段、状态、创建时间。其中三个设计点值得展开说。第一个是时段字段。很多同类项目把「上午 / 下午」直接存成字符串上午、下午这能跑但查询和统计的时候 SQL 写起来别扭。我一般建议存TINYINT0代表上午、1代表下午页面展示时再映射成中文。这样按时段统计号源、判断某个时段是否约满都比字符串匹配快。第二个是状态字段。预约状态不是只有「已预约」和「已取消」两个值完整的流转是这样的患者提交预约后状态为0待就诊医生完成接诊后变为1已完成患者发起取消申请时先变为2待取消管理员审核通过后才变为3已取消。中间那个「待取消」是为了让管理员的审核动作有地方落笔如果患者一点取消就直接变已取消那取消申请表就失去了存在意义。第三个是唯一索引。为了防止同一个患者在同一天重复预约同一时段可以在patient_id appointment_date time_slot上建唯一索引。这个规则一旦定下来代码里就算忘了查重数据库层也能兜底拦截。实际医院里更合理的约束是「同一患者同一天不能挂同一个医生的号」所以唯一索引的字段组合要根据你的业务规则调整答辩时能说清楚这个设计就加分。3.3 建表 SQL 与初始化数据五张核心表的建表 SQL 大致如下字段命名和源码 Mapper 里的映射保持一致直接导入就能用CREATE DATABASE IF NOT EXISTS hospital_booking DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE hospital_booking; CREATE TABLE sys_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL COMMENT 登录账号, password VARCHAR(100) NOT NULL COMMENT MD5加密后的密码, real_name VARCHAR(50) COMMENT 真实姓名, role TINYINT NOT NULL DEFAULT 3 COMMENT 1管理员 2医生 3患者, phone VARCHAR(20) COMMENT 手机号, openid VARCHAR(64) COMMENT 微信openid小程序登录后回填, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表; CREATE TABLE department ( id INT PRIMARY KEY AUTO_INCREMENT, dept_name VARCHAR(50) NOT NULL COMMENT 科室名称, intro VARCHAR(500) COMMENT 科室介绍, sort_order INT DEFAULT 0 COMMENT 排序权重 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT科室表; CREATE TABLE doctor_info ( id INT PRIMARY KEY AUTO_INCREMENT, doctor_name VARCHAR(50) NOT NULL, department_id INT NOT NULL COMMENT 所属科室ID, title VARCHAR(30) COMMENT 职称如主任医师, specialty VARCHAR(200) COMMENT 擅长领域, intro TEXT COMMENT 医生简介, max_appointments INT NOT NULL DEFAULT 20 COMMENT 每时段号源上限 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT专家信息表; CREATE TABLE appointment ( id INT PRIMARY KEY AUTO_INCREMENT, patient_id INT NOT NULL COMMENT 患者用户ID, doctor_id INT NOT NULL COMMENT 医生ID, appointment_date DATE NOT NULL COMMENT 预约日期, time_slot TINYINT NOT NULL DEFAULT 0 COMMENT 0上午 1下午, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待就诊 1已完成 2待取消 3已取消, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_patient_slot (patient_id, appointment_date, time_slot), KEY idx_doctor_date (doctor_id, appointment_date, time_slot) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT预约记录表; CREATE TABLE cancel_application ( id INT PRIMARY KEY AUTO_INCREMENT, appointment_id INT NOT NULL COMMENT 关联的预约ID, patient_id INT NOT NULL COMMENT 发起取消的患者ID, reason VARCHAR(500) COMMENT 取消原因, audit_status TINYINT NOT NULL DEFAULT 0 COMMENT 0待审核 1通过 2驳回, audit_time DATETIME COMMENT 审核时间, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT取消预约申请表;SQL 里有几个值得注意的点。全库统一用utf8mb4不是utf8否则小程序端提交的 emoji 表情和生僻字存入数据库会变成问号这是老生常谈但每次都能踩到。唯一索引uk_patient_slot防重复预约idx_doctor_date是给「按医生和日期查号源」这个高频查询用的没有这个索引预约量一大查询就会慢。max_appointments字段放在doctor_info表里表示这个医生每个时段最多接多少患者这个值决定了余号判断的阈值。初始化数据至少要有一条管理员账号和几个科室记录。管理员账号密码一般用 MD5 加密存储初始密码常见的是123456MD5 值可以直接在 SQL 里写死插入。科室数据按医院常见的几个科室插入几条即可比如内科、外科、儿科、妇产科每个科室再配一两名医生不然小程序端点进去全是空列表演示效果会打折扣。4. SSM 后端接口从登录鉴权到预约状态机核心业务怎么写4.1 Controller 层只做参数校验业务逻辑下沉到 Service看这套后端代码时先抓住分层结构。Controller 层只接收前端传来的参数做最基础的校验非空、格式然后调 Service 层方法拿到结果返回 JSON。业务逻辑一律不写在 Controller 里这是 SSM 项目的基本约定也是答辩时容易被打分老师追问的点。Controller 返回的统一结构一般是这样code表示业务状态码200 成功、401 未登录、500 异常、msg是提示信息、data是业务数据。小程序端和后端约定好这套结构前端封装的wx.request才能统一处理错误。路由设计上患者相关的接口一般放在/patient/**路径下管理端接口放在/admin/**下用拦截器做登录态校验。RequestMapping是 SSM 里最常用的一组注解类上写路径前缀方法上写具体路径和请求方式。拦截器里校验每个请求带不带合法 token不带就返回 401小程序端收到 401 后自动跳登录页这个闭环比在每个 Controller 方法里手动判断要省事得多。4.2 预约的核心逻辑事务、余号检查与状态机流转提交预约是整个系统最核心的一个接口也是答辩时最容易问到的业务点。这个接口要考虑的不只是 insert 一条记录还包括三个前置条件患者存在、医生存在、当前时段有余号。先看 Service 层的核心代码我按这套项目的典型写法整理过Service public class AppointmentService { Autowired private AppointmentMapper appointmentMapper; Autowired private DoctorInfoMapper doctorInfoMapper; Autowired private UserMapper userMapper; Transactional(rollbackFor Exception.class) public AppointmentResult submitAppointment(AppointmentRequest request) { // 1. 校验患者身份role 必须是 3患者 User patient userMapper.selectById(request.getPatientId()); if (patient null || !Objects.equals(patient.getRole(), 3)) { return AppointmentResult.fail(患者账号不存在); } // 2. 校验医生是否存在 DoctorInfo doctor doctorInfoMapper.selectById(request.getDoctorId()); if (doctor null) { return AppointmentResult.fail(所选医生不存在); } // 3. 余号检查统计该医生当天该时段已预约数量 int used appointmentMapper.countByDoctorAndSlot( request.getDoctorId(), request.getAppointmentDate(), request.getTimeSlot()); if (used doctor.getMaxAppointments()) { return AppointmentResult.fail(该时段号源已满请选择其他时段); } // 4. 写预约记录初始状态为 0 待就诊 Appointment appointment new Appointment(); appointment.setPatientId(request.getPatientId()); appointment.setDoctorId(request.getDoctorId()); appointment.setAppointmentDate(request.getAppointmentDate()); appointment.setTimeSlot(request.getTimeSlot()); appointment.setStatus(0); appointmentMapper.insert(appointment); return AppointmentResult.ok(appointment.getId()); } }这段代码的逻辑说明分四步。第一步和第二步是基础校验防止前端传了不存在的 ID 导致外键错误。第三步是余号检查countByDoctorAndSlot这条 SQL 统计的是该医生、该日期、该时段所有状态不是「已取消」的预约数量数量达到max_appointments就返回号源已满。Transactional(rollbackFor Exception.class)的作用是把校验和插入包在同一个事务里。注意rollbackFor指定了只对Exception.class回滚如果不写这个参数Spring 默认只在抛出 RuntimeException 时才回滚checked exception 是不会触发的。很多同学在这个细节上翻过车。这里有个需要认清的边界先查后插这种写法在并发高的时候会有超卖风险两个请求同时查到used 19、max 20然后都走到插入号源就变成 21 个了。毕业设计答辩如果被问到可以如实说这是课设级别的方案生产环境需要加数据库行锁或乐观锁。进阶做法在第 6 章讲。4.3 取消预约和管理员审核的状态推进逻辑取消预约不是直接把状态改成「已取消」而是先进入「待取消」状态等管理员审核。对应的逻辑是患者发起取消申请写入cancel_application表同时把appointment的状态从0改为2。管理员在后台审核审核通过就把预约状态改成3驳回则改回0。Transactional(rollbackFor Exception.class) public AppointmentResult cancelAppointment(CancelRequest request) { // 1. 查预约记录校验归属 Appointment appointment appointmentMapper.selectById(request.getAppointmentId()); if (appointment null) { return AppointmentResult.fail(预约记录不存在); } if (appointment.getPatientId() ! request.getPatientId()) { return AppointmentResult.fail(只能取消自己的预约); } // 2. 判断状态是否允许取消只有待就诊状态才能发起 if (appointment.getStatus() ! 0) { return AppointmentResult.fail(当前状态不允许取消); } // 3. 写入取消申请审核状态为待审核 CancelApplication application new CancelApplication(); application.setAppointmentId(appointment.getId()); application.setPatientId(request.getPatientId()); application.setReason(request.getReason()); cancelApplicationMapper.insert(application); // 4. 预约状态改为 2待取消 appointment.setStatus(2); appointmentMapper.updateById(appointment); return AppointmentResult.ok(); }这个接口的逻辑要点是状态机约束。第 2 步的判断非常关键如果患者已经完成就诊状态 1或已经在待取消状态 2就不能再次发起取消申请。状态机的好处就在这里每一步流转都有前置状态校验数据不会乱跳。管理员的审核接口逻辑类似区别是操作主体是管理员审核通过就把预约状态从2改成3同时记录审核时间到cancel_application表。审核驳回则把预约状态从2改回0让这个号源重新释放给其他患者。接口联调阶段我一般会先用 Postman 把接口逐个跑通再连小程序。Postman 里只需要注意两点一是登录接口拿到的 token 要填在请求头的Authorization字段二是预约接口的日期参数格式要和后端约定一致用yyyy-MM-dd字符串避免前端传时间戳后端解析不了。先跑了接口再回头看小程序端的报错问题定位会快很多。5. 避坑经验从拉取源码到跑通业务流程最常见的四类问题5.1 MySQL 连接与驱动版本启动就报错的两个高频场景现象运行1-install.bat导入数据库时报Communications link failure或者启动后端程序时报The server time zone value Öйú±ê׼ʱ¼ä is unrecognized还有一部分项目报Public Key Retrieval is not allowed。原因这三种报错本质是一个问题——本机装的是 MySQL 8.x但项目配置文件里写的还是 5.x 时代的连接参数。MySQL 8.x 的驱动类改成了com.mysql.cj.jdbc.Driver而且强制要求时区参数。密码加密方式也变了没有allowPublicKeyRetrievaltrue时部分连接工具会拒绝第一次的密钥请求。解决打开后端的 JDBC 配置文件把 URL 改成下面这种写法jdbc.drivercom.mysql.cj.jdbc.Driver jdbc.urljdbc:mysql://127.0.0.1:3306/hospital_booking?useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltruecharacterEncodingutf8 jdbc.usernameroot jdbc.password你自己的密码改完重启服务。如果还想用 5.7那就把 MySQL 版本降回去驱动保持不变。我一般建议直接对着 8.x 调因为新装的机器大概率是 8.x让项目适配新版本比要求评委换环境靠谱。5.2 微信开发者工具的请求问题本地能通、真机不通现象在微信开发者工具里点「编译」小程序能打开页面但所有接口都请求失败控制台报url not in domain list或者request:fail。用开发者工具里的「预览」功能在真机上跑接口照样不通。原因微信小程序有域名白名单校验正式发布的小程序只能请求 HTTPS 且配置在小程序后台的合法域名。本地开发时没有配域名就必须在开发者工具右上角的「详情—本地设置」里勾选「不校验合法域名、web-view业务域名、TLS 版本以及 HTTPS 证书」。这是本地联调的前提。真机预览时还要注意另一个问题127.0.0.1在手机上指向的是手机自己不是你的电脑所以真机调试必须把请求地址改成电脑的局域网 IP。解决本地开发时勾选「不校验合法域名」真机预览时把请求封装里的BASE_URL从127.0.0.1改成电脑在局域网里的 IP比如http://192.168.1.23:8080/hospital手机和电脑连同一个 Wi-Fi 后再预览。这个 IP 我之前改的时候踩过一次坑忘了删掉旧构建缓存结果改了代码没生效确认一下开发者工具是否重新编译了。5.3 日期序列化小程序端显示的预约日期变成一串数字现象小程序端拿到预约记录后日期字段显示成1715673600000这种长数字或者显示时间只有日期没有时分秒跟数据库里存的不一样。原因后端返给前端的是 JSONJava 的Date类型经过 Jackson 序列化时如果没配格式默认输出时间戳。前端拿到时间戳直接渲染在页面上自然就是一串数字。如果之前配置过部分字段的JsonFormat但新加的字段忘了标也会出现部分日期正常、部分不正常的情况。解决在application.yml里配全局日期格式比每个字段单独加注解省事得多spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8如果项目用的不是 Spring Boot而是原生 SSM 配置就在 SpringMVC 的配置文件里加一个全局的 Jackson 格式化器。注意appointmentDate这种只存日期不存时刻的字段可以用yyyy-MM-dd单独格式化否则后端Date类型带出来的00:00:00会一并显示看着别扭。5.4 管理后台改样式不生效改了.vue文件但页面没变化现象管理后台是 Vue 构建后的静态资源直接改了源码里的.vue文件刷新浏览器发现页面还是老样子。原因浏览器加载的是构建产物不是源码。Vue 源码经过 webpack 打包后变成了app.26c1910f.css、app.js这类带 hash 的文件你改的.vue文件根本没参与构建或者构建后没有替换到对应的静态资源目录。解决如果需要改管理后台页面先找到 Vue 源码工程改完跑3-build.bat重新构建构建产物会覆盖旧的静态资源。改之前一定先把要改的文件复制一份.bak——这套工程里已经存在的IndexAsideStatic.vue.bak这类文件就是这么来的。直接改.bak文件是无效的它只是留底浏览器不认识它。另外一个常被忽略的点是浏览器缓存构建后如果页面没变Ctrl Shift R 强刷一次不然很容易误判是构建失败了。6. 部署验证与扩展按一条完整链路跑通后再往里加真实号源整套工程拿到手我建议按顺序做三件事。第一步打开1-install.bat看它初始化了哪些东西确认 MySQL 版本、数据库脚本路径、Maven 仓库路径没问题然后执行。第二步执行2-run.bat启动后端留意 Tomcat 启动日志里有没有报错端口是不是 8080。第三步执行3-build.bat构建管理后台构建完把静态资源部署到后端能访问到的目录。三步走完系统应该是「管理后台浏览器可登录、小程序端可请求接口」的状态。跑通之后手动走一遍完整业务链路来验证系统没有隐藏问题。用患者账号登录小程序从首页选科室、选医生、选日期时段提交预约然后到「我的预约」里看到这条记录发起取消申请再到管理后台的「取消预约申请管理」里审核这条申请。走完这轮核心的状态流转就全部覆盖了。验证完基础流程再考虑把项目往外扩一步。号源管理目前是每个时段一个固定总数实际医院是医生排班后才放号可以加一张排班表让每个医生每周的号源单独配置预约并发的问题可以在appointment表加一个version字段做乐观锁update ... where version ?更新失败就提示用户稍后重试小程序端要正式上线还需要把测试用的 appid 换成自己注册的小程序账号并配置合法域名。这三个方向都是答辩时能讲出深度的加分点工作量也都在可控范围内。从那以后我每次拿到陌生毕设工程都会强制走一遍「看数据库脚本 → 看配置文件 → 看启动脚本」的流程日志打开成 debug 级别再动手跑而不是直接双击 bat 看它转圈。这套流程帮我少踩了大半的坑。希望帮到你。本文还有配套的精品资源点击获取
