基于Spring Boot的医院预约挂号系统：从选题到答辩全攻略

每年到了毕业设计选题季，总有不少计算机专业的同学来找我参谋：有的想选个容易过审的题目，有的想找个能写进简历的项目，还有的干脆就是想找个附源码的现成项目改一改。说实话，如果你在Java技术栈上有点基础，又不想碰那些烂大街的图书管理、商城系统，“医院预约挂号系统”是一个性价比很高的选择。它业务场景清晰、功能边界明确，能覆盖Spring Boot框架的多数核心知识点，而且面试时聊起来也能讲出点东西。

这篇博文我会结合我自己带学生做这类项目的实际经验，把基于Spring Boot框架的医院预约挂号系统从选题逻辑、功能设计、数据库建模，到核心代码实现、论文写作、答辩准备，完整梳理一遍。无论你是打算用现成源码二次开发，还是想完全自己从零写，这篇内容都值得你收藏。

1. 为什么是“医院预约挂号系统”：选题背后的底层考虑

先别急着打开IDE写代码。做过毕设的人都知道，选题这一步基本决定了你后面三个月过得是舒服还是痛苦。医院预约挂号系统能被一届又一届学生选中，不是没有原因的。

1.1 毕业设计选题的常见误区

我见过太多人选错题目的案例。一类是选过于简单的，比如“XX信息管理系统”，说白了就是单表增删改查，写完了答辩时老师三句话就问穿，毫无亮点可言。另一类是选过于复杂的，比如“基于深度学习的医学影像辅助诊断系统”，听起来高大上，但自己根本hold不住，最后只能东拼西凑，代码跑不通，论文圆不回来。

医院预约挂号系统刚好卡在中间：功能复杂度足够撑起一篇像样的毕业设计，但技术难度又完全在一个普通本科生能驾驭的范围内。它的核心业务——预约挂号，本质上是“库存扣减”逻辑的变种，任何一个写过订单系统的人都能理解。

1.2 这个题目能覆盖哪些核心技能点

把医院预约挂号系统的功能模块拆开来看，你会发现它几乎是为Spring Boot量身定做的练手项目：

• 用户模块：注册、登录、个人信息维护，对应Spring Security或JWT鉴权，是每个Java后端项目都要有的基础功能。
• 科室/医生管理：管理员对基础数据的增删改查，对应MyBatis-Plus的常规CRUD操作。
• 排班模块：医生按日期、时段放号，涉及日期时间处理和业务规则的约束。
• 预约挂号模块：选科室、选医生、选时段、提交预约，这是整个系统的核心，也是你可以在答辩时重点讲的东西。它涉及事务、并发控制、状态流转。
• 支付模块：有些实现会接一个模拟支付接口，虽然毕设一般不要求真实支付，但加上会更有完整性。
• 消息通知模块：预约成功后发送邮件或站内信，对应Spring的事件机制或消息队列（简化版）。

这些技能点是互相咬合的：你用JWT解决登录认证，就要考虑接口如何放行和拦截；你写预约接口，就要思考“同一时段多人抢号”怎么处理；你设计数据库表，就会自然引入外键、唯一索引、状态字段。一套做下来，你对Spring Boot框架的理解不再是“背八股”，而是真正建立起了前后端联动的整体认知。

1.3 Spring Boot在毕业设计中的地位

说句实在话，现在毕设不用Spring Boot，倒显得有点奇怪了。Spring Boot之所以成为Java后端毕设的“标准选择”，核心原因是它把Spring繁琐的XML配置全部自动化了，内置Tomcat，一个jar包就能跑起来。对毕设场景来说，这意味着你节省了大量配置时间，可以把精力放在业务逻辑本身。

另外Spring Boot庞大的生态也意味着，不管你遇到什么问题，网上基本都能找到答案。我经常和同学说：毕设技术栈选型，别追求最新最炫，要选“出了问题你搜得到解决方案”的。Spring Boot + MyBatis-Plus + MySQL这套组合，就是目前Java毕设题库里最稳的答案。

2. 系统整体设计：从需求分析到数据库表结构

