Spring Boot医疗信息管理系统毕业设计：架构、权限与源码实战解析

Spring Boot医疗信息管理系统，这个题目在毕业设计里出现频率真的高。如果你正在为选题发愁，或者已经拿到一套带“96589”编号的源码准备跑起来，这篇文章就是写给你看的。我会从一个做过类似项目、也带过学弟学妹的人的角度，把这套系统的核心设计、源码结构、业务模块、数据库设计、安全权限，以及你在答辩时要准备的东西，全部拆开讲一遍。

先说说这套系统到底在干嘛。它就是一个典型的医院门诊管理场景的数字化实现：患者建档、医生排班、在线挂号、门诊医生接诊、开处方、药品库存扣减、收费记录、住院床位管理，再加上系统背后的用户角色权限控制。简单说，就是把传统医院里从“患者进门”到“看完病拿药离开”这条完整链路，用Spring Boot + 前端模板 + MySQL这套组合做成一个能跑通全流程的Web系统。适合谁来参考？正在做Java方向毕业设计的学生，想快速了解医疗管理系统整体架构的开发者，以及需要一个CRUD项目练手的初级程序员。

1. 项目整体设计与思路拆解

1.1 为什么选择Spring Boot做医疗信息管理系统

毕业设计选技术栈，最重要的不是“最先进”，而是“最合适”。Spring Boot在这一点上有天然优势：它把Spring那套繁琐的XML配置几乎全部干掉，用注解和自动配置就能起一个可运行的Web服务。对于学生来说，这就意味着不用在环境配置上耗掉大量时间，可以把精力花在业务逻辑上。

再说医疗信息管理系统这个业务方向。它的核心是实体多、关系复杂、状态流转明确、权限分层严格。患者、医生、科室、药品、挂号单、处方单、收费记录，这些实体之间存在大量一对多、多对多的关联关系，非常适合用Spring Boot + Spring Data JPA或MyBatis来展示对象关系映射的能力。同时在权限上，系统天然包含管理员、医生、药房人员、收费员多种角色，用Spring Security做基于角色的访问控制也顺理成章。这两个点，正好是答辩时最能体现你“有设计思维”的地方。

结合这套“毕业设计源码96589”的命名规律来看，通常这类项目采用的就是经典三层架构：Controller接收请求、Service处理业务、Mapper或Repository访问数据库。前端一般用Thymeleaf服务端渲染，搭配Bootstrap或Layui做样式，不用前后端分离，省掉跨域、Token鉴权这些额外负担。这个选型思路对新手非常友好，因为每一层都能单独调试，出问题也好定位。

1.2 技术选型与依赖版本的内在逻辑

这套系统的技术栈，我建议你按以下组合来准备，这也是目前绝大多数医疗管理系统毕业设计源码的统一解法：

这里要特别提醒：项目拿到手第一件事，先看pom.xml里的Spring Boot版本，再看JDK版本是否匹配。很多源码跑不起来，80%的原因是JDK版本太高，比如本机装了JDK 17，但项目是给JDK 8编译的，启动直接报错。我建议直接装JDK 8，然后IDE里把Project Structure和Settings里的Java Compiler全部指向8，最稳妥。

还一个容易忽视的点是MyBatis Plus的版本和Spring Boot版本存在兼容关系。如果用的是MyBatis Plus 3.5.x，配Spring Boot 2.4以上的项目基本没问题；但如果项目里同时有旧版PageHelper之类的分页插件，就要小心冲突。总之，不要轻易升级源码里锁定的依赖版本，跑通比尝鲜重要。

1.3 业务模块拆解：从患者进门到离院的完整闭环

这套系统的功能模块，通常在导航菜单上已经能看得很清楚。我按业务流转顺序给你拆一下：

1. 挂号管理：患者信息查询/新增、就诊卡号生成、选择科室、选择医生、选择号源时间、挂号缴费确认。
2. 门诊医生站：查看已挂号候诊患者列表、开始接诊、录入诊断结果、开处方（药品明细、用量用法）、提交处方。
3. 药房管理：待发药处方列表、药品库存自动扣减、处方完成状态流转、退药处理（恢复库存）。
4. 收费管理：待收费处方列表、费用明细计算（药品总价）、收费确认、发票/收据打印信息生成。
5. 住院管理：入院登记、分配床位、住院费用记录、出院结算。这个模块选做，因为它牵扯的数据表更多。
6. 系统管理：用户管理（医生/药师/收费员账号维护）、角色权限分配、科室信息维护、药品字典维护。

