1. 毕业设计选题：为什么选血库管理系统而不是“烂大街”的商城或图书管理
每年到了毕业设计开题季，总有一批同学在“商城系统”“图书管理系统”“博客系统”这几个老面孔之间反复横跳。倒不是说这些题目不能做，而是它们已经被做了太多遍，开题答辩时老师看一眼题目就失去了一半兴趣。相比之下，医院血库管理系统属于医疗信息化方向的细分领域，业务逻辑更复杂、更有真实的应用场景，同时又能完整覆盖Spring Boot的核心知识体系，是一个性价比非常高的选题。
这个系统说白了就是给医院输血科（或血库）用的管理工具，核心任务是管好血液的入库、出库、库存预警、用血申请和审批、血液有效期追踪。血液不是普通商品，它有严格的有效期（红细胞悬液35天，血小板只有5天）、有温度要求、有血型匹配和交叉配血规则，这种“不可替代、过期作废”的特性，让系统的业务设计比普通进销存软件复杂得多，也正因为如此，它比图书管理这种纯CRUD的题目更有内容可以写。
我自己的一个感觉是，这类医疗业务系统在答辩时的优势在于痛点明显。评委老师不太会问“你这个系统有什么意义”这种悬空问题，因为血液管理的安全性和可追溯性是实打实的刚需。同时，你还可以把库存预警、近效期提醒、统计报表这些功能做成论文里的亮点，工作量也容易量化为“实现了X个功能模块、设计了X张数据表”，整个论文逻辑会很顺。
适合哪些人选这个题目呢？三类人比较匹配：第一类是对Spring Boot已经有一定基础，想找一个兼顾业务深度和技术广度的题目；第二类是时间相对充裕，愿意花心思研究真实业务流程的；第三类是希望论文里能用上RabbitMQ、Redis、定时任务、JWT等“加分项”技术的。如果你纯粹想快速水一个CRUD项目，血库管理系统反而不太适合——它的业务规则比图书管理多得多，但也正是这些规则，才让项目在答辩时有话可说。
2. 系统整体架构设计：从业务模型到技术选型的完整思路
2.1 先理清血库到底管什么：业务流程是地基
写代码之前，先把业务捋清楚，这一点比什么都重要。我见过很多同学一上来就建表建entity，结果做到一半发现很多字段没想明白，回头返工，特别浪费时间。
医院血库的核心业务流程大致是这样一条线：
采血/入库：血站或者本院献血屋把血液送过来，血库工作人员核对血液成分、血型、血量、采血日期、失效日期，然后入库。入库后的血液进入“待检”或者“合格”状态。
科室申请：临床科室（比如外科、血液科）的医生在系统里发起用血申请，填上患者信息、诊断、需要用的血液成分、单位数、紧急程度。
血库审核：血库工作人员审核申请是否合理（比如有没有不必要的输血），审核通过后进行交叉配血或发血准备。
出库记录：血液出库时，记录发放给了哪个科室、哪个患者、操作人是谁、时间是什么，实现全程可追溯。
库存盘点与预警：血液库存有下限阈值，低于阈值要提示补货；同时有近效期预警，快要过期的血液要优先发放或者做退血处理。
这就是这个系统最核心的流程。对应的，你的功能模块划分就很明确了：系统管理（用户、角色、菜单）、血液入库管理、库存管理、出库管理、用血申请管理、统计报表、预警通知等。
我在设计阶段强烈建议用Xmind或者手绘把流程图先画出来，把每个角色的“动作”和“状态”标清楚。比如血液从入库到出库，中间状态可能是：未检验、检验中、已入库（可用）、已出库、已报废/退回。把这些状态定义清楚后，数据库的表结构和后端接口其实已经出来一半了。
2.2 技术栈选型：为什么是Spring Boot 3 + MyBatis-Plus
技术选型遵循一个原则：用最主流、最容易答上来的组合，但不要盲目追新。我推荐的是Spring Boot 3.x + MyBatis-Plus + MySQL 8.0，前端可以用Vue 2或Vue 3，也可以用JSP/Layui走全后端路线。很多同学纠结要不要上微服务，我的建议是不要，单机单体架构足以支撑毕业设计，分布式架构反而会给自己挖坑。
Spring Boot 3.x要注意一点，它基于JDK 17，所以本地环境一定要把JDK版本配好。另外Spring Boot 3对javax包改为了jakarta包，如果参考的代码还是Spring Boot 2的老写法，导入的包名会报错。这也是很多同学从网上找参考项目后遇到的头一个问题。
MyBatis-Plus的核心价值是减少重复的CRUD代码。单表操作基本不用手写SQL，内置的分页插件、条件构造器都非常好用。它的逻辑删除、自动填充功能（比如createTime自动填充）是演示时的加分细节，写进论文也能体现设计感。
Redis在这个系统里有两个典型用途：一是缓存用户登录token，实现带过期时间的会话管理；二是缓存库存数据和预警数据，避免每次查询都打MySQL。毕业设计能用到Redis并说出“为什么这里要用缓存”的理由，在答辩时是很加分的。
定时任务用Spring自带的@Scheduled即可。主要负责两件事：每天凌晨扫描库存，低于阈值自动生成补货预警记录；扫描全部血液记录，标记近效期到期的条目并发送站内通知。你不需要引入Quartz，Spring Boot的@Scheduled已经足够，代码量小又能满足要求。
2.3 数据库设计：这8张核心表决定了项目成败
数据库设计是血库管理系统里最需要花功夫的部分，因为业务规则多，表之间的关联关系复杂。我以下面这组表结构为例，你可以直接用：
员工信息表（employee）：存放员工基本信息，包括科室信息。它和用户表可以合也可以分，建议分开，因为员工是静态的档案信息，用户是登录账号信息，两者分开更灵活。
用户表（sys_user）：负责登录认证，字段包括用户名、加密密码（MD5加盐或BCrypt）、状态、关联员工ID。这张表要做权限隔离，不同角色登录后看到的是不同的菜单和操作权限。
角色表（sys_role）和权限表（sys_menu）：这是后端开发必做的RBAC权限模型。血库管理系统的角色大体上有三类：系统管理员、血库工作人员、临床科室医生。基础权限模型一套搞定，后续扩展用户也只需要往关系表里插记录。
血液入库表（blood_in）：记录入库批次信息，包括血液成分、血型、血量、采血单位、采血日期、失效日期、入库操作人等。这里有个关键点，入库时往往会有多袋血液，所以通常还会加一张血液库存批次明细表（blood_stock），每一袋血生成一条记录，状态是“可用/已出库/已报废”。
用血申请表（blood_apply）：临床医生填写的申请记录，包括患者信息、诊断、申请血液成分及数量、申请科室、申请状态。状态环节设计为待审核、审核通过、已发血、已取消。
出库记录表（blood_out）：出库时生成记录，关联库存批次明细记录表、用血申请表，记录发血人、领血人、领血科室、出库时间。这张表是追溯的线索，一定要关联完整。
登录日志表（sys_log）：记录每次登录和关键操作，这个在很多项目里是可选模块，但在医疗系统里是必要的，“操作留痕”是医疗业务的基本要求，写在论文里也是个安全性设计的好卖点。
这些表的字段在设计时需要特别注意一点：血型、血液成分这些能枚举的字段，尽量定义规范，不要用名称字符串直接到处填。血型建议用A、B、AB、O区分，还要考虑Rh阴阳性，这个“Rh类型”字段不要漏掉，现实中输血科人员都会问你Rh是阳性还是阴性。
3. 核心功能模块的落地实现：从登录鉴权到库存预警的完整代码逻辑
3.1 登录认证与权限分配：医疗系统必须控制“谁能发血”
血库管理系统不是公开网站，每个操作都关系到患者安全，所以登录认证和权限控制是第一个要做扎实的模块。
登录加密我建议直接用Spring Security或者Sa-Token来做。用Spring Security的话，BCryptPasswordEncoder加密密码是标配，存储密码时做加密，登录验证时用matches方法判断。毕业设计如果用JWT方案，可以自己实现一套简单的JWT生成和校验逻辑：用户登录成功后，后端生成一个包含用户ID、角色信息的token返回给前端，前端每次请求把token放在请求头里，后端通过拦截器（HandlerInterceptor）校验token的合法性和有效期。
这里有个实操中的坑：JWT拦截器只拦截需要登录的接口，但放行登录接口本身，所以要在WebMvcConfigurer里配置排除路径。如果一个不小心把登录接口也拦了，前端请求登录接口时会直接401，而且这种问题很难定位，表现是“登录功能突然不生效了”。
权限分配层面，不需要做太细的按钮级控制，做到接口级别就够了。比如血液出库的接口标注@PreAuthorize("hasRole('ADMIN')")，用血申请接口允许DOCTOR角色调用，血库工作人员可以审批。答辩时如果被问到“不同角色怎么区分”，把这个注解体系讲清楚，基本就能过关。
3.2 血液入库：批号生成与状态初始化是重点
血液入库的难点不在于插入一条记录，而在于批量操作和状态流转。现实中血站往往一次送过来几十袋血，不会一袋一袋录入。所以在入库的Service层，入参应该是“批次ID + 血液明细列表”，前端提交一个批次列表，后端遍历插入，并为每条明细设置状态为“0-可用”。
批次号的生成有一个小细节：可采用“入库日期+随机数”的方式，比如20250611001这样的格式，一方面方便查看是哪天入库的，另一方面保证不同批次不会重号。不要用数据库自增ID直接当批次号外部展示，因为自增ID会暴露业务量，而且跨表关联时不够直观。
入库之后还有一环很容易被忽略：血液“待质检”的状态。现实中血库收到血后不是立刻就能发给患者，而是要做血型复核、检测报告审核，通过后才算可用。所以入库时状态可以有两种选择：一种直接标记为“已入库-可用”，适合毕业设计简化流程；另一种设置“待检验”状态，血库人员确认检验结果后手动点击“转为可用”。我建议你做第二种，因为它让你的系统在业务上更说得通，答辩时也能解释“这里为什么多一个状态”。
3.3 出库与发血：库存扣减不能直接用“先查再减”
发血是最考验数据一致性的环节。如果并发情况下两个护士同时为两个患者申请同一袋血，很容易出现“同一个ABO型Rh阴性的A型红细胞被发给了两个患者”的尴尬情况。
注意，这里不是说完全不可以用查询再更新的方式，而是提醒你不要在单线程写代码时忽略了并发场景。更合理的做法是使用数据库乐观锁：在blood_stock表加一个version字段，每次更新时校验version是否一致，不一致则回滚。SQL核心就是update blood_stock set status = 1, version = version + 1 where id = ? and version = ? and status = 0。只有影响行数为1的时候，才代表扣减成功，否则提示“库存已变化，请刷新后重试”。
如果你想做得更严谨，还可以用MyBatis-Plus的@Version注解配合乐观锁插件实现，代码层面会更加优雅。答辩时把这个并发处理讲清楚，评委一般会认为你有工程意识，而不是只会写单表CRUD。
3.4 库存预警与近效期提示：用对定时任务和SQL条件
库存预警分两个维度。一个是数量下限：当某种血型某种成分的可用库存量低于设定的阈值（比如A型红细胞悬液小于5袋），系统自动生成预警消息。实现方式不用太过花哨，每天凌晨定时任务扫一遍blood_stock表，按血型、成分分组统计，低于阈值就把记录插入预警表，同时给出状态标识。
另一个是近效期预警：血液的失效日期是固定的，比如血小板只有5天保存期。SQL查询条件用失效日期减去当前日期，在3天内和7天内是两个提醒级别。近效期预警的现实意义在于，血液是稀缺资源，不能等到过期了才去报废，之前就要调度优先发放，“近效期先出”本身也是血库的操作规范。
这块如果用Redis来做实时缓存统计当然可以，但毕业设计阶段我认为直接在MySQL里统计足够了——数据量就那么点，杀鸡不用牛刀。但你可以做一个合并点：每天统计完把预警结果写入Redis并设置过期时间，用于前端页面的快速展示，这样Redis的引入也自然合理。
3.5 统计报表：一个能让你在论文中多出两三页“干货”的功能
报表模块被很多人做成摆设，但我建议认真做一下。血库管理系统至少要有这几张报表：每月血液入库/出库总量对比表、各血型库存余量分布表、用血申请科室分布表、血液报废原因统计表。
报表的展示方式可以采用ECharts柱状图、饼图、折线图配合后端返回的JSON数据。注意一点：后端接口的返回值尽量按图表维度分好组，前端直接取用即可。比如按月份统计入库量，SQL是select DATE_FORMAT(create_time, '%Y-%m') as month, count(*) as total from blood_in group by month，后端返回就是一个月份对应一个总数的数组。这是报表模块的核心套路。
4. 完整展示一个前端页面的请求链路：从用户输入到数据库落库
为了让你对整个实现链路有体感，我用“新增血液入库”这个场景来串一遍，从前端页面点到按钮到数据库落库，每一步对应什么代码和操作，都说得清清楚楚。
第一步：前端填表提交。前端页面是一张血液入库登记单，包含批次号、采血单位、入库日期、若干袋血液明细（血型、成分、血量、失效日期）。用户点击“提交”按钮，前端用axios向后端/app/bloodIn/save接口发送POST请求，请求体是JSON。
第二步：后端Controller接收参数。控制器用@RequestBody接收前端传来的DTO，DTO是一个符合JavaBean结构的对象。这里建议直接在Controller层做参数校验（Bean Validation），比如失效日期不能早于当天，血量必须大于0，校验失败直接返回提示信息。
第三步：Service层处理业务。处理逻辑分几步循环：生成批次ID、遍历血液明细列表、逐条绑定status为可用状态并插入blood_stock表。这一步用到了事务注解@Transactional，意思是其中任意一条失败则全部回滚——入库这种操作如果出现一半成功一半失败，后果很严重，这也是事务注解的典型使用场景。
第四步：Mapper层写库。MyBatis-Plus的saveBatch方法可以批量插入，底层会拼接一条多值INSERT语句，执行效率比单条循环插入高不少。插入前自动填充字段create_time、create_by。
第五步：返回结果给前端。统一结果封装类R.ok()、R.error()搞定，前端拿到code为200时刷新表格并提示成功，code非200时弹出后台返回的错误消息。
这个链路走一遍之后，基本上你对“一个接口从被调用到落库”的整个流程就很清楚了。答辩时老师问你“从这个页面到数据库发生了什么”，你就按这个顺序讲，条理清楚，不会有东拉西扯的感觉。
5. 常见问题与排查技巧实录：这些坑我帮你踩过了
5.1 Spring Boot版本和依赖冲突问题
Spring Boot 3.x下如果直接引用了MyBatis-Plus的3.4.x版本，启动时大概率会报“Invalid value type for attribute 'factoryBeanObjectType'”之类的错误。原因是MyBatis-Plus老版本没有适配Spring Boot 3的类加载逻辑。解决办法就是使用MyBatis-Plus官方提供的Spring Boot 3对应starter，或者使用最新版3.5.x以上。版本不匹配的问题在毕业设计里出现频率非常高，记住“先确定Spring Boot版本，再去找配套的中间件版本”这个原则，能省去大量排查时间。
5.2 日期时间格式化问题
数据库的datetime类型和后端LocalDateTime互转时很容易出现前端显示为“2025-06-11T10:30:00”这种带T的格式。解决方案是在application.yml中配置spring.jackson.date-format和time-zone，统一格式为yyyy-MM-dd HH:mm:ss。注意，纯前端处理的“带T字符串”也经常被坑，建议在后端统一序列化格式，不要期望前端兼容所有格式。
5.3 前端跨域问题
Spring Boot后端如果单独部署在8080端口，前端用Vue开发服务器跑在8081，就会出现跨域。解决办法一个是后端写CorsConfig配置类，一种是前端配置代理proxy。我更推荐前端配置代理，这样生产环境部署时不容易暴露接口地址，而且开发环境下调试提示也更干净。
5.4 为什么我的定时任务不执行
检查三点：定时任务类是否加了@Component注解并交给Spring扫描；方法是否加了@Scheduled(cron = "表达式")；启动类是否遗漏了@EnableScheduling注解。其中启动类的注解是最容易被忽略的，网上很多教程代码片段不会特意提醒，但少了它就是不行。
5.5 登录状态突然丢失以及token过期时间设置
很多人JWT写着写着就发现“刷新页面后登录状态没了”，大概率是前端没有把token存到localStorage，或者页面刷新后没有在路由守卫中重新认证。另外一个容易被忽略的点是：把JWT过期时间设置为2小时，你辛苦调了两小时代码后再测试就“自然过期”了，注意别把它当成Bug来排查。
6. 部署发布与开发效率的实用建议
6.1 将项目打包部署到服务器
Maven打包用package命令生成jar包，部署时使用java -jar参数启动。没有服务器验流程又不想本机装MySQL的人，可以用Docker Compose一次性拉起MySQL、Redis和应用的容器。在本地用Docker Desktop跑一套环境，开发调试效率会高很多。
6.2 Windows下用宝塔面板做部署
很多同学的服务器是云服务，宝塔面板对新手非常友好。在宝塔中创建Java项目，上传jar包，配置好端口和数据库即可。有一个细节是：Spring Boot默认端口8080，如果服务器上还有其他服务占用，要在application.yml里改成自定义端口，比如端口改为8090，然后再去宝塔安全组和云服务商安全组里放行这个端口，不然外部永远访问不到。
6.3 提高开发效率的小技巧
Lombok的@Data注解能省去手写Getter/Setter，配合构造器也非常方便。代码热更新用Spring Boot DevTools，改完代码自动重启，能提升不少效率，但注意生产环境要去掉这个依赖。调试接口时用Apifox或Postman，可以直接导入接口文档，大大减少自测时间。
7. 写在最后：个人实操经验和答辩准备心得
血库管理系统这个题目本身不难做，难的是把业务逻辑做“真实”。期末答辩时，真正让评委眼睛一亮的地方，往往不是代码量，而是你对业务细节的理解和设计上的小心思。比如“为什么入库血液有两种状态”“近效期血液为什么优先发”“同一个患者的两次输血申请为什么自动弹出历史记录提醒”——这些才是论文和项目里最有价值的东西。
根据我的经验，做这个项目时最值得花时间画的两张图，第一是系统总体业务流程图，第二是数据库ER图。把这两张图画明白，你的论文逻辑基本就顺了。代码是在图的基础上“翻译”出来的。
最后再分享一个答辩时的小技巧：准备一段3分钟的Demo路径。从医生PC端登录提交用血申请开始，切到血库人员账号审核，再到入库血液和库存预警展示，最后是统计报表看板，尽可能按照真实业务顺序去演示，千万不要演示功能时东点一个西点一个，毫无逻辑。让老师跟着你的节奏走，等他问题提得越具体，说明你的设计越有说服力。祝答辩顺利，做一个能真正落地的血库管理系统，而不只是交一份作业。
