医院设备科最头疼的不是设备坏了而是坏了之后那一套流程用手写报修单、打电话找人、翻Excel查设备档案、维修完再手写记录。更麻烦的是保养计划靠人工盯日历漏了就是安全隐患。我参与过的这套基于SpringBoot的医疗设备维护平台就是要把这套线下流程搬到线上用一套统一的数据模型把设备台账、维修工单、保养计划、巡检任务、备件耗材全部串起来。文章里我会把项目的设计思路、核心表结构、关键功能实现和踩过的坑都摊开讲适合三类人看医疗信息化的后端开发、医院信息科的运维工程师还有正在做SpringBoot毕设想找业务场景的同学整套东西拿来就能参考落地。1. 项目概述与业务背景1.1 医疗设备维护的痛点到底在哪先聊业务侧的问题。一台呼吸机从进院建档到报废中间要经历无数次维修、保养、计量检测,每一环都涉及记录。传统模式下设备科用纸质台账登记设备编号、型号、科室位置维修记录散落在各维修工程师的笔记本里报修通过电话或微信发起等设备科想起来要统计故障率时才发现数据根本凑不齐。做这个平台之前我在医院设备科蹲过现场真实情况比想象中更原始报修信息靠科室护士手写设备的品牌型号靠脑子记维修进度靠催。一台CT机停机半天直接影响几十个患者的检查排期而工程师还在路上临床科室根本不知道维修进度只能一遍遍打电话催问。这些痛点归纳下来就三类设备档案不集中、维修流程不透明、保养计划靠人工盯。所以我们做平台的核心目标很明确让每一台设备从入库到报废的状态可查让每一个报修工单的流转进度可追让每一份保养计划自动提前提醒。这也是整个项目最有价值的部分它把原来散落的信息汇聚成一套可查询、可统计、可追溯的数据资产。1.2 为什么选SpringBoot而不是其他框架技术选型上最初团队有过分歧有人建议用Spring Cloud微服务觉得医疗平台将来扩展空间大也有人提出用Python的Django快速开发。我坚持用SpringBoot单体应用起步理由很实际。第一是设备维护平台的用户量不会爆炸。医院设备科加维修工程师也就几十号人并发量按最乐观的估计也就一两百这种量级上微服务纯属给自己找麻烦服务拆分、注册中心、配置中心、分布式事务一套搞下来光运维成本就压死人。SpringBoot单体应用一台服务器一个Jar包就能跑部署简单排查问题也直接。第二是SpringBoot的生态太成熟了。权限管理有Spring Security任务调度有Scheduled数据库访问有MyBatis和JPA文件上传、参数校验、统一异常处理全都有现成方案。团队招人也好招市面上一抓一大把SpringBoot的经验。第三是演进路径清晰。先用SpringBoot把业务跑通将来真要拆微服务了按模块边界切出来接个Spring Cloud Alibaba也顺理成章不会推倒重来。我给团队的结论是单体优先把业务做扎实比什么都重要。2. 平台整体架构与功能模块设计2.1 功能模块全景与设计思路这个平台按角色和使用场景划分核心模块一共六个设备档案管理、维修工单管理、保养计划管理、巡检任务管理、备件耗材管理、统计报表与系统管理。每个模块对应的都是设备科日常工作的一个环节。设备档案管理是整个平台的数据基石。每台设备建立独立档案包含设备编号、名称、型号、生产厂家、所属科室、安装位置、购置日期、保修截止日期、设备状态这些字段。做设计时我们把设备状态用枚举约束住取值只有五种正常、维修中、待保养、已报废、已停用避免录入时出现修好了坏了这类口语化数据。维修工单模块是流程最复杂的部分从临床科室发起报修到工程师接单、维修、验收、归档整整走五步。这里我特意把验收环节独立出来因为医院设备维修必须经过临床科室确认签字否则维修质量没人负责。流程流转用状态机控制状态只能按既定顺序跳转防止跳过验收直接归档这种操作。保养计划和巡检任务我归到预防性维护这一类。设备科的一大职责是定期保养像CT球管、超声探头这些高值易耗件都有固定的保养周期。系统用定时任务每天扫一遍所有设备的保养计划凡是到期前七天自动生成提醒工单推送给工程师。2.2 核心业务流程拆解维修工单的主流程我用一张图在文档里画过这里用文字描述大家也能看得明白。临床科室用户在PC端或移动端提交报修申请填写设备编号、故障描述、紧急程度系统根据设备编号自动带出设备名称、型号、所在科室设备科审核人员判断是派单给院内工程师还是联系厂商售后紧急程度为紧急的工单会在列表顶部标红置顶。工程师接单后上门维修在系统里更新维修进度和解决方案涉及更换配件的从备件库存里扣减并关联到工单。维修完成后提交完工申请临床科室验收人确认后工单关闭。整个流程里每个节点都有时间戳记录谁在什么时间做了什么操作全部留痕这个在后续统计工程师工作量时特别好用。保养计划的关键在于提前量。每种设备的保养周期不一样高压灭菌锅是每月一次呼吸机是每季度一次大型影像设备按半年和一年来。系统在建档时就把保养周期录入定时任务每天凌晨两点扫描把未来七天内到期的设备生成待办保养工单同时推送站内信通知对应工程师。巡检任务更像一张动态清单。工程师按周、按月创建巡检批次系统按设备所在科室自动生成巡检路线每巡检一台设备在手机上打勾拍照留存异常设备一键转为维修工单。这个设计让巡检和维修两个模块间产生了联动避免巡检发现问题后还要手工重新录入一张报修单的重复劳动。2.3 技术选型细节与取舍后端框架SpringBoot我用的是2.7.x版本。这里说明一下2.7版本是2.x系列最后一个稳定大版本SpringBoot 3.0起强制要求JDK 17而很多医院信息科手里还是JDK 8的存量环境为了兼容老版本我锁定了2.7.18。持久层选了MyBatis而不是Spring Data JPA原因是维修工单、统计类报表需要写大量多表联查SQLMyBatis的Xml里写SQL更直观可控。MyBatis-Plus顺手引入单表CRUD和分页查询不用手写SQL开发效率提升明显。数据库用MySQL 5.7这是医疗信息化项目里最常见的版本稳定不折腾。前端选了Vue 2 Element UI后端只提供RESTful接口用JWT做无状态认证。Redis用来存验证码、登录token刷新和热门统计数据的缓存。定时任务直接用Spring的Scheduled没有引入Quartz或XXL-JOB原因还是量级全平台的定时任务加起来不到十个调度频率都是每天或每小时单机跑就够了。整个部署就一台4核8G的服务器前端Nginx托管打包后的静态文件后端直接挂系统服务MySQL和Redis装在同一台机器上。这个配置被认定为过于简陋但事实上撑住了全科室的日常使用高峰期接口响应时间在200毫秒以内。3. 核心数据模型与数据库设计3.1 设备档案表的设计要点设备档案表是平台的一号主数据表字段设计直接决定后面所有模块的查询效率。我的设计是基础字段加扩展字段分开基础字段用固定列扩展属性用JSON字符串存储。固定字段包括设备编号、设备名称、规格型号、生产厂家、设备类别、所在科室、安装位置、购置日期、启用日期、保修截止日期、设备单价、设备状态、备注、创建时间、更新时间。设备编号是业务上的唯一键采用分段编码规则类别码-科室码-序列号比如CT-RM-00017这样光看编号就能判断是CT机还是呼吸机、放在哪个科室。这里有个容易忽略的点设备类别我做了两级分类一级是设备大类如影像类、检验类、急救类、消毒类二级是具体设备类型如CT、DR、超声。这样设计是为了统计维度更灵活一级维度看科室的设备规模二级维度看同类设备的故障率。扩展属性存的是每类设备特有的参数比如CT球的管电压范围、超声探头的频率这些字段不同设备差异太大不适合每个都建列我用一个JSON字段存起来。MySQL从5.7开始支持JSON类型查询时用JSON_EXTRACT也能索引到实用性很高。另外一个关键设计是逻辑删除。设备档案这种核心数据绝不能物理删除一旦误删整个台账就少了审计线索。我在表里加了deleted字段默认0删除操作改写为1所有查询默认过滤deleted0。相应的维修记录、保养记录也做了同样的设计保证数据全生命周期可审计。3.2 维修工单表与状态流转设计维修工单表是流程模块的核心字段设计围绕谁报修、谁处理、什么进度、什么结果来组织。核心字段工单号、设备编号、报修人、报修科室、故障现象、紧急程度、工单状态、指派人、维修工程师、维修方式、故障原因分类、维修结果、实际完成时间、验收人、验收时间、更换配件明细、创建时间、更新时间。工单号用项目前缀加日期加自增序号生成比如WO202407150001好处是每天的单号长度一致人工排查问题时按工单号就能定位到当天的第几单。并发下生成工单号有个坑后面在问题排查章节详细讲。工单状态我用了枚举取值八种待审核、已驳回、待派单、待接单、维修中、待验收、已完成、已取消。状态之间的流转关系用状态机统一管理实现上我用一个Map维护了每个状态允许跳转的目标状态集合流转方法里先校验当前状态是否允许跳转到目标状态不允许直接抛业务异常。这里多说一句为什么状态流转不能直接在前端切换。前端控制状态会有两个问题一是绕过接口直接调数据库改数据状态就不可信了二是状态规则散落在多个前端页面上改一处漏一处。把流转规则收敛在后端一个地方以后加状态或者改流转规则只需要动一处代码。故障原因分类字段我也做了统一维护六级分类硬件故障、软件故障、网络问题、操作不当、耗材到期、其他。这个字段的价值在统计阶段体现半年下来哪个类别的设备最容易出哪类问题一目了然采购部门也能拿着这个数据去跟厂商谈质保条款。3.3 保养计划与巡检任务的数据建模保养计划表的核心是周期与执行记录的关联。表结构三张设备保养配置表、保养计划实例表、保养执行记录表。配置表定义某台或多台同型号设备的保养周期周期单位按月或按季下次应保养日期由程序计算。保养计划实例表是定时任务每天扫描的待办池每台设备对应一条当前周期内的待执行记录包含设备编号、计划开始日期、计划截止日期、计划保养类型、执行状态。定时任务扫描时就是判断计划截止日期减当前日期是否小于七天小于就生成提醒。执行完成后在记录表插入一条完成记录同时把实例表的状态置为已完成并计算生成下一条实例记录。巡检任务的数据模型简单一些巡检批次表、巡检明细表、批次负责人。批次表记录巡检周期、科室范围、开始和截止日期明细表按科室展开具体的设备列表每台设备对应一条明细记录记录巡检结果、照片URL、异常备注。巡检结果异常的明细记录通过一个按钮一键转维修工单转单时把照片和异常备注带过去。数据模型设计阶段我反复强调的冗余策略就是能用加字段解决的查询问题就不要join。像设备名称、所在科室这些字段在工单表里我直接冗余了一份虽然违背了严格的三范式但换来的是列表查询不用连表查询速度提升明显这在数据量只有几十万级别的业务场景里是完全划算的交易。4. 关键功能实现与实操要点4.1 SpringBoot项目搭建与工程目录结构项目搭建用Spring Initializr注意选择Java 8、SpringBoot 2.7.18这两个关键选项。依赖勾选Web、MyBatis、MySQL Driver、Validation、LombokRedis和Security我会建议后续手动引入因为Initializr生成的版本号可能不是最稳定的组合。工程目录我习惯按业务模块分包而不是按技术层分包也就是先建device、repair、maintain、inspect、system、common这些包每个包下面再建controller、service、mapper、entity、dto。这样做的好处是改一个业务功能时所有相关文件在一个目录树里找得到不用跨多个包来回跳。按技术层分包适合小项目一旦业务多起来controller目录下几十个类堆在一起找起来很痛苦。配置文件application.yml里我建议把数据源、Redis、日志级别这些按环境拆分用spring.profiles.active控制。开发环境application-dev.yml连接本地库生产环境application-prod.yml连接正式库。这里有个小坑SpringBoot默认加载application.yml环境配置文件命名必须包含application-前缀加环境名否则profile不生效。工程结构里还要放一个统一的响应体类Result所有接口返回{R code, message, data}结构前端拿到code是200就正常处理否则弹Toast。这个类模板在项目一开始就定好后期所有接口保持一致前端也不用为每一种返回格式写判断分支。4.2 设备档案CRUD与Excel批量导入设备档案的后台管理界面没什么特殊花样就是标准的表格CRUD但有两个功能点需要重点打磨条件组合查询和Excel批量导入。条件查询的难点在于多条件拼接。设备名称支持模糊查询设备类别支持精确查询购置日期支持范围查询三种条件可能有任意组合。MyBatis的Xml里用if标签逐个判断参数是否为空动态拼接SQL片段。这个方案简单可靠但要注意一个常见错误多个条件同时为空时不能用恒真条件WHERE 11来兜底虽然在SQL层面可行但会影响索引使用。正确做法是用 标签自动处理首个子条件前的AND。Excel导入我用的是EasyExcel而不是POI。POI直接操作HSSFWorkbook在数据量大的时候特别占内存几万行数据导入随时可能OOMEasyExcel基于SAX模式边读边解析内存占用低一个量级。导入前先做模板校验第一列必须符合设备编号的编码规则第二列设备名称不能为空逐行校验错误信息收集起来一次性返回给前端让用户一次性看到所有错误行而不是改一行导一次。导入时还需要处理重复问题。设备编码是唯一索引导入一批数据里如果混了已存在的编号直接插库会报DuplicateKeyException。我的方案是导入前先查库里已有的编号集合在内存里比对重复的行标记已存在错误信息。虽然多了一次查询但避免了事务中途异常导致全部回滚的尴尬。4.3 维修工单状态机的工程实现状态机的实现我专门抽了一个工单状态处理类类里定义状态枚举和流转规则Map。枚举里每个状态附带一个code和desc流转规则Map的key是当前状态value是允许跳转的目标状态集合。状态流转的核心方法放在service层用Transactional包裹因为工单状态更新往往伴随多个表的修改比如指派工单时要同时更新工单表、给工程师发通知消息这两个操作必须保证原子性。这里有一个特别容易踩的坑Spring事务加在私有方法上不生效。我以前见过同事把事务注解加在状态机的内部私有方法上调了半天事务一直回滚不成功。正确的用法是事务方法放在public方法上且通过代理对象调用也就是必须从外部进入service方法类内部方法互调是绕过代理的。紧急程度为紧急的工单在流转时还有额外逻辑在状态变更的同一个事务里给对应设备科的负责人发一条短信通知。短信服务我用的是阿里云短信接口封装在common模块里生产环境替换服务商时只需要改这一个封装类。紧急工单设置两小时未接单的话定时任务自动升级给设备科主任这条逻辑是设备科后来强烈要求加的。工单列表的查询有个性能优化点默认只查当月工单历史工单通过时间范围条件按需查询。直接全量查的话运营两年后工单表几十万条数据列表接口会明显变慢。建索引时我在工单表上加了联合索引idx_device_status_time包含设备编号、工单状态、创建时间覆盖了绝大部分查询场景。4.4 定时任务实现保养到期提醒定时任务是整个预防性维护功能的核心引擎。我在SpringBoot启动类上加了EnableScheduling注解然后写了一个MaintainRemindTask类方法上标注Scheduled(cron 0 0 2 * * ?)每天凌晨两点执行一次保养到期扫描。这个扫描任务的逻辑不复杂查所有保养计划实例表中执行状态为待执行的记录取出计划截止日期跟当前日期比较差值在7天内的就生成提醒。提醒动作有两类一类是生成站内信待办另一类是组装短信内容调用短信接口发送给工程师。站内信写进message表短信走阿里云接口两类消息都可以在系统里查历史记录。定时任务这里最容易栽的跟头是单机重复执行。项目如果部署在单机上问题不大但一旦将来扩展成两台服务器负载均衡定时任务每台机器都会执行一遍重复短信轰炸用户。解决方案有三种用分布式锁框架或者用数据库唯一约束做幂等最简单的是加一个开关配置部署时只在指定的那台服务器上把开关打开。项目初期我直接用第三种配置了开关一劳永逸。扫描任务在凌晨两点执行还有个细节这个时间点医院业务基本处于低谷数据库压力小不会跟白天的业务操作争抢连接池资源。如果任务执行时间长我建议在任务开始和结束时各打一条日志记录扫描到的设备数量、生成的工单数量方便第二天早上排查万一漏了哪个科室的保养提醒还能及时补上。4.5 消息通知模块设计消息通知这个功能看起来简单实际设计时还需要分层。我把通知渠道拆成三层站内信、短信、微信公众号模板消息三个渠道通过一个统一的通知服务对外提供接口业务层不需要关心走哪个渠道只要调用notify(userId, title, content)就行。站内信实现最简单插一张message表查询时按接收人ID和已读状态过滤前端轮询未读数。我这里是登录后每隔30秒查一次未读数有更新就弹角标。短信和公众号模板消息都封装成独立的Client短信服务走阿里云公众号走微信开放平台接口各自的配置项都放在配置文件里用ConfigurationProperties绑定。消息内容我用了模板化的方式管理数据库里存了一个message_template表每条记录包含模板类型、模板内容、占位符说明。业务层调用通知服务时传入模板编码和参数Map服务内部渲染成完整文本再发送。这样运营人员可以在后台修改通知文案而不用重新发版后面还避免了硬编码文案在代码库里到处乱飞的问题。通知服务还有一个去重机制同一用户同一业务类型在同一小时内只发一条通知。这个机制的实现是Redis里存一个key结构是通知类型加用户ID加业务ID过期时间设为3600秒存在就跳过发送。维修工单频繁流转时这个机制大大减少了短信骚扰临床科室反馈明显好转。5. 常见问题排查与避坑记录5.1 大事务导致的连接池耗尽上线运行一个月后某天早上设备科反馈系统卡死排查半天发现数据库连接池全部占满。看监控发现有个接口的活跃连接数持续不减最后定位到是导出报表的接口把整个Excel生成逻辑和查询逻辑放在了一个大事务里导出一万行数据时事务长时间持有连接高峰期同时几个导出一来连接池被榨干了。解决的办法是拆分事务边界查询数据不需要事务只有写入操作才需要事务。我把导出接口改造成先查询全部数据到内存然后事务只包裹写入日志的部分耗时操作全部移出事务范围。这个经验之后我在项目里定了条规矩用Transactional注解前先想清楚这个方法里哪些操作真的需要事务不是整个方法无脑加注解。还有一类隐性大事务在循环调Mapper时出现。有人习惯在事务方法里循环调用dao.insert操作几百个循环下来事务一直不提交锁一直不释放。批量插入一定要用MyBatis的foreach或者MyBatis-Plus的saveBatch单批限制在500条以内效率高不说事务持有时间也短。5.2 定时任务执行时间与日志时间差8小时开发环境一切正常部署到生产环境后发现定时任务的日志时间戳比实际时间慢了8个小时附带的结果是保养提醒工单的生成时间全部错位。排查发现是服务器时区默认是UTC而应用里的定时任务调度用的cron表达式是基于服务器本地时间的时钟一岔凌晨两点变成当天的上午十点。解决很简单在启动脚本里加上JVM参数-Duser.timezoneAsia/Shanghai部署脚本统一处理。同时MySQL连接串里也加上了serverTimezoneAsia/Shanghai保证数据库连接时区一致。时间相关问题排查时第一件事就是先确认服务器时区、JVM时区、MySQL时区三个地方是否一致很多时候问题都是这里出来的。5.3 文件上传大小限制导致图片上传失败工程师巡检拍照上传时出现了大图上传失败的问题。SpringBoot的默认上传限制了单文件大小为1MB手机拍的照片动不动两三兆根本传不上去。配置里加了spring.servlet.multipart.max-file-size10MB和max-request-size20MB后解决。但是光改配置还不够Nginx层也有client_max_body_size限制默认1MB同样需要调大。前端上传组件也要注意请求头里的Content-Type用axios上传时如果没设对后端解析MultipartFile时拿到的会是null。逐个排查下来文件上传的问题往往是三层限制同时卡着前端、网关、后端三个地方都要检查。5.4 并发环境下工单号重复生成工单号用SELECT查询最大值再加一的方式在并发场景下会产生重复单号。两个工程师同时提交工单都查到当前最大值都加一后提交的插库直接报唯一索引冲突。解决用的是数据库的原子自增操作单独建一张sequence表生成单号时执行UPDATE sequence SET current_value LAST_INSERT_ID(current_value 1)再查LAST_INSERT_ID()这段SQL保证了并发下取号不重复。这个方案不使用Redis的原因是不想引入额外的依赖点工单号生成本身就在事务里用数据库的原子操作最可靠。如果将来单量再大一两个量级可以换成Redis的INCR命令做号段生成但当前MySQL方案已经足够稳定。5.5 MyBatis动态SQL的常见陷阱动态SQL里我踩过的坑收集一下。第一个是if标签里判断字符串相等注意用单引号包参数值双引号在某些MyBatis版本里无法正确解析。第二个是 集合参数为空时默认会生成不带IN子句的SQL这是合法的SQL不会报错但结果全空查出来的数据让人抓狂。第三个是条件拼接时忘记考虑参数转换数字类型的查询条件传成字符串MySQL有隐式转换问题索引会失效查询直接全表扫描。排查SQL问题我习惯先打印出最终执行的SQL看看MyBatis实际拼出来的语句长什么样。配置mybatis.configuration.log-implorg.apache.ibatis.logging.stdout.StdOutImpl后控制台会输出完整的SQL和参数。这一步能省掉很多靠猜的排查时间开发环境和测试环境建议常开生产环境关闭免得日志文件膨胀。6. 运维部署与后期扩展思考6.1 单机部署的最佳实践这台系统部署用的还是最传统的方式前端npm run build后把dist目录传到服务器的Nginx目录后端mvn package打好Jar包用systemd注册成系统服务。SpringBoot的Jar包可以直接用java -jar运行但生产环境还是要做守护我给后端服务写了一个systemd服务文件崩溃自动重启开机自启配合日志追加重定向。JVM参数我建议至少加上-Xms2048m -Xmx2048m盒子是4G内存给JVM 2GMySQL和Redis各占1G这样分配基本平衡。元空间设置-XX:MetaspaceSize256m防止频繁触发Full GC。部署后建议再配一个简单的接口健康检查脚本每五分钟curl一次系统的/ping接口连续几次失败就调用systemctl restart重启服务。数据库备份是这个项目前期被忽视的一块。上线一个多月后磁盘故障差点丢了一个月的工单数据从那以后我加了crontab每天凌晨三点执行mysqldump全量备份保留最近七天的备份文件。备份脚本加个find -mtime 7 -delete清理旧文件磁盘不会无限膨胀。医疗系统的数据是审计追溯的基础备份比什么都重要。6.2 从单体到微服务的演进边界先说结论这个平台在可预见的三年内不需要拆微服务。设备科的用户量不增长单机性能绰绰有余拆微服务引入的消息队列、注册中心、网关这些组件反而成了新的不稳定源。真到了需要横向扩展的节点优先进化方向是按领域拆分。维修工单、设备档案、统计分析这三个模块是天然的拆分边界统计报表的实时性要求不高可以做成定时预计算的数据服务从主库同步数据到独立的统计库。这个演进思路提前留好了接口边界每个模块的service接口不要直接暴露内部实体通过DTO传输数据将来拆分时就少很多适配工作。SpringBoot的项目我还想提一个模块化思路虽然当前是单体应用但包结构已经按业务域切分了代码层面满足高内聚低耦合。这种模块化单体的形态其实非常适合中小型团队比一上来就上微服务的动车架构稳得多。6.3 数据驱动的设备运行分析平台运行半年后工单表、保养记录表、巡检记录表积累了几万条数据这些数据的分析价值远超预期。我基于MySQL的简单聚合统计就能产出几份核心报表设备故障率排行、科室报修趋势、工程师工单处理时长分布、保养完成率。设备故障率排行让采购有了明确依据某个品牌的监护仪半年故障率比同类型其他品牌高出三倍续采时直接跟厂商提要求。工程师工单处理时长分布可以客观评估工程师的工作量也暴露了培训需求某类设备平均处理时长过长说明整体技能短板。保养完成率在月底评审时直接展示给设备科领导原来是手工统计一两天出不来现在系统实时刷新。统计报表的实现我建议用定时任务预聚合的方式每天晚上把当天的数据汇总到统计表里查询报表时直接查统计表不要写大SQL嵌套子查询。这个方案比实时统计快得多报表页面加载时间从几百毫秒降到几十毫秒用户体验完全不一样。平台还能做更进一步的设备健康度预测比如用维修频率和维修时长两个维度给每台设备算一个健康得分低于阈值就建议升级采购计划。这个是下一步想做的事情数据基础已经足够就看设备科愿意投入多少精力来用这些数据做决策了。我个人在实际落地这套系统时最大的体会是技术框架的选择反而不是最难的部分SpringBoot早已发展得足够成熟稳定真正花时间的是理解医院设备科的业务流程把每一台设备的生命周期管理想透。最初版本上线时设备科提了一堆修改意见大部分集中在流程细节上比如报修时紧急程度分档、验收环节必须人工确认、保养提醒提前天数可配置这些调整都不改动技术架构却是系统能不能真正被用户接受的胜负手。如果你也在做类似的医疗后勤类管理系统我的建议是前期多花时间蹲在用户现场看他们怎么干活比闷头写代码有用得多。至于SpringBoot的编码实现本身网上资料已经足够多跟着这篇文章把数据模型和状态机设计想清楚后面就是水到渠成的事。