每个模块之间不是孤立的，它们通过数据库里的状态字段相互驱动。比如挂号单状态是“待就诊”，医生工作站才能拉到人；处方状态是“待缴费”，收费处才能看到记录；缴费完成后状态变成“待发药”，药房才能开始配药。

这种状态流转设计，就是整个项目最大的亮点之一。你答辩的时候能把这个流转图画出来，说清楚每一个状态由谁触发、由谁推进，就能让评委看到你不是纯粹复制代码，而是真的理解了业务流程。

2. 核心业务实现与API设计解析

2.1 实体设计与表关系

一个医疗系统的核心，永远是数据模型。这套源码里的表设计，我见过的大同小异，核心表大概是这些：sys_user（用户表）、sys_role（角色表）、sys_user_role（用户角色关联表）、his_patient（患者表）、his_doctor（医生表）、his_department（科室表）、his_registration（挂号记录表）、his_prescription（处方主表）、his_prescription_item（处方明细表）、his_drug_info（药品表）、his_drug_stock（药品库存表）。

表之间的关系，举几个关键例子：

• sys_user和his_doctor通常通过doctor_id字段关联，医生也是登录用户，但带额外职称、科室、简介等属性。
• his_registration会同时记录patient_id、doctor_id、department_id，相当于把三张表串起来的事实表。
• his_prescription和his_prescription_item是典型的主从表设计，一个处方主记录保存患者、医生、诊断信息，明细表保存药品、数量、单价的明细，最后通过SUM聚合算总价。
• 药品库存会单独建表，因为药品信息是静态字典，库存是动态数据，分开才能支持入库、出库、盘点操作。

这个设计讲清楚后，你就能理解为什么说这个项目“麻雀虽小五脏俱全”。它不是随便堆了几个CRUD页面，而是按照真实医院信息系统的业务逻辑把数据模型做出来了。

补充一点：表里通常都有create_time、update_time、deleted这几个通用字段。deleted是逻辑删除标记，用0和1表示是否删除，目的就是防止误删数据，这个在答辩中也是可以讲的一个安全设计亮点。

2.2 核心接口与业务规则配置

接口设计上，这套系统遵循的是标准REST风格加统一返回结果。建议源码里有个Result类或R类，里面封装code、msg、data三个字段。前端每个Ajax请求回调里，都会先判断code是否为200，再做后续操作。

核心接口我给你列一些常见的：

这些接口看着简单，但每个背后都藏着业务规则。比如提交挂号这个接口，一定要做事务管理：插入挂号记录的同时，要原子性地更新号源余量；否则会出现“挂了号但医生端看不到对应号源”的脏数据。源码里如果用了@Transactional，你要能解释清楚它的作用：让多个数据库操作要么全部成功，要么全部回滚，保证数据一致性。

处方缴费接口也是同理。缴费确认后，不仅要把处方状态改了，还要生成一条收费流水记录。这里如果不做事务，就有可能出现费用已经收了、但状态没更新的情况，这在真实业务里是大事故。毕业设计虽然不要求生产级严谨，但你能在代码里看到并讲出这个点，说明你是有工程意识的。

2.3 前端页面与后端的数据交互逻辑

由于这套系统多数采用服务端渲染，所以与前后端分离式的开发在交互模式上有很大不同。以前端页面里最核心的“挂号管理”为例，大概的执行路径是这样：

浏览器访问页面，Controller直接返回视图名称，Thymeleaf解析模板，把科室列表、医生列表渲染成HTML。当用户选择科室时，页面发起一个Ajax请求（通常是post或get），调用后端的/doctor/listByDepartment接口，返回JSON数组，前端用jQuery把医生下拉框重新渲染。选择医生后，再查询该医生的排班和剩余号源。

后端处理的顺序一般是这样：Controller接收请求 -> 调用Service层方法 -> Service里先校验参数 -> 再调用Mapper执行SQL -> 结果封装成Result返回。

搞懂这条链路对你调试太重要了。很多人拿到源码后，在页面上点“挂号”按钮没反应，用浏览器F12打开Network看到请求报了500，第一反应是“代码坏了”，其实大部分情况是数据库字段对不上、参数传成了字符串、或者某个必传字段为空。

你要学会看前端的调用代码。通常在主页面最下面或者单独的JS文件里，能看到$.ajax({url: '/xxx', type: 'post', data: {...}})。找到请求路径后，再去Controller里搜索对应的RequestMapping，照着参数一个一个比对，问题就一目了然了。

