王杰岸在医院场景里，设备报修这件事，远没有想象中那么简单。一台心电监护仪坏了，护士要先找设备科电话，报完型号、故障现象，再等工程师下来判断，中间还得手填一张纸质报修单，后续进度基本靠问。这样的情况多了，设备科自己也很头疼，台账要补、记录要查、维修响应快慢全凭印象。我做了一套基于SpringBoot+微信小程序的医院医疗设备管理系统，把报修、接单、维修、验收、台账归档全部搬到线上，科室人员扫设备上的二维码就能发起报修，工程师在微信小程序里直接接单和填写维修记录，设备科后台查看统计。这套系统面向两类人：一是真正想解决医护设备管理繁琐问题的医院内部信息化场景，二是正在忙计算机毕设、需要一个完整前后端项目做参考和二次开发的同学。如果你正好拿到类似题目，这篇内容能帮你少踩很多坑，把项目从“能跑”做成“能答辩、能演示、能讲清楚”。
1. 项目的起点：医院设备管理到底在管什么
1.1 从医院现场梳理出的三个核心痛点
做任何系统前，我最讨厌一上来就画表建库。这次我先去医院设备科待了大半天，看他们日常怎么处理报修，核心痛点其实就三条。
第一，报修入口分散。科室护士遇到设备故障，有人打电话，有人发微信群，有人干脆把设备推到走廊等人发现。电话报修最大的问题是没有留痕，过了三个月再追问“这台机器到底修没修过”，没人说得清。微信群报修信息会被聊天刷掉，设备科要自己翻聊天记录维护Excel，活生生多出很多重复劳动。
第二，状态不透明。报修单交上去之后，护士不知道工程师什么时候来，工程师不知道设备在哪个楼层哪个房间，设备科不知道现在有多少单子积压、哪些超时了。整个流程像个黑盒，所有人都只能靠催。
第三，设备台账和维修记录脱节。设备买了多少年、使用科室在哪、上次保养是什么时候、换过什么配件，这些问题平时没人关心，等设备科要申报采购、做资产盘点时，才发现资料根本对不上。维修如果没记录，设备的全生命周期管理就是一句空话。
所以这套系统在设计时，我没有按常规思路先把“设备信息管理”做成堆增删改查的模块，而是把所有功能都围绕“报修单”这个核心流转对象来展开。设备信息、科室信息、用户信息都是报修单的上下文，修好之后自然沉淀成维修记录，维修记录反过来更新设备状态，这样就形成了完整闭环。
1.2 参与系统的三类角色与核心链路
这套微信医院医疗设备管理系统里，一共设计了三个端。
科室报修人员，通常是护士长或科室设备管理员，他们负责扫码发起报修，上传故障照片，查看维修进度，最后参与验收。维修工程师，负责查看待接单列表、抢单或由设备科派单，维修时填写故障原因、维修措施，结束后上传维修照片提交验收。设备科管理员，拥有最高权限，可以管理设备台账、维护科室体系、指派工程师、关闭异常工单，并查看各类统计报表。
三类角色在微信小程序里面对的功能界面不同，对应后端接口的权限控制也不同，具体后面会讲。这里先把最核心的一条链路画出来：扫码或者手工选择设备，填写故障描述和图片，生成一张报修单；工程师接单后状态变成维修中，等工程师提交“维修完成”，系统生成待验收状态；科室人员确认没问题，点击验收通过，整张工单结束并归档。管理员随时可以把流程反向操作，比如发现工单信息填错了，或者设备已经报废不能再修，直接强制关闭。
1.3 需求边界：先想清楚不做什么
毕设项目最怕什么？最怕“需求失控”。我见过太多同学一上来就想做设备定位、温湿度监控、配件库存预警、AR眼镜维修指导，结果三个月做出来一个半成品。这里我给自己定了一条规矩：一个报修单从发起到归档的闭环，必须完整体验流畅；闭环之外的功能，统统往后排。
基于这个原则，我做了三处取舍。
第一，不做微信支付。有人觉得可以做一个维修费用结算模块，但小程序的医疗类目本身对支付场景审核很严格，而且医院设备的维修费用通常是科室间内部结算，走的是线下流程。为了一个毕设去撞支付审核的墙，不值。
第二，不做过于复杂的审批流。报修单走的是状态机，不是完整的工作流引擎。SpringBoot整合Flowable确实可以做复杂流程，但引入引擎意味着额外的表、模型和资源文件，对一个报修场景来说属于杀鸡用牛刀。后面我会专门说状态机的设计。
第三，不做设备的实时联网监控。医疗设备本身有通信协议，但不同厂商协议差异巨大，统一采集需要硬件网关和大量适配，这超出了信息管理系统的范畴。系统里有“保养周期”字段，定时生成保养提醒就够了，这已经能覆盖设备科对“预防性维护”的核心诉求。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 整体方案架构与技术选型，为什么这样搭
2.1 SpringBoot版本选择一个容易被忽略的大坑
项目后端采用SpringBoot，这个基本没什么悬念，Java技术栈稳定、生态成熟，答辩时老师也熟悉。但在版本选择上，我强烈建议不要追新，我当时用的是SpringBoot 2.7.18，配合JDK 1.8。
为什么不用SpringBoot 3.x？很多同学搜索时看到“springboot版本太高”这个话题，以为只要换版本就行，其实背后的坑非常实际：SpringBoot 3.0开始强制要求JDK 17，包名从javax.servlet迁移到了jakarta.servlet，相当一部分老教程、旧版本的第三方starter都会出现兼容问题。毕设阶段时间紧张，没有必要为“用最新版本”这个执念多花精力调兼容性。
具体版本搭配如下：
| 组件 | 版本 | 说明 |
|---|---|---|
| JDK | 1.8 | 稳定、兼容性好，几乎所有云服务器都能跑 |
| SpringBoot | 2.7.18 | 2.x系列最后一个维护版本 |
| MyBatis-Plus | 3.5.3 | 简化CRUD，分页和逻辑删除好用 |
| MySQL | 5.7或8.0 | 建议8.0，字符集直接utf8mb4 |
| Sa-Token或JWT | jjwt 0.9.1 | 小程序登录token签发校验 |
| Swagger | knife4j 3.0.3 | 生成接口文档，答辩演示加分 |
顺带提一个让项目显得很精致的小操作：SpringBoot启动时那行默认的Spring Banner很单调，网上有banner生成器，把想要的项目名生成字符画粘到resources/banner.txt里。这个虽然不影响功能，但演示时大屏幕上整屏打印一个“MedicalDevice System”的自定义Banner，老师会觉得你做项目确实用心了。
2.2 单体分层架构与统一返回封装的必要性
这套系统没有拆微服务，也不需要拆。我心里很清楚，一个医院内部科室规模的管理