SpringBoot+Vue3医院挂号系统：从架构到部署的完整实战解析

很多朋友做毕业设计或者公司内部系统选型时经常在“SpringBootVue3医院医疗挂号信息管理系统”这个标题上反复犹豫到底值不值得做前后端分离到底怎么落地挂号这种高并发场景到底要不要上消息队列我前后带团队完整做过两套这类系统一套是院内自助机配套的挂号子系统另一套是互联网医院的小程序端管理后台说句实话SpringBoot和Vue3这对组合在医疗挂号这个业务场景里属于够用且好维护的典型方案今天就把全套思路和核心代码逻辑拆开讲透。这个项目适合三类人重点参考一是正在准备毕设或简历项目的同学二是中小型诊所、私立医院需要快速搭建预约系统的技术负责人三是想从单体项目转型前后端分离的开发者。它解决的问题很清晰把“科室排班、号源管理、患者挂号、医生看诊记录、后台统计”这一条业务链全部数字化我下面直接跳过概念铺垫从架构、数据库、后端、前端到部署一条龙讲。1. 项目概述与核心需求拆解1.1 医院挂号管理系统到底在解决什么问题挂号这个动作看起来简单患者选科室、选医生、选时间、缴费、取号但背后牵扯的是一整套资源调度逻辑。线下医院排队挂号的痛点大家都经历过窗口排队时间长、热门专家号一放出来就没了、号贩子倒号、退号改号流程繁琐这些问题映射到系统里就变成了几个核心需求点科室与医生信息维护、排班计划管理、号源库存控制、在线挂号与取消、患者档案管理、医生看诊记录。我接触过不少第一次做医疗系统的开发者最容易犯的毛病是只做了一张“挂号订单表”把科室、医生、时间段全塞进去结果一到上线就发现医生请假怎么办同一个时间段放几个号退号之后这个号能不能重新放出去这些问题全是表结构设计不合理埋下的坑。所以真正动手前必须先把业务角色理清楚系统里至少要有三类用户患者前端挂号、医生查看排班和患者、管理员维护基础数据和统计报表如果再细一点还要有导诊台人员来处理线下加号、退号。1.2 为什么选SpringBootVue3这套组合SpringBoot在这个场景里的优势是稳定和生态成熟。医疗系统最怕的是框架本身不稳定SpringBoot的自动配置和起步依赖能让你在很短时间内把Web层、数据层、权限层全部搭起来而且它对MySQL、Redis这些中间件的整合非常顺后续想加缓存、加消息队列都有成熟方案。Vue3这边的优势就更明显了Composition API把逻辑复用能力提升了一大截尤其是挂号页面那种“选中科室联动医生列表、选中医生联动号源列表”的复杂交互用组合式函数拆起来相当舒服再加上Element Plus组件库后台管理界面基本是开箱即用。再补一个选型维度招人好招、资料好查。SpringBoot和Vue3是目前国内Java和前端岗位需求量最大的技术栈出了问题去搜索引擎一搜全是答案这对医疗这类对稳定性要求高的项目来说非常加分。我见过用很冷门框架做的项目最后维护的人走了代码没人敢动这种教训太多了。2. 系统架构设计与技术选型2.1 前后端分离的整体架构这套系统我建议直接采用标准的单体前后端分离架构不要一上来就上微服务。挂号系统的并发量通常远没有大家想象的那么高一个普通三甲医院一天的门诊量也就几千到一两万人次高峰期集中在早上七点到九点这种量级用单体后端加Redis缓存完全扛得住。微服务带来的分布式事务、服务治理复杂度在这个业务体量下是纯粹的负担。整体架构分为四层前端Vue3单页应用负责页面渲染和用户交互后端SpringBoot提供RESTful API数据层以MySQL存储关系数据Redis缓存热点数据部署层用Nginx托管前端静态资源并反向代理API请求。如果后面真要面对高并发可以直接在Redis层做分布式锁控制号源扣减不需要重构业务代码这也是我把Redis提前放进架构的原因。2.2 后端工程结构与关键依赖我习惯把后端工程按照业务模块分包而不是按照技术类型分包。也就是说不要建一堆controller、service、mapper这样的顶层包而是建appointment、doctor、patient、system这样的业务包每个包内部再去分controller、service、mapper。这样做的好处是改一个功能时所有相关文件都在同一个包下尤其对后续维护的人非常友好。关键依赖就六样spring-boot-starter-web、mybatis-plus、mysql-connector-java、spring-boot-starter-data-redis、jjwt、lombok。这里特别说一下为什么用MyBatis-Plus而不是JPA医疗系统里复杂查询特别多比如按科室、按医生、按时间范围组合筛选号源MyBatis-Plus的条件构造器写起来很直观还能跟XML里的手写SQL共存灵活性比JPA高很多。2.3 前端工程结构与页面组织前端用Vite创建Vue3工程比Webpack的启动速度快了一个量级开发体验好很多。路由用Vue Router状态管理用PiniaUI组件库用Element PlusHTTP请求用Axios。页面组织上我建议按“布局嵌套”来设计最外层是登录页登录后进入主布局主布局左侧是菜单、右侧是内容区内容区里又分为患者端和管理端两套页面。患者端的核心页面是挂号页这个页面要支持“选择科室、选择医生、选择日期、选择号源时间段、确认信息、提交挂号”六步每一步之间都有数据联动管理端的核心页面是排班管理、号源管理、订单管理和基础数据维护。还有一个很容易被忽略但很重要的页面是“我的挂号”患者要能看到自己的挂号记录并且能做取消操作取消后号源要能自动释放。3. 数据库设计与核心业务模型3.1 核心表设计与关系梳理数据库设计是整个挂号系统最关键的一步我在这里踩过不少坑先给出一版经过实际验证的表结构。医院医疗挂号信息管理系统涉及的表比较多但核心就这六张科室表department、医生表doctor、排班表schedule、号源表slot、挂号订单表registration、患者表patient。关系是这样的科室和医生是一对多一个科室下有多个医生医生和排班是一对多一个医生在多个时间段有排班排班和号源是一对多一个排班时间段可以对应多个号源号源和挂号订单是一对一一个号源被挂出后生成一笔订单。把号源单独抽一张表是为了精确控制每一个时间段的挂号和退号状态这是比单纯在订单表里存个剩余数量的方案可靠得多。CREATE TABLE department ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT 主键, name VARCHAR(100) NOT NULL COMMENT 科室名称, code VARCHAR(50) NOT NULL UNIQUE COMMENT 科室编码, intro TEXT COMMENT 科室简介, status TINYINT DEFAULT 1 COMMENT 状态1启用 0停用, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE doctor ( id BIGINT PRIMARY KEY AUTO_INCREMENT, department_id BIGINT NOT NULL COMMENT 所属科室, name VARCHAR(50) NOT NULL, title VARCHAR(50) COMMENT 职称主任医师/副主任医师/主治医师, avatar VARCHAR(255), specialty TEXT COMMENT 擅长领域, status TINYINT DEFAULT 1, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_department_id (department_id) );排班表和号源表这两张表的设计直接决定了并发控制怎么写我放在下一节单独说。3.2 号源与排班的数据模型设计排班表存的是“某医生在某天某时段出诊”这一条计划号源表存的是“这个时段里面具体每个可以被挂出的号”。举个例子某个主任医师周一上午8:00到8:30出诊放出10个号那就对应一条schedule记录和10条slot记录每条slot的状态都是“待挂号”。CREATE TABLE schedule ( id BIGINT PRIMARY KEY AUTO_INCREMENT, doctor_id BIGINT NOT NULL, work_date DATE NOT NULL COMMENT 出诊日期, period TINYINT NOT NULL COMMENT 时段1上午 2下午 3晚, start_time TIME NOT NULL, end_time TIME NOT NULL, total_slots INT NOT NULL COMMENT 总号源数, remain_slots INT NOT NULL COMMENT 剩余号源数, status TINYINT DEFAULT 0 COMMENT 状态0未开始 1进行中 2已结束, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_doctor_date_period (doctor_id, work_date, period), INDEX idx_work_date (work_date) ); CREATE TABLE slot ( id BIGINT PRIMARY KEY AUTO_INCREMENT, schedule_id BIGINT NOT NULL, slot_number INT NOT NULL COMMENT 序号从1开始, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待挂号 1已挂号 2已锁定 3已取消, patient_id BIGINT COMMENT 挂号患者, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_schedule_number (schedule_id, slot_number) );这里有个细节一定要提醒schedule表里一定要有remain_slots这个冗余字段否则每次判断有没有余号都要count一下slot表数据量大了会非常慢。维护这个字段的正确姿势是在挂号事务里update remain_slots同时要求update语句的影响行数为1才能证明操作成功这件事在下一章讲并发控制时会详细展开。4. 后端核心实现从登录鉴权到挂号流程4.1 基于JWT的登录鉴权方案登录鉴权我用的是JWT没有引入Spring Security原因是挂号系统里角色就三种用拦截器加注解完全够用Spring Security那一套过滤链配置在里面反而显得笨重。JWT的逻辑很简单用户登录成功后后端生成一个tokentoken里包含userId、role和过期时间前端后续每次请求都在Header里携带token后端写一个拦截器统一解析校验。拦截器有三个注意点白名单放行登录接口、科室列表等公开接口不需要token解析token失败时统一返回401状态码把解析出来的用户信息放到请求上下文中后续业务方法直接用。权限控制我用了一个RequireRole注解配合拦截器实现标注在Controller方法上取值是ADMIN、DOCTOR、PATIENT拦截时会校验当前用户角色是否匹配。4.2 排班与号源生成的具体实现排班这个功能是给管理员用的页面上选择医生、日期、时段、号源数量后端拿到这些参数后在一个事务里做两件事插入schedule记录然后循环插入total_slots条slot记录。生成号源后可以顺手做一件事情把可以挂号的日期范围缓存到Redis比如未来七天有排班的日期列表患者挂号页初始化时直接读缓存减少数据库查询压力。这里有一个人工排班时容易漏掉的场景医生某天临时停诊管理员要批量停掉这个医生当天所有时段的排班。实现上不能只改schedule表的状态还要把该schedule下所有状态为“待挂号”的slot改成“已取消”同时给已经挂了号的患者发通知。完善的做法是加一张消息表记录停诊通知患者端“我的挂号”页面把停诊的订单标记出来。4.3 挂号下单的并发控制实战挂号业务流程是患者选择某个slot系统判断这个slot的状态是“待挂号”然后创建一个registration订单同时把slot状态改成“已挂号”。这个过程如果不做控制两个患者同时点同一个号就会出现超卖。我用了三种手段叠加保证万无一失。第一种是MySQL行级锁在事务里用select for update锁住slot记录再判断状态这是最底层的兜底第二种是Redis分布式锁用setnx命令锁住“scheduleId_returnSlots”这个key针对退号回补和高峰抢号场景做第一层拦截第三种是库存预减在进入事务前先通过Redis的decrement命令预减schedule表的remainSlots如果减后小于0就直接返回“号源不足”。写得比较核心的一段伪代码如下这是整套挂号逻辑里最值得反复推敲的部分Transactional(rollbackFor Exception.class) public RegistrationResult register(Long slotId, Long patientId) { String lockKey lock:slot: slotId; boolean locked redisTemplate.opsForValue() .setIfAbsent(lockKey, 1, Duration.ofSeconds(10)); if (!locked) { throw new BizException(系统繁忙请稍后重试); } try { // 数据库行锁二次兜底 Slot slot slotMapper.selectByIdForUpdate(slotId); if (slot.getStatus() ! 0) { throw new BizException(当前号源已被挂号); } int updated scheduleMapper.reduceRemainSlots(slot.getScheduleId()); if (updated 0) { throw new BizException(号源已挂完); } slot.setStatus(1); slot.setPatientId(patientId); slotMapper.updateById(slot); Registration registration new Registration(); // 生成订单号、记录挂号时间、关联医生和排班信息 registrationMapper.insert(registration); return success(registration); } finally { redisTemplate.delete(lockKey); } }4.4 分页查询与条件检索的封装思路挂号系统里列表查询特别多医生列表、排班列表、挂号订单列表每个都有不同的筛选条件。我用MyBatis-Plus的Page对象封装了一个统一的分页查询工具配合LambdaQueryWrapper来动态拼接条件。比如订单查询支持按患者ID、按医生姓名、按日期范围、按状态四个维度组合筛选。这里要特别提醒一个关于时间查询的坑前后端传时间参数时如果直接把“2025-03-10 00:00:00”这种字符串交给MySQL比较很容易出现时区偏差导致查不到当天的数据。我建议所有时间参数统一用LocalDateTime接收前端传的时间戳或者特定格式字符串在后端先转成LocalDateTime再拼条件MyBatis-Plus对LocalDateTime有很好的类型处理支持不会出现JDBC时区问题。5. 前端核心实现Vue3ElementPlus落地5.1 项目初始化和路由设计前端工程我用Vite初始化命令执行npm create vitelatest选择Vue3和TypeScript模板。为什么不选JavaScript模板医疗挂号系统里患者数据、医生数据、排班数据的结构都比较复杂字段多且类型明确用TypeScript能在一开始就把很多低级错误拦住比如把doctorId传成了字符串、把时间字段的格式搞错这些在编译阶段就能发现。路由设计上我用了嵌套路由主布局组件负责渲染侧边栏和顶栏子路由根据用户角色动态加载。动态加载的好处是患者登录后看不到管理菜单医生登录后看不到患者端的功能入口权限在前端路由层面就先做了一层过滤。当然前端路由过滤只是体验优化真正的权限控制必须依赖后端接口校验这一点一定要在项目文档里写清楚否则就是安全隐患。5.2 接口封装与状态管理的合理分工Axios封装是前端工程质量的分水岭。我封装了一个request模块做了三件核心事情统一注入JWT token到请求头、统一处理HTTP错误码和业务错误码、统一解析后端的Result包装结构。后端返回格式是固定的code0表示成功data里放业务数据message里放错误信息前端拦截器里如果发现code非0直接弹Element Plus的Message提示业务代码里就不用到处都是try catch了。状态管理用Pinia但只用来存三类全局共享的东西当前用户信息和token、医院的基础配置比如医院名称、挂号费模板、以及一些跨页面需要保持的数据。不要拿着Pinia什么都往里面放像挂号表单那种只在单个页面内部流转的数据用组件内部的reactive或ref就够了强行上全局store反而会让状态流的追踪变得困难。5.3 核心页面实战号源日历与挂号表单挂号页是整个前端最复杂的页面。我的做法是把“选科室、选医生、选号源”这三个联动的过程抽成一个组合式函数useRegisterFlow里面维护currentDepartment、currentDoctor、currentDate、currentPeriod、selectedSlot这五个响应式变量以及loadDepartments、loadDoctors、loadSlots、submitRegistration这四个方法。号源日历这一块的交互要做得顺畅页面左侧是科室树或科室下拉列表中间是医生卡片列表右侧是排班日历和号段列表。选完科室马上发请求查医生列表选完医生马上查这个医生未来七天的排班点中某个日期后下面展示这个日期所有时段的号源占用情况。每个号源按钮的样式根据状态做不同处理待挂号高亮可点、已挂号置灰、已取消打斜线。script setup langts import { ref, watch } from vue import { getDoctorSchedules, getAvailableSlots } from /api/register const selectedDate refstring() const scheduleList refScheduleItem[]([]) const slotList refSlotItem[]([]) watch(selectedDate, async (date) { if (!date) return slotList.value await getAvailableSlots({ doctorId: currentDoctor.value.id, workDate: date }) }) /script表单提交前要做的最后一道校验是把患者选择的“医生、日期、时段、号源序号”拼成一段摘要展示给患者确认避免挂错号。确认后调submitRegistration接口后端成功返回订单号后页面跳转到挂号成功页成功页上要展示挂号流水号、就诊地点、注意事项。这个信息要让患者看一眼就能记住非常关键。6. 典型问题与排查技巧实录6.1 高并发下的号源超卖问题我做过一个压测场景用JMeter模拟200个并发用户同时抢一个医生的号第一次上线时因为只在代码里判断了slot状态没有加数据库行锁和Redis分布式锁结果产生了超卖。排查过程很典型前端页面显示有号点进去却约不上业务日志里出现多个相同的slotNumber被不同患者绑定。修复方案就是前面提到的三重保障Redis分布式锁做应用层限流数据库乐观锁update条件里带expected状态做最终一致性兜底事务内的for update行锁做强一致性保证。三轮压测下来数据完全正确200并发下单订单总数等于号源总数一个不差。这个案例我想表达的是代码里该有的锁一个都不能省但也不是越多越好“够用且正确”才是目标。6.2 跨域与代理配置问题前后端分离最烦人的就是联调阶段的跨域。开发环境下前端在Vite的配置里加一个server.proxy代理把/api开头的请求转发到后端的localhost:8080这样浏览器看到的所有请求都来自同一个源没有跨域问题。生产环境下Nginx配置里做同样的反向代理把/api路径转发到后端服务地址。这里有一个很隐蔽的坑代理配置里经常漏掉pathRewrite导致前端请求路径带上了/api前缀后端Controller的RequestMapping也要写/api结果加上代理之后请求就404了。我的习惯是后端所有接口统一带api前缀前端代理配置里不重写路径统一规则避免绕来绕去把自己绕晕。6.3 日期时间处理的时区陷阱医疗业务里“日期”和“时间”是严格分开的两个概念。排班日期用java.time.LocalDate时段开始结束时间用LocalTime这两类都不会受到时区影响。但是前端向后端传日期字符串时如果不加处理很可能会被Jackson反序列化成Timestamp类型导致日期偏移一天查出来的排班全错位。解决办法是统一约定前端所有日期格式传YYYY-MM-DD字符串后端用DateTimeFormat(pattern yyyy-MM-dd)注解接收并且在后端配置类里给Jackson配置JavaTimeModule设置LocalDate的序列化格式为yyyy-MM-ddLocalDateTime的格式为yyyy-MM-dd HH:mm:ss。这几行配置写好后前后端传时间就再不会出错了。6.4 接口越权访问的防护挂号系统里有一个常见的越权漏洞患者A登录后直接调接口查询患者B的挂号记录。如果后端接口只根据请求参数里的patientId去查而不校验这个patientId是否等于当前登录用户的ID那数据就泄露了。这个问题在团队新人写的代码里尤其常见。我梳理接口时会强制遵循一个原则所有涉及查询当前用户数据的接口一律从登录上下文获取用户ID禁止从前端参数读取patientId管理员操作类接口必须校验角色医生查看患者的接口要校验该患者是否确实挂过这个医生的号。前端可以不做这些限制但后端必须层层校验。7. 部署与上线要点7.1 前端打包与Nginx配置前端开发完成后运行npm run build生成dist目录把dist目录上传到服务器用Nginx托管。Nginx配置里有两个关键点location /里配置try_files $uri $uri/ /index.html保证前端路由在刷新页面时不404location /api/里配置proxy_pass http://127.0.0.1:8080/把API请求转发到后端。生产环境我强烈建议开启gzip压缩对js和css文件进行压缩后体积可以减小60%到75%页面加载速度显著提升。另外给Nginx配置了静态资源缓存带hash的静态文件设置7天强缓存html文件设置no-cache这样既能保证加载速度又不会在发版后让用户拿到旧的缓存文件。7.2 后端Docker化部署后端部署我封装了一个Dockerfile基础镜像用eclipse-temurin:17-jre然后把打包好的jar文件拷进去暴露8080端口。用Docker部署的好处是环境一致性不会再出现“在我电脑上能跑、到服务器上就报错”的问题。docker-compose里我一般同时编排三个服务mysql、redis和应用容器。mysql使用官方镜像并挂载数据卷redis同理应用容器依赖这两个中间件健康检查通过后才启动。这里有一个小坑应用启动时如果数据库还没初始化好启动过程会报连接失败所以要在启动命令里加一个等待重试机制比如用/bin/sh -c下先循环探测数据库3306端口通了再启动Java进程。7.3 数据库初始化与备份策略数据库初始化我整理了一份完整的SQL脚本分三个文件schema.sql建表结构、data.sql导入初始化的科室医生数据、index.sql单独存放所有索引脚本。之所以把索引单独拆出来是方便后续做索引优化时直接对比调整不用在庞大的建表语句里翻找。备份策略这块吃过亏早期以为数据量小不用每天备份结果有一次误操作把排班表全清了恢复数据花了大半天。现在我用crontab每天凌晨两点执行mysqldump备份文件按日期命名保留最近30天的备份。这个习惯推给所有做医疗系统的朋友患者数据和挂号数据都是核心数据资产一点都不能马虎。整个项目从架构设计到落地部署这一整套流程走下来我对SpringBootVue3做医疗挂号系统最大的体会是技术难点从来不在框架本身而在业务细节的把握和边界情况的处理上。比如号源状态的流转、退号后的资源释放、医生停诊时的通知链路这些才是真正决定系统能不能在真实医院环境里站稳脚跟的关键。如果你正在做这个项目先把业务表关系和状态流转画清楚再动手写代码后面会省掉非常多返工的时间。