3. 数据库设计与关键SQL解析

3.1 核心表结构与字段约束

数据库脚本在这类源码里一定以sql文件形式提供，导入MySQL即可。我建过类似的库，把几张大表的字段给你画出关键框架，你自己对照源码里的脚本看会清晰很多。

his_registration表（挂号记录表）的关键字段：reg_id（挂号单号，可以是自增主键或时间戳生成的业务单号）、patient_id、department_id、doctor_id、reg_time（挂号时间）、visit_date（就诊日期）、visit_time（午别或时间段）、reg_status（待就诊/已就诊/已退号）、fee_reg（挂号费用）、create_by。

his_prescription表（处方主表）的关键字段：prescription_id、registration_id（关联挂号单）、patient_id、doctor_id、diagnosis（诊断结果）、total_amount（处方总金额）、prescription_status（待缴费/已缴费/已发药/已退药）、create_time。

his_prescription_item表（处方明细表）：item_id、prescription_id、drug_name或drug_id、quantity（数量）、dosage（每次用量）、frequency（频次）、unit_price（单价，通常冗余保存，防止药品价格后续调整影响历史处方）。

这里要重点理解两个设计思路。第一，为什么要冗余保存药品单价？因为药品价格可能会变，一张处方生成后，不能因为药品基础资料调价，就影响已经开的处方总价。这是医疗系统里一个非常实用的设计细节，能在答辩中加分。第二，为什么要单独用状态字段而不是直接删除记录？

因为处方涉及患者权益和财务记录，任何操作都要能追溯，所以状态流转比物理删除更符合业务合规要求。

3.2 关键SQL与统计查询的写法

如果源码里用MyBatis，一定要看Mapper XML里的SQL脚本，因为里面有很多值得学习的多表联查写法。比如查询挂号列表时，会关联患者表拿患者姓名、关联医生表拿医生姓名、关联科室表拿科室名称。典型SQL大概是：

SELECT r.reg_id, p.patient_name, p.patient_phone, d.dept_name, doc.doctor_name, r.visit_date, r.reg_status FROM his_registration r LEFT JOIN his_patient p ON r.patient_id = p.patient_id LEFT JOIN his_department d ON r.department_id = d.dept_id LEFT JOIN his_doctor doc ON r.doctor_id = doc.doctor_id WHERE r.reg_status = #{status} ORDER BY r.reg_time DESC

这个查询的重点在于表别名和关联字段的明确。你在答辩时，如果被问到“页面查询的数据来源”，能把这段SQL的含义讲清楚，说明你真的看懂了。

还有一个值得关注的是统计类SQL，比如按科室统计挂号量、按月统计药品消耗量、统计医生接诊量。这类分组统计的SQL写法，通常是：

SELECT d.dept_name, COUNT(*) AS total_count FROM his_registration r LEFT JOIN his_department d ON r.department_id = d.dept_id WHERE r.visit_date BETWEEN #{startDate} AND #{endDate} GROUP BY r.department_id

这类统计功能往往是医疗系统区别于“纯图书管理”这类简单CRUD项目的核心差异点。如果你的源码里没有现成统计报表，可以考虑自己加一个，作为“系统的创新点”。

3.3 索引设计与数据一致性考虑

既然是毕业设计，可能不会刻意设计索引，但你要能说出哪些字段应该加索引，以及为什么。比如his_registration表里patient_id、doctor_id、visit_date是高频查询字段，如果不加索引，数据量一大，全表扫描就会很慢。再比如his_prescription表里的registration_id是关联查询的桥梁，也应该建索引。

MySQL给这个字段建索引的语法很简单：

ALTER TABLE his_registration ADD INDEX idx_patient_id (patient_id); ALTER TABLE his_registration ADD INDEX idx_visit_date (visit_date);

这部分在论文的“数据库设计”章节里可以重点展开，因为很多毕业设计论文里的数据库设计章节都是草草画几张表就结束了，你能放上索引设计、数据冗余策略、逻辑删除策略，会让论文更有技术深度。

4. 安全与权限：Spring Security的多角色实现

4.1 基于角色的访问控制模型

医疗信息管理系统最大的特点，就是用户类型多、权限边界必须清晰。一个标准的RBAC模型有三张基础表：用户表、角色表、用户角色关联表。这套源码里一般是用户有多少角色，再配合Spring Security的框架能力，在拦截器层面做接口验证。

