基于SpringBoot的医院门诊在线挂号系统：从数据库设计到并发控制-代码聚汇网

基于SpringBoot的医院门诊在线挂号系统：从数据库设计到并发控制

小扁不扁·2026-09-03·阅读 22 GEO检测（免费）

SpringBoot医院门诊在线挂号系统并发控制

|难度：普通|阅读约 33 分钟

又到了一年一度赶毕业设计的时候。每年这个时候，我的私信里问得最多的问题就是："学长，毕业设计选什么题目好？不想写纯增删改查的，怕答辩挂，但太复杂的又怕做不完。" 如果你也卡在这个阶段，那我认真推荐一个我自己当年做过、也帮人改过无数遍的题目——基于SpringBoot的医院门诊在线挂号系统。这个题目恰好卡在"有一定技术含量但不至于失控"的位置上。这篇文章我就从选题理由、技术选型、数据库设计、核心链路实现，一直聊到毕业答辩的高频问题，完整梳理一遍。不管你手头已经有一份源码，还是准备从零开始自己写，看完都能少走很多弯路。

1. 为什么"医院门诊在线挂号"是毕业设计中最稳的选题之一

1.1 一个业务闭环完整的题目，几乎覆盖Web开发全部核心技能

毕业设计选题有个潜规则：不是越难越好，而是"该有的都有了，而且每一个点你都能讲清楚"。医院门诊在线挂号系统正好踩在这个甜点上。

拆开看，这个系统的业务量级虽然不大，但技术覆盖面很完整：

多角色权限：患者、医生、管理员三种角色，涉及登录认证、权限控制、数据隔离
复杂的数据关联：科室-医生-排班-号源-订单，至少五张核心表之间层层关联，天然需要多表查询、级联设计
真实的并发场景：热门专家号放出来几十秒就约满，这就是一个典型的并发资源竞争问题
状态机流转：挂号订单从待支付、已支付、已取消到已完成，状态流转必须清晰
前端交互：日期选择、时段选择、剩余号数实时展示，对前端组件使用是一种实战锻炼

这些技能点几乎都是面试时会被问到的东西。换句话说，做完这个项目，你不只是交了一个毕设，更像是把后端高频知识点完整串了一遍。到时候写在简历上，"实现了基于乐观锁的号源防超卖设计"这一句话，面试官一定会多看你两眼。

1.2 项目工作量可控，既能过盲审也讲得清楚

盲审老师看论文时真正关注的是：你有没有分析问题的过程，有没有方案之间的取舍，有没有设计到实现的闭环。医院挂号系统天然自带业务痛点可以写——线下排队时间长、号源信息不透明、热门科室预约全靠现场抢。你一上来就有"问题背景"可写，不是硬编的。

从开发量来看，这个项目的合理规模大约是：核心表十张以内、接口六十到八十个、页面十五个左右。一个人安安静静写一个月，完成核心功能完全够用，剩下时间还能打磨前端样式和论文。对大多数本科同学来说，这个节奏刚好不焦虑。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 需求拆解：从一次真实挂号动作反推系统设计

2.1 三个角色、三条主线的设计逻辑

做毕业设计最容易犯的第一个错误：题目拿到手，立刻打开Navicat开始建表。我见过很多同学建了二十多张表，最后自己都不知道哪些表是"凑数"的。我的建议是先反过来，模拟一次真实挂号流程，从流程里倒推需求，让每张表都有明确的业务来源。

整个系统围绕三种角色展开三条主线：

患者（前端用户）
注册登录后，按科室分类浏览科室，进入科室列表查看医生，再进入医生详情看到排班日历，选择一个有余号的时段，确认挂号信息，完成支付或模拟支付，最后在我的挂号记录里查看状态、取消订单。

医生（业务执行者）
登录后查看自己的排班表，选择某一天查看已挂号患者列表，按顺序接诊，并把患者状态标记为"已完成"。

管理员（系统维护者）
维护科室分类和科室信息，维护医生账号和医生资料，为医生批量生成排班，查看整体挂号统计数据，处理异常订单。

三条主线各司其职，互相之间有清晰的调用关系。你在设计阶段把这三条线画出来，后面建表、写接口、写论文都会非常顺。

