医疗废弃物收运这件事以前在很多医院信息科的人眼里是边缘系统做好了不被看见做不好一旦出问题就是环保督察和院感两条线的双重问责。但这两年情况完全变了从《医疗废物管理条例》到各地卫健委对医废闭环管理的硬性要求再加上互联网监管平台的普及一套能跑的收运管理系统已经从可选变成了刚需。我去年完整做了一个基于Spring Boot的医疗废弃物收运管理系统从需求调研到上线运维都走了一遍今天把这套系统的设计思路和实现细节整理出来希望能给正在做同类项目的同行一些参考。这个项目本质上解决的是三个问题医废从产生、暂存、收运到处置的全流程可追溯各环节责任人的交接留痕以及跟监管平台的数据对齐。技术上的核心载体是Spring Boot配合MyBatis-Plus操作数据库、Redis做缓存和扫码校验、WebSocket推送实时任务。适合正在做医疗信息化、智慧后勤类项目的开发团队也适合拿这个方向做毕业设计或者毕业项目的同学——这个题目的业务边界清晰既有管理流程又有硬件对接做出来以后无论是答辩还是实际落地都有东西可讲。1. 项目背景与业务需求拆解1.1 医疗废弃物收运的业务现状与痛点医疗废弃物和普通生活垃圾有个本质区别它具有感染性、毒性等危险属性一旦脱离监管流向不明后果非常严重。过去大多数医院的收运流程是这样的科室护士把医废扔进黄色垃圾袋保洁员定时过来收走推到暂存间再由外部处置公司拉走焚烧。这中间有大量环节依赖纸质交接单签字、称重、登记全凭自觉出了问题很难追溯是哪一环丢的。我调研过一家三甲医院的实际数据他们每天产生医废约800到1200公斤涉及到临床科室、检验科、手术室、病理科等几十个产废点每天收运车次在15到20趟次。纸质单据模式下月底对账要翻一厚摞单据而且经常出现重量对不上、签字漏签、暂存间库存不清晰的情况。这就是这个项目要解决的第一个核心问题把传统的纸面留痕变成数据留痕。另外一个痛点来自监管侧。现在很多省的卫健委都建了医疗废物监管平台要求医疗机构定期上传收运数据包括产废量、交接时间、处置去向。如果是纯手工台账每月整理上报材料就要花掉后勤部门好几天时间。所以这个系统在设计之初就把数据导出和接口对接作为一等公民而不是后期补丁。1.2 系统角色与核心业务流程梳理做系统设计之前我习惯先把角色画清楚。医疗废弃物收运管理系统的核心角色有六类系统管理员、科室护士产废端、收运人员医废转运工、暂存间管理员、处置公司运输司机、医院管理层。不同角色关心的数据粒度完全不同。科室护士只管我这个科室产生了多少、什么时候被收走的收运人员关心今天要跑哪几个科室、每个点位的袋数和重量是多少暂存间管理员关心库里还有多少、哪些已经超过48小时了管理层则要看到趋势性数据。系统中所有的权限设计和页面功能都是沿着这些角色诉求展开的。业务流程上典型的一次收运闭环是这样的收运人员登录App端查看今日任务列表推车到科室暂存点扫码识别科室条码和医废袋条码逐一称重录入电子秤数据双方护士和收运员在PDA上签名交接任务完成后数据自动同步到后端生成电子联单。医废进入暂存间后再次扫码入库出库交给处置公司时打印五联单并关联运输车辆信息。这个流程里每一步的状态流转都是在系统里实时记录的任何一步不完成下一个环节就没法启动。这套流程说白了就是把原来的线下SOP搬到了线上但搬的过程中不是简单照抄而是把关键节点做了强制校验。比如护士签名没有签收运员就无法提交这个科室的任务电子秤重量小于1公斤会提示确认医废袋在暂存间超过48小时会自动触发预警。这些强制规则才是系统真正的价值所在。2. 技术选型与整体架构设计2.1 为什么选Spring Boot作为基础框架聊技术选型之前先说结论这个项目用Spring Boot 2.7.x完全够用而且是目前同类系统中性价比最高的选择。原因有三个。第一是生态成熟Spring Boot经过这么多年的迭代各种中间件都有非常成熟的Starter集成方案Redis、MyBatis-Plus、WebSocket、定时任务这些都是加依赖就能用不需要自己造轮子。第二是团队上手成本低做医疗后勤系统的开发团队通常不是大型互联网团队Spring Boot的约定优于配置能显著降低团队协作时的理解成本一个刚进组的Java开发看Spring Boot项目很快就知道controller、service、mapper该往哪放。第三是部署运维方便Spring Boot自带内嵌Tomcat打包成jar就能跑这在医院内网环境里非常实用不用单独去装应用服务器。有些同行会纠结要不要上Spring Cloud微服务我的建议是别上。这个系统的并发量撑死不过几百人同时在线微服务拆分引入的分布式事务、服务治理、链路追踪等问题反而会淹没核心业务的开发精力。单体应用加合理分层配合Redis处理热点性能和可维护性都完全能打。架构的复杂度应该跟着业务走不是跟着概念走。2.2 总体架构与代码四层组织方式我采用的是典型的Spring Boot四层架构Controller层、Service层、Mapper层、Domain层。这个分层方式在互联网上讨论很多但真正落地时很多人容易把层和层之间的职责搞混。我的划分原则是这样的Controller层只做参数接收、格式转换和结果返回不在里面写任何业务逻辑一个方法只对应一个接口动作。Service层承载全部业务规则和事务控制比如收运任务的状态机流转、库存台账的增减、电子联单的生成。Mapper层对应MyBatis-Plus的BaseMapper接口只做数据持久化复杂的多表查询我倾向自己写XML不用MyBatis-Plus的LambdaQueryWrapper硬拼。Domain层放实体类、枚举、DTO、VO特别注意Entity和VO一定要分离我见过太多人直接把数据库实体扔给前端结果字段暴露了一堆不应该暴露的东西。举一个具体例子。收运记录列表页前端需要的字段是收运时间、科室名称、收运人、袋数、总重量、状态。如果直接返回MedicinalWasteTransport实体里面会带着数据库自增id、创建时间、更新时间、逻辑删除标记这些内部字段。所以我一定会定义TransportRecordVO在Service层做一次转换。虽然代码量稍微多一点但接口的稳定性和安全性明显更好。目录规范也很重要我习惯按业务模块分包而不是按技术类型分包。就是com.hospital.mwms下按controller/er、service/er、mapper/er这样组织而不是把所有controller堆在一个包里。收运、暂存、库存、预警、系统管理这些模块的代码互不干扰后期维护定位问题会快很多。2.3 数据库表结构的设计思路数据库设计是这个系统最见功力的部分。我前前后后设计了二十多张表核心的几张表有必要单独说明。科室产废点表waste_produce_point记录了每个点位的基本信息包括所属科室、所在楼层、条码编号、负责人、联系电话。这里注意一个细节条码编号要有规则我的规则是楼栋号-楼层-科室序号比如3-5-12表示3号楼5层12号产废点方便现场人员肉眼识别和排查问题。收运任务表transport_task是业务流程的主线。每次收运人员去科室收医废都会生成一条任务记录字段包括任务编号、收运人id、科室id、计划收回时间、实际完成时间、状态。任务编号我用日期加序号yyyyMMddHHmmss加四位随机数保证并发情况下不会重复。关键的一张表是医废袋明细表waste_bag_detail每个医废袋从产生到销毁都有独立记录。字段包括袋条码、类型感染性、损伤性、病理性等、重量、科室id、收集时间、收运人id、交接状态、入库时间、出库时间、处置公司id、处置时间。这张表承载了全生命周期追溯的核心需求我给它建了复合索引(科室id, 交接状态, 入库时间)日常查询效率实测很好。库存台账表我做了两张一张是暂存间库存表storage_inventory记录当前实物库存另一张是库存流水表storage_stock_flow记录每一次入库出库的增减明细。为什么要拆成两张因为库存流水是审计追踪的基础如果只维护一个库存总数一旦数据不对根本查不出是哪个环节出了问题。库存流水表写入后不更新、不删除只追加这是保证可追溯性的基本纪律。这里还要提一个很容易踩的坑不要直接在数据库里存照片和签名的二进制大对象。我的做法是上传到服务器文件目录数据库只存文件路径。医院内网环境带宽有限医废交接时的电子签名图片一张也就几十KB直接在表里加个varchar字段存相对路径就够了千万不要用longblob。3. 核心功能模块设计与实现3.1 用户权限与组织架构管理这个系统涉及多个科室多个角色权限设计的严谨程度直接关系到医疗废物的管理安全。我采用的是RBAC模型基于角色的访问控制基础数据表是用户表、角色表、菜单权限表、用户角色关联表、角色菜单关联表。Spring Boot结合Spring Security框架来做认证和授权JWT做无状态Token。为什么不用Session因为医院环境里用户可能从PC端、PDA端、手机端多个入口登录无状态的JWT在跨端场景下更友好而且后面如果要对接医院统一的单点登录JWT的改造空间也更大。JWT的密钥我建议放在Nacos配置中心里不要写死在代码中运维那边方便定期轮换。权限粒度上除了角色控制菜单访问页面内的操作按钮也要做权限控制。比如普通的收运人员只能看到扫码收运、我的任务这些菜单不能看到基础数据维护科室护士能查看本科室的产废记录但不能修改历史重量。这个在实现层面就是给每个按钮绑定一个权限标识后端接口用PreAuthorize注解校验。实际部署的时候我发现一个问题医院的保洁人员和收运人员流动性较大人员账号的开通和禁用要做得足够简单。我的方案是支持Excel批量导入用户管理员下载模板填好姓名、手机号、所属科室、角色上传后系统自动生成账号初始密码统一为手机号后六位且首次登录强制修改。这样后勤管理员每周花十分钟就能维护完人员变动。3.2 收运任务调度与路线管理收运任务调度是这个系统比较有业务深度的模块。大型医院每天产生几十个收运任务如果不做规划收运人员满院跑效率非常低。我的做法是把产废点按照科室物理位置和产废量进行路线分组收运人员启动App后系统按分组自动下发当天任务清单。实现上每组产废点维护一个路线编号route_code收运人员绑定到固定路线。收运人员在App上点击开始收运后系统会显示这条路线上的产废点列表按照预设顺序排列。每到一个点位扫码完成收运列表中的该点位状态变为已完成整个路线的完成进度实时反馈。调度策略上我用了一个比较务实的方案优先基于固定班次辅以临时任务。固定班次是每天上午一次下午一次的常规收运这个靠后台定时任务在每天凌晨生成当天任务临时任务是某个科室医废量突增或接到临床科室电话后调度员在后台手动创建任务并指派给在线收运人员。App端通过WebSocket接收新任务通知实测下来基本两三秒内就能收到推送。路线的规划设计其实有算法可以做比如用TSP旅行商问题模型优化最短路径但在实际场景中收益有限因为医院内部路径不是透明的物理距离电梯等待时间、洁净区隔离要求这些因素算法很难建模。所以我的建议是让后勤主管在后台手动配置产废点的路线归属和顺序系统做好记录和提醒就够了不需要在这个点上过度设计。3.3 条码管理与扫码交接环节条码是这个系统追溯链路的唯一身份标识它的管理质量直接决定了整个追溯系统的可信度。系统用Code128编码生成医废袋条码一维码即可满足需求没必要上二维码——现场扫码枪和PDA对一维码的支持最稳定。条码打印设备用的是医院常见的佳博标签打印机耗材是40mm乘20mm的三防热敏纸。每卷标签纸都有编号印刷时由系统控制打印机按批次输出每次打印都会同步在数据库中登记条码号和打印时间、打印人确保每一个条码都有来源记录。条码分配策略上我的设计是一袋一码。科室护士领用标签后扫码即自动关联到当前科室不需要在PC端做任何预绑定操作。这样做的好处是取消了过去先领标签再和科室绑定的中间步骤减少了人为操作遗漏。护士在产废时贴好袋子等收运人员来了之后用PDA扫袋码和台秤上的重量联动数据就记录到系统里面了。扫码交接是医废收运的关键节点双方确认是硬约束。收运人员在PDA上扫描袋码后系统自动弹出该科室和袋码信息收运员录入实际称重克数精度到克然后需要护士本人的电子签名确认。签名是在PDA的触摸屏上手写的保存为图片并和收运记录关联。护士确认之前这个袋子在系统中是待交接状态数据不允许被修改。这套机制运行下来科室之间的重量纠纷少了很多因为每笔数据都能回溯到对应的签名。3.4 重量录入与电子联单生成重量数据是医疗废物管理的核心数据之一涉及汇总统计和费用结算所以录入的准确性和防作弊很重要。我的电子秤对接方案是RS232串口通信。PDA通过OTG线连接电子秤电子秤的重量数据通过串口实时读取PDA扫码后在输入框显示当前重量收运员点击确认即可完成录入不支持手工直接填重量支持按需微调但会有日志记录。这个设计从源头避免了估重和手误录入的问题实测称重数据和台账数据的偏差率控制在0.5%以内。为什么不用蓝牙秤因为医院内的无线环境复杂蓝牙干扰源多而RS232串口通信稳定且不需要配对开箱即用。安卓PDA的串口通信用UsbSerial库就能搞定网上资料很多踩坑点主要是部分PDA的USB模式需要手动切换为串口模式而不是充电模式这个在设备选型时就需要注意筛选。电子联单是这个系统对接监管要求的重要输出。当一车医废从暂存间出库交给处置公司时系统会生成一张五联单内容包括车牌号、驾驶员信息、医废类别、袋数、总重量、出库时间、暂存间管理员签名、运输司机签名。这张联单可以PDF格式导出也可以直接对接打印。五联单的数据同时写入台账作为后续对账的重要依据。联单编号的规则是年份加六位流水号比如2024-000126每年重置。3.5 预警监控与统计报表医疗废物处置有明确的时间要求比如暂存间内的医废原则上不超过48小时这就要求系统具备超时预警能力。预警模块我实现了三种类型库存超时预警、重量异常预警、收运延迟预警。库存超时预警是核心功能后台每分钟跑一次定时任务扫描暂存间库存表把入库时间超过48小时的记录找出来通过WebSocket推送给暂存间管理员和后勤主管同时在PC端的预警中心显示醒目的红点。重量异常预警针对单袋重量明显偏离正常范围的情况比如感染性废物正常重量区间是1到5公斤超过上下限自动标记为可疑数据防止空袋入库类的异常。收运延迟预警是指一个收运任务超过计划时间2小时还未完成系统自动发短信给调度员。统计报表是管理层最关心的模块。我实现了日报、周报、月报三个粒度的报表核心指标包括各科室产废量排行、各类型医废占比、收运及时率、暂存间周转时间。报表用ECharts做图表展示也支持导出Excel。月报数据可以直接用于向卫健委监管平台报送行政人员再也不用对着Excel手工做表了。技术上讲统计报表用MySQL的聚合查询就能搞定但要注意数据量上来之后的查询性能。我做了两张汇总表日统计表waste_daily_stat和月统计表waste_monthly_stat每天晚上由定时任务从明细表聚合数据到汇总表。前端报表页面只查汇总表不扫明细表查询速度稳稳的。明细数据则永久保留用于反查溯源。4. 关键环节实操过程与实现细节4.1 收运任务派单闭环的代码实现收运任务的闭环是这个系统的主线程我把这个流程的代码逻辑完整走一遍。第一步是定时生成任务。我用Scheduled(cron 0 30 6 * * ?)每天凌晨六点半执行任务生成函数查询所有启用状态的产废点为每个产废点生成一条当天的收运任务初始状态为待收运。生成任务的代码要记得加幂等控制我的方法是查一下当天是否已经存在该产废点的任务记录存在则跳过防止定时任务被重复触发后产生脏数据。第二步是任务派发。任务生成后并不绑定具体收运人而是等待收运人员在App端点击领取任务来认领。为什么不是管理员指派因为医院的收运班组排班经常临时调整让现场人员自助认领更加灵活。收运人员认领后任务状态变为进行中后台记录认领人id和认领时间。第三步是执行收运。收运人员到达产废点后PDA上展示该点位关联的所有待交接医废袋列表。用户逐袋扫码每扫一个袋子系统会先校验这个袋子的状态是否为已出库待交接也就是科室护士在产生时扫码登记的初始状态校验通过后进入称重环节。重量确认后收运人员填写收集时间默认当前时间点击提交任务提交的Service方法是在一个Transactional事务里完成的同时更新袋明细状态为已收运插入一条收运记录更新产废点的当日统计信息。第四步是暂存入库。医废拉回暂存间后收运人员再次扫描每个袋码入库操作会更新袋明细中的暂存间id和入库时间同时往库存流水表插入入库记录更新暂存间的库存总数。这一步是事务操作务必保证袋明细、库存流水、库存总数三者的强一致。这里要提醒一个我踩过的坑事务方法内部不要调用同类中的其他方法因为Spring的事务是基于AOP代理的同类内部调用不会经过代理对象Transactional注解会失效。我的习惯是把任务流转相关的更新操作都写在同一个Service类里但涉及跨表多步写入时拆成独立的事务方法并从Controller层调用或者用一个聚合Service来编排。4.2 扫码高频场景下的并发幂等处理医废收运有个特点就是下班前的一两个小时是收运高峰多个收运人员几乎同时在扫码提交。在这个场景下如果不做并发控制很容易出现重复提交和数据不一致的问题。我遇到的一个真实案例收运员小张在3号楼同时扫描了两个科室的袋子同一个袋子在极短时间内被提交了两次结果袋子的状态被更新了两次库存流水里出现了两条重复的入库记录。排查后定位到原因是PDA的网络请求超时用户以为提交失败又点了两次而后端两次都处理成功了。解决这个问题我用了两个手段。第一个是前端防重PDA上提交按钮在请求发出后立即置灰等到后端响应后才恢复并且对同一个袋子在30秒内不允许重复提交同一个操作。第二个是后端幂等我给收运记录表加了唯一索引waste_bag_id operation_type task_id在插入时如果发生唯一键冲突直接捕获异常返回该操作已提交请勿重复操作的提示而不是抛出一个让App端白屏的数据库异常。对于库存流水表同样加了业务唯一键bag_id before_status after_status从数据库层面挡住并发重复。我在设计库表的时候习惯给关键业务操作设计一个天然的幂等键这比在代码里面用分布式锁要简单可靠得多。4.3 电子签名与图片存储的最佳实践电子签名是医疗废物交接的法律凭证我在存储和校验上花了些心思。PDA端采集签名使用的是Android的SignatureView控件用户书写完成后压缩为JPEG图片质量设为85%宽度限制在800像素内实测一张签名图片约30KB。图片通过HTTP接口上传到后端后端将文件保存到配置的上传目录并按年月/签名时间戳_随机数.jpg的路径命名避免同一秒内并发上传导致文件覆盖。数据库中的收运记录表只存储这个路径字符串。文件存储目录需要提前规划好并确保磁盘空间充足。医院内网服务器通常是单机部署这个项目的数据量一天也就增长几十MB一张500GB的硬盘够用几年。但如果后续要对接云端或者做负载均衡就需要把文件存储迁移到对象存储服务或者统一的文件服务上数据库里的路径结构保持不变迁移时只需要同步文件并在配置中心切换访问域名。重要提醒签名图片不要直接放行给非授权人员访问。我在后端写了一个专用的文件访问Controller先做登录鉴权和文件名合法性校验防止路径穿越攻击然后通过FileSystemResource返回文件流。文件名必须校验正则只允许数字、字母、短横线和下划线、点防止用户构造带斜杠的路径去读取服务器上的其他文件。4.4 对接外部监管平台的数据上报接口跟卫健委监管平台对接是医院刚需也是项目验收时的加分项。虽然各地的监管平台接口规范不同但大体上都是数据格式以JSON为主走HTTP POST请求。我的对接方案是写一个单独的上报适配模块。模块中定义了通用的上报数据模型包含收运批次号、产废点名称、医废类别、袋数、总重量、交接人、交接时间、运输车辆等信息。考虑到监管平台的接口可能因为升级而调整我把上报逻辑和业务逻辑隔离得很干净——业务数据落库后通过事件驱动触发上报用Spring的事件发布机制上报失败后不会影响主业务流程只是记录失败日志等待重试。重试机制我用了一个简单的定时任务来处理每十分钟扫描一次上报失败记录表把失败原因不是报文格式错误这类问题重试也没用的记录重新上报。为了防止对监管平台造成请求压力重试设置了最大次数默认5次超过后标记为人工处理并在后台提供一个手动重报的按钮。接口对接还有一点容易被忽视安全性。监管平台的接口通常要求使用白名单IP、数字证书或者Token认证。我在对接时发现有些平台在HTTP Header中传递凭证那么项目里就必须用RestTemplate或HttpClient设置好超时时间避免网络抖动导致请求悬挂占用线程池。超时时间我的设置是连接3秒、读取5秒实测这个配置在医院内网带宽下是合理的。5. 常见问题与排查经验实录5.1 PDA扫描枪扫码没有反应这个问题在项目上线初期非常频繁。排查下来主要原因是PDA的系统设置问题部分PDA的扫描头默认关闭需要在系统设置中把扫描头电源打开或者在某些设备上需要先按一下侧键唤醒扫描头。第二次类是USB外接扫码枪的情况需要确认扫码枪的USB模式设置为键盘模式而不是HID模式否则数据无法正常输出到输入框。我的处理办法是测试团队用三款不同的设备国内几个主流PDA牌子跑了一遍把扫码枪的初始化步骤写在项目操作手册里并在PDA的固定位置贴了简易操作指引。这个看起来很小的问题处理不好会让一线的收运人员觉得系统很难用所以一定要提前验证设备兼容性。5.2 收运数据提交后消失了用户反馈说在PDA上提交成功的收运数据在后台列表里看不到。我查了日志后发现是PDA端和后台的时间不一致导致的。PDA的系统时间被设成了空指针时间或者说设备重启后时间重置了提交时请求头里的时间戳和服务器当前时间相差太大被后端的接口签名校验拦截了数据其实根本没有落库但PDA端由于没有做好响应处理误以为提交成功了。这个问题的解决措施有两层。第一层是在PDA端增加时间校准逻辑每次登录App时向服务器请求当前时间并进行本地校正避免设备时钟漂移。第二层是在后端做兼容处理如果请求头时间和服务器时间差超过5分钟就返回特定错误码App端根据错误码提示用户校准设备时间而不是一律返回200成功。这也是一个很典型的前后端联调问题务必在模拟环境里提前测试。5.3 报表数据对不上第二个多月的时候后勤主管找我说日报表里的总重量和实际称重台账差了十几公斤。我排查后发现是重复计重的问题。原因是部分科室的医废袋在收运人员扫码后由于电子秤读数不稳重量被PDA读取了两次而后台去重逻辑没有覆盖到这种场景。查清楚原因后我在袋明细表加了一个重量快照字段在提交时记录电子秤的稳定读数并且提交接口中加入了一个30秒内同一袋子仅允许提交一次的业务校验。如果重量读数波动较大PDA端还会弹出重量异常请重新称重的提示。这里也反映出一个经验凡是牵扯到电子秤之类的硬件数据一定要在采集端做稳定性处理不能把原始数据直接透传到数据库。5.4 系统运行卡顿和慢查询优化系统上线一段时间后收运记录表的数据量很快突破了几十万条部分查询页面开始变慢特别是按科室和时间段查收运记录时响应时间一度达到了6秒以上。排查后发现两个主要原因一是部分查询没用索引比如按收运人姓名模糊查询这确实造不了索引二是列表页默认会加载近三个月的数据数据量太大传输耗时。优化的方案第一是在关键字段上建好复合索引比如收运记录表收运时间、科室id、状态三列复合索引效果立竿见影。第二是列表页的默认查询时间缩短为最近7天并且后端做分页查询页面上显示共xxx条记录这是第x页禁止一次返回全量数据。第三是把收运统计汇总逻辑从实时聚合改成每日定时任务预聚合查询只走汇总表。优化后列表页响应时间降到1秒以内报表页也基本能秒开。6. 部署与运维的实用建议6.1 服务器方案与部署结构医院内部的服务器资源通常不会太充裕这个系统我用的是单台服务器部署配置是4核8G内存CentOS 7系统。核心部署组件包括一个Spring Boot的jar包一个Nginx做反向代理和静态资源服务一个MySQL 8.0实例一个Redis单机实例。内网环境有时无法访问外网所以提前把所有依赖的Maven仓库做成了离线包安装部署时直接本地安装。Spring Boot的jar包外部化配置文件放在/opt/mwms/config/application.yml可以通过--spring.config.location指定外部配置位置确保升级应用包时不需要重新打配置。Nginx配置里需要把上传文件目录的访问代理到对应的Controller接口同时配置好请求体大小限制我设置为20M因为PDA偶尔会传稍微大一点的图片。6.2 数据备份与恢复演练医疗数据的备份要求比其他行业更高。我设置了每日凌晨全量备份、每4小时增量备份两个策略。全量备份用mysqldump导出SQL文件压缩后保留30天增量备份用binlog通过脚本定期将binlog同步到备份目录。但是我一定要强调一点光有备份策略还不够必须定期做恢复演练。我曾在测试环境做了一次模拟恢复结果发现备份文件在导出时没有加--single-transaction参数导致备份期间的数据不一致恢复时校验失败。当然后续修复了这个问题。恢复演练能发现备份策略里隐藏的问题这个工作平时不做真到了灾难发生时就是大事故。6.3 日志监控与告警系统上线后我就把日志接入到了日志文件中按照日期切割保留90天。但我发现只靠人工看日志效率太低所以加了一个简单的告警机制写了一个Shell脚本每五分钟扫描日志文件中是否有ERROR级别的异常如果有就通过医院内部的短信接口发送告警短信给开发负责人。告警关键词我做了过滤像SQLIntegrityConstraintViolationException这类已知的偶尔业务冲突异常会自动忽略避免频繁骚扰。同时也过滤了Druid连接池初始化这种启动时容易出现的正常日志。这类规则在脚本里维护起来不难但需要根据实际错误不断优化否则报警太频繁就没人看了。医疗废弃物收运管理系统的开发难不难单看技术点确实不难Spring Boot加MyBatis-Plus加Vue都是Web开发的常规组合。但难就难在对业务的理解深度和现场环境的适配能力上。在我实际做下来的过程中最大的体会是这类系统的价值不在于用了多新的技术栈而在于能否把闭环流程真正跑通让每袋医废从产生到处置都有据可查让管理者打开系统就知道今天全院几百个产废点的状态。如果再去规划这个项目我会从一开始就把与监管平台的接口对接放在更重要的位置因为那才是系统的长期生命力所在。最后分享一个项目验收时的小技巧准备一个全流程演示数据模拟从科室产废、扫码收集、称重交接、暂存入库、出库联单到报表生成的全过程让演示在五分钟内走完。这套演示脚本能让评审人员和客户在最短时间内理解系统的价值也会让整个项目显得非常成熟和完整。