题目定下来之后，下一个关键步骤是写需求分析和系统设计。很多同学喜欢跳过这步直接写代码，结果写到一半发现表结构不合理、功能逻辑对不上，再回头改就是一锅粥。医院预约挂号系统尤其如此，因为它的业务逻辑比普通CRUD复杂不少。

2.1 功能角色划分：管理员、医生、用户三条主线

医院预约挂号系统，按角色来划分功能模块是清晰的，可以这样设计：

这个设计的好处是，三方角色的需求边界非常清晰。你在论文的需求分析章节里，可以分别从这三个角色出发画用例图、写功能需求表，内容既充实又好组织。

我见过有些项目还加了“科室排班日历”和“号源池”的复杂设计，但对毕设而言有点超出范畴了。一个简化的排班模型足够支撑论文的核心创新点：每个医生在某个工作日有若干个可预约时段（例如上午、下午），每个时段设定号源总数和剩余号数。挂号就是锁定号源，取消预约就是释放号源。

2.2 数据库表设计：核心九张表与其关联逻辑

数据库是整个系统的地基。医院预约挂号系统我推荐拆成9张核心表，它们之间的关联关系如下：

用户类

• sys_user：用户表，字段包括id、用户名、密码（BCrypt加密）、姓名、手机号、性别、年龄、角色（admin/doctor/patient）等。
• sys_role、sys_user_role：如果做角色权限分离，建议加这两张表，实现基于角色的访问控制（RBAC）。

医院基础数据类

• department（科室表）：id、科室名称、科室描述、科室位置、创建时间。
• doctor（医生表）：id、姓名、所属科室ID、职称、简介、头像、排班状态。科室与医生是一对多关系。
• schedule（排班表）：id、医生ID、排班日期、时段（如上午/下午）、号源总数、剩余号数、排班状态。这是核心业务表，预约功能就是围绕它展开。
• appointment（预约挂号表）：id、排班ID、用户ID、预约编号、预约时间、状态（待支付/已支付/已取消/已完成）、取消时间。
• payment_record（支付记录表）：id、预约ID、支付金额、支付方式、支付状态、流水号。模拟支付即可，不一定对接真实支付网关。
• medical_record（病历表）或consultation_record（就诊记录表）：id、预约ID、诊断内容、用药建议、创建时间。这对应医生角色的核心操作。

辅助功能类

• notice（公告表）：id、标题、内容、发布时间。用来撑起前台首页的动态信息展示。

这9张表之间，schedule表是整个业务逻辑的心脏：用户发起预约时，系统要检查该排班剩余号数是否大于0；预约成功后剩余号数减1；取消预约后剩余号数加1。理解了这个“号源流转”模型，你就能理解整个预约系统的核心机制。

2.3 前后端交互与接口设计思路

接口设计方面，我推荐走RESTful风格。你不需要在毕设里把RESTful做到教科书级别，但基本的资源化命名要有：/api/department（科室列表）、/api/schedule/doctorId/{id}（查医生排班）、/api/appointment/submit（提交预约）、/api/appointment/cancel（取消预约）。合理的接口设计，往往也是老师在论文评阅时给你画重点的地方。

关于前端，毕设项目两种路线都可以：

• 前后端分离：Vue + Axios + Element UI 调Spring Boot接口，工作量稍大，但答辩效果更好，也更贴近企业开发方式。
• 服务端渲染：Thymeleaf模板引擎直接渲染页面，工作量小，跑起来不易出架构性问题，适合时间紧张或前端基础不太扎实的同学。

个人建议如果你时间还算充裕，尽量做前后端分离。面试时这段“前后端分离架构 + 接口签名设计 + JWT鉴权流程”的描述，含金量远高于“用模板引擎拼页面”。

3. 核心功能实现：Spring Boot工程搭建与关键模块细节

工程搭建本身不复杂，我给你一份可以直接照着用的依赖清单和核心逻辑写法。

3.1 工程搭建与常用依赖配置

创建一个Spring Boot项目，建议选 Java 8 或 11，Spring Boot 版本用 2.7.x 系列（稳定且资料最多，不要追新，3.x对部分插件和框架兼容性要求变化较大，对毕设来说是徒增麻烦）。核心依赖配置如下：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3.1</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.33</version> <scope>runtime</scope> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-security</artifactId> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt</artifactId> <version>0.9.1</version> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency>