Spring Security在Spring Boot项目里的核心逻辑，是先自定义一个UserDetailsService，重写loadUserByUsername方法，在方法里通过用户名从数据库查出用户信息，并加载对应的角色列表。然后自定义一个PasswordEncoder，最常用的是BCryptPasswordEncoder。登录校验通过后，后续每次请求都会带着用户权限信息。

权限配置的核心是那段SecurityConfig里的配置。举一个常见的过不过滤名单思路：

• 登录页面、登录请求、静态资源（js/css/images）放行，不需要登录就能访问。
• /patient/**、/registration/**这些患者相关接口，通常要求ROLE_DOCTOR或ROLE_ADMIN才能访问。
• /pharmacy/**、/prescription/dispense这些药房相关接口，要求ROLE_PHARMACIST。
• 系统管理下的/user/、/role/，严格要求ROLE_ADMIN。

配置方式就是重写WebSecurityConfigurerAdapter（Spring Boot 2.x）里的configure方法，用antMatchers("/path/**").hasRole("ADMIN")这种链条式写法。Spring Boot 3.x改成了SecurityFilterChain写法，如果你拿到的是2.x的源码，就不要升级到3.x，否则配置方式全都变了。

这部分内容在答辩时属于高频考点。你要能够解释：为什么不能让一个挂号收费人员访问药品库存管理的入口？因为库存数据直接影响采购和财务，权限应该最小化。然后还要能说出RBAC模型相对普通权限标记的优势：用户和角色解耦，角色和权限解耦，后续调整权限不用改代码。

4.2 密码加密与登录会话处理

这套系统的密码一定不能明文存储，用的一定是加密后的摘要值。基于BCrypt的加密特点是“同一个密码每次加密结果都不一样”，因为里面混合了随机盐值。校验的原理是每次登录时，把用户输入的密码和库里存的那串密文跑一次check方法。

毕业设计里，很多人会忽略一个点：系统初始化数据里的密码是怎么来的。其实源码里通常会在启动时或导入SQL时，用明文123456加密后的值给初始账号。你可以自己在代码里写一个测试方法，调用passwordEncoder.encode("123456")，把生成的密文替换到SQL里。答辩时如果老师问到“初始密码是什么”，你能回答“密码是123456，数据库里存的是BCrypt加密后的密文，管理员登录后可以自己改密码”，这个回答就滴水不漏了。

登录会话的处理，Spring Security底层用的是Session机制。用户在登录认证通过后，服务端Session里会存Authentication对象，后续请求从Session里获取当前登录人信息。源码里要在Controller里获取当前登录用户，通常这样写：

Authentication authentication = SecurityContextHolder.getContext().getAuthentication(); String username = authentication.getName();

再通过username去sys_user表查到完整的用户信息。这个操作在医院系统里很常见，比如医生登录后，进入医生工作站，系统需要自动识别“当前登录的医生是哪位”，然后只给这个医生拉到对应科室、对应人的挂号患者。

4.3 接口层面的防越权处理

虽然Spring Security从路径层面做了权限拦截，但真实业务场景里还有一层垂直越权问题。举个例子，一个普通医生登录后，如果把接口地址改成访问其他医生的患者列表，怎么办？

这套源码里处理得好的地方，是在Service层又做了一层数据级权限控制。比如查询患者列表时，如果断言当前用户角色是医生，那SQL里还会自动加上“doctor_id等于当前登录用户ID”的条件。这样即使用户恶意改了请求参数，也无法看到别人的数据。

这个点在论文里可以写成一节“数据级权限控制方案”，实操代码如下：

String username = SecurityContextHolder.getContext().getAuthentication().getName(); SysUser user = userService.getByUsername(username); if (user.getRoleId() == ROLE_DOCTOR) { queryWrapper.eq("doctor_id", user.getDoctorId()); }

逻辑很简单，但能体现出你考虑问题的完整性。医疗数据的隐私性比一般业务系统强很多，患者就诊记录属于敏感信息，数据级防越权是行业里绕不开的合规要求。

5. 实操过程：从源码导入到跑起来

5.1 环境准备与配置修改

我假设你手里已经拿到了那套“毕业设计源码96589”，不管是从什么渠道下载的，第一件要做的事情是建一个干净的文件夹，把压缩包解出来，然后用IDEA打开。打开之前，本机环境建议准备好：

• JDK 1.8（强制推荐）
• Maven 3.6.3以上
• MySQL 5.7或8.0，Navicat或Workbench任选
• IDEA 2022或以上版本（社区版也可以跑Spring Boot项目，但一些Spring插件功能的体验会差一些，专业版更省事）

打开项目后，IDEA会自动通过Maven拉取依赖。这一步经常会有个坑：settings.xml里的中央仓库地址如果默认为国外源，依赖会下载得很慢甚至卡死。

建议检查Maven安装目录下的conf/settings.xml，把你的镜像地址改成阿里云公共仓库，这样Spring Boot和MyBatis相关的依赖包几乎一分钟内就能全部拉完。

依赖全部加载成功后，把src/main/resources目录下的application.yml或application.properties打开，重点修改三处：数据库连接地址、数据库账号密码、MyBatis的mapper-locations路径。如果数据库密码里有特殊字符，例如123%^&，要记得在配置里加引号或者转义，否则Spring启动时解析数据源会直接报错。

之后打开Navicat新建数据库，名称、字符集、排序规则要按源码里SQL文件的开头来定，一般是utf8mb4。然后导入SQL文件。

注意了，导入SQL文件千万别直接拖拽整个文件到Navicat里面执行，容易因为文件过大出错。正确做法是：选中你的数据库 -> 点击右键 -> 运行SQL文件 -> 选择你项目里的xxx.sql文件 -> 等待执行完成。

5.2 常见报错与解决实录

这部分是实操价值的集中体现。我按自己调试类似项目的经验，把出现概率最高的几个报错和对应解法写出来。

启动报错: java.sql.SQLException: Access denied for user 'root'@'localhost' (using password: YES)。原因很直白，application.yml里的数据库密码写错了，或者本机MySQL里root账号密码不是这个。解决办法是改成你自己本机的数据库账号密码。注意MySQL 8.0默认加密规则是caching_sha2_password，某些老版本驱动不支持，要么把数据库用户加密规则改成mysql_native_password，要么在pom.xml里换成mysql-connector-java 8.0.x版本。

启动报错: Field xxxMapper in com.xxx.service.YyyService required a bean of type 'xxxMapper' that could not be found。这是MyBatis的Mapper扫描没生效。检查启动类上是否加了@MapperScan("com.xxx.mapper")这个注解，或者接口上有没有加@Mapper注解。两者至少占一个，否则Spring容器没法给你自动注入Mapper对象。

启动报错: Failed to configure a DataSource: 'url' attribute is not specified and no embedded datasource could be configured。这是Spring Boot里经常出现的误导性报错，实际原因可能是application.yml文件名不对，比如被改名成application.yaml但格式有误，或者文件放在src/main/resource目录外了。先检查资源目录结构，再仔细看配置文件里的url拼接有没有问题，比如url里的useSSL=true设置，时区参数serverTimezone=Asia/Shanghai是否遗漏。

启动报错: Consider defining a bean of type 'XxxService' in your configuration。这类问题多半是service实现类没有加@Service注解，或者接口和实现类路径不对，导致Spring扫描不到。IDEA里按Shift按两次，搜一下这个Service类，看它头上标注是不是只是普通的Java类。

页面访问时出现Whitelabel Error Page。这个是Spring Boot的兜底错误页，真实错误信息要去看控制台。最常见的，是接口路径映射写错了，或者某个实体类里有一个数据表不存在的字段。遇到这个错误，把IDEA控制台里最下面那一堆堆栈往上拉，找到Caused by那一行，85%的错误原因都在那。

5.3 账号与演示数据的准备

系统启动后，在浏览器输入http://localhost:8080（具体端口看application.yml里的server.port配置），如果源码没有自定义登录页，用的是Security自带的默认登录页，那你直接用初始化SQL里预留的账号密码登录即可。

这样一来，就能看到系统的完整面貌。通常默认的管理员账号密码都是admin/admin123或类似组合，医生账号可能是doctor/123456。

登录进去以后，第一件事不要急着乱点，按业务流程从头到尾测一遍：先建一个患者档案；再用患者去挂号（或者直接通过管理员后台新增一条挂号记录）；然后用医生账号登录工作站，把刚才挂号的病人接诊、开处方；再用收费员账号登录做缴费；最后用药房账号发药，顺便看一眼药品库存是不是扣掉了。完整走完一个闭环，你才能真正了解流程中哪些地方在设计上做了状态制约，也才能在答辩中做到心中有数。

6. 源码二次开发与功能扩展

6.1 加一个数据可视化看板的实操

如果你不满足于只运行现有功能，想在答辩时增加一点亮点，强烈建议在首页加一个后台数据统计面板。通过ECharts展示三类统计信息：各科室一周的挂号量趋势折线图、所有药品库存的剩余量占比图、近期医生接诊量的柱状图。

实现思路并不复杂：后端写一个DashboardController，提供三个请求接口，分别返回统计结果集；前端在index.html里引入ECharts的CDN文件，页面加载时用Ajax拉数据并渲染图表。

每一步都不难，但组合起来，你的系统就从普通CRUD项目提升到了“具备基础数据分析能力的管理系统”。

6.2 敏感操作日志留痕

医疗系统的合规性很强，还有一个很实用的扩展点就是操作日志功能。比如谁在什么时间给哪个患者挂了号、谁发过哪一个处方的药品，这些关键操作都应该有日志记录。

最简洁的方式是利用Spring的AOP切面，自定义一个@OperationLog注解，标注在需要记录的方法上，然后写一个切面类，在方法执行成功之后获取当前登录用户、方法参数里的业务对象信息，再异步写入日志表。

网上都有现成实现方式，对应代码在网上也能找到很多参考。真正要思考的，是你要让日志记什么：操作人员、操作类型、操作对象、操作详情、操作时间、操作结果。把这些字段定义好，你的系统就自带“审计追踪”能力了。这是很多商业级医疗系统才有的功能，放到毕业设计里绝对能压住场子。

7. 常见问题速查与使用技巧

还有一个很容易被忽略的技巧：修改代码后，IDEA里一定要先重新编译再启动。很多人改了Java代码，直接点Rerun但HotSwap失败，看到系统没变化就以为改错了，其实只是没有执行Build -> Rebuild Project。

另外一个很实用的调试技巧是开启MyBatis的SQL日志输出，在application.yml里添加：

mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

这样每次执行SQL，控制台都会把完整语句打印出来，对你排查数据库相关问题帮助极大。

8. 毕业设计与论文整理的建议

8.1 论文里的系统架构图怎么画

毕业论文里有一个章节必然需要展示系统架构图。很多人会用文字描述半天，不如画一张图来得清晰。架构层次还是那四层：视图层（Thymeleaf页面+Bootstrap）+ 控制层（Spring MVC Controller）+ 业务层（Service + Spring事务管理）+ 数据访问层（MyBatis Mapper接口 + MySQL）。

图中各层之间用箭头标注数据流向，特别要标注用户请求从浏览器进入控制器、调用业务层、执行SQL、返回JSON或页面视图的过程。

这里注意，不要用过于复杂的架构图。老师希望看到的是你理解分层架构，而不是让人觉得你把公司级的微服务架构堆到了一个课程设计项目上。

8.2 那些容易被问住的细节问题

根据我参与过的毕业设计评审经验，评委老师问得最多的问题集中在几个点上：事务怎么做的、权限怎么控制的、请求从发出到响应的完整链路是什么、你的索引设计是什么、为什么选择这个表结构、统计分析报表的SQL思路是什么。

你在准备答辩之前，就按这七个问题整理文档：事务用@Transactional加在哪里、传播行为是什么；权限继承自Spring Security的哪个过滤器链、白名单里有哪些路径、未登录访问受保护资源时跳转到哪个URL；患者从挂号到发药的完整请求链路上经过了哪些方法；数据库里有哪些索引、在哪些场景下生效；他如果问“你的系统能扛多少并发”，你可以如实说这只是学习项目，没有做压测，但你能讲清楚哪些表结构能够支撑乐观锁控制号源并发，这一点上你的认知是达到产业级别的。

最后，还有一个小但关键的观察：很多毕业生在展示系统时，都喜欢打开源码快速滚动找代码位置，但真正的评委最反感这个过程。建议你提前把几个核心模块的代码截图保存到Word里或者电脑桌面上，展示时直接放大图片，配合流程讲解。这样一来，从打开项目到关键环节展示，全程都在“讲”，而不是让人看着你“找”，这个过程的表现会自然很多。

这套Spring Boot医疗信息管理系统，拿来跑通只是第一步，真正的价值在于：你能把一个多角色协作的复杂业务场景，拆解成表结构、状态机、接口链路、权限模型这些可落地的工程结构，并且用清晰的语言向别人解释为什么这样设计。这就是毕业设计真正想要你具备的能力。最后再分享一个小技巧：下载源码之后，先全局搜索一下有没有遗留的TODO标记和测试方法，很多源码里藏着上一手使用者的调试痕迹，把这些清理干净，交给老师的一定是一个清爽整洁的工程。