企业官网建设流程全解析

Spring Boot医院就诊系统毕设全解析：从排班到电子病历，把毕业设计做成能答辩的作品

每年到毕业季，后台总有一堆人问我同一个问题：“博主，Java方向的毕设选什么题目好？有没有那种功能全、体面、能写论文、还能讲清楚的项目？” 说实话，医院就诊系统是我近几年推荐频率最高的一类题目。原因很简单：它不偏门，不炫技，业务场景真实且完整，覆盖了用户角色管理、核心业务流程、状态机切换、数据关联设计这些毕设考察的硬指标。而且从外部看，它贴近民生，自带“有意义”的光环，答辩老师听到题目第一反应就不会刁难你。

这篇东西不是给你贴一堆源码截图就完事，我会把整个项目从设计思路到核心模块的实现细节，再到答辩时容易被追问的点，一层层拆开来讲。手里有这套“Spring Boot + Java Web医院就诊系统”源码和文档的同学，对照着看，你会知道每一段代码为什么这么写；还没定题的同学，看完这篇文章，你也可以判断这个题目适不适合你，以及上手要从哪里开始。

1. 项目全貌与核心需求拆解

1.1 这个系统到底是做什么的

抛开“医院就诊系统”这个喊起来有点大的名字，本质就一句话：把线下医院“挂号、候诊、看病、开药”这条线，搬到Web端，用代码把流程管起来。

角色划分很清晰，三个端，三类人：

• 患者（前台用户）：注册登录、浏览医生排班、在线预约挂号、查看自己的电子病历和处方。
• 医生（后台用户）：查看自己的排班、处理待就诊患者、书写电子病历、开处方（关联药品）。
• 管理员（后台管理员）：管理科室、医生信息、药品库存、排班规则、统计数据。

这套结构几乎是医疗类毕设的标准范式，也是它最大的优点：角色越多，意味着你可以展示的技术点就越多——Spring Security或JWT做认证授权、AOP做操作日志、MyBatis-Plus做数据操作、Redis做缓存与分布式锁。每个技术点都能在业务里找到落地的位置，而不是生硬地堆砌。

你需要认清一个现实：毕设评审老师看重的不是你用了多冷门的技术，而是你对一个完整业务的理解能力。一个能把排班、挂号、病历、药品这四个模块之间的数据流转讲清楚的学生，比一个堆了一堆中间件却说不出业务逻辑的学生，得分高得多。

1.2 核心痛点：为什么很多类似系统做着做着就崩了

很多人拿到这种题目，第一反应是“不就是CRUD吗”，然后上手写代码，写到最后发现几个绕不开的坎：

• 排班怎么生成？总不能让管理员每天手动录一次排班，这是不可能的，必须有一次生成，未来N周自动重复的能力。
• 号源怎么控制？上午号源30个，第31个人来挂号，不能让他成功。这就要求挂号和号源扣减必须是原子操作。
• 电子病历和处方怎么关联？病历是患者维度的，处方是一次就诊维度产生的，药品库存又要跟着处方走，如果设计不当，这三张表会写得非常乱。

这些问题在校期间的项目里没有被认真对待，但恰恰是它们构成了系统的“业务复杂度”。而这个复杂度，就是你论文里“核心难点与解决方案”那一章的内容来源。我建议你先别急着写代码，把这几个问题的数据关系想明白，再动手。

2. 技术选型与项目结构设计

2.1 为什么是Spring Boot + MyBatis-Plus这套组合

技术选型这件事，我见太多人翻车了。有人用JSP + Servlet做完了整个系统，答辩的时候被老师问“Spring Boot在里面解决了什么问题”，当场语塞；有人非要上微服务、上分布式事务，结果自己都跑不起来。

对于这个项目，最稳的组合是：