2.2 核心业务流程：预约挂号这个动作里到底发生了什么

一个完整的挂号动作，表面上看是用户点了个按钮，数据库里多了条记录。但真正落库的瞬间，系统至少要做这几件事：

用户选中了某科室某医生在某个时段的一个余号
系统必须先判断当前号源是否还有剩余，否则直接提示"号源已满"
号源有剩余，则执行号源扣减，同时生成一条挂号订单
如果系统设计了支付环节，订单会进入"待支付"状态，支付完成后变成"已预约"
订单创建后，患者手机端立刻能看到挂号记录，医生端也能实时看到患者列表

这里最关键的决策点在第三步：号源扣减和订单创建这两个动作必须保证原子性。如果先扣减号源、订单创建却失败了，号源就凭空消失；如果先创建订单、再扣减号源，又可能发生超卖。这个矛盾是整个系统最核心的技术难点，也是答辩时老师最有可能深挖的地方。具体怎么设计，我在第五部分会专门展开讲。

3. 技术选型：SpringBoot主线的搭配方案与选型理由

3.1 后端框架：SpringBoot版本怎么定

打开Spring Initializr，第一个纠结的就是版本。目前主流选择是Spring Boot 2.7.x稳定版，或者Spring Boot 3.x。对毕业设计我的建议很明确：如果你想少踩坑，用Spring Boot 2.7.x + JDK 1.8的组合。

原因非常现实：绝大多数学校机房、指导老师熟悉的是2.x时代的使用方式，网上能搜到的教程和踩坑记录也基本集中在2.x。Spring Boot 3.0之后强制要求JDK 17，一些老牌的第三方库（如某些二维码生成组件、Excel导出工具、旧版MyBatis Plus）对3.x的兼容性还在补，你很可能把时间耗在依赖冲突上。不过如果你本机已经是JDK 17且对Spring Boot 3生态很熟，直接用3.x也可以，只是遇到问题时要会看依赖树。

技术栈清单我建议这样定：

层面	选型	说明
后端框架	Spring Boot 2.7.x	稳定、资料多、支持JDK 1.8
持久层	MyBatis Plus 3.5.x	单表CRUD一键生成，省时间
数据库	MySQL 5.7/8.0	免费，考试环境通用
认证授权	Spring Security 或 Sa-Token	Sa-Token上手更简单，Spring Security更经典
前端方案	Vue 3 + Element Plus 或 Thymeleaf	按是否前后端分离二选一
缓存（可选）	Spring Data Redis	用于验证码、分布式锁演示，加分项

3.2 持久层：MyBatis还是MyBatis Plus，别再纠结了

这个问题我私下被问过太多次。直接给结论：用MyBatis Plus，但在答辩前要搞清楚它的底层逻辑。

MyBatis Plus提供的BaseMapper、ServiceImpl、LambdaQueryWrapper，能把单表CRUD的开发时间压缩到传统MyBatis三分之一。比如分页查询，传统写法要手写PageHelper配置还要写XML，MyBatis Plus直接一个selectPage搞定。

但你要能说清楚：MyBatis Plus本身不替代MyBatis，它是在MyBatis之上做的增强，核心SQL执行能力依旧来自原生MyBatis。这个回答看起来简单，但在答辩时能体现出你确实知道自己在用什么。

3.3 前端与数据库的搭配

毕设项目里最稳妥的前端方案有两个方向。

方向一：前后端分离，Vue 3 + Element Plus + Axios。Vue生态成熟，Element Plus的表格、表单、日历组件对管理后台类页面几乎是开箱即用，特别适合快速做出"看起来挺专业"的界面。前提是你要会处理跨域，这个坑我后面单独讲。

方向二：服务端渲染，Thymeleaf + Bootstrap。对后端为主、不想碰前端工程化的同学很友好，模板直接在后端渲染，数据用Model传过去，全程不用考虑跨域问题。缺点是页面交互体验弱一些。

数据库没有悬念，MySQL 5.7或8.0都行。建表时统一用utf8mb4字符集、InnoDB引擎，否则后面做中文排序或存储特殊字符时会出现奇葩问题。

3.4 初始化项目时最容易忽略的两个配置

