1. 项目概述与技术选型做毕业设计选这个“医院血库管理系统”的人我猜十有八九是被血库管理的业务流程吸引住了——它不是纯CRUD还有库存预警、效期管理、出入库追踪这些真实业务逻辑做完讲答辩的时候能聊的东西比别人多一大截。我自己改写过类似系统今天这篇就把我当时的设计思路、踩坑记录、核心代码实现完整拆给你照着改就能交差不多的版本。先说结论这个毕设用SpringBoot做后端是完全正确的选择。原因有三。第一SpringBoot的自动化配置能让你在三天内把项目骨架跑起来不需要像传统SpringMVC那样纠结一堆XML配置。你用spring-boot-starter-web导进来main方法一启动内嵌Tomcat就直接挂好端口了本地调试、答辩演示都非常顺手。第二血库管理系统这种业务本质上是典型的库存管理状态流转场景SpringBoot配合MyBatis-Plus来做单表CRUD和分页查询几乎不用写复杂SQL就能把所有模块撑起来开发量集中在业务逻辑而不是技术门槛。第三毕设答辩的时候老师大概率会问“为什么选这个框架”你直接回答SpringBoot的自动配置、内嵌容器、生态成熟度以及互联网上大量的中文参考资料出了问题好查这就是最务实的理由。再从业务角度说血库管理系统的核心实体其实就几个血液制品批次入库、库存记录、患者用血申请、出库记录、预警规则。有些同学可能担心“系统太简单会不会被刷”实际上你只要把库存预扣、效期预警、批次追溯这三个环节做扎实整个项目的工作量就完全撑得起一篇毕业设计论文。技术栈我推荐这样组合这是我测试过最稳的搭配组件选型说明后端框架SpringBoot 2.7.xJDK8可跑稳定中文资料最多ORMMyBatis-Plus 3.5.x单表CRUD免写SQL代码量骤减数据库MySQL 5.7或8.0免费、通用老师机器上也好装前端Thymeleaf Bootstrap毕业设计场景够用不用前后端分离权限Spring Security 或拦截器简单角色区分管理员、护士、医生报表ECharts库存趋势和用血分类统计版本这块要提醒一句SpringBoot别用3.0以上的因为JDK版本和部分yml配置写法变了你答辩的机器上可能装的是JDK8出问题自己还得临时补没必要自找麻烦。2.7.x配合JDK8是最省心的组合。回到拓扑上整个系统就是标准的浏览器-后端-MySQL三层不需要引入Redis和MQ来画蛇添足。有些同学会为了“看起来高级”强加一套Redis缓存我劝你不要——那是给自己挖坑答辩前一周如果紧张状态出bug排查起来很痛苦。毕设的首要目标是能跑、能讲、能答。2. 数据库设计与核心业务流程2.1 数据表拆分思路血库管理系统的表结构我建议拆成5张核心业务表加上3张辅助表这个粒度正好匹配毕设的体量也不会显得单薄blood_product血液制品基础信息表。包括血型A/B/AB/O、RH因子、成分全血、红细胞、血浆、血小板、单位规格200ml/400ml等、生产单位、批号。blood_stock_batch入库批次表。每次从血站或中心血库接收血液时生成一条记录包含入库时间、效期截止时间、入库数量、当前可用数量、状态在库/冻结/已用完/过期。blood_receive_record入院接收记录表。病人入院登记时需要绑定血型信息方便后续开申请时自动关联匹配。blood_apply_record用血申请单。包括申请科室、申请医生、病人信息、申请血量、申请状态待审核/审核通过/已出库/已取消。这是整个流程的中枢表出库操作必须依附于申请单。blood_out_record出库记录表。记录出库的申请单ID、出库批次ID、出库量、出库人、领血人、出库时间。sys_user系统用户表。区分管理员、医护人员、库存管理员等角色。blood_request_log血站补货申请记录。库存低于阈值时发起补货流程。operation_log操作日志表。这个表很重要虽然看着像辅助表但答辩的时候可以专门拿出来强调——所有出入库和审核操作都留有痕迹。表关系的核心逻辑是批次表决定“有多少血可用”申请单决定“谁要用血”出库单把批次的可用量扣减掉。这三个表之间形成了完整的闭环。有一点很多第一次做的人容易漏血液不是普通商品同一血型下不同成分要分开管理。比如一个批次是“A型Rh阳性红细胞”另一个批次是“A型Rh阳性血浆”如果混在同一个blood_type字段里去查询后面做效期预警和维护盘点时会乱成一团。所以设计时一定要明确“一个批次就是一类血液制品”不要试图把多个成分合并到一条记录里。2.2 状态流转设计血库里的每一条入库批次它的状态应该是这样流转的待验收 - 在库 - 冻结 - 出库完毕 |- 过期报废待验收血液送到医院之后先登记但还没正式核验完成。实际上实操中可以省掉直接入库但保留这个状态能让流程更完整。在库可通过效期预警查询处于可出库状态。冻结当批次被某个申请单锁定预分配时暂时不可被其他申请单匹配。过期报废超过效期截止时间未使用的血液自动标记为报废不能参与正常出库。对应的应用逻辑就是申请单审核通过之后先在可用批次里做一次“预占”——把申请血量从批次可用数中扣减逻辑锁定不做物理删除生成一出库单关联等到实际发血时完成物理扣减。这样做的好处是同一批血不会被两个申请单同时抢走。这套状态流转涉及到的字段调整我给你列一个简表场景操作涉及字段变化新批次入库blood_stock_batchinsert新增记录available_num total_num申请单通过blood_apply_recordupdate状态改为已通过金额不涉及只需记录申请量预占批次blood_stock_batchupdatefrozen_num 申请量available_num 不变或冻结量单独计实际出库blood_out_recordinsertavailable_num 扣减frozen_num 释放并减少 total_num过期预警定时任务扫描状态改为过期报废可用数量清零预占这块我多说一句我见过有同学直接改available_num不做冻结另计导致申请单取消时还得“阴差阳错地加回来”逻辑搞得非常绕极易出错。正确做法是把“冻结数量”和“可用数量”分开看待真正物理在库但被锁定的血不计入可分配库存。这样的好处是你出库的时候不用反复核对申请数据出库多少就扣多少。2.3 效期预警与库存阈值规则血液管理跟普通库存最大的区别就在于效期敏感。国家规定红细胞和全血效期一般不超过21~35天血小板更是只有5天左右。系统里必须在批次记录保存时就开始计算剩余天数并设置两档预警一级预警剩余效期不足3天。列表标红提示优先发放。二级预警剩余效期不足7天。提示尽快协调用血。库存低阈值某血型成分库存少于10单位具体数可按医院级别调整触发补货申请。这个逻辑我建议用Scheduled定时任务挂在后端每天早上9点和晚上6点各扫一遍全表更新批次的预警状态。为了不让预警把页面刷爆预警只记录最近一次的变更结果存放在批次记录的状态字段里。CPU开销非常小别担心扫描性能问题——血库系统的批次表每天新增量很少全表扫描完全可行。如果非要用Redis缓存那类东西来做反而把一个简单需求弄复杂了。2.4 血型匹配关系另一个关键设计是用血申请必须关联入院登记时的血型信息。实际业务里病人输血前医生必须核对血型这个核对逻辑直接放在系统里省事很多。建议的策略是病人信息表或病历表里保存血型。申请单创建时自动带出血型和RH因子显示给医生核对。出库时系统强制校验申请单血型与出库批次血型一致否则阻断操作并提示“血型不符禁止出库”。哪怕只是一个小小的校验答辩时老师问“有没有做容错和完整性校验”你就可以理直气壮地拿这个例子出来讲。3. 核心代码实现与关键细节3.1 项目初始化与依赖配置我用的SpringBoot 2.7.5创建项目时只需要选Web、MySQL驱动、Lombok这三个依赖剩下的MyBatis-Plus和Thymeleaf手动加到pom.xml里dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-thymeleaf/artifactId /dependencyapplication.yml里面核心配置如下注意mybatis-plus的逻辑删除和分页插件都要显式声明server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/blood_manage?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 thymeleaf: cache: false mybatis-plus: mapper-locations: classpath*:mapper/*.xml type-aliases-package: com.example.blood.entity global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0有一点必须踩过坑才记得住MySQL 8.0以上必须加serverTimezoneAsia/Shanghai不加的话日期字段在JDBC驱动里会报告时区异常。如果是5.7的库驱动类名还是com.mysql.jdbc.Driver别直接用8.0的写法。这两个小坑耽误过我校验时区的半天时间。3.2 实体类设计样例以批次实体为例字段设计要注意“逻辑删除与操作日志分开处理”Data TableName(blood_stock_batch) public class BloodStockBatch { TableId(type IdType.AUTO) private Long id; /** 批次号医院内部唯一 */ private String batchNo; /** 血型A、B、AB、O */ private String bloodType; /** RH阳性或阴性 */ private String rhFactor; /** 血液成分全血、红细胞、血浆、血小板 */ private String component; /** 入库时间 */ private LocalDateTime receiveTime; /** 生产日期 */ private LocalDate produceDate; /** 效期截止 */ private LocalDate expireDate; /** 总入库量单位U/200ml */ private Integer totalNum; /** 可用数量 */ private Integer availableNum; /** 冻结数量 */ private Integer frozenNum; /** 状态1在库 2冻结 3用完 4过期 */ private Integer status; /** 预警状态0正常 1二级预警 2一级预警 */ private Integer warnStatus; TableLogic private Integer deleted; }这里我特意把totalNum和availableNum都存成普通的Integer不搞触发器所有数量统计都在Service层事务里完成。毕设项目不需要用数据库触发器因为那样会让排查数据问题时多一层隐藏逻辑反而更难调试。另外注意TableField(fill FieldFill.INSERT)这类自动填充如果项目里没有时间字段审计的需求可以不用。但操作日志表的记录时间我强烈建议直接用数据库的NOW()或者后端的LocalDateTime.now()不要用JS在页面传——始终以后端为准减少被篡改的可能。3.3 入库操作的事务处理入库核心逻辑是两张表联动插入批次记录同时写入操作日志。如果日志表插入失败批次表也要回滚保持数据完整。Service RequiredArgsConstructor public class BloodStockServiceImpl implements BloodStockService { private final BloodStockBatchMapper batchMapper; private final OperationLogMapper operationLogMapper; Transactional(rollbackFor Exception.class) public void receiveBlood(BloodReceiveRequest req) { // 1. 构建批次记录 BloodStockBatch batch new BloodStockBatch(); batch.setBatchNo(generateBatchNo(req)); batch.setBloodType(req.getBloodType()); batch.setRhFactor(req.getRhFactor()); batch.setComponent(req.getComponent()); batch.setReceiveTime(LocalDateTime.now()); batch.setProduceDate(req.getProduceDate()); batch.setExpireDate(req.getExpireDate()); batch.setTotalNum(req.getTotalNum()); batch.setAvailableNum(req.getTotalNum()); batch.setFrozenNum(0); batch.setStatus(1); batch.setWarnStatus(0); batchMapper.insert(batch); // 2. 写日志 OperationLog log new OperationLog(); log.setOperator(SecurityUtils.getUsername()); log.setOperationType(入库); log.setTargetType(批次); log.setTargetId(batch.getId()); log.setContent(接收血制品 req.getComponent() req.getBloodType() Rh req.getRhFactor() 数量 req.getTotalNum()); log.setCreateTime(LocalDateTime.now()); operationLogMapper.insert(log); } }生成批次号的方法是医院常见的规则receiveYear reciveMonth 当天序号类似BL20250512001。如果最后四位操作不写了直接用yyyyMMddHHmmss三位随机数也可以反正必做唯一键检查。这里有个容易被同学们忽略的点Transactional默认只回滚RuntimeException。如果你在方法里捕获了Exception又往外抛了个一般异常事务可能不生效导致日志插进去了、批次却没插成数据对不上。所以注解上务必用Transactional(rollbackFor Exception.class)而不是默认的空注解。3.4 出库操作与预扣库存出库是整个系统里最容易出并发bug的地方。我建议在申请审核通过时“预占”批次库存而不是等到出库时才扣减。预占的SQL可以用UPDATE ... WHERE available_num ?靠受影响行数判断是否抢占成功Transactional(rollbackFor Exception.class) public boolean freezeBatchStock(Long batchId, Integer qty) { int rows batchMapper.update(null, new LambdaUpdateWrapperBloodStockBatch() .eq(BloodStockBatch::getId, batchId) .ge(BloodStockBatch::getAvailableNum, qty) .setSql(frozen_num frozen_num qty) .setSql(available_num available_num - qty)); return rows 0; }这个写法的关键在于把“判断数量足够”和“扣减数量”合并成一条UPDATE数据库行级锁会保证同一时间只有一个申请能扣固有库存不会出现两个申请各扣了100、实际库存只有80的情况。这是秒杀系统里减库存的经典写法放到血库管理里同样有效。出库记录那边还要同步更新申请单状态同时把操作日志记上。这里同样要注意一致性出库成功后如果日志写入失败还得靠事务回滚保证两个表都干干净净。3.5 过期扫描任务用Spring的Scheduled实现效期扫描比较轻量。先给启动类加上EnableScheduling再写一个定时任务类Component Slf4j public class ExpireScanTask { Resource private BloodStockBatchMapper batchMapper; /** 每天8点、18点各执行一次 */ Scheduled(cron 0 0 8,18 * * ?) public void expireScan() { // 查询所有在库批次 ListBloodStockBatch batches batchMapper.selectList( new LambdaQueryWrapperBloodStockBatch() .eq(BloodStockBatch::getStatus, 1)); for (BloodStockBatch batch : batches) { long days ChronoUnit.DAYS.between(LocalDate.now(), batch.getExpireDate()); // 一级预警3天内 if (days 0 days 3) { batch.setWarnStatus(2); log.warn(批次 {} 剩余效期仅 {} 天, batch.getBatchNo(), days); } // 二级预警7天内 else if (days 7) { batch.setWarnStatus(1); } else { batch.setWarnStatus(0); } // 过期自动报废 if (days 0) { batch.setStatus(4); batch.setAvailableNum(0); batch.setFrozenNum(0); log.error(批次 {} 已过期自动报废, batch.getBatchNo()); } batchMapper.updateById(batch); } } }注意不要用LocalDate.now().until(batch.getExpireDate()).getDays()来计算剩余天数因为Period.between返回的getDays()在天数跨月时会变成“不足一个月的天数”瞬间变成负数。用ChronoUnit.DAYS.between()就没这种坑。这个过期计算的小陷阱我可以负责任地说很多网上教程的代码都写错了你如果用的Period.between最好立刻改掉。3.6 用血申请审核流程审核流程上我设计了“提交申请 - 科室护士初审 - 库存管理员核血 - 出库”四步。实际代码里拆成三个状态就够状态说明可执行操作0待审核护士可撤销1审核通过待出库管理员核血后出库2已出库完成-1已驳回医生可重新申请“核血”这个动作在界面上其实就是点一下“确认匹配批次”后端调用前面写的freezeBatchStock预占库存。我这边建议你把“核血”和“出库”分开按钮核血时不真正扣减实物库存仅做逻辑匹配和预占出库时才把状态拧到“已出库”。这样如果医生临时取消用血只需把冻结批次解冻即可不用做逆向冲单数据干净很多。看到这里你可能觉得流程有点多但这就是血库管理跟普通进销存系统的关键差异——它有严格的容器隔离和质量追踪机制不是为了繁琐而繁琐。4. 前端页面与报表模块4.1 页面布局和权限区分前端我用的Thymeleaf模板一个基于AdminLTE样式定制的后台布局。页面主要分四块仪表盘大屏统计库存总量、过期预警批次、近7天出库趋势、用血类型分布。入库管理列表批次记录的增删查改、有效期排序。出库管理列表通过申请单维度查看出库明细支持按血型、时间筛选。系统管理用户管理、角色权限、操作日志。权限这块不要自己手写一套太复杂的RBAC一个简单的HandlerInterceptor判断session里的用户角色就行。管理员能看到全部菜单护士只能操作申请单创建、撤回库存管理员只看到入库、出库和盘点菜单。一定有同学想上Spring Security我给你的建议是如果你的论文篇幅和答辩精力有限优先用Interceptor如果确实想用就做一个最简版本的登录认证角色判断不要把密码加密、Token、刷新令牌这些全铺上去跟系统本身的规模不匹配还会引入大量你没法解释清楚的细节。4.2 库存列表页的关键查询实现库存页要支持按血型、成分、预警状态三个条件筛选同时按效期从近到远排序这是血库系统的核心查询场景之一。public PageResultBloodStockBatch queryStockPage(StockQuery query) { PageBloodStockBatch page new Page(query.getPage(), query.getSize()); LambdaQueryWrapperBloodStockBatch wrapper new LambdaQueryWrapper(); // 只查在库状态过期和已用完的单独入口查 wrapper.eq(BloodStockBatch::getStatus, 1); wrapper.like(StringUtils.hasText(query.getBloodType()), BloodStockBatch::getBloodType, query.getBloodType()); wrapper.eq(StringUtils.hasText(query.getComponent()), BloodStockBatch::getComponent, query.getComponent()); wrapper.eq(query.getWarnStatus() ! null, BloodStockBatch::getWarnStatus, query.getWarnStatus()); // 按效期升序临期批次排前面 wrapper.orderByAsc(BloodStockBatch::getExpireDate); PageBloodStockBatch result batchMapper.selectPage(page, wrapper); return PageResult.from(result); }这里要注意一个问题StringUtils.hasText和wrapper.like的boolean条件你用MyBatis-Plus的LambdaWrapper写起来很爽但SQL层面其实是用if动态拼接条件。如果筛选条件为空SQL就是WHERE status 1 ORDER BY expire_date ASC索引利用率没问题数据量几百条也不会卡。关于查询列表的分页我强调一个前端配合的点分页参数page和size必须通过提交表单传后端不能靠前端JS自己把全表数据翻页。很多同学为了省事一次性selectList全部数据扔到前端然后前端分页——这在小项目里确实能用但答辩时老师一句“如果库存到一万条怎么办”就尴尬了。用MyBatis-Plus的selectPage代码多花的时间几乎为零让后端真正做分页这句话在答辩中是可以直接拿出来讲的加分项。4.3 出库明细与打印单据出库记录页建议展示这些列申请单号、患者姓名、科室、血型、成分、出库量、出库批次号、领血人、出库人、出库时间。在此基础上我加了一个“打印出库单”按钮通过浏览器的window.print()调出打印样式纸张格式直接就是横版单据。打印功能虽然简单但放在毕设里很加分因为它是真实医院场景里护士们每天都在做的事。实现上就是写一个专门的/out-record/{id}/print页面用GetMapping返回一个Thymeleaf模板模板里只用简单的表格排版不用任何前端框架。这大概一百行代码不到却能让你的系统看起来完整度高一个档次。4.4 统计报表实现报表我采用了ECharts 后端聚合接口的方式。这里不建议搞复杂的联表SQL直接用简单的GROUP BY就好。例如出库趋势图的查询public ListMapString, Object outTrendLast7Days() { return outRecordMapper.selectMaps(new QueryWrapperBloodOutRecord() .select(DATE_FORMAT(create_time, %Y-%m-%d) as day, SUM(out_num) as total) .groupBy(day) .orderByAsc(day)); }ECharts前端用fetch拿这个JSON数组塞给Bar图。后端接口返回的字段名是day和total对应前端xAxis.data和series.data。整个链路很直观没什么高深的玄机。用血类型分布图饼图也是类似的思路就是GROUP BY component统计每种成分的出库总量。这个图表放入系统首页的仪表盘能让首页看起来没那么单调同时也是论文里“系统的社会效益分析”的好素材——有图表就等于有数据支撑。5. 常见问题排查与避坑指南5.1 MySQL时区异常现象启动后查询所有与时间相关的字段报The server time zone value йʱ is unrecognized。原因JDBC连接串没有指定时区MySQL 8.0默认按服务器本地时区解析而中文Windows系统的时区名编码在connector里经常乱码。解决url中加上serverTimezoneAsia/Shanghai一行搞定。这个问题的报错全是乱码中文搜网上教程经常找不到答案我当初也折腾了半小时。5.2 Map重复键导致报表总数异常现象ECharts饼图数据总量少算或者多算。原因selectMaps查询返回LinkedHashMap如果你在Java代码里手动分组累加一不小心用的分组键是bloodTypecomponent而不是单独某个字段导致同成分不同血型被拆成多个空对象。解决把聚合直接放在SQL的GROUP BY里Java端只做一个ListMap的转换和JSON序列化避免人为聚合出错。这是我自己的习惯——凡是能由SQL完成的聚合绝不在Java里再写一遍。5.3 Thymeleaf模板缓存导致修改不生效现象改了templates/stock/list.html刷新页面还是旧的。原因spring.thymeleaf.cache默认trueSpringBoot 2.7的开发环境也不会自动关闭。解决开发期在application.yml里写死spring.thymeleaf.cache: false同时配合IDEA的Build - Build Project。如果用的是JSP那类的模板还要设置server.servlet.jsp.init-parameters.developmenttrueThymeleaf不需要这个。5.4 血型校验逻辑不小心绕过现象申请单A型但出库单发成了B型走流程时数据能保存。原因只在页面做了下拉框联动后端出库接口没有校验申请单和批次的bloodType一致性。解决后端出库接口增加一个守卫判断不匹配直接抛业务异常if (!applyRecord.getBloodType().equals(batch.getBloodType()) || !applyRecord.getRhFactor().equals(batch.getRhFactor())) { throw new BusinessException(血型含RH因子不匹配禁止出库); }这个校验放后端看似多写了五行代码但实际是血库系统最核心的业务安全阀之一。答辩时被问到“数据完整性和安全性怎么保证”这是我排在第一位的回答内容。5.5 日期计算中的Period陷阱前面提过一次这里再展开讲透Period.between是用来计算“年月日三个字段的差值”的。假设LocalDate.now()是2025年5月18日expireDate是2025年6月2日Period.between的结果是P0Y0M15D这时getDays()等于15没问题。但如果是2025年4月30日到2025年6月2日结果是P0Y1M2DgetDays()只有2实际上期间有33天差了十万八千里。用ChronoUnit.DAYS.between就能得到正确的33。这个坑在库存不多时一般察觉不到等到有一批跨月效期的时候预警就全乱了。6. 实操经验与部署建议6.1 项目演示数据怎么造答辩前一定要生成一份能被口头讲出故事的数据别只空跑一个“admin登录进去啥都没有”的裸系统。我推荐写一个DataInitializer类在项目启动时往库里插入这些演示数据不同血型的红细胞、血浆若干批次其中至少两个批次效期在3天内触发一级预警。在库数量恰好低于低阈值的某个血型让库存预警图表有数据可画。过去7天的出库记录保证趋势图有曲线且数值看起来“日常有波动但不夸张”。操作日志里至少30条不同类型的操作体现系统被使用过的痕迹。具体数值我建议每个批次的总量设10到30单位之间不要每条都是100太假。血型分布上A型和O型略多AB型稀少一点这点可以支撑“用血数量与人群血型分布正相关”的论文论据。生成数据的代码写在CommandLineRunner里判断数据表非空就不再插入这样不会影响你后续手工添加的数据。6.2 打包部署与演示环境毕设答辩现在很多是带自己的电脑或者上交一份可运行包。无论哪种建议都是直接用Maven打成jar包运行做好以下准备mvn clean package -DskipTests java -jar blood-manage-0.0.1-SNAPSHOT.jar如果电脑上没有MySQL最稳妥的是在自己电脑装一个MySQL 8.0并把blood_manage库建好spring.datasource改成localhost。注意把druid如果引入的监控页面配置关掉避免答辩时有无关的弹窗。如果需要放到演示服务器上那就直接在Linux里执行先装JDK8和MySQL。建库导入init.sql。把jar包上传后nohup java -jar xxx.jar app.log 21 。防火墙放行8080端口。Linux下部署时尤其要注意MySQL默认的character_set_server是不是utf8mb4如果库表建的时候不是这个字符集插入中文姓名时会报Incorrect string value这也是一个高频问题。建库语句直接写CREATE DATABASE blood_manage DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;6.3 论文里的技术亮点怎么写这个系统在毕业论文中能提炼的技术点不少建议按以下顺序组织创新点血液库存状态闭环管理以“批次-状态机”为核心实现入库、预占、出库、过期报废的完整生命周期区别于普通库存管理的静态记录。基于预占机制的并发安全库存扣减用单条UPDATE条件语句解决并发抢血问题可扩展说明这种思想在电商秒杀中的应用。多级效期预警机制按剩余天数划分预警等级配合定时任务自动扫库提升血液使用的安全性。全程操作日志追踪所有关键业务动作都留痕形成可追溯的审计链条。这四个点任何一个都可以在答辩时展开聊个5分钟。这比单纯说“我用了SpringBoot和Vue”要有力得多。我个人实际做下来的体会是血库管理系统这种毕业设计真正的门槛不在技术框架而在对业务状态的建模是否清晰。只要你把“批次可用量”“冻结量”“有效期预警”这三个概念想透了代码只是按图索骥。反过来如果你一上来就急着写Controller和页面到最后肯定会出现库存扣减混乱、申请状态对不上的情况然后越改越乱。最后分享一个小经验演示之前把所有库存列表按效期升序排好先点开预警页给老师看“这批血还有3天过期系统标红了”再现场演示一个出库流程紧接着去库存明细里确认可用量扣了1个单位。这一套动作下来比你在PPT里念十页功能列表都更有说服力。祝顺利。
基于SpringBoot的血库管理系统毕业设计：库存预警与事务并发实践
1. 项目概述与技术选型做毕业设计选这个“医院血库管理系统”的人我猜十有八九是被血库管理的业务流程吸引住了——它不是纯CRUD还有库存预警、效期管理、出入库追踪这些真实业务逻辑做完讲答辩的时候能聊的东西比别人多一大截。我自己改写过类似系统今天这篇就把我当时的设计思路、踩坑记录、核心代码实现完整拆给你照着改就能交差不多的版本。先说结论这个毕设用SpringBoot做后端是完全正确的选择。原因有三。第一SpringBoot的自动化配置能让你在三天内把项目骨架跑起来不需要像传统SpringMVC那样纠结一堆XML配置。你用spring-boot-starter-web导进来main方法一启动内嵌Tomcat就直接挂好端口了本地调试、答辩演示都非常顺手。第二血库管理系统这种业务本质上是典型的库存管理状态流转场景SpringBoot配合MyBatis-Plus来做单表CRUD和分页查询几乎不用写复杂SQL就能把所有模块撑起来开发量集中在业务逻辑而不是技术门槛。第三毕设答辩的时候老师大概率会问“为什么选这个框架”你直接回答SpringBoot的自动配置、内嵌容器、生态成熟度以及互联网上大量的中文参考资料出了问题好查这就是最务实的理由。再从业务角度说血库管理系统的核心实体其实就几个血液制品批次入库、库存记录、患者用血申请、出库记录、预警规则。有些同学可能担心“系统太简单会不会被刷”实际上你只要把库存预扣、效期预警、批次追溯这三个环节做扎实整个项目的工作量就完全撑得起一篇毕业设计论文。技术栈我推荐这样组合这是我测试过最稳的搭配组件选型说明后端框架SpringBoot 2.7.xJDK8可跑稳定中文资料最多ORMMyBatis-Plus 3.5.x单表CRUD免写SQL代码量骤减数据库MySQL 5.7或8.0免费、通用老师机器上也好装前端Thymeleaf Bootstrap毕业设计场景够用不用前后端分离权限Spring Security 或拦截器简单角色区分管理员、护士、医生报表ECharts库存趋势和用血分类统计版本这块要提醒一句SpringBoot别用3.0以上的因为JDK版本和部分yml配置写法变了你答辩的机器上可能装的是JDK8出问题自己还得临时补没必要自找麻烦。2.7.x配合JDK8是最省心的组合。回到拓扑上整个系统就是标准的浏览器-后端-MySQL三层不需要引入Redis和MQ来画蛇添足。有些同学会为了“看起来高级”强加一套Redis缓存我劝你不要——那是给自己挖坑答辩前一周如果紧张状态出bug排查起来很痛苦。毕设的首要目标是能跑、能讲、能答。2. 数据库设计与核心业务流程2.1 数据表拆分思路血库管理系统的表结构我建议拆成5张核心业务表加上3张辅助表这个粒度正好匹配毕设的体量也不会显得单薄blood_product血液制品基础信息表。包括血型A/B/AB/O、RH因子、成分全血、红细胞、血浆、血小板、单位规格200ml/400ml等、生产单位、批号。blood_stock_batch入库批次表。每次从血站或中心血库接收血液时生成一条记录包含入库时间、效期截止时间、入库数量、当前可用数量、状态在库/冻结/已用完/过期。blood_receive_record入院接收记录表。病人入院登记时需要绑定血型信息方便后续开申请时自动关联匹配。blood_apply_record用血申请单。包括申请科室、申请医生、病人信息、申请血量、申请状态待审核/审核通过/已出库/已取消。这是整个流程的中枢表出库操作必须依附于申请单。blood_out_record出库记录表。记录出库的申请单ID、出库批次ID、出库量、出库人、领血人、出库时间。sys_user系统用户表。区分管理员、医护人员、库存管理员等角色。blood_request_log血站补货申请记录。库存低于阈值时发起补货流程。operation_log操作日志表。这个表很重要虽然看着像辅助表但答辩的时候可以专门拿出来强调——所有出入库和审核操作都留有痕迹。表关系的核心逻辑是批次表决定“有多少血可用”申请单决定“谁要用血”出库单把批次的可用量扣减掉。这三个表之间形成了完整的闭环。有一点很多第一次做的人容易漏血液不是普通商品同一血型下不同成分要分开管理。比如一个批次是“A型Rh阳性红细胞”另一个批次是“A型Rh阳性血浆”如果混在同一个blood_type字段里去查询后面做效期预警和维护盘点时会乱成一团。所以设计时一定要明确“一个批次就是一类血液制品”不要试图把多个成分合并到一条记录里。2.2 状态流转设计血库里的每一条入库批次它的状态应该是这样流转的待验收 - 在库 - 冻结 - 出库完毕 |- 过期报废待验收血液送到医院之后先登记但还没正式核验完成。实际上实操中可以省掉直接入库但保留这个状态能让流程更完整。在库可通过效期预警查询处于可出库状态。冻结当批次被某个申请单锁定预分配时暂时不可被其他申请单匹配。过期报废超过效期截止时间未使用的血液自动标记为报废不能参与正常出库。对应的应用逻辑就是申请单审核通过之后先在可用批次里做一次“预占”——把申请血量从批次可用数中扣减逻辑锁定不做物理删除生成一出库单关联等到实际发血时完成物理扣减。这样做的好处是同一批血不会被两个申请单同时抢走。这套状态流转涉及到的字段调整我给你列一个简表场景操作涉及字段变化新批次入库blood_stock_batchinsert新增记录available_num total_num申请单通过blood_apply_recordupdate状态改为已通过金额不涉及只需记录申请量预占批次blood_stock_batchupdatefrozen_num 申请量available_num 不变或冻结量单独计实际出库blood_out_recordinsertavailable_num 扣减frozen_num 释放并减少 total_num过期预警定时任务扫描状态改为过期报废可用数量清零预占这块我多说一句我见过有同学直接改available_num不做冻结另计导致申请单取消时还得“阴差阳错地加回来”逻辑搞得非常绕极易出错。正确做法是把“冻结数量”和“可用数量”分开看待真正物理在库但被锁定的血不计入可分配库存。这样的好处是你出库的时候不用反复核对申请数据出库多少就扣多少。2.3 效期预警与库存阈值规则血液管理跟普通库存最大的区别就在于效期敏感。国家规定红细胞和全血效期一般不超过21~35天血小板更是只有5天左右。系统里必须在批次记录保存时就开始计算剩余天数并设置两档预警一级预警剩余效期不足3天。列表标红提示优先发放。二级预警剩余效期不足7天。提示尽快协调用血。库存低阈值某血型成分库存少于10单位具体数可按医院级别调整触发补货申请。这个逻辑我建议用Scheduled定时任务挂在后端每天早上9点和晚上6点各扫一遍全表更新批次的预警状态。为了不让预警把页面刷爆预警只记录最近一次的变更结果存放在批次记录的状态字段里。CPU开销非常小别担心扫描性能问题——血库系统的批次表每天新增量很少全表扫描完全可行。如果非要用Redis缓存那类东西来做反而把一个简单需求弄复杂了。2.4 血型匹配关系另一个关键设计是用血申请必须关联入院登记时的血型信息。实际业务里病人输血前医生必须核对血型这个核对逻辑直接放在系统里省事很多。建议的策略是病人信息表或病历表里保存血型。申请单创建时自动带出血型和RH因子显示给医生核对。出库时系统强制校验申请单血型与出库批次血型一致否则阻断操作并提示“血型不符禁止出库”。哪怕只是一个小小的校验答辩时老师问“有没有做容错和完整性校验”你就可以理直气壮地拿这个例子出来讲。3. 核心代码实现与关键细节3.1 项目初始化与依赖配置我用的SpringBoot 2.7.5创建项目时只需要选Web、MySQL驱动、Lombok这三个依赖剩下的MyBatis-Plus和Thymeleaf手动加到pom.xml里dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-thymeleaf/artifactId /dependencyapplication.yml里面核心配置如下注意mybatis-plus的逻辑删除和分页插件都要显式声明server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/blood_manage?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 thymeleaf: cache: false mybatis-plus: mapper-locations: classpath*:mapper/*.xml type-aliases-package: com.example.blood.entity global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0有一点必须踩过坑才记得住MySQL 8.0以上必须加serverTimezoneAsia/Shanghai不加的话日期字段在JDBC驱动里会报告时区异常。如果是5.7的库驱动类名还是com.mysql.jdbc.Driver别直接用8.0的写法。这两个小坑耽误过我校验时区的半天时间。3.2 实体类设计样例以批次实体为例字段设计要注意“逻辑删除与操作日志分开处理”Data TableName(blood_stock_batch) public class BloodStockBatch { TableId(type IdType.AUTO) private Long id; /** 批次号医院内部唯一 */ private String batchNo; /** 血型A、B、AB、O */ private String bloodType; /** RH阳性或阴性 */ private String rhFactor; /** 血液成分全血、红细胞、血浆、血小板 */ private String component; /** 入库时间 */ private LocalDateTime receiveTime; /** 生产日期 */ private LocalDate produceDate; /** 效期截止 */ private LocalDate expireDate; /** 总入库量单位U/200ml */ private Integer totalNum; /** 可用数量 */ private Integer availableNum; /** 冻结数量 */ private Integer frozenNum; /** 状态1在库 2冻结 3用完 4过期 */ private Integer status; /** 预警状态0正常 1二级预警 2一级预警 */ private Integer warnStatus; TableLogic private Integer deleted; }这里我特意把totalNum和availableNum都存成普通的Integer不搞触发器所有数量统计都在Service层事务里完成。毕设项目不需要用数据库触发器因为那样会让排查数据问题时多一层隐藏逻辑反而更难调试。另外注意TableField(fill FieldFill.INSERT)这类自动填充如果项目里没有时间字段审计的需求可以不用。但操作日志表的记录时间我强烈建议直接用数据库的NOW()或者后端的LocalDateTime.now()不要用JS在页面传——始终以后端为准减少被篡改的可能。3.3 入库操作的事务处理入库核心逻辑是两张表联动插入批次记录同时写入操作日志。如果日志表插入失败批次表也要回滚保持数据完整。Service RequiredArgsConstructor public class BloodStockServiceImpl implements BloodStockService { private final BloodStockBatchMapper batchMapper; private final OperationLogMapper operationLogMapper; Transactional(rollbackFor Exception.class) public void receiveBlood(BloodReceiveRequest req) { // 1. 构建批次记录 BloodStockBatch batch new BloodStockBatch(); batch.setBatchNo(generateBatchNo(req)); batch.setBloodType(req.getBloodType()); batch.setRhFactor(req.getRhFactor()); batch.setComponent(req.getComponent()); batch.setReceiveTime(LocalDateTime.now()); batch.setProduceDate(req.getProduceDate()); batch.setExpireDate(req.getExpireDate()); batch.setTotalNum(req.getTotalNum()); batch.setAvailableNum(req.getTotalNum()); batch.setFrozenNum(0); batch.setStatus(1); batch.setWarnStatus(0); batchMapper.insert(batch); // 2. 写日志 OperationLog log new OperationLog(); log.setOperator(SecurityUtils.getUsername()); log.setOperationType(入库); log.setTargetType(批次); log.setTargetId(batch.getId()); log.setContent(接收血制品 req.getComponent() req.getBloodType() Rh req.getRhFactor() 数量 req.getTotalNum()); log.setCreateTime(LocalDateTime.now()); operationLogMapper.insert(log); } }生成批次号的方法是医院常见的规则receiveYear reciveMonth 当天序号类似BL20250512001。如果最后四位操作不写了直接用yyyyMMddHHmmss三位随机数也可以反正必做唯一键检查。这里有个容易被同学们忽略的点Transactional默认只回滚RuntimeException。如果你在方法里捕获了Exception又往外抛了个一般异常事务可能不生效导致日志插进去了、批次却没插成数据对不上。所以注解上务必用Transactional(rollbackFor Exception.class)而不是默认的空注解。3.4 出库操作与预扣库存出库是整个系统里最容易出并发bug的地方。我建议在申请审核通过时“预占”批次库存而不是等到出库时才扣减。预占的SQL可以用UPDATE ... WHERE available_num ?靠受影响行数判断是否抢占成功Transactional(rollbackFor Exception.class) public boolean freezeBatchStock(Long batchId, Integer qty) { int rows batchMapper.update(null, new LambdaUpdateWrapperBloodStockBatch() .eq(BloodStockBatch::getId, batchId) .ge(BloodStockBatch::getAvailableNum, qty) .setSql(frozen_num frozen_num qty) .setSql(available_num available_num - qty)); return rows 0; }这个写法的关键在于把“判断数量足够”和“扣减数量”合并成一条UPDATE数据库行级锁会保证同一时间只有一个申请能扣固有库存不会出现两个申请各扣了100、实际库存只有80的情况。这是秒杀系统里减库存的经典写法放到血库管理里同样有效。出库记录那边还要同步更新申请单状态同时把操作日志记上。这里同样要注意一致性出库成功后如果日志写入失败还得靠事务回滚保证两个表都干干净净。3.5 过期扫描任务用Spring的Scheduled实现效期扫描比较轻量。先给启动类加上EnableScheduling再写一个定时任务类Component Slf4j public class ExpireScanTask { Resource private BloodStockBatchMapper batchMapper; /** 每天8点、18点各执行一次 */ Scheduled(cron 0 0 8,18 * * ?) public void expireScan() { // 查询所有在库批次 ListBloodStockBatch batches batchMapper.selectList( new LambdaQueryWrapperBloodStockBatch() .eq(BloodStockBatch::getStatus, 1)); for (BloodStockBatch batch : batches) { long days ChronoUnit.DAYS.between(LocalDate.now(), batch.getExpireDate()); // 一级预警3天内 if (days 0 days 3) { batch.setWarnStatus(2); log.warn(批次 {} 剩余效期仅 {} 天, batch.getBatchNo(), days); } // 二级预警7天内 else if (days 7) { batch.setWarnStatus(1); } else { batch.setWarnStatus(0); } // 过期自动报废 if (days 0) { batch.setStatus(4); batch.setAvailableNum(0); batch.setFrozenNum(0); log.error(批次 {} 已过期自动报废, batch.getBatchNo()); } batchMapper.updateById(batch); } } }注意不要用LocalDate.now().until(batch.getExpireDate()).getDays()来计算剩余天数因为Period.between返回的getDays()在天数跨月时会变成“不足一个月的天数”瞬间变成负数。用ChronoUnit.DAYS.between()就没这种坑。这个过期计算的小陷阱我可以负责任地说很多网上教程的代码都写错了你如果用的Period.between最好立刻改掉。3.6 用血申请审核流程审核流程上我设计了“提交申请 - 科室护士初审 - 库存管理员核血 - 出库”四步。实际代码里拆成三个状态就够状态说明可执行操作0待审核护士可撤销1审核通过待出库管理员核血后出库2已出库完成-1已驳回医生可重新申请“核血”这个动作在界面上其实就是点一下“确认匹配批次”后端调用前面写的freezeBatchStock预占库存。我这边建议你把“核血”和“出库”分开按钮核血时不真正扣减实物库存仅做逻辑匹配和预占出库时才把状态拧到“已出库”。这样如果医生临时取消用血只需把冻结批次解冻即可不用做逆向冲单数据干净很多。看到这里你可能觉得流程有点多但这就是血库管理跟普通进销存系统的关键差异——它有严格的容器隔离和质量追踪机制不是为了繁琐而繁琐。4. 前端页面与报表模块4.1 页面布局和权限区分前端我用的Thymeleaf模板一个基于AdminLTE样式定制的后台布局。页面主要分四块仪表盘大屏统计库存总量、过期预警批次、近7天出库趋势、用血类型分布。入库管理列表批次记录的增删查改、有效期排序。出库管理列表通过申请单维度查看出库明细支持按血型、时间筛选。系统管理用户管理、角色权限、操作日志。权限这块不要自己手写一套太复杂的RBAC一个简单的HandlerInterceptor判断session里的用户角色就行。管理员能看到全部菜单护士只能操作申请单创建、撤回库存管理员只看到入库、出库和盘点菜单。一定有同学想上Spring Security我给你的建议是如果你的论文篇幅和答辩精力有限优先用Interceptor如果确实想用就做一个最简版本的登录认证角色判断不要把密码加密、Token、刷新令牌这些全铺上去跟系统本身的规模不匹配还会引入大量你没法解释清楚的细节。4.2 库存列表页的关键查询实现库存页要支持按血型、成分、预警状态三个条件筛选同时按效期从近到远排序这是血库系统的核心查询场景之一。public PageResultBloodStockBatch queryStockPage(StockQuery query) { PageBloodStockBatch page new Page(query.getPage(), query.getSize()); LambdaQueryWrapperBloodStockBatch wrapper new LambdaQueryWrapper(); // 只查在库状态过期和已用完的单独入口查 wrapper.eq(BloodStockBatch::getStatus, 1); wrapper.like(StringUtils.hasText(query.getBloodType()), BloodStockBatch::getBloodType, query.getBloodType()); wrapper.eq(StringUtils.hasText(query.getComponent()), BloodStockBatch::getComponent, query.getComponent()); wrapper.eq(query.getWarnStatus() ! null, BloodStockBatch::getWarnStatus, query.getWarnStatus()); // 按效期升序临期批次排前面 wrapper.orderByAsc(BloodStockBatch::getExpireDate); PageBloodStockBatch result batchMapper.selectPage(page, wrapper); return PageResult.from(result); }这里要注意一个问题StringUtils.hasText和wrapper.like的boolean条件你用MyBatis-Plus的LambdaWrapper写起来很爽但SQL层面其实是用if动态拼接条件。如果筛选条件为空SQL就是WHERE status 1 ORDER BY expire_date ASC索引利用率没问题数据量几百条也不会卡。关于查询列表的分页我强调一个前端配合的点分页参数page和size必须通过提交表单传后端不能靠前端JS自己把全表数据翻页。很多同学为了省事一次性selectList全部数据扔到前端然后前端分页——这在小项目里确实能用但答辩时老师一句“如果库存到一万条怎么办”就尴尬了。用MyBatis-Plus的selectPage代码多花的时间几乎为零让后端真正做分页这句话在答辩中是可以直接拿出来讲的加分项。4.3 出库明细与打印单据出库记录页建议展示这些列申请单号、患者姓名、科室、血型、成分、出库量、出库批次号、领血人、出库人、出库时间。在此基础上我加了一个“打印出库单”按钮通过浏览器的window.print()调出打印样式纸张格式直接就是横版单据。打印功能虽然简单但放在毕设里很加分因为它是真实医院场景里护士们每天都在做的事。实现上就是写一个专门的/out-record/{id}/print页面用GetMapping返回一个Thymeleaf模板模板里只用简单的表格排版不用任何前端框架。这大概一百行代码不到却能让你的系统看起来完整度高一个档次。4.4 统计报表实现报表我采用了ECharts 后端聚合接口的方式。这里不建议搞复杂的联表SQL直接用简单的GROUP BY就好。例如出库趋势图的查询public ListMapString, Object outTrendLast7Days() { return outRecordMapper.selectMaps(new QueryWrapperBloodOutRecord() .select(DATE_FORMAT(create_time, %Y-%m-%d) as day, SUM(out_num) as total) .groupBy(day) .orderByAsc(day)); }ECharts前端用fetch拿这个JSON数组塞给Bar图。后端接口返回的字段名是day和total对应前端xAxis.data和series.data。整个链路很直观没什么高深的玄机。用血类型分布图饼图也是类似的思路就是GROUP BY component统计每种成分的出库总量。这个图表放入系统首页的仪表盘能让首页看起来没那么单调同时也是论文里“系统的社会效益分析”的好素材——有图表就等于有数据支撑。5. 常见问题排查与避坑指南5.1 MySQL时区异常现象启动后查询所有与时间相关的字段报The server time zone value йʱ is unrecognized。原因JDBC连接串没有指定时区MySQL 8.0默认按服务器本地时区解析而中文Windows系统的时区名编码在connector里经常乱码。解决url中加上serverTimezoneAsia/Shanghai一行搞定。这个问题的报错全是乱码中文搜网上教程经常找不到答案我当初也折腾了半小时。5.2 Map重复键导致报表总数异常现象ECharts饼图数据总量少算或者多算。原因selectMaps查询返回LinkedHashMap如果你在Java代码里手动分组累加一不小心用的分组键是bloodTypecomponent而不是单独某个字段导致同成分不同血型被拆成多个空对象。解决把聚合直接放在SQL的GROUP BY里Java端只做一个ListMap的转换和JSON序列化避免人为聚合出错。这是我自己的习惯——凡是能由SQL完成的聚合绝不在Java里再写一遍。5.3 Thymeleaf模板缓存导致修改不生效现象改了templates/stock/list.html刷新页面还是旧的。原因spring.thymeleaf.cache默认trueSpringBoot 2.7的开发环境也不会自动关闭。解决开发期在application.yml里写死spring.thymeleaf.cache: false同时配合IDEA的Build - Build Project。如果用的是JSP那类的模板还要设置server.servlet.jsp.init-parameters.developmenttrueThymeleaf不需要这个。5.4 血型校验逻辑不小心绕过现象申请单A型但出库单发成了B型走流程时数据能保存。原因只在页面做了下拉框联动后端出库接口没有校验申请单和批次的bloodType一致性。解决后端出库接口增加一个守卫判断不匹配直接抛业务异常if (!applyRecord.getBloodType().equals(batch.getBloodType()) || !applyRecord.getRhFactor().equals(batch.getRhFactor())) { throw new BusinessException(血型含RH因子不匹配禁止出库); }这个校验放后端看似多写了五行代码但实际是血库系统最核心的业务安全阀之一。答辩时被问到“数据完整性和安全性怎么保证”这是我排在第一位的回答内容。5.5 日期计算中的Period陷阱前面提过一次这里再展开讲透Period.between是用来计算“年月日三个字段的差值”的。假设LocalDate.now()是2025年5月18日expireDate是2025年6月2日Period.between的结果是P0Y0M15D这时getDays()等于15没问题。但如果是2025年4月30日到2025年6月2日结果是P0Y1M2DgetDays()只有2实际上期间有33天差了十万八千里。用ChronoUnit.DAYS.between就能得到正确的33。这个坑在库存不多时一般察觉不到等到有一批跨月效期的时候预警就全乱了。6. 实操经验与部署建议6.1 项目演示数据怎么造答辩前一定要生成一份能被口头讲出故事的数据别只空跑一个“admin登录进去啥都没有”的裸系统。我推荐写一个DataInitializer类在项目启动时往库里插入这些演示数据不同血型的红细胞、血浆若干批次其中至少两个批次效期在3天内触发一级预警。在库数量恰好低于低阈值的某个血型让库存预警图表有数据可画。过去7天的出库记录保证趋势图有曲线且数值看起来“日常有波动但不夸张”。操作日志里至少30条不同类型的操作体现系统被使用过的痕迹。具体数值我建议每个批次的总量设10到30单位之间不要每条都是100太假。血型分布上A型和O型略多AB型稀少一点这点可以支撑“用血数量与人群血型分布正相关”的论文论据。生成数据的代码写在CommandLineRunner里判断数据表非空就不再插入这样不会影响你后续手工添加的数据。6.2 打包部署与演示环境毕设答辩现在很多是带自己的电脑或者上交一份可运行包。无论哪种建议都是直接用Maven打成jar包运行做好以下准备mvn clean package -DskipTests java -jar blood-manage-0.0.1-SNAPSHOT.jar如果电脑上没有MySQL最稳妥的是在自己电脑装一个MySQL 8.0并把blood_manage库建好spring.datasource改成localhost。注意把druid如果引入的监控页面配置关掉避免答辩时有无关的弹窗。如果需要放到演示服务器上那就直接在Linux里执行先装JDK8和MySQL。建库导入init.sql。把jar包上传后nohup java -jar xxx.jar app.log 21 。防火墙放行8080端口。Linux下部署时尤其要注意MySQL默认的character_set_server是不是utf8mb4如果库表建的时候不是这个字符集插入中文姓名时会报Incorrect string value这也是一个高频问题。建库语句直接写CREATE DATABASE blood_manage DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;6.3 论文里的技术亮点怎么写这个系统在毕业论文中能提炼的技术点不少建议按以下顺序组织创新点血液库存状态闭环管理以“批次-状态机”为核心实现入库、预占、出库、过期报废的完整生命周期区别于普通库存管理的静态记录。基于预占机制的并发安全库存扣减用单条UPDATE条件语句解决并发抢血问题可扩展说明这种思想在电商秒杀中的应用。多级效期预警机制按剩余天数划分预警等级配合定时任务自动扫库提升血液使用的安全性。全程操作日志追踪所有关键业务动作都留痕形成可追溯的审计链条。这四个点任何一个都可以在答辩时展开聊个5分钟。这比单纯说“我用了SpringBoot和Vue”要有力得多。我个人实际做下来的体会是血库管理系统这种毕业设计真正的门槛不在技术框架而在对业务状态的建模是否清晰。只要你把“批次可用量”“冻结量”“有效期预警”这三个概念想透了代码只是按图索骥。反过来如果你一上来就急着写Controller和页面到最后肯定会出现库存扣减混乱、申请状态对不上的情况然后越改越乱。最后分享一个小经验演示之前把所有库存列表按效期升序排好先点开预警页给老师看“这批血还有3天过期系统标红了”再现场演示一个出库流程紧接着去库存明细里确认可用量扣了1个单位。这一套动作下来比你在PPT里念十页功能列表都更有说服力。祝顺利。