这里有个取舍要说清楚：为什么不推荐用重型Shiro或Spring Security的完整配置？因为对于这种规模的项目，它的很多概念（Filter链、Session管理、RememberMe等）用不上，但配置复杂度却上来了。你只需要一个拦截器校验JWT，加上注解控制角色权限，就已经足够应对“管理员功能”和“患者功能”的区分。答辩时老师问权限控制怎么做，你能讲清楚注解+拦截器的原理，比背出一串Security配置更加分。

2.2 项目目录结构与包划分的讲究

源码里的目录结构基本是这个模式，我强烈建议你不要随手改掉，这是照着企业级项目的规范来分的：

com.hospital ├── controller // 接口层，只做参数接收和结果封装 ├── service // 业务层，核心逻辑都在这 │ └── impl ├── mapper // 数据访问层，MyBatis-Plus的BaseMapper ├── entity // 数据库实体 ├── dto // 前端交互对象（避免直接把实体暴露给前端） ├── vo // 视图对象（组合数据用） ├── config // 配置类（跨域、JWT、MyBatis-Plus分页） ├── utils // 工具类（JWT生成校验、日期处理） ├── interceptor // 拦截器（登录校验、角色校验） └── common // 统一返回结果、异常处理、常量

这个包结构的好处是，每一个文件放哪里，规则是明确的。你写代码的时候不用想“这个类该放哪”，直接对号入座。更重要的是，论文里的“系统架构图”和“模块设计”，基本可以照着这个结构画，逻辑上完全能自洽。

很多同学拿到源码第一件事就是打开IDE直接Run，我建议不要这样。先花半小时看包结构和表结构，你会对整个系统的数据流有直觉。数据流想清楚了，后面改bug也好，加功能也好，都不会晕。

3. 核心业务模块逐层拆解

3.1 预约挂号模块：并发场景下的号源扣减

这是整个系统最核心、也是最需要在答辩时讲清楚“为什么”的模块，没有之一。

一个标准的预约流程是这样的：患者选择科室 → 选择医生 → 选择日期和午别（上午/下午）→ 选择剩余号源 → 提交挂号单。听起来简单，但背后有两个必须处理的问题。

第一个问题是号源怎么设计。常见做法是在排班表里直接放一个total_count和remain_count字段。每天生成排班的时候，remain_count等于total_count；患者每次挂号成功，remain_count减1。这个设计简单直接，但要注意：扣减操作和创建挂号记录必须在一个事务里，否则会出现“记录建好了，号没扣掉”或者反过来。

第二个问题是并发。两个患者同时请求最后一个号，会有一次超卖风险。在实际业务里我们通常用两种手段解决，这个项目里采用的办法值得你理解：

• SQL层面的原子扣减：UPDATE schedule SET remain_count = remain_count - 1 WHERE id = ? AND remain_count > 0。让数据库自己保证扣减不会扣成负数。
• 如果使用了Redis，还可以加上分布式锁（setnx）做二次保障，但本质上上面这条SQL已经足够。

这里需要特别留意一个高频bug：如果后台管理端修改了排班号源总数，前端展示的剩余号数还是旧数据。回忆一下你写的查询接口，是不是每次请求都实时查了数据库？如果是，就不会出现这个问题。如果用了缓存，就要在修改排班时主动清理缓存。

3.2 医生排班模块：周期规则与批量生成

排班模块常见的实现方式是维护一个schedule_rule表，记录每个医生的坐诊周期规则。比如：医生张三，每周一上午、周三下午在消化内科坐诊，每次放号30个。那么管理员只需要设置一次规则，系统就按照规则批量生成未来四周的排班。

生成排班的代码逻辑，核心就一句话：从开始日期循环到结束日期，判断每一天是否符合该医生的坐诊星期规则，符合则插入一条排班记录，随带生成号源数。

我见过初学的人在这里犯的一个最典型的错误：把排班表和排班规则表合在一张表里，手动一条条插入未来N周的记录。这样做的问题在于——没有“排班规则”这个概念，系统就不具备自动生成的能力，管理员的维护成本极高，而且论文里也少了一个可以展开讲的业务设计点。

