这些年接触过不少医疗信息化相关的项目，也带过几届毕业设计的开发小组，如果要选一个“麻雀虽小但五脏俱全”的题目来完整走一遍需求、设计、编码、部署的全流程，基于SpringBoot的医院医用耗材全程追踪平台是个非常合适的切入点。表面上看，它只是一个常规的“进销存”系统，但真正深入进去会发现，医疗耗材的管理逻辑和普通商品库存完全是两码事：批次要可溯、效期要可控、高值耗材要做到“一物一码”、低值耗材要做到“期批追溯”，甚至还要跟临床收费、科室成本挂钩。这个系统做透了，等于把一套可落地的精细化运营方案握在了手里，也把SpringBoot+MySQL从CRUD到复杂业务状态流转的整套能力练了一遍。这篇文章我想从需求拆解、技术选型、表结构设计、核心追踪链路实现到排查实录，把整个项目的关键环节和坑点完整复盘一遍，给准备做同类系统或者正在搞医疗信息化毕业设计的同学一份能直接参考的底稿。
1. 项目定位：医疗耗材管理的难点从哪来
1.1 医院耗材管理为什么难做
很多人一开始会把医用耗材管理理解成“做个库存表，进出登记一下就行”，这个认知偏差会在需求调研阶段被狠狠纠正。医院的耗材体系远比想象中复杂。按价值和管理方式划分，至少包含三大类：一是低值耗材，比如注射器、输液器、纱布、棉签、手套这类单价低、用量大、常用于常规诊疗的品种；二是高值耗材，比如心脏支架、骨科植入物、起搏器、介入导管这类单价高、风险高、必须单独追溯的品种；三是检验试剂，这类对效期和冷链存储要求极高，一旦过期或者存放条件不达标，直接影响检验结果准确性。
三类耗材的管理要求各不相同，但核心矛盾是统一的：“账面上有数”不等于“实际中能用”。传统Excel表格管理最典型的问题有三个——第一，单据流和数据流脱节，入库单、领用单、退库单散落在科室和库房手中，月底对账要耗费大量人工；第二，批次和效期信息靠人工记忆，效期管理完全依赖库管员的责任心，出现过效期耗材被遗忘在货架角落的情况；第三，高值耗材的追溯链断裂，一旦发生产品质量反馈，医院需要反查某一批耗材用在了哪个患者身上，如果记录不全，整个过程可能要翻找几天甚至最终无果。这三个痛点正是“全程追踪”这个设计目标存在的根本原因。
1.2 “全程追踪”到底在追什么
全程追踪，本质上是围绕耗材的唯一标识建立一条从供应商发货、医院入库验收、院内科室领用、临床使用/计费，到最终关联患者的完整数据链路。要做到这点的前提，是把追踪抽象成“批次级”和“单品级”两套并行策略。
低值耗材量大、单价低，没必要也没可能逐个扫码赋码，所以管理粒度是“批次”。采购入库时按供应商、生产批号、效期生成一个唯一的批次编号，出库领取时按“先进先出”自动匹配批次，这样任何一个出库记录都能反查到当时的采购批次、供应商、效期和生产厂家。高值耗材则必须做到“一物一码”，入库时给每一个最小销售单元生成唯一的内部追溯码，出库时记录领用科室、操作人和使用患者，实现从“产品到家”到“用到谁身上”的全链路闭环。全程追踪追踪的不仅是物，更是数据间的关系——每一次状态变更、每一次经手人都要留下记录，这才是“系统”和“台账”的分水岭。
2. 技术选型：为什么是SpringBoot+MySQL
2.1 SpringBoot的适配性判断
选SpringBoot，首先考虑的是它对这个业务的匹配度。医疗耗材管理系统本质是一个企业内部业务管理系统，特点是界面多、逻辑复杂、并发量有限（医院内部几百个操作人员同时在线已经是高负载了，远达不到互联网级并发），这类场景恰恰是SpringBoot最擅长的领域。它的核心优势在于“约定大于配置”，内嵌Tomcat，一个fat jar就能跑起来，对部署环境要求很低，在医院内部的服务器上不需要额外安装复杂的应用服务就能启动，这一点在多轮现场调试中省了很大力气。
SpringBoot的生态整合能力同样关键。权限管理可以直接用Spring Security+JWT做无状态认证，适合前后端分离开发的场景；数据访问用Spring Data JPA或者MyBatis都是成熟方案，本项目选择MyBatis的原因前面说过，主要是对SQL可控性要求高，很多复杂的关联查询需要人工优化；日志用SLF4J+Logback，天然和SpringBoot集成。对于毕业设计或者中小型项目来说，SpringBoot能让我们把精力集中在业务逻辑上，而不是浪费在环境配置和框架整合上，这一点很实在。
2.2 MySQL存储方案的取舍
数据存储选用MySQL，同样基于业务特征。医疗耗材系统的数据量核心在流水表和追踪日志表，按一家中等规模医院计算，年出入库流水几十万条量级，加上追踪明细和操作日志，一年数据量在百万级左右。MySQL在百万级数据量下只要索引设计合理，查询性能完全可以接受，而且MySQL在事务支持、运维便利度、学习成本上的综合表现是性价比最高的选择。
这里有一个替大家避过坑的判断：不要为了追求“高性能”就盲目引入分布式存储方案。曾见过有同学在这个量级的数据场景里强行使用分库分表中间件甚至NoSQL数据库，结果是系统复杂度急剧上升，而业务上并没有实际的性能瓶颈，纯属给自己挖坑。MySQL在这样的业务量级下，配合合理的索引、分页查询和适当归档，已经能够让绝大部分查询在毫秒级返回。当然，为了保证高值耗材追踪数据的不可篡改性，可以在项目中设计对追踪日志表增加逻辑删除标识而不是物理删除，也可以引入数据库层面的定期备份策略，这些都是轻量且有效的保护手段。
2.3 前端、缓存与权限组件的搭配思路
前后端分离是目前这类系统的主流形态。前端可以选择Vue3+Element Plus作为管理后台框架，组件成熟度高，表格、表单、弹窗、树形控件这些高频场景都是现成的，能显著缩短开发周期。脚手架方面推荐Vite，启动和构建速度比老一代打包工具快得多。逆向后端只需要提供统一的RESTful API接口，接口路径按资源命名，配合JWT令牌做身份校验，整体结构清晰。
缓存层面，建议引入Redis但不是为了图花哨，而是解决两个实际问题。第一是登录会话的分布式管理，多实例部署时Session不再保存在单台服务器内存里；第二是高频查询的缓存，比如耗材字典、科室列表、供应商基础信息这类变更频率极低的数据，放入Redis缓存后可以减少数据库压力。不过要特别注意：库存数量和批次可用量这类核心数据绝不能放入Redis做长期缓存，因为库存准确性依赖数据库事务保证，一旦缓存和数据库不一致，会直接影响追踪逻辑的可靠性，这种一致性风险在医疗场景是不能接受的。
权限管理是三员分立还是简化角色，取决于系统使用范围。如果独立部署且只面向库房管理人员、采购人员和院级管理员，建议采用“超级管理员+库房管理员+普通操作员”三类角色即可，权限控制到菜单和按钮级别。如果计划跟医院现有的统一身份认证系统做对接，则需要预留OAuth2或CAS的适配接口，这个在系统设计阶段就要提前考虑，否则后期改造成本很高。
3. 系统架构与核心功能模块
3.1 系统总体分层架构
从前端浏览器到数据库，整个系统按标准的分层架构组织。前端通过HTTP请求访问后端RESTful API，后端采用经典的三层结构：Controller负责接口接收与参数校验，Service负责业务逻辑事务处理，Mapper/Repository负责数据持久化操作。在Service层内部，针对耗材流转的关键动作——入库、出库、退货、盘点、报损，统一采用事务管理，保证数据的一致性和完整性。
这里重点想讲一下，为什么入库和出库操作必须加事务。以领用出库为例，它的业务动作不是一个简单的“库存减一”，而是一组关联操作：校验当前科室领用数量是否满足可用库存、检查批次是否在效期内、扣减批次可用数量、生成出库单记录、同时生成一条追踪日志。这五个步骤只要任何一个失败，整个操作就必须回滚。如果不用事务，可能会出现“库存扣了但出库单没生成”的中间状态，这在耗材管理中是绝对不允许出现的故障模式。
3.2 六大核心功能模块拆解
实际落地时，系统按业务域拆分为六个相对独立又互相协作的功能模块。
基础数据管理模块，管理耗材字典信息、耗材分类、计量单位、生产厂家、供应商档案、临床科室信息。这里的关键点在于耗材字典必须支持“一物多码”的情况，同一个耗材可能因为规格、包装、生产厂家的不同，在系统内有多个条目，但它们需要关联到一个统一的“通用名称”维度上，方便统计汇总。
采购与入库管理模块，实现采购计划申请、审批、采购单生成、到货验收、入库单生成。入库是整个追溯链路的源头，每一条入库记录必须包含供应商信息、生产批号、生产日期、失效日期、注册证号、入库数量。对于高值耗材，在入库环节就要触发“单品赋码”，即按入库数量生成同等数量的唯一追溯码，并支持打印粘贴在最小包装上。
库存管理模块，包括库位管理、库存批次查询、库存上下限设置、效期管理、定期盘点、报损报溢处理。库存数据在页面上必须按“批次+库位”维度展示，能直观看到每个批次剩余多少、放在哪、什么时候到期。
领用出库与科室申领模块，支持临床科室在线提交申领单、库房审核发放、科室签收确认，替代线下纸质单据。出库时系统自动按照设定的出库策略——通常是先进先出——匹配批次，并且标记本次发放的追溯范围。
全程追踪与追溯查询模块，是整个系统的功能核心。通过一个耗材批次号或单品追溯码，能够逆向查询完整上下游流转记录：供应商→入库单→库位变动→出库单→领用科室→使用患者（高值耗材），形成一条可视化时间线。这个模块也承担合规审计职能，当产品出现质量反馈时，能在几分钟内定位到涉及批次和流向。
统计报表与预警模块，提供入库明细、出库明细、科室领用汇总、库存周转率分析、近效期耗材清单、过期耗材清单、供应商供货质量分析等报表。预警模块是系统“主动性”的体现，主要包含效期到期预警和库存上下限预警，通过定时任务扫描数据，达到预警条件时生成通知记录并在系统首页展示。
3.3 全流程追踪的角色视角设计
在设计追踪链路时，有一个容易被忽略但必须处理的细节：不同角色关心追踪数据的角度不同。库房管理员关心的是“这批货放在哪个库位、还剩多少、什么时候到期”；护士长关心的是“科室本月领了哪些耗材、金额多少、是否超预算”；院级管理者关心的是“全院耗材品类分布、供应商集中度、周转效率”；如果专职质量管理人员介入，他关心的是“某个批次的完整去向”。如果系统只做一条流水线，无法同时满足这些视角。
因此，在实现追踪数据模型时，建议以“单据-明细-日志”三种对象作为基础数据结构。单据承接每一次业务动作的行为本身（入库单、出库单、盘点单），明细层记录该单据涉及的每个耗材项目、数量、批号，日志层则用于记录每一次状态推进和经手人。基于这一套底层数据，前端做多视角查询就变得非常容易——既可以按“批次”做纵向穿透，也可以按“科室”做汇总统计，还可以按“时间范围”拉出全量流水导出Excel。这个数据模型的设计是我个人在整个项目中收益最大的部分，多花一点时间把底层结构理清楚，后面所有功能开发都是顺水推舟。
4. 数据库设计：核心表结构与关键字段
4.1 八张核心数据表
整个系统的数据模型可以围绕八张核心表来组织，其他辅助表视具体功能再做扩展。
耗材基础信息表（material_info）是主数据的起点，关键字段包括耗材通用名称、规格型号、计量单位、生产厂家、医疗器械注册证号、耗材分类（低值/高值/试剂）、默认库存上限和下限、是否启用单品追溯标识。这里要特别注意注册证号字段不能省，医疗器械的产品身份就靠它来界定，同样一个产品不同规格注册证号也可能不同，查询时必须用它来筛。
供应商信息表（supplier_info）存储供应商统一社会信用代码、企业名称、联系人、联系方式、经营资质有效期。供应商在入库环节是要被强校验的，资质过期时系统应给出阻断性提示，不允许继续入库，这个合规逻辑要在入库ServiceImpl中写清楚。
入库单主表和入库明细表（inbound_order、inbound_detail）构成入库的父子结构。主表记录入库单号、供应商、入库类型（采购入库/退货入库/调拨入库）、入库总金额、操作人、入库时间；明细表记录每个入库耗材对应的数量、单价、生产批号、生产日期、失效日期，以及是否为高值耗材需生成单品码。入库明细表是批次库存的数据源头，它的字段设计决定了后续批次追踪的精细度。
库存批次表（stock_batch）是核心状态表，每个可用的库存批次在表中都有一条记录，包含耗材ID、批次编号、生产批号、失效日期、当前可用数量、所在库位编码、库存状态（正常/冻结/近效期/已过期）、入库时间。这里我特别推荐增加“可用数量”和“占用数量”两个字段分开维护，而不是只放一个总库存数量。这样做的好处是，当科室申领已经通过但还未实际出库时，可以将数量冻结，避免其他科室把同一批货重复申领走，从机制上预防超发。
出库主表和出库明细表（outbound_order、outbound_detail）管理领用出库，主表关联领用科室、出库类型（科室领用/报损出库/调拨出库）、出库时间；明细表记录每个出库项对应的耗材批次ID、出库数量、单价、目标科室，同时在高值耗材出库时记录患者相关信息字段。出库明细表与库存批次表、耗材基础信息表一起，构成了追溯查询的三表联合基础。
追踪日志表（trace_log）记录每一次耗材状态变更的原始事件，建议字段为追踪编号、关联单据类型与单据号、耗材ID、批次编号、单品追溯码、动作类型（入库/移库/出库/盘点/报损）、操作前数量、操作后数量、操作人、操作时间。这个表只做追加写入，不做更新，是全程追踪的凭证。
预警配置表与预警记录表（warning_config、warning_record）配合定时任务使用。配置表用于设定不同耗材的效期预警提前天数（比如高值耗材提前90天预警、试剂提前30天预警）和库存上下限阈值；记录表则持久化每一次实际触发的预警信息，包括级别、内容、处理状态，避免同一条预警被高频重复提示。
4.2 关键表关系和唯一性设计
从实体关系上看，耗材基础信息表与库存批次表是一对多关系，一个耗材可能对应多个批次；库存批次表与入库明细表是一对多关系，但一个入库明细可能产生多个批次——所以更准确地说，入库明细和库存批次是通过“耗材ID+生产批号”这个组合来关联的。出库明细通过批次ID与库存批次表关联，通过单据ID与出库主表关联。追踪日志表则保留业务单据号的冗余字段，便于按单据反查。
唯一性设计有两个关键点。第一，入库单号、出库单号必须唯一，建议采用“业务类型前缀+日期+流水号”的规则生成，比如RK20250112001，这样在日志和报表中看到单号，不用深查就能识别单据类型。第二，同一批次同一耗材在库存批次表中的组合必须唯一，即用“耗材ID+生产批号+失效日期+供应商ID+库位编码”这些字段组合做唯一索引，防止同一批耗材在相同条件下重复生成多条库存记录，这是很多半成品系统会出现的脏数据源头。
4.3 全程追踪的数据链路实现方式
在数据库层面，追踪链路的路径是固定的：从库存批次表出发，向上关联入库明细表和入库主表获得供应商及采购信息；向下关联出库明细表和出库主表获得科室去向信息；同时关联追踪日志表，列出这个批次所有发生过的时间和操作人。如果细化到单品级，还需要在库存批次表之下增加一个“单品追溯码表”，记录每一个高值耗材小包装的唯一码和当前状态（在库/已出库/已使用/已报废）。
我做一个简化示意，展示追踪查询的核心思路：前端输入一个批次号或者追溯码，后端先定位到批次记录，然后用一个异步方法分别查询该批次的入库来源和出库去向，再按时间线合并展示。这种方式的好处是查询逻辑清晰、易于在页面上做分区展示，坏处是多次数据库查询会放大延迟，所以实践中会对高频使用的批次维度增加一个轻量的索引，比如在trace_log表上建立“批次ID+操作时间”的联合索引，让日志查询不拖慢主流程。
5. 核心功能的编码实现与实操要点
5.1 库存批次追踪的核心代码逻辑
整个系统最核心的查询功能可以想象成这样一个场景：护士长发现科室领用的一批采血针包装有点问题，需要查这一批采血针是哪家供应商供的、什么时间入库的、这段时间发给了哪些科室。这个操作的SQL核心逻辑主要包括按条件定位批次、关联查询供应商和出库去向等步骤。
实际编码中建议把查询拆成两个方法，一个走基础信息查询，一个走流水分页查询，避免单条SQL过于复杂导致难以优化。对于系统来说，查询的可读性和可维护性比“一行SQL搞定”带来的所谓性能更重要，这也是我在实际项目中多次重构查询代码后得出的经验。
5.2 库存扣减与先进先出实现
出库扣减库存是另一个高价值编码场景。先进先出的实现思路是：根据耗材ID查询所有“正常状态且未过期”的批次，按失效日期升序排序，然后逐批扣减。每扣减一个批次前要判断数量是否足够，如果本批次不足则扣减到零后继续取下一批次，同时记录本次出库涉及到哪些批次。
这里有一个细节要特别提示：排序条件不能只看失效日期，还要看入库时间。因为两个不同批次的耗材可能失效日期相同，此时应该先出先入库的那个批次。排序条件应该是“失效日期升序，入库时间升序”。这个小细节不处理好，就会出现同效期批次跨批混乱，给后续追溯带来麻烦。出库操作整体必须放在一个事务方法里，防止扣到一半失败产生脏数据。
5.3 效期预警与库存上下限预警的实现机制
预警模块最常用的实现方式是SpringBoot内置的定时任务加注解驱动。配置一个固定的扫描频率，比如每天凌晨执行一次效期扫描和库存扫描。
效期预警的规则按耗材分类差异化管理。对低值耗材，失效前30天开始预警；对检验试剂，失效前60天开始预警，因为试剂类耗材对效期极其敏感且涉及检验准确性；对高值耗材和植入性耗材，建议提前90天预警，因为涉及全流程召回风险，越早介入越好。预警生成时自动去重，逻辑是检查预警记录表中是否存在“同批次同耗材同级别且状态为未处理”的记录，如果存在则不再重复生成。这个去重逻辑非常重要，否则定时任务每天跑一次就会产生大量重复预警，几天不处理，首页就会被预警红点堆满，预警功能就失去了意义。
库存上下限预警则比较简单：统计每个耗材当前所有批次可用数量之和，与配置表中的上下限值相比，低于下限或高于上限时生成预警。设置上下限可以参考耗材的月度平均使用量和采购周期，比如一个耗材月均用量为1000，采购周期为7天，那么安全库存可以粗略设置为“日均用量×采购周期×安全系数”，安全系数取1.2到1.5，这样能有效避免临床断货。
5.4 高值耗材一物一码的实现建议
高值耗材的单品管理，建议在库存批次表和追踪日志之间增加一张独立的“单品追溯码表”（material_unique_code）。入库时按数量循环生成对应数量的唯一码，建议生成规则为“分类码+日期流水+随机数”，并支持批量导出打印功能。每次出库时，操作员扫描包装上的唯一码，系统自动标记为“已出库”并关联出库单号和患者信息。
这里涉及一个实际的编码难点——如果二维码打印后识别率不高，临床科室会直接放弃扫码，回到手工记录。所以编码层面要同时支持两种输入方式：扫码枪录入和手工输入追溯码。我曾经在现场见过因为扫描枪接口配置不当导致扫一个码需要等三秒的情况，这在实际场景中是不能接受的。复盘后发现问题出在扫描枪的输入模式和浏览器焦点冲突上——解决方案很简单，把扫码输入框固定设置为自动聚焦，并监听回车结束输入，配合本地校验，整体响应速度就能控制在一秒内。
5.5 前端交互与报表呈现的经验
前端部分，表格页面建议通用化设计：列表查询条件放在页面顶部，主表格展示数据，操作列放按钮，表单页用抽屉或者弹窗承载。耗材管理系统的用户大多是医院工作人员，年龄跨度大、计算机操作水平参差不齐，界面的信息密度不能太高，关键标签和状态要有明显的颜色区分，比如近效期批次标黄、过期批次标红、正常批次标绿。这个投入虽然不起眼，但对系统实际接受度的影响非常大。
报表模块除表格外，建议引入一个通用图表组件库（比如ECharts）。常用的可视化报表包括科室领用排行柱状图、耗材品类分布饼图、月度出入库趋势线图。在设计报表接口时，建议后端直接返回汇总数据而非原始流水，在前端做图表展示时更直观，也减少了浏览器端的数据计算压力。
6. 常见问题与排查技巧实录
6.1 并发领用导致超发，该怎么处理
曾经在系统测试阶段遇到过这样一起问题：两个科室同时提交了对同一批高值耗材的领用申请，系统校验时都显示库存足够，但实际出库时发现库存不够用了。这个问题的根因是典型的并发操作下“检查-再操作”不是原子性动作。
解决思路有两个层次。第一层是数据库层面加锁，在扣减库存的SQL语句中使用显式的行级锁，把目标批次的记录锁住，确保同一时刻只有一个事务能够修改该批次库存，从机制上避免超发，代价是会稍微增加并发等待时间，但医院场景下这个代价完全可接受。第二层是业务层冻结机制，科室提交申领后，系统先把所需数量在“占用数量”字段中冻结，库房确认出库后才扣减“可用数量”，同时释放冻结量。如果申领单被拒绝，则直接解冻。用“可用数量”和“占用数量”两个字段配合，即使并发量再大，超发风险也会大大降低。双管齐下的方式我在多个项目中验证稳定，值得直接采用。
6.2 批次追溯查询慢，索引该怎么优化
追溯查询模块在数据量增长到一定级别后可能会出现明显的卡顿，特别是在查询某个热点耗材的整条流转时间线时。排查的第一步就是看慢查询日志，定位到具体SQL后，用数据库执行计划分析工具查看走了哪个索引。
针对这个业务场景，最适用的索引策略集中在三个方向：耗时长的追溯查询主要在库存批次、出库明细和追踪日志三张表之间关联，批次ID是连接核心，必须建立在出库明细和追踪日志上都有批次ID的索引；按时间和科室筛选是所有查询的常见前缀条件，出库明细表上的“出库时间+目标科室”联合索引非常有必要；状态字段因为存量数据中状态值分布极不均衡，大量数据是“已出库”，单独建索引效果不佳，建议在联合索引中带上需要过滤的状态字段，而不是单独建索引。经过这三步调整，追溯查询基本能在秒级完成，满足现场演示和日常使用的要求。
6.3 效期预警不生效，常见的原因是什么
预警功能开发完成后自测时发现一个问题：明明有耗材临近效期，但首页预警列表就是没有数据。排查日志发现，定时任务已经正常执行了，但预警生成条件中的日期比较逻辑写反了。这是一个非常经典的低级错误——在判断有效期时搞混了日期先后顺序，导致扫描时把大量正常批次的耗材当成预警对象，或者反过来把所有预警对象排除在外。
另一个容易出的问题是时区或者时间精度不一致。有的数据入库时保存的是日期格式，有的保存了完整时间戳，比较时不做格式化统一，就会出现“今天到期的耗材没有被识别出来”的情况。建议在预警扫描的查询条件中统一使用当天零点作为比较基准，将失效日期大于等于当前日期且小于等于预警触发日期的数据筛选出来，再配合预警记录表去重，就能保证每天只产生有限且准确的新预警。
6.4 现场部署时最容易忽略的配置项
系统部署到医院环境时，有件容易被忽略的事是服务器时间同步。如果服务器时间不准，定时任务执行时间、效期计算结果都会跟着出偏差。务必确认主机已经配置了时间同步服务，这是最基础也最重要的一项。
另一个是Tomcat/嵌入式容器的最大上传文件大小配置。医院耗材入库时，很多操作员会直接把供应商发来的电子发票、随货同行单拍照上传，如果SpringBoot应用没有显式配置上传大小限制，超过默认值就会报错，现场操作人员会误以为系统有问题。建议在配置文件中明确设置上传大小上限，并在前端做对应的文件大小校验。数据库连接池的参数也要重视，特别是最大连接数和等待超时时间，医院库房上班高峰期操作密集，连接池配置过小容易出现连接获取超时，这一点可以在压力测试阶段提前暴露。
7. 项目复盘与可扩展方向
限于篇幅，这套系统的很多细节没法一次性铺开讲，但整体框架搭起来之后，后续扩展的方向是非常清晰的。如果医院要提升自动化程度，可以对接SPD供应链管理系统的耗材柜，通过接口自动扣减库存并生成补货申请；如果要跟收费系统打通，高值耗材的使用记录可以在手术计费后自动生成消耗记录，减少护士手工二次录入；如果要做更精细的效期管理，可以在预警规则中增加“按批次实龄自动计算剩余有效期百分比”的逻辑，让管理颗粒度更细。
从我个人的实际体会来说，做这类系统的价值不只是把它做出来能运行，而是在这个过程中把业务链条上的每一个环节都摸透了。数据库设计阶段多花一天，编码阶段就能省下三天；事务边界划分清楚，线上排查故障时就不会手忙脚乱；追踪链路的设计从“能用”提升到“好用”，靠的是对使用场景的反复换位思考。最后分享一个实实在在的建议：如果正在规划这个题目，动手前务必先去目标医院或者身边有医疗资源的朋友那里要一份真实的耗材出库单和库存盘点表，照着真实单据设计功能和字段，比闭门造车看十篇论文都管用。
