目录
- [Java 核心与应用:基于 Spring Boot 的医院预约挂号系统(全端协同)设计与实现](#Java 核心与应用:基于 Spring Boot 的医院预约挂号系统(全端协同)设计与实现)
- [第一章 绪论](#第一章 绪论)
-
- [1.1 研究背景](#1.1 研究背景)
- [1.2 研究意义](#1.2 研究意义)
- [1.3 国内外研究现状](#1.3 国内外研究现状)
- [1.4 研究内容与研究目标](#1.4 研究内容与研究目标)
- [1.5 研究难点与创新点](#1.5 研究难点与创新点)
- [1.6 本文组织结构](#1.6 本文组织结构)
- [第二章 相关技术与理论基础](#第二章 相关技术与理论基础)
-
- [2.1 Spring Boot 与分层架构](#2.1 Spring Boot 与分层架构)
- [2.2 Spring Security + JWT](#2.2 Spring Security + JWT)
- [2.3 Spring Data JPA + MySQL](#2.3 Spring Data JPA + MySQL)
- [2.4 Vue3 + Vite(Admin/Portal)](#2.4 Vue3 + Vite(Admin/Portal))
- [2.5 微信小程序原生框架](#2.5 微信小程序原生框架)
- [第三章 需求与可行性分析](#第三章 需求与可行性分析)
-
- [3.1 功能需求分析](#3.1 功能需求分析)
-
- [3.1.1 Admin 功能需求](#3.1.1 Admin 功能需求)
- [3.1.2 Portal 功能需求](#3.1.2 Portal 功能需求)
- [3.1.3 小程序 功能需求](#3.1.3 小程序 功能需求)
- [3.2 非功能需求分析](#3.2 非功能需求分析)
- [3.3 可行性分析](#3.3 可行性分析)
- [第四章 系统总体设计](#第四章 系统总体设计)
-
- [4.1 系统架构设计](#4.1 系统架构设计)
- [4.2 功能模块设计](#4.2 功能模块设计)
- [4.3 数据库设计](#4.3 数据库设计)
-
- [4.3.1 概念结构设计](#4.3.1 概念结构设计)
- [4.3.2 逻辑结构设计(表结构三列表)](#4.3.2 逻辑结构设计(表结构三列表))
- [第五章 系统详细设计与实现](#第五章 系统详细设计与实现)
-
- [5.1 多端页面与导航结构设计](#5.1 多端页面与导航结构设计)
-
- [5.1.1 Admin 页面结构](#5.1.1 Admin 页面结构)
- [5.1.2 Portal 页面结构](#5.1.2 Portal 页面结构)
- [5.1.3 小程序页面结构](#5.1.3 小程序页面结构)
- [5.2 核心业务模块设计与实现](#5.2 核心业务模块设计与实现)
-
- [5.2.1 多端统一鉴权与 Token 注入](#5.2.1 多端统一鉴权与 Token 注入)
- [5.2.2 患者端预约创建与号源扣减(Portal/小程序共用 /api/mp)](#5.2.2 患者端预约创建与号源扣减(Portal/小程序共用 /api/mp))
- [5.2.3 小程序请求封装与 401 处理](#5.2.3 小程序请求封装与 401 处理)
- [5.2.4 Admin 号源批量生成](#5.2.4 Admin 号源批量生成)
- [5.2.5 Admin 接诊与病历闭环](#5.2.5 Admin 接诊与病历闭环)
- [5.3 全端关键链路汇总](#5.3 全端关键链路汇总)
-
- [5.3.1 患者预约全链路(Portal/小程序一致)](#5.3.1 患者预约全链路(Portal/小程序一致))
- [第六章 总结与展望](#第六章 总结与展望)
-
- [6.1 系统成果总结](#6.1 系统成果总结)
- [6.2 不足与改进方向](#6.2 不足与改进方向)
- [6.3 未来扩展展望](#6.3 未来扩展展望)
Java 核心与应用:基于 Spring Boot 的医院预约挂号系统(全端协同)设计与实现
系统演示视频 :点击查看B站视频
Django、Flask、SpringBoot版本项目源码获取地址:项目获取地址
第一章 绪论
1.1 研究背景
门诊预约挂号业务覆盖科室与医生信息、排班号源、患者档案、预约支付、接诊与病历、公告发布与运营统计等关键环节。传统线下模式依赖窗口排队与人工咨询,存在号源余量不可视、出诊信息更新滞后、患者往返成本高、业务流程难追溯、数据难沉淀等问题。
本项目为"医院预约挂号系统(Spring Boot 版)",采用前后端分离与多端协同架构,形成"管理端 + 患者端(Web/小程序)"的统一服务形态:
- 后端:Spring Boot 2.7.18 + Spring Data JPA + Spring Security + JWT + MySQL
- 管理端 Admin:Vue3 + Vite + Element Plus
- 患者门户 Portal:Vue3 + Vite + Element Plus(患者 Web 入口)
- 微信小程序:原生小程序框架(患者移动端入口)
后端在路由层按前缀对接口分组:
- 管理端接口:
/api/... - 患者端接口:
/api/mp/...
Portal 与小程序共享患者端接口与业务规则,从而保证"同一业务口径,多端一致体验"。
1.2 研究意义
从业务价值看,全端协同能够显著提升医疗服务效率:
- 患者侧:在 Portal 或小程序完成科室/医生查询、号源可用查询、预约创建/支付/取消、病历与公告查询,减少排队与咨询压力。
- 医院侧:在 Admin 完成基础数据维护、号源生成、预约管理、接诊与病历、公告发布与统计概览,提升运营管理效率。
从工程实现看,全端形态强调"统一后端权威 + 多端薄客户端"的思想:
- 后端通过 Spring Security + JWT 实现无状态鉴权,将身份识别与权限边界集中在服务端。
- Admin/Portal 通过 Axios 拦截器统一注入 Token 并处理 401 过期跳转。
- 小程序通过
utils/request.js封装wx.request,统一 Loading、错误提示与 401 清理登录态。
1.3 国内外研究现状
医疗预约系统逐渐从单一 Web 后台演进为"后台管理 + 患者端入口(H5/APP/小程序)"的多端协同模式。工程实践中常采用 Token 鉴权、接口分组、分页加载、路由守卫与请求拦截器等手段,保证安全边界一致与跨端体验一致。
预约业务的主要难点集中在:
- 号源库存一致性(扣减/回滚)
- 预约状态机约束(支付、取消、接诊完成)
- 多角色权限边界(管理员/医生/患者)
- 统计口径统一(成功率、取消/爽约、收入)
1.4 研究内容与研究目标
本文档以"全端(后端 + Admin + Portal + 小程序)"为交付范围,研究内容与目标包括:
- 构建统一后端 API(管理端与患者端接口分组)与统一鉴权机制。
- 实现核心业务闭环:科室/医生/号源、预约创建/支付/取消、接诊与病历、公告发布与统计。
- Admin 完成运营与业务处理入口;Portal/小程序提供患者侧查询与预约入口。
- 通过统一响应结构与分页结构保证多端列表渲染逻辑一致。
1.5 研究难点与创新点
难点:
- 一致性 :预约创建扣减号源
remainCount,取消回滚remainCount,避免重复预约与状态错乱。 - 状态机:支付必须从"待支付"推进为"待就诊",取消只允许在部分状态执行。
- 多端协同 :Portal 与小程序共享
/api/mp,需要保持字段命名、分页结构与错误码口径一致。
创新点:
- 接口分组 + 业务复用 :患者端统一
/api/mp,Portal 与小程序复用同一业务规则。 - 请求层统一封装:Admin/Portal 通过 Axios 拦截器,小程序通过 request 封装,实现统一鉴权与 401 处理。
1.6 本文组织结构
第一章介绍研究背景、意义与目标;第二章阐述相关技术;第三章进行需求与可行性分析;第四章给出系统总体设计与数据库设计;第五章对多端核心页面与关键业务模块进行详细设计与实现说明(含流程图与关键代码片段);第六章总结与展望。
第二章 相关技术与理论基础
2.1 Spring Boot 与分层架构
后端采用 Spring Boot 2.7.18 构建 REST 服务。整体采用 Controller/Service/Repository 分层:Controller 接收参数与处理异常,Service 承载业务规则与一致性控制,Repository(JPA)负责数据访问与分页。
2.2 Spring Security + JWT
系统采用 JWT 无状态鉴权。SecurityConfig 中配置放行登录与患者端公共查询接口,其余接口要求认证;JwtAuthenticationFilter 解析 Bearer Token,获取 userId 并查询用户角色,将认证信息写入 SecurityContextHolder。
2.3 Spring Data JPA + MySQL
系统采用 MySQL 作为关系型数据库,Entity 映射表结构,Repository 支持分页与聚合统计。application.yml 配置数据库连接、JPA 行为与 JWT 密钥/过期时间。
2.4 Vue3 + Vite(Admin/Portal)
Admin/Portal 均采用 Vue3 + Vite 构建 SPA,并使用 Element Plus 作为组件库。两端通过 Axios 请求封装与路由守卫实现登录态与权限控制。
2.5 微信小程序原生框架
小程序采用原生框架:app.json 配置页面与 TabBar,app.js 存储 baseUrl/token/userInfo 并在启动时恢复登录态;utils/request.js 封装 wx.request 实现统一 Loading、错误提示与 401 处理。
第三章 需求与可行性分析
3.1 功能需求分析
3.1.1 Admin 功能需求
- 登录鉴权
- 工作台统计概览
- 科室/医生/患者管理
- 号源管理:分页、单条创建、批量生成、停诊
- 预约管理:查询、详情、取消
- 接诊管理:今日待就诊、开始接诊、保存病历、完成接诊
- 病历管理:列表与详情
- 公告管理:创建、编辑、发布/撤回
- 统计报表:概览/科室/医生/按日
3.1.2 Portal 功能需求
- 登录
- 首页、科室导航/详情、医生详情
- 预约挂号:号源查询、提交预约
- 我的预约:支付、取消、详情
- 就诊记录:列表与详情
- 公告列表与详情
- 个人中心
3.1.3 小程序 功能需求
- 登录/注册(含短信入口)
- 首页、科室/医生查询、号源可用查询
- 预约创建/支付/取消、预约列表与详情
- 病历列表与详情、按预约查病历
- 公告最新/列表/详情
- 个人资料、修改密码、医保绑定/解绑
3.2 非功能需求分析
- 安全性:JWT 鉴权、401 统一处理
- 一致性:预约/号源余量一致维护
- 性能:分页与弱网适配
- 可维护性:多端请求层封装、后端分层清晰
3.3 可行性分析
Spring Boot/JPA/Security/JWT 生态成熟,Vue3 与小程序生态完善;接口分组与统一封装降低多端重复实现,技术风险可控。
第四章 系统总体设计
4.1 系统架构设计
HTTP JSON /api
HTTP JSON /api/mp
管理员/医生/患者
Admin Vue3
患者用户
Portal Vue3
Spring Boot后端 API
MySQL数据库
图4.1 全端系统架构图
4.2 功能模块设计
后端
Spring Security + JWT
Controller
Service
Repository
Entity
终端
Portal
小程序
患者端
登录
科室/医生查询
号源查询
预约创建/支付/取消
个人中心
病历与公告
管理端
登录鉴权
基础数据管理
号源管理
预约管理
接诊与病历
公告管理
统计报表
图4.2 功能模块图
4.3 数据库设计
4.3.1 概念结构设计
has
has
contains
publishes
makes
consumed_by
generates
writes
owns
belongs_to
USERS
DOCTORS
PATIENTS
DEPARTMENTS
SCHEDULES
APPOINTMENTS
MEDICAL_RECORDS
ANNOUNCEMENTS
BIGINT
id
VARCHAR
title
INT
type
INT
status
DATETIME
publish_time
图4.3 数据库E-R图
4.3.2 逻辑结构设计(表结构三列表)
(本章表结构与前两份文档一致,此处为全端论文按论文格式再次列出核心表)
users 表用于存储登录账号及角色。
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | BIGINT | 主键 |
| username | VARCHAR(50) | 用户名 |
| password_hash | VARCHAR(256) | 密码哈希 |
| real_name | VARCHAR(50) | 真实姓名 |
| phone | VARCHAR(20) | 手机号 |
| role | VARCHAR(20) | 角色 |
| status | INT | 状态 |
| last_login_time | DATETIME | 最后登录时间 |
patients 表用于存储患者档案信息。
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | BIGINT | 主键 |
| user_id | BIGINT | 关联 users.id |
| real_name | VARCHAR(50) | 姓名 |
| gender | INT | 性别 |
| age | INT | 年龄 |
| phone | VARCHAR(20) | 手机号 |
| id_card | VARCHAR(20) | 身份证号 |
| address | VARCHAR(200) | 地址 |
| emergency_contact | VARCHAR(50) | 紧急联系人 |
| emergency_phone | VARCHAR(20) | 紧急联系人电话 |
| medical_insurance_no | VARCHAR(50) | 医保卡号 |
| insurance_type | VARCHAR(20) | 医保类型 |
| status | INT | 状态 |
| create_time | DATETIME | 创建时间 |
departments 表用于存储科室基础信息。
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | BIGINT | 主键 |
| name | VARCHAR(50) | 科室名称 |
| description | TEXT | 科室描述 |
| location | VARCHAR(100) | 位置 |
| phone | VARCHAR(20) | 联系电话 |
| status | INT | 状态 |
| create_time | DATETIME | 创建时间 |
doctors 表用于存储医生信息。
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | BIGINT | 主键 |
| user_id | BIGINT | 关联 users.id |
| department_id | BIGINT | 关联 departments.id |
| real_name | VARCHAR(50) | 医生姓名 |
| title | VARCHAR(50) | 职称 |
| specialty | TEXT | 擅长 |
| introduction | TEXT | 简介 |
| phone | VARCHAR(20) | 联系电话 |
| consultation_fee | DECIMAL(10,2) | 挂号费 |
| status | INT | 状态 |
| create_time | DATETIME | 创建时间 |
schedules 表用于存储排班号源。
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | BIGINT | 主键 |
| doctor_id | BIGINT | 关联 doctors.id |
| department_id | BIGINT | 关联 departments.id |
| schedule_date | DATE | 出诊日期 |
| time_slot | VARCHAR(20) | 时间段 |
| appointment_type | INT | 门诊类型 |
| total_count | INT | 总号数 |
| remain_count | INT | 剩余号数 |
| fee | DECIMAL(10,2) | 挂号费 |
| status | INT | 状态 |
| create_time | DATETIME | 创建时间 |
appointments 表用于存储预约与状态。
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | BIGINT | 主键 |
| appointment_no | VARCHAR(30) | 预约号 |
| patient_id | BIGINT | 患者 |
| doctor_id | BIGINT | 医生 |
| schedule_id | BIGINT | 号源 |
| fee | DECIMAL(10,2) | 挂号费 |
| status | INT | 状态 |
| payment_time | DATETIME | 支付时间 |
medical_records 表用于存储病历。
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | BIGINT | 主键 |
| record_no | VARCHAR(30) | 病历编号 |
| appointment_id | BIGINT | 预约 |
| patient_id | BIGINT | 患者 |
| doctor_id | BIGINT | 医生 |
| chief_complaint | TEXT | 主诉 |
| diagnosis | TEXT | 诊断 |
| advice | TEXT | 医嘱 |
announcements 表用于存储公告。
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | BIGINT | 主键 |
| title | VARCHAR(200) | 标题 |
| content | TEXT | 内容 |
| type | INT | 类型 |
| status | INT | 状态 |
| publish_time | DATETIME | 发布时间 |
| create_time | DATETIME | 创建时间 |
第五章 系统详细设计与实现
5.1 多端页面与导航结构设计
5.1.1 Admin 页面结构
Admin 端以侧边菜单为主导航,覆盖:工作台、挂号预约、接诊管理、就诊记录、科室管理、号源管理、医生管理、患者管理、系统公告、统计报表、账号管理与个人中心。

5.1.2 Portal 页面结构
Portal 端以患者视角组织页面:登录、首页、科室导航/详情、医生详情、预约挂号、我的预约、就诊记录、公告、个人中心。

5.1.3 小程序页面结构
小程序采用 TabBar:首页、预约、病历、我的;其余页面通过跳转进入(科室、医生详情、预约创建/详情、病历详情、公告列表/详情、个人资料、医保绑定等)。

5.2 核心业务模块设计与实现
5.2.1 多端统一鉴权与 Token 注入
登录签发token
多端存储token
请求层注入Authorization
后端解析token写入SecurityContext
执行业务逻辑
图5.1 多端鉴权一致性流程图
java
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
http
.csrf().disable()
.sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS)
.and()
.authorizeRequests()
.antMatchers("/api/auth/**", "/api/mp/auth/**").permitAll()
.antMatchers("/api/mp/department/**", "/api/mp/doctor/**").permitAll()
.antMatchers("/api/mp/schedule/**", "/api/mp/announcement/**").permitAll()
.anyRequest().authenticated();
return http.build();
}
5.2.2 患者端预约创建与号源扣减(Portal/小程序共用 /api/mp)
Portal 与小程序共享 /api/mp,预约创建在后端事务内完成:校验号源可用 → 创建预约 → 扣减余量。

否
是
选择号源
提交预约
余量>0且未停诊?
返回失败
创建预约 status=待支付
remainCount-1
图5.2 预约创建与扣减流程图
java
@Transactional
public Map<String, Object> createForUser(Long userId, Long scheduleId, String patientName, String phone, String idCard) {
Schedule schedule = scheduleRepository.findById(scheduleId)
.orElseThrow(() -> new RuntimeException("号源不存在"));
if (schedule.getRemainCount() <= 0) throw new RuntimeException("该时段号源已满");
if (schedule.getStatus() == 0) throw new RuntimeException("该时段已停诊");
Patient patient = patientRepository.findByUserId(userId).orElseGet(() -> {
Patient p = new Patient();
p.setUserId(userId);
p.setRealName(patientName);
p.setPhone(phone);
p.setIdCard(idCard);
return patientRepository.save(p);
});
int queueNo = schedule.getTotalCount() - schedule.getRemainCount() + 1;
Appointment appointment = new Appointment();
appointment.setAppointmentNo(NoGenerator.generate("GH"));
appointment.setPatientId(patient.getId());
appointment.setDoctorId(schedule.getDoctorId());
appointment.setDepartmentId(schedule.getDepartmentId());
appointment.setScheduleId(scheduleId);
appointment.setQueueNo(queueNo);
appointment.setStatus(0);
schedule.setRemainCount(schedule.getRemainCount() - 1);
scheduleRepository.save(schedule);
appointmentRepository.save(appointment);
return toMap(appointment);
}
5.2.3 小程序请求封装与 401 处理
小程序 request 封装统一实现 Authorization 注入与登录过期处理,避免每个页面重复写网络请求逻辑。


javascript
const request = (options) => {
return new Promise((resolve, reject) => {
const { url, method = 'GET', data = {}, showLoading = true, needAuth = true } = options
if (showLoading) wx.showLoading({ title: '加载中...', mask: true })
const header = { 'Content-Type': 'application/json' }
if (needAuth && app.globalData.token) {
header['Authorization'] = `Bearer ${app.globalData.token}`
}
wx.request({ url: app.globalData.baseUrl + url, method, data, header,
success: (res) => { if (showLoading) wx.hideLoading(); res.data.code === 200 ? resolve(res.data) : reject(res.data) }
})
})
}
5.2.4 Admin 号源批量生成
Admin 端用于快速生成排班号源,降低人工录入成本,并通过"是否已存在"判断防止重复创建。


选择医生
日期范围
timeSlots与数量
逐日逐时段检查
创建Schedule
返回createdCount
图5.3 号源批量生成流程图
5.2.5 Admin 接诊与病历闭环
医生在 Admin 端从今日待就诊列表进入接诊页面,保存病历字段并完成接诊,预约状态推进为已就诊,同时病历可在患者端查询。

今日待就诊
开始接诊
保存病历字段
完成接诊
预约状态=已就诊
图5.4 接诊与病历闭环流程图
5.3 全端关键链路汇总
5.3.1 患者预约全链路(Portal/小程序一致)

支付
取消
科室/医生选择
查询可用号源
创建预约
待支付
支付/取消
待就诊
已取消
医生接诊
生成病历
图5.5 全端预约链路流程图
第六章 总结与展望
6.1 系统成果总结
本系统完成了后端 + Admin + Portal + 小程序的全端协同:后端提供统一鉴权与核心业务能力;Admin 支撑基础数据维护、号源生成、预约管理、接诊病历、公告与统计;Portal 与小程序作为患者入口完成查询、预约与病历/公告查询。系统实现了预约状态流转与号源一致性维护,并具备可扩展的工程基础。
6.2 不足与改进方向
权限控制目前以鉴权与前端路由限制为主,后端可进一步细化角色级授权与审计日志;高并发场景下预约扣减需引入更严格的事务隔离/锁策略;支付流程可进一步对接真实支付并完善回调验签与对账。
6.3 未来扩展展望
未来可扩展订阅消息推送、预约提醒与停诊通知;增加统计维度与可视化报表;完善合规性能力(脱敏、访问审计、权限体系)。
查询可用号源]
B --> C[创建预约]
C --> D[待支付]
D --> E{支付/取消}
E -->|支付| F[待就诊]
E -->|取消| G[已取消]
F --> H[医生接诊]
H --> I[生成病历]
图5.5 全端预约链路流程图
---
# 第六章 总结与展望
## 6.1 系统成果总结
本系统完成了后端 + Admin + Portal + 小程序的全端协同:后端提供统一鉴权与核心业务能力;Admin 支撑基础数据维护、号源生成、预约管理、接诊病历、公告与统计;Portal 与小程序作为患者入口完成查询、预约与病历/公告查询。系统实现了预约状态流转与号源一致性维护,并具备可扩展的工程基础。
## 6.2 不足与改进方向
权限控制目前以鉴权与前端路由限制为主,后端可进一步细化角色级授权与审计日志;高并发场景下预约扣减需引入更严格的事务隔离/锁策略;支付流程可进一步对接真实支付并完善回调验签与对账。
## 6.3 未来扩展展望
未来可扩展订阅消息推送、预约提醒与停诊通知;增加统计维度与可视化报表;完善合规性能力(脱敏、访问审计、权限体系)。