初始化项目最简单的方式是去Spring Initializr网站生成工程骨架，或者直接用IDEA自带的Spring Initializr。自己手动建依赖的话，最容易被忽略的是application.yml里的时区配置。很多项目接口返回的时间比实际时间整整多了8小时，就是因为数据库连接串少了serverTimezone=Asia/Shanghai。

code复制spring:
  datasource:
    url: jdbc:mysql://localhost:3306/hospital?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai
    username: root
    password: 123456
    driver-class-name: com.mysql.cj.jdbc.Driver

还有一件值得花两分钟做好的事：统一返回结果类。定义一个R对象，包含code、msg、data三个字段，所有接口都返回这个结构。再配一个全局异常处理器@RestControllerAdvice，把业务异常和系统异常分别处理。这样做的好处是，前端只需要判断code等于200就能正常取值，异常时直接读msg提示用户，代码维护起来会清爽很多。

4. 核心数据表设计与接口规划

4.1 六张必建的核心表

我见过不少毕设源码把表拆得稀碎，二十多张表堆在一起，JOIN查询把自己都绕晕了。实际上医院门诊在线挂号系统的核心，有六张表就完全够用：

表名	作用	关键字段
sys_user	用户表，患者、医生、管理员通过user_type字段区分	id, username, password, user_type, real_name, id_card, phone, status
department	科室表	id, dept_name, dept_code, intro, status
doctor	医生表，与用户表一对一，关联科室	id, user_id, dept_id, title, specialty, avatar, intro
schedule	排班表，核心中的核心	id, doctor_id, dept_id, schedule_date, period, total_count, remain_count, start_time, end_time
order_info	挂号订单表	id, order_no, user_id, schedule_id, doctor_id, dept_id, patient_name, status, appointment_time, create_time
dept_category	科室分类表，如一二级科室分类（可选但推荐）	id, category_name, parent_id, sort

这六张表覆盖的完整链路是：科室分类 -> 科室 -> 医生 -> 排班 -> 号源 -> 订单。每一张表都能在真实业务逻辑中找到明确位置，不会给人"为了多建表面凑数"的感觉。

4.2 字段设计与索引的实用建议

给初学者一个非常实用的建议：所有作为查询条件的字段都考虑加索引。特别是schedule表的schedule_date和doctor_id，order_info表的user_id、order_no和status。

有一个细节容易踩坑：password字段千万别明文存储。哪怕只是毕设，也要用BCrypt加密。Spring Security自带的BCryptPasswordEncoder可以单独拿出来用，注册时加密、登录时校验，这一个点写进论文，盲审老师直接给你加印象分。

订单号字段要设计成业务可见的编号格式，比如20250601103015加随机数，这样光看订单号就知道大致下单时间，排查问题时特别有用。

4.3 接口设计的几条约定

接口规范越统一，写代码时大脑负担越小。几个实用的约定：

路径风格统一用RESTful：POST /api/order/create、POST /api/order/pay、GET /api/schedule/list?doctorId=xx&date=xx
所有接口统一返回R对象；分页参数统一叫pageNum和pageSize
时间类型后端统一用LocalDateTime，配合JavaTimeModule序列化，避免出现时间格式歧义
业务异常统一抛自定义BizException，由全局异常处理器捕获

5. 核心模块实现：排班管理、号源锁定、订单创建的完整链路

5.1 排班生成：一个自动生成功能让演示效果直接拉满

排班是整套系统的"货源"。最普通的做法是管理员手动创建某位医生某一天的排班，点一次生成一条记录。更聪明的做法是支持批量生成：管理员选择医生、开始日期、结束日期，输入每个时间段的可挂号人数，系统自动生成多天的排班记录。

这个功能实现起来并不多难，但演示效果非常惊艳。比如我当初就是在管理后台加了个按钮——"一键生成未来一个月排班"，选择几个医生，点击生成，页面立刻出现几十条排班记录，台下老师眼睛都亮了。代码思路大概是：