排班表的关键字段建议这样设计：doctor_id、department_id、clinic_date、time_slot（上午/下午）、total_count、remain_count、status（开启/停诊）。需要注意的是，如果医生临时停诊，不要删除排班记录，而是把status置为停诊，已挂号的用户需要在挂号记录中标记“已退号”，这样数据的完整性更经得起推敲。

3.3 电子病历模块：结构化的才是好病历

电子病历如果做成一个富文本编辑器，让医生随便填一段HTML，那么这个模块就废了。你没法统计、没法分析、也没法设权限，答辩被问“为什么不用文本域”会很难受。

正确的做法是结构化设计。一次就诊的病历，至少包含这些核心部分：

之所以强调结构化，是因为要关联处方。当医生写完病历时，可以针对当次就诊开具处方，处方明细表里存药品ID、数量、用法用量。一份病历可以对应多张处方，一张处方可以包含多种药品，这就是典型的“主-子表”结构，反映在数据库表设计上：

• medical_record（病历主表）：主键id、患者id、医生id、就诊id、主诉、诊断结果、创建时间。
• prescription（处方表）：处方id、病历id、医生id、患者id、总金额、状态（未取药/已取药）。
• prescription_item（处方明细表）：明细id、处方id、药品id、药品名称、单价、数量、用法、用量。

这里有个细节值得注意：处方明细表里，药品名称和单价是冗余存储的。这是有意为之，因为药品的名称、价格未来可能调整，而历史处方必须保持开单当时的信息不变。这就是“快照”的思路，答辩时能说出这一层，老师会觉得你真的考虑过业务。

电子病历还有一个必须做的功能——查看历史。也就是患者每次就诊结束后，能够列出自己的历次病历和对应处方。这个并不复杂，就是按患者id查两张表，但体现的是“数据关联设计”的能力。

3.4 药品管理模块：库存与处方联动

药品管理这个模块看上去是“纯CRUD”，但如果你只做增删改查，就浪费了一个展示业务完整性的机会。真正有含量的是两件事：

第一，药品分类与检索。用drug_category表管理分类，药品表通过category_id关联。这样在前端可以按分类浏览药品，在药房窗口可以快速按名称关键字检索。这个小设计在很多毕设系统里被忽略了，但它能让你的系统在演示时显得“像个真实系统”。

第二，库存与处方联动。当医生开完处方，不应该立即扣库存，因为患者可能还没去药房取药。正确的做法是：医生开处方只写清单，状态置为“待取药”；患者在药房窗口完成取药操作时，才把处方状态改成“已取药”，同时对每种药品执行库存扣减。这个流程拆解成代码，就是两个独立接口：createPrescription和dispensePrescription。前者校验医生身份和患者信息，后者校验处方状态并扣库存。

在这个地方你一定会遇到一个经典问题：库存不足时怎么处理？我在源码里处理的方式是，在dispensePrescription中对每个药品检查库存，如果任一药品库存不足，整个取药操作回滚，并提示“库存不足”。遵循的原则是“要么全部扣减成功，要么一个都不扣”。这个逻辑要讲给答辩老师听，因为它是“事务一致性”最典型的业务案例。

4. 从0到1完成项目的实操过程记录

4.1 初始化项目与数据库环境的搭建

这部分看起来基础，但我见过太多人在这一步浪费了整整两天。先把操作顺序写清楚：

1. 装JDK 8+（推荐JDK 1.8或11），配好JAVA_HOME环境变量。IDE务必用IDEA，社区版就足够。
2. 安装MySQL 5.7+，记得把字符集设置成utf8mb4，否则后面写中文病历必乱码。建库语句：CREATE DATABASE hospital_system DEFAULT CHARACTER SET utf8mb4;
3. 导入项目源码。这一步之后先别急着Run，先找到application.yml，把数据库账号、密码改成你自己的。
4. 初始化数据表。源码包的sql目录下一般会有init.sql或hospital.sql，直接导入即可。内置的管理员账号密码、测试医生账号密码都在这个SQL文件里，要注意看一眼。

