基于 Spring Boot 的医院预约挂号系统(全端协同)设计与实现

目录

  • [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 未来扩展展望

未来可扩展订阅消息推送、预约提醒与停诊通知;增加统计维度与可视化报表;完善合规性能力(脱敏、访问审计、权限体系)。
相关推荐
静心观复2 小时前
foreach中使用remove踩坑
java
袁慎建@ThoughtWorks2 小时前
如何发布自定义 Spring Boot Starter
java·spring boot·后端
码农幻想梦2 小时前
实验7 知识表示与推理
开发语言·人工智能·python
写代码的【黑咖啡】2 小时前
深入理解 Python 中的 SQLAlchemy
开发语言·python·oracle
开开心心_Every2 小时前
强制打字练习工具:打够百字才可退出
java·游戏·微信·eclipse·pdf·excel·语音识别
xiaolyuh1232 小时前
Redis 核心业务流程
java·redis·spring
BD_Marathon2 小时前
MyBatis——封装SqlSessionUtils工具类并测试功能
java·windows·mybatis
未定义.2212 小时前
第1篇:0基础入门!Python+Selenium环境搭建与第一个自动化脚本
python·功能测试·selenium·自动化·jenkins·pytest
特行独立的猫2 小时前
python+Proxifier+mitmproxy实现监听本地网路所有的http请求
开发语言·爬虫·python·http