这里我选MyBatis-Plus而不是原生MyBatis，是因为它提供了BaseMapper，单表CRUD基本不用写SQL，能帮你节省大量重复劳动。分页插件直接内置了PaginationInnerInterceptor，配置十几行就能用。这对毕设来说足够了。

application.yml里重点是数据库连接配置和数据源初始化：

spring: datasource: url: jdbc:mysql://localhost:3306/hospital_db?useUnicode=true&characterEncoding=utf-8&serverTimezone=Asia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

注意设置时区为Asia/Shanghai，否则本地时间比数据库时间早8小时，你测试预约时间时会突然发现日期对不上。

3.2 预约模块的实现逻辑：事务与并发控制

预约挂号是整个系统的核心，也是答辩时老师最可能深挖的地方。它的流程并不复杂：用户提交预约请求→校验排班是否存在、是否在有效期内、剩余号数是否大于0→扣减号源→生成预约记录。

难点在于并发场景：当大量用户同时抢同一个时段的号源时，如何保证不会超卖？

最简单也最经典的解决办法是乐观锁。在排班表的映射实体上加一个version字段，更新号源时使用带版本条件的SQL：

@Update("UPDATE schedule SET remain_count = remain_count - 1, version = version + 1 " + "WHERE id = #{scheduleId} AND remain_count > 0 AND version = #{version}") int deductStock(@Param("scheduleId") Long scheduleId, @Param("version") Integer version);

当update返回影响行数为0时，说明该时段号源已被抢完或者版本号冲突，此时抛出业务异常“该时段已被约满，请选择其他时段”。配合Spring的@Transactional注解，就能保证以下逻辑的原子性：扣减号源和创建预约记录要么同时成功，要么同时失败。

完整预约方法示例：