启动Spring Boot应用后，控制台出现Tomcat started on port(s): 8080，基本就算是环境通了。接着前端项目（Vue部分）用npm install安装依赖，再npm run dev启动。如果前端跑起来后接口报跨域错误，去后端找CorsConfig确认是否已经放行。

4.2 核心接口的开发顺序建议

如果你不是直接拿现成源码，而是想自己写一遍，我建议你严格按这个顺序来开发，每完成一步都是一个可运行、可验证的里程碑：

这个顺序的精髓在于：每完成一步，业务链都是通的。做到第4步时，你已经跑通了“患者→医生→排班→号源”的核心链路；做到第6步时，整套系统从挂号到取药的闭环就完整了。最后一步统计报表，是论文截图和高分演示的加分项。

4.3 必须避开的五个开发坑

我平常帮人调试这类项目，发现低级的错误反反复复就那么几个。你自己动手做的时候，先把这个清单存一下，能帮你省一大半时间：

• 数据库时区问题。连接URL里一定要加serverTimezone=Asia/Shanghai，否则日期字段会出现8小时时差。
• MyBatis-Plus的逻辑删除。如果启用了@TableLogic，所有的查询会被自动追加deleted=0条件，此时如果你的SQL里用了自定义delete语句，会出现删不掉的问题。
• 日期格式化。前端传2025-06-01这种字符串，后端接收要用@DateTimeFormat(pattern="yyyy-MM-dd")，否则直接400报错。
• JWT过期时间。设置过期时间不要太短，建议24小时，否则患者看个病历的中途token就过期了，体验非常差。
• 分页插件的配置。用MyBatis-Plus分页一定要配置PaginationInnerInterceptor，否则调用Page对象时数据查不出来，这是最典型的“启动不报错，一查就出问题”。

4.4 运行视频和讲解视频怎么配合使用

这套资料里附带了运行视频和讲解视频，很多人直接从头看到尾，看完就忘了。我的建议是换一种用法：

• 第一遍，只看运行视频，跟着操作一遍系统，目标是搞清楚“这个系统能干什么”。
• 第二遍，结合源码，看讲解视频中关于核心模块（挂号、病历）的部分，目标是搞清楚“这个功能是怎么实现的”。
• 第三遍，带着自己的问题去看，比如“如果我改了排班规则，对已有的挂号记录有什么影响”。这时你会比第一遍收获大得多。

你最后去答辩，老师手里的评分表基本就是：系统演示（40%）、论文与文档（30%）、讲解与回答问题（30%）。系统演示靠你平时的操作熟练度，讲解和回答靠你对自己项目的理解深度。把视频里讲过的模块关系消化成自己的话，比背代码重要得多。

5. 常见问题与排查技巧实录

5.1 启动失败“Field userMapper in ... required a bean of type”

这是最高频的问题，原因几乎千篇一律：@MapperScan注解没有加，或者加了但扫描的包路径不对。去主启动类上确认一下，注解里的路径必须是mapper接口所在的包名。如果加了还是不行，再检查一下mapper接口上是不是漏了@Mapper。

其次常见的是依赖冲突。用了spring-boot-starter-web还手贱引入了旧的JAX-RS依赖，会导致启动时一系列奇怪的Bean创建异常。这类问题看堆栈第一行，按图索骥去搜索解决方案，比自己瞎猜快。

5.2 前端调用接口返回404或405

404优先排查两个地方：一是controller的@RequestMapping路径有没有写全，二是前端axios请求的baseURL是不是指向了正确端口。如果前后端分离部署，后端还要确认CorsConfig是否配置正确，否则前端跨域请求会被浏览器拦截，表现为页面报错，但浏览器Network里其实已经发出了请求。

405通常意味着请求方式不匹配。后端接口定义的是@PostMapping，前端用了get请求，就会报405。我习惯的排查方式：先看浏览器Network面板，点开请求看Request Method，再对照后端方法上的注解。这个对照30秒就能定位。