java复制@Transactional
public void batchGenerateSchedule(BatchScheduleDTO dto) {
    DateTimeFormatter fmt = DateTimeFormatter.ofPattern("yyyy-MM-dd");
    LocalDate startDate = LocalDate.parse(dto.getStartDate(), fmt);
    LocalDate endDate = LocalDate.parse(dto.getEndDate(), fmt);
    List<Schedule> list = new ArrayList<>();
    for (LocalDate date = startDate; !date.isAfter(endDate); date = date.plusDays(1)) {
        Schedule s = new Schedule();
        s.setDoctorId(dto.getDoctorId());
        s.setDeptId(dto.getDeptId());
        s.setScheduleDate(date);
        s.setPeriod(dto.getPeriod());
        s.setTotalCount(dto.getTotalCount());
        s.setRemainCount(dto.getTotalCount());
        list.add(s);
    }
    scheduleService.saveBatch(list);
}

注意方法上的@Transactional，批量生成要么全成功要么全失败，不能生成一半就报错。

5.2 号源扣减的并发处理：从最简单的写法到真正可落地的方案

这一节是整个系统的技术核心，也是答辩时最值得展开讲的部分。我要说清楚一个问题：为什么看起来简简单单的update schedule set remain_count = remain_count - 1里面藏着大学问。

先说绝大多数毕设初学者的错法。很多人会在Service方法里写：

java复制Schedule schedule = scheduleMapper.selectById(scheduleId);
if (schedule.getRemainCount() > 0) {
    schedule.setRemainCount(schedule.getRemainCount() - 1);
    scheduleMapper.updateById(schedule);
    // 接着创建订单...
}

这段代码在单用户测试时完全没问题。但一旦有两个用户同时抢同一个号源，线程A读到remain_count=1，线程B也读到remain_count=1，两个人都进入了if，最后都执行了扣减和订单创建，结果就是同一个号源被两个人挂到了，这就是超卖。经典问题，病根在于"先读后写"不是原子操作。

正确的做法有很多种，我按从"最简单"到"最严谨"给你排开：

方案一：条件更新SQL（强烈推荐毕设使用）

sql复制UPDATE schedule 
SET remain_count = remain_count - 1 
WHERE id = #{scheduleId} AND remain_count > 0

这条SQL由数据库层保证原子性，remain_count > 0这个条件能防止扣成负数。在Java里执行后判断影响行数：

java复制int rows = scheduleMapper.deductCount(scheduleId);
if (rows == 1) {
    // 扣减成功，创建订单
} else {
    // 扣减失败，号源不足
}

受影响行数为1说明成功扣减，为0说明号源已经没了。这个方案简洁、优雅、无锁、性能好，而且面试时你能讲清楚为什么affected rows能当作判断依据，就已经超出很多同龄人了。

方案二：乐观锁

给schedule表加一个version字段，更新时带上版本号：

sql复制UPDATE schedule 
SET remain_count = remain_count - 1, version = version + 1 
WHERE id = #{scheduleId} AND version = #{version} AND remain_count > 0

如果影响行数为1，版本号自增，其他线程再用老版本号去更新就会失败。这个方案在答辩时很好讲，因为它自然引出"乐观锁和悲观锁区别"这个经典面试题。

关于事务边界：扣减号源和创建订单必须放在同一个事务里。但注意，如果你在方法上加了synchronized关键字，只能保证单机单实例下有效，一旦系统部署成多实例，锁就失效了。答辩时老师极有可能追问："如果以后部署多个服务实例，你的方案还成立吗？"这时候你可以回答：条件更新SQL的方案依然成立，因为锁的粒度在数据库这一层。你要是能到这个深度，答辩基本稳了。

5.3 挂号订单的状态机与过期释放

订单表里的status字段建议用数字枚举，含义清晰：

0：已取消
1：待支付
2：已预约（支付成功）
3：已完成（就诊完）
4：已过期

这里有一个特别容易处理的坑：如果用户锁定号源但迟迟不支付，号源就会被白白占用。毕设里最简单的处理方案是"30分钟过期释放"：支付接口判断订单创建时间是否超过30分钟，超过就返回"订单已过期"，同时在一个事务里执行两条SQL——把订单状态改成"已取消"，把schedule表的remain_count加一。这两步必须在一个事务里，否则会出现"订单已取消但号源没恢复"的bug。这个bug一旦在演示时正好撞上，评分基本就崩了。

6. 毕业设计验收的隐形坑：这些细节会让评分直接降档