@Transactional(rollbackFor = Exception.class) public AppointmentVO submitAppointment(AppointmentSubmitDTO dto) { Schedule schedule = scheduleMapper.selectById(dto.getScheduleId()); if (schedule == null) { throw new BusinessException("排班不存在"); } if (schedule.getRemainCount() <= 0) { throw new BusinessException("该时段号源已约满"); } int rows = scheduleMapper.deductStock(dto.getScheduleId(), schedule.getVersion()); if (rows == 0) { throw new BusinessException("预约冲突，请重新选择时段"); } Appointment appointment = new Appointment(); appointment.setUserId(dto.getUserId()); appointment.setScheduleId(dto.getScheduleId()); appointment.setAppointmentNo(generateAppointmentNo()); appointment.setStatus(0); // 0-待支付 appointmentMapper.insert(appointment); return convertToVO(appointment); }

这里有几个细节值得注意：

• rollbackFor = Exception.class必须带上，Spring 默认只回滚运行时异常，如果漏了，前面的库存扣减可能已经提交了。
• 乐观锁的version字段并非必须，但加了之后，你可以在论文里多写一段“并发控制方案对比”，这是加分项。
• 预约编号建议用时间戳+随机数生成，例如APPOINT_NO前缀加日期，这样看起来专业，也便于后续按编号查询。
• 取消预约时同样要加事务：释放号源（remain_count + 1）并更新预约状态为已取消。

3.3 登录与权限控制的落地方式

毕设项目最常用的两种登录方案是Spring Security + JWT，或简单拦截器 + Redis Session。对于要写进论文的项目，我更推荐前者，因为Spring Security是面试高频考点，你做了它就能顺带弄明白过滤链、认证管理器这些概念。

实现思路是这样的：用户登录时传入用户名密码，服务端校验后用JWT生成一个token返回给前端，前端在后续请求的Header里带上Authorization: Bearer token，后端通过一个JwtAuthenticationFilter来解析token并注入用户上下文。

@Component public class JwtAuthenticationFilter extends OncePerRequestFilter { @Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws ServletException, IOException { String authHeader = request.getHeader("Authorization"); if (authHeader != null && authHeader.startsWith("Bearer ")) { String token = authHeader.substring(7); try { Claims claims = Jwts.parser().setSigningKey(secretKey) .parseClaimsJws(token).getBody(); Long userId = Long.parseLong(claims.getSubject()); request.setAttribute("userId", userId); } catch (Exception e) { response.setStatus(401); return; } } chain.doFilter(request, response); } }

权限控制还得配合Spring Security的SecurityFilterChain配置，放行登录接口、科室列表接口等无需鉴权的URL，其余接口一律要求认证。具体放行配置我就不贴了，网上资料很多，核心理解是：认证用AuthenticationManager，鉴权用注解@PreAuthorize("hasRole('ADMIN')")，这两个概念吃透，答辩时讲权限模块就游刃有余了。

3.4 消息通知模块：用Spring事件机制解耦

预约成功后给用户发通知是一个很有实用性的扩展点，直接调用邮件服务当然可以，但更好的做法是用Spring的ApplicationEventPublisher把业务逻辑和通知逻辑解耦。

业务里只需要一行：

applicationEventPublisher.publishEvent(new AppointmentSuccessEvent(appointment));

然后定义监听器处理发送逻辑，例如发送邮件、站内信或短信（毕设中对接阿里云短信网关需要资质，通常不做，预留接口即可）。

这种写法在论文的“系统设计”里能写出一个像样的“基于事件驱动的模块解耦设计”小节。就一行代码的改动，就能给论文增加一个亮点。

4. 论文写作如何与代码配合：少走弯路的顺序

代码写完只是第一步，论文才是毕业设计真正的交付物。很多人有个误区：先狂写代码，最后两天再赶论文。这样写出来的论文往往和代码严重脱节，答辩时一被问细节就崩。我的建议是论文写作一定要跟开发同步推进，至少在大框架上齐头并进。

4.1 论文章节结构与对应代码模块

医院预约挂号系统的毕业论文，标准的五章结构是这样安排的：

第一章 绪论：写研究背景、国内外现状、研究内容、论文组织结构。对应你前期调研的需求，不用搞太宏大，聚焦“传统人工挂号排队耗时、医疗资源分配不均”这些问题即可。注意查重，不要直抄官方文件的表述。

第二章 相关技术介绍：介绍Spring Boot、MyBatis-Plus、MySQL、Vue（如果你用了）、JWT、Maven。每个技术写清楚“为什么选它”，不要写成纯概念介绍。例如，Spring Boot可以强调其自动化配置，MyBatis-Plus可以强调其代码生成和分页能力。

第三章 系统需求分析：画用例图、写角色分析、功能需求表、非功能需求（性能、安全性、可维护性）。这一章最好在系统设计阶段就写完，因为它是设计的基础。

第四章 系统设计：架构设计、功能模块划分、数据库设计。数据库设计里要画出E-R图，然后把建表SQL转成“数据字典”表格，字段名、类型、约束、说明都要写清楚。

第五章 系统实现：对应代码逐模块展开，展示核心类的设计、关键方法的逻辑、核心代码片段。注意代码片段不要贴太长，一般展示核心逻辑10~15行为宜。每个模块配上运行截图。

第六章 系统测试：写功能测试用例表（用例编号、前置条件、输入、期望输出、实际结果）、做简单的性能测试（如JMeter并发10个用户预约，记录响应时间），这部分其实是最好写的内容，只要把表格填好就行。

4.2 图表怎么画才规范

论文中图片和表格是加分项，也是最难做好的部分。常见的规范是：

• 用例图：三个角色分别画三个用例图，主用例包括注册登录、预约挂号、取消预约、排班管理、医院公告管理等。工具推荐ProcessOn或Visio。
• 时序图：画一个提交预约的时序图，从请求进来、到校验、扣库存、创建记录、返回结果，一条时间轴走完，这张图是答辩时的好武器。
• E-R图：展示9张表的实体关系和约束关系。
• 功能结构图：把系统按角色和模块画成树状图。

画图的价值在于：答辩时老师问你“系统是怎么设计的”，你指着图讲三分钟，绝对比对着代码块干讲要清楚得多。

4.3 查重和降重的实用经验

论文查重是很多同学的噩梦。降低查重率的方法有几种：

一是不要直抄博客和网上的代码分析。Spring Boot的代码逻辑都差不多，但你用自己的语言把实现细节描述一遍，配合自己的命名，查重率会低很多。

二是技术介绍章节不要堆名词。写Spring Boot自动配置原理时，与其把官方文档翻译一遍，不如结合你项目的某个具体现象来写，比如“在本系统中，配置文件设置server.port=8080后启动器自动完成Tomcat的初始化和端口绑定，省去了传统Servlet容器的配置步骤”。

三是数据库设计部分用表格完成。数据字典表格是原创的，查重系统无法关联检测，而且本身就是规范做法。

5. 部署演示与答辩准备：让项目经得起提问

代码写完了，论文也交了，最后还剩下一个重要环节：把项目跑起来演示，让老师信服这是真的会做的项目。这步看着简单，但我见过太多人在这里翻车。

5.1 本地部署演示的完整步骤

毕设演示不需要上云服务器，本地跑就够了。推荐一套稳妥的本地环境：

1. 安装JDK 1.8或11，配置JAVA_HOME环境变量。
2. 安装MySQL 8.0，创建数据库hospital_db，导入项目提供的hospital_db.sql脚本。
3. 用IDEA打开项目，等待Maven完全下载完依赖，注意检查右下角进度条，很多同学翻车在这步——依赖没下完就启动，各种ClassNotFound。
4. 修改application.yml里的数据库账号密码，确保与本地环境一致。
5. 启动HospitalApplication主类，看到“Started HospitalApplication”日志即启动成功。
6. 浏览器访问http://localhost:8080，进入系统首页。

有一个本地启动的坑值得提醒：如果你的项目用了Spring Security且配置了CORS跨域，本地调试时Vue前端如果开了不同端口（比如8081），记得把跨域配置里的allowedOrigins改成对应地址，否则前端永远报401/403。这是前后端分离项目本地联调最易出现的问题。

5.2 演示数据准备

演示环节最怕冷场。建议提前把演示数据做好：

• 创建3个科室：内科、外科、儿科，每个科室配2名医生。
• 排班数据至少覆盖未来一周，每个时段号源总数设置10个、剩余数5个左右，这样既能演示“有号可约”，也能演示“约满无号”的提示。
• 管理员账号（admin）、医生账号（doctor01）、患者账号（patient01）各准备一个，密码统一设置为测试密码并牢记。

演示流程我建议固定成一条主线：用户登录 → 浏览科室 → 选择医生 → 选择有号的日期时段 → 提交预约 → 模拟支付 → 查看我的预约 → 取消预约 → 重新预约。整个过程大概3分钟，既展示了核心功能，又不会因为临场找数据而卡壳。

5.3 答辩高频问题与应对思路

毕设答辩老师最爱问的问题其实就那么几类，提前准备就能应付：

• 问：为什么选Spring Boot？答：它解决了传统Spring配置繁琐的问题，内嵌容器一键启动，生态完善，适合快速开发和部署，同时也为后续微服务扩展留了基础。如果能结合项目里自动装配的例子讲更好。
• 问：预约并发冲突怎么解决？答：用乐观锁版本号机制，在更新排班表号源时通过SQL条件version = 当前版本保证并发安全，匹配失败即提示用户重试，避免超卖。
• 问：登录鉴权是怎么做的？答：JWT无状态认证，登录成功签发token，前端在请求头携带token，后端用过滤器统一解析校验，用Spring Security管理接口访问权限。
• 问：如果用户同时取消和支付，数据会冲突吗？答：支付和取消都要以预约号为条件更新状态，并且加事务和条件更新，例如UPDATE appointment SET status = 已支付 WHERE id = ? AND status = 待支付，保证状态只能按流程流转。
• 问：你的系统有哪些不足？答：不要只说“没有不足”，那样反而显得假。可以真诚地说：当前只做了模拟支付，未对接真实第三方支付平台；短信通知未实际接入，只预留了接口；预约时间粒度偏大，未精细化到具体时间段。

这几个问题你心里有数了，答辩基本就稳了。

我个人做项目指导时的体会是：毕设不只是为了拿学分，它更像一次完整的工程训练。你在医院预约挂号系统里踩过的每一个坑——数据库时区问题、乐观锁失效、JWT过滤器放行路径写错、跨域被拦——都是以后工作中真实会遇到的问题。源码和论文是结果，但过程中养成的排查思路和工程习惯，才是真正能带走的东西。希望这篇实战梳理能帮你把项目做扎实，答辩场上心里有底。