5.3 中文乱码问题

这问题主要集中在两端：一端是HTTP请求响应乱码，一端是数据库存储乱码。

HTTP层面，Spring Boot 2.x默认已经是UTF-8，如果你还看到乱码，多半是前端页面的<meta charset>没有设置，或者表单提交时没有显式指定编码。数据库层面，最稳妥的方案是建库时统一utf8mb4，连接串加characterEncoding=utf8，并且表结构也是utf8mb4。注意：已经建好的表，单独修改某几个字段的字符集是不够的，容易出现“库里能存中文，展示出来是???”的情况。

5.4 并发挂号导致号源超卖

如果我自己测的时候用两个浏览器同时挂号，结果发现剩余号源变成负数了，那一定是扣减SQL没有加remain_count > 0这个条件。

修复方式上面已经写了：更新语句里带上AND remain_count > 0，并且让整个流程处于事务管理下。如果你用的是MyBatis-Plus，在service方法上加@Transactional(rollbackFor = Exception.class)即可。顺带提一句，@Transactional只对public方法生效，而且同类内部调用是不走代理的，自己写测试的时候注意别在这上面踩坑。

5.5 医生登录后看不到“待就诊患者”列表

这个一般不是权限问题，而是consultation状态没有被正确初始化。患者在预约挂号时，系统就应该自动生成一条状态为“待就诊”的consultation记录，医生端只查状态等于“待就诊”的数据。如果挂号时没有生成这条记录，医生端自然什么都看不到。排查时先查数据库，按患者id查询挂号记录，确认status字段值。

6. 论文与答辩准备中的几个关键心得

6.1 论文的章节安排怎么对应项目

论文的目录框架，你可以按这个路子来：绪论（背景、意义、国内外现状）→ 相关技术介绍（Spring Boot、MyBatis-Plus、JWT、Vue）→ 系统需求分析（功能性需求、非功能性需求、用例图）→ 系统设计（总体架构、功能模块设计、数据库设计）→ 系统实现（核心功能页面截图+关键代码+实现逻辑）→ 系统测试（测试用例+测试结果）→ 总结与展望。

注意，开题报告和任务书里的“目标、内容、方法”要和这个框架严格对应。很多同学前期开题写了一套，后来做系统的时候改了一堆功能，论文数据完全对不上，这会被老师一眼看出态度问题。我的建议是：开发前先确定论文大纲，功能上有改动就同步更新文档。

6.2 答辩高频问题与回答思路

我总结一下这类题目答辩时老师最喜欢问的几个问题，以及你应该回答的侧重点：

记住一个诀窍：答辩的时候，引导老师问你准备过的东西。比如你主动说“这里我用到了事务，因为要考虑库存扣减的一致性”，老师大概率会顺着问“事务怎么实现的”，而不是突然问一个冷门问题。

6.3 测试数据与演示脚本的准备心得

这个心得可能没人跟你提过，但极其重要：准备一份完整的演示脚本。

很多同学自己开发的时候数据库里什么数据都用，但到了演示现场，患者账号查出来的病历是空的，医生账号看到的排班是过期的，然后现场登录一个新建账号，发现没有排班数据可挂，演示效果大打折扣。

正确做法是：专门准备一个演示用的数据库备份，里面包含至少3个月的排班数据、10个以上的患者账号、每个患者至少2次就诊记录和处方记录，管理员账号、医生账号密码都改成好输入的简单密码。演示前把所有账号都登录一遍，确认每个按钮都能点通，再上场。细节决定印象分，这套东西花不了半小时，但能让你的答辩过程顺畅十倍。

最后再分享一个小经验：把项目的启动过程写成一个简单的说明文档，放在项目根目录的README里，包括数据库导入步骤、配置文件修改位置、默认账号、前端启动命令。放到GitHub或者打包发老师的时候，这个文档会让你的项目完整度直接高一个档次。不少老师会去看你项目的目录结构，一份整洁的README和一个乱糟糟的项目相比，好感度差距非常明显。