6.1 事务失效和异常被吞：最常见的两个大坑

我带过的毕设项目中，代码能跑、功能正常、但一查源码就发现严重问题的案例太多了。最典型的就是事务失效。

先看这段代码：

java复制@Transactional
public void createOrder(OrderCreateDTO dto) {
    this.deductScheduleCount(dto.getScheduleId());
    orderMapper.insert(...);
}

public void deductScheduleCount(Long scheduleId) {
    scheduleMapper.deductCount(scheduleId);
}

问题出在this.deductScheduleCount()是同一个类内部方法调用。Spring的@Transactional是通过代理实现的，内部方法调用不会经过代理，所以事务根本就没生效。如果deductScheduleCount执行失败，它前面的SQL并不会回滚。解决办法很简单：扣减号源和插入订单的代码直接写在同一个带@Transactional的方法里，或者拆到另一个Service类里互相调用。

第二个常见大坑是try-catch把异常吞了。比如：

java复制@Transactional
public void createOrder(...) {
    try {
        // 业务代码
    } catch (Exception e) {
        log.error("error", e);
        // 没有继续抛出
    }
}

异常被catch住后没有往外抛，事务管理器根本感知不到出错，就会正常提交，导致数据不对。如果你确实需要捕获异常做处理，记得手动回滚：

java复制TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();

或者干脆不要吞异常，交给全局异常处理器去处理。

6.2 前端跨域、时间格式这类不显眼但必踩的坑

前后端分离项目，跨域问题躲不掉。在Spring Boot里配置一个CorsFilter，允许前端的源、请求方法和请求头，并且允许携带凭证。很多人配了还是报错，原因基本都出在allowedOrigins没写对。注意：本地Vue开发服务器默认跑在http://localhost:5173，你的跨域配置里必须包含这个源地址，否则前端一打开页面，控制台一片红。

时间格式是另一个高频扣分点。如果接口返回2025-06-01T10:30:00这种带T的格式，页面展示会很难看。在application.yml里做全局配置就能一次解决：

yaml复制spring:
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    time-zone: GMT+8

这样所有接口返回的时间都是2025-06-01 10:30:00这种人类可读格式。

前端还有一个特别容易被忽视的问题：刷新页面时，浏览器会重新加载应用，Vuex或Pinia里的登录状态会丢，导致用户被踢回登录页。解决思路是把登录状态持久化到localStorage，路由守卫里根据本地存储判断是否已登录。

6.3 论文与答辩准备的关键思路

论文部分最需要用心的是第四章"系统设计"和第五章"系统实现"。数据库设计要画出完整的E-R图，字段表要规范，系统实现部分不要贴大段代码，用核心代码片段加文字说明就够了，重点讲设计思路和实现逻辑。

答辩时老师最喜欢问的问题，我提前帮你列出来：

为什么选择SpringBoot？它相比传统的SSM（Spring MVC + Spring + MyBatis）框架有什么优势？ 答：自动配置降低了配置成本，内置容器让部署更简单，生态丰富。最好再补一句"SSM的自动化程度低，大量时间花在XML配置上"。
号源扣减是怎么保证不超卖的？如果是集群部署，方案还成立吗？ 答：核心用条件更新SQL或乐观锁控制并发，再解释一下为什么集群下synchronized会失效，用Redis分布式锁可以做进一步兜底。
数据库表建了哪些索引？为什么？ 答：结合查询场景说明，比如order_info表经常按user_id查订单、按order_no查单，所以都要加索引。
你的@Transactional事务一定生效吗？什么情况下会失效？ 答：要能说出同一个类内部调用失效、异常被吞覆盖失效这两点，再提一下Spring事务是基于代理实现的。

第五个问题是压轴的加分题："如果要做成商业级系统，你觉得自己还缺什么？" 你可以从这几个方向答：支付网关对接、短信通知、详细日志与链路追踪、Redis缓存热门科室排班、消息队列削峰。不需要真的实现，能把方案说出来，就已经证明你有全局视野了。

整个系统做完，最大的收获不是"我会写代码"了，而是你完整经历了一遍从需求分析、系统设计、编码实现到测试答辩的全流程。这套思维方式，才是毕业设计真正留给你的东西。