基于Spring Boot+微信小程序的医院医疗设备管理系统设计与实现解析

这阵子接连帮几个准备毕设的学弟做了代码走查，发现很多人看到"基于Spring Boot+微信小程序的医院医疗设备管理系统"这个题目光是开题就卡住了。说实话这个选题很聪明：业务场景真实、功能模块多而不杂、前后端分离结构完整，无论你走小程序端、Android管理端还是Spring Boot后端，工作量都刚好卡在本科毕设该有的体量。我手上这套源码就是按这个思路整理的，完整包含程序、论文文档、代码讲解视频和定制支持，下面把整个系统的设计思路、每个模块关键实现，以及拿到源码后从部署到答辩的全链路经验一次性讲透，给正在做同类题目的同学参考。

1. 设备科的真实场景：为什么这个系统能撑起一套像样的毕设

很多同学选题目喜欢问"什么系统最热门"，其实真正决定毕设好坏的不是技术多新，而是业务场景有没有值得设计的矛盾点。医院医疗设备管理系统比普通的"XX管理系统"高级在哪儿？我第一次去医院设备科做需求调研的时候就被震住了——几十个科室、几百台设备，贴在机器上的固定资产标签早就磨得看不清了，工程师手上拿的还是一张张纸质维修单。

1.1 医院设备管理的日常到底在管什么

设备科的工作可以拆成几条线：设备从采购入库、建档贴标开始，中间经历日常使用、定期巡检、保养、故障报修，到最后报废处置，这是最基本的生命周期线。还有一条是成本线，每台设备的维修花了多少钱、保养做了几次、哪些科室设备使用率低，这些都要有据可查。再加上设备分布在各个科室，医疗设备还涉及强检计量、消毒记录等合规要求，业务复杂度比通用的库存管理系统高很多。

这种复杂度对毕设来说反而是好事。想象一下如果你做的是"图书管理系统"，无非是增删改查加借还，功能描述几句话就交代完了，论文第三章写不满五页。一旦落到设备管理，台账信息、维修工单、巡检记录、保养计划、报废审批、科室间调拨借用，任何一个模块拉出来都能独立成章节，这就是业务本身给你的内容支撑。我在代码里也特意保留了7张核心业务表，把完整的功能链路都串起来了，不是为了炫技，而是为了让论文的"系统设计"和"系统实现"有东西可写。

1.2 为什么这个组合天然适合毕设

Spring Boot + 微信小程序这套组合已经被验证过无数次了。Spring Boot的好处是约定大于配置，不用像SSH那样写一堆XML，Maven依赖一把梭，本地开发一个Application.java就能起服务，对于论文里要写的分层架构也清楚：Controller、Service、Mapper一一对应，老师看了也容易理解。

微信小程序端则解决了"谁来用"的问题。医院里用户是分角色的，科室内医护人员可能只是扫个码报个修，不想装App；设备科维修工程师每天跑现场，用小程序比用PC端方便；设备科主任又需要一个管理分析的窗口，这部分我安排给了Android管理端。前端一个小程序、一个Android App，后端一套Spring Boot服务，形成一个完整的"一后端两端"结构，这在毕设里是妥妥的加分项，工作量也容易描述清楚。

2. 系统架构与三端角色分工：谁在用什么终端干活

我把系统的总体结构拆成三个部分，看标题你可能觉得只是个普通Web项目加个小程序壳子，但实际落地的时候，角色的边界决定了你代码里权限控制、接口设计、甚至数据库表结构的走向。先想明白人怎么用系统，再动手写代码，能帮你少走一大半弯路。

2.1 后端Spring Boot服务和一个项目的关系

后端是整个系统的大脑，跑在一台服务器或者你自己电脑上，提供RESTful API。这一层要管的事情是：用户登录与鉴权、设备台账的CRUD、工单流转、巡检/保养计划生成、审批流程、消息推送、统计报表。技术栈就是Spring Boot + MyBatis Plus + MySQL + Redis（Redis主要做登录token缓存和设备编码缓存）。

小程序端和Android管理端本身不存业务数据，它们所有页面展示的内容都是调后端接口拿JSON再渲染的。这种结构有个很直接的好处：论文的架构图好画，你可以画一张很清晰的部署图，客户端指向Spring Boot服务，服务指向MySQL，Redis在旁边做缓存，老师一眼就能看懂你的系统是前后端分离的。

2.2 Android管理端与微信小程序的边界划分

这两端的划分是我设计系统时做的关键决定，很多网上的烂项目就是把同一个页面在小程序和App里各写一遍，业务逻辑完全没有区分。我这边严格按照"用户角色"切：

• 微信小程序端：面向科室医护人员和维修工程师。医护人员扫码查看设备档案、发起报修；工程师接收维修工单、更新维修进度、填写维修结果。强调轻量、随手可用。
• Android管理端：面向设备科管理员/主任。做设备的入库登记、整体台账管理、设备报废审批、维修记录审核、统计报表查看。强调功能全、管理性强。

为什么要这么切？你可以想想真实场景：护士发现心电监护仪坏了，她不可能回办公室开电脑填工单，站在机器旁边用微信扫一下二维码就能报修，这是最高效的。而设备科主任做月底统计的时候，给他看一堆卡片式页面反而不方便，Android管理端用列表、抽屉、图表去呈现会更顺手。这种设计思路放到论文里，就是"基于用户场景的需求分析"，这比空泛地写"系统分为管理员和普通用户"要有力得多。

2.3 权限控制的落地方式

权限这里我没有引入Spring Security那套厚重的框架。毕设项目引入Security最大的坑是配置复杂，要么绕不过登录拦截，要么角色匹配写不明白，调试时间比写业务还长。我的实现方案是基于JWT + 拦截器的轻量权限控制：

• 登录成功后后端签发一个JWT，里面放进userId和roleCode。
• 前端每个请求的header里带上Authorization: Bearer token。
• Spring Boot写一个WebMvcConfigurer注册拦截器，放行登录接口和静态资源，其余请求全部校验token。token中携带角色，在需要特定角色才能访问的接口上通过自定义注解或简单判断处理。

核心拦截器代码大概长这样：

java复制public class AuthInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        String token = request.getHeader("Authorization");
        if (StringUtils.isBlank(token)) {
            response.setStatus(401);
            return false;
        }
        // 解析JWT，校验roleCode是否属于白名单，超时或非法直接返回401
        return true;
    }
}

小程序端登录后把token存在storage里，请求封装时统一带上；Android端用一个拦截器Interceptor来做同样的事。写清楚这个链路，无论你是答辩还是自己扩展功能都会省力很多，因为新加的接口只要校验逻辑一致就不会出现未授权访问的漏洞。

3. 数据建模才是设备管理的灵魂：核心表与状态流转

业务系统的开发有个经验：页面和接口能抄，数据库表结构很难抄。因为建表的方式直接反映你到底有没有理解业务。我第一次看到有的项目把"维修记录"和"保养记录"硬合成一张表，还用一个type字段区分，就知道这届系统后期统计肯定一堆坑。设备管理系统的表设计不需要花活，但要表义清晰、状态可追踪、统计容易查。

3.1 设备台账表的设计思路

设备台账是系统的主数据，相当于医院所有设备的档案库。我设计的device_info表有这样几类字段：

• 基础档案：设备编号、设备名称、规格型号、生产厂家、出厂编号。
• 状态字段：当前状态（1在用、2维修中、3停用、4待报废）、所在科室ID、设备分类。
• 财务相关：购置日期、购置价格、折旧年限、供应商。
• 追溯字段：保修截止日期、上次保养日期、下次保养日期、二维码编码。

sql复制CREATE TABLE device_info (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  device_code VARCHAR(64) NOT NULL UNIQUE COMMENT '设备唯一编码',
  device_name VARCHAR(128) NOT NULL COMMENT '设备名称',
  model VARCHAR(64) COMMENT '规格型号',
  factory VARCHAR(128) COMMENT '生产厂家',
  category VARCHAR(64) COMMENT '设备分类',
  status TINYINT DEFAULT 1 COMMENT '1在用 2维修中 3停用 4待报废',
  dept_id BIGINT COMMENT '所在科室',
  purchase_date DATE,
  price DECIMAL(12,2),
  warranty_end DATE,
  created_time DATETIME
);

这里有个很容易忽略的细节：设备编码必须唯一且稳定。你在页面上看它只是个编号，但实际上后续扫码、报修、审批全部靠这个编码关联。如果表里没有唯一索引，两台设备编码重复，后面做出来的二维码就是灾难。所以建表的时候直接加UNIQUE约束，比在Service里写判断稳妥得多。

3.2 维修、巡检、报废的状态如何流转不丢数据

医院设备的每个动作都是有时效和状态的。比如一台呼吸机坏了，它不能再作为正常设备出现在可用列表里；修完之后要有维修结论、花费金额、维修人，才能重新标记为"在用"。这些状态不能靠前端改，必须是后端按照业务规则做流转。

我设计的维修工单是核心流转单据，状态机包含：

• 待接单：科室扫码提交后生成，此时工程师可以在小程序里看到待抢单列表。
• 维修中：工程师接单后进入，设备状态同步变为"维修中"。
• 待验收：工程师填写维修结果后，报修人还能做一次验收确认。
• 已完成：验收通过或管理员强制结束。
• 已驳回：报修信息填写有误，管理员退回并填写原因。

这个状态机的好处是每一步都有记录，环节之间不会跳。实现上我用一张repair_order表加一个status字段，但所有的状态变更都通过Service层的方法严格控制，前端不能直接提交任意状态值。论文里画一张状态转换图，也是答辩非常喜欢的内容。

巡检记录和保养计划也是类似，我单独建了inspect_record和maintenance_plan。定期保养到期之后生成待办提醒给Android管理端，管理员指派工程师去执行，做完之后回填执行记录，同时更新设备的"下次保养日期"。这种由计划生成执行记录的逻辑，也是设备管理系统区别于普通CRUD功能的关键业务点。

3.3 统计报表直接走的SQL聚合思路

设备管理系统里报表是躲不开的，安卓管理端首页要展示设备总数、维修中数量、本月报修数量、科室设备分布等。这些数据我全部用SQL聚合，没有引入复杂的前端图表库之外的额外服务。

比如按科室统计设备数量：

sql复制SELECT d.dept_id, COUNT(*) AS device_count
FROM device_info d
GROUP BY d.dept_id;

维修费用统计就关联工单表，按月分组：

sql复制SELECT DATE_FORMAT(create_time, '%Y-%m') AS month, SUM(repair_cost) AS total_cost
FROM repair_order
WHERE status = 4
GROUP BY DATE_FORMAT(create_time, '%Y-%m');

Android端用MPAndroidChart画成柱状图和饼图，接口返回的数据结构固定成数组，前端直接绑定。整体报表模块不要做得太重，一张首页统计卡加两张趋势图足够展示数据分析能力，也容易在答辩时撑住"数据可视化"这个点。

4. 小程序端从登录到扫码报修的完整链路

微信小程序端是使用频次最高的入口，也是老师看演示时第一眼看到的界面。系统里小程序主要干三件事：登录、扫一扫、报修/接单。这部分看起来简单，实际上有不少细节会卡住人，尤其是第一次跑通微信登录和扫码那块。

4.1 微信登录与用户身份的对应

小程序登录分为两步。第一步是调wx.login()拿到code，把code发给后端，后端调微信接口换openid，拿openid去查你是谁。但医院系统不能光靠openid认人——设备科主任要用管理功能，普通护士只能报修，所以还要做一层手机号绑定或账号绑定。

我这套系统是开放了两种进入方式：如果是首次打开的小程序，用户先用手机号登录，后端会把这个openid和真实用户表里的人关联上；或者直接用预先分发的测试账号去登录。关键点是openid只是"钥匙"，真正决定权限的是你的账号角色。代码里我用一张用户表存好了登录账号、密码、手机号、角色，openid登录后自动绑定到对应用户，这样比每次从微信侧拿资料更可控，也给演示留了余地——即使没有测试微信号，也能靠普通账号跑通全部流程。

4.2 扫码识别设备的方案选择

每台设备在入库时会生成一个唯一的二维码，小程序里护士点击"扫码报修"，直接调wx.scanCode扫设备上贴的二维码标签。这里有个设计分岔：

• 方案一：把设备ID直接编码成二维码。优点是最简单，后端拿到ID直接查表；缺点是二维码等于暴露了设备内部ID，别人乱扫会扫出不该看的东西。
• 方案二：二维码里放一个随机UUID的设备编码，后台通过编码反查设备。我最终选了方案二。

实际使用体验是一样的，但设计上更科学。你自己做的时候如果赶时间，用方案一也能跑，但论文里如果写编码不可猜、防止遍历ID这种安全设计，无论是查重还是老师答辩印象都会好不少。

扫码之后小程序跳到设备详情页，展示这台设备的名称、型号、位置、当前状态和保修期，下面直接放两个按钮："我要报修"和"查看历史维修记录"。报修提交的时候要选故障类型、填故障描述、上传图片，图片是先传到后端的文件上传接口，再拿到URL返回给小程序填入表单。

4.3 工单闭环：从报修人到维修工程师的动作衔接

科室的人提交报修之后，维修工程师打开小程序会看到一个待接单队列。工程师点接单后，报修人端会看到工单状态变成"维修中",设备状态也自动同步成"维修中"—这两步联动通过一次后端接口调用就完成了。维修完成时工程师填写处理方案和维修费用，如果涉及更换零件还要勾选配件名称。

我复盘过很多同学做这块容易犯的错：报修提交完就结束，后续状态全靠管理员在管理端手动改。这就把闭环做断了。真正能让老师觉得你系统"完整"的，是一个工单从提交、接单、处理、验收、评价每个环节都有对应角色去推进，并且在状态变化的瞬间有消息推送给相关人。

所以我在后端设计上严格要求：所有状态变更都发生在Service层，并发送一条通知记录到notice表。小程序的开单人在App里能实时看到工单进度，Android管理端设备科主任也能看到当天待处理工单数量。从一个按钮到一个页面到最后的数据表变化，业务是能从头走到尾的，这是毕设演示时最有说服力的部分。

5. Android管理端：审批、消息推送与离线加载的处理

Android管理端在整个系统里的定位是设备科的日常办公入口。如果只是把Web页面套个WebView壳子，答辩老师问起来会很尴尬——那何必单列一个Android端？要让Android端有独立价值，它必须承担"管理、审批、分析"这些大屏PC端或小程序不好干的重活，还要处理好移动端特有的推送和弱网问题。

5.1 为什么用原生Android而不是套壳

我的做法是用原生Kotlin + Jetpack组件，MVVM架构。网络层用的Retrofit + OkHttp，数据解析用Gson，页面之间用Navigation传递参数。异步用协程处理，避免回调地狱。

kotlin复制viewModelScope.launch {
    val result = apiService.getDevicePage(1, 10)
    when (result.isSuccess) {
        true -> { deviceListAdapter.submitList(result.data.records) }
        false -> { toast("加载失败，请检查网络") }
    }
}

这里需要注意Android 11以上对明文HTTP的限制——本地调试时后端地址是http://192.168.x.x:8080，默认是禁止访问的。你要在AndroidManifest里手动加上android:usesCleartextTraffic="true"，或者在networkSecurityConfig里对开发环境IP放行。这个坑，几乎每个第一次调试的同学都会撞上，报错全是"Cleartext HTTP traffic to xxx not permitted"，不是接口问题，是Android版本策略问题。

5.2 审批中心和消息推送的实现细节

Android管理端最核心的页面是审批中心。维修单审核、报废审核、保养任务分配，三种单据都靠状态枚举区分。页面做一个TabLayout + ViewPager2，每个Tab里一个Fragment，各自请求不同API。审批通过或驳回时，调对应接口并返回工单页刷新。

消息推送我一开始试过集成厂商推送SDK，后来发现为了毕设弄全套极光推送反而增加复杂度，而且还要注册推送厂商账号。我的做法是"Android端拉取 + 本地通知"组合：Android管理端的设备科主任登录后，开启一个前台服务定时拉取未处理消息数量；一旦发现有待办数量变化，就发一条本地通知提醒。这样不用依赖第三方推送服务，又能在演示时看到通知栏弹出消息。

kotlin复制val builder = NotificationCompat.Builder(this, CHANNEL_ID)
    .setSmallIcon(R.drawable.ic_notification)
    .setContentTitle("新的维修工单待处理")
    .setContentText("科室${deptName}报修${deviceName}")
    .setPriority(NotificationCompat.PRIORITY_HIGH)
NotificationManagerCompat.from(this).notify(1001, builder.build())

从效果和代码可讲性来说，这比引入一套完整的推送SDK更合适：你自己能讲清楚原理，演示效果又能看得见，老师问起来也不至于露怯。

5.3 列表和图片加载的性能优化

管理端要加载设备列表，一部分设备有报修图片，如果没有做分页和图片优化，几千条数据一次拉到本地，Android端很容易卡顿甚至OOM。设备列表我分了页，每页20条，上拉加载更多。图片用的是Glide加载，缩略图在服务端生成或Glide里直接指定尺寸，避免原图直接进内存。

另外一个容易被忽视的问题：管理端的科室筛选。设备列表顶部有科室Spinner，这个科室数据量很小，我直接在App启动时缓存到本地数据库里，用Room存起来，每次进入页面先从本地读缓存，再刷新一次。这个设计虽然代码量不大，但是使用体验提升很明显。

6. 源码拿到手以后怎么跑起来：版本搭配和排错经验

很多同学从网上下了一堆源码，最后死在"跑不起来"这一步，然后开始怀疑人生怀疑代码。我给出的这套源码，只要版本对齐，理论上半小时内就能本地跑起来。下面的版本和启动顺序是我自己压测过多次的，照抄基本不会翻车。

6.1 环境版本搭配建议

强烈建议不要用太新的版本，也不要太旧的版本。我的实测组合如下：

如果你用HBuilderX跑小程序端代码，有个点要特别注意：每个小程序项目都有唯一的AppID。HBuilderX运行到微信开发者工具时，它默认会读项目里的manifest.json中的mp-weixin.appid。很多同学在自己机器上跑别人的源码，一直提示AppID不对，其实你只需要在manifest.json里换成自己的测试号AppID，或者在微信开发者工具里把"不校验合法域名"的选项打开，就能解决大部分联调问题。

6.2 启动顺序与联调关键点

建议的顺序是：先启动MySQL和Redis，再启动Spring Boot后端，然后启动Android管理端或小程序端。如果浏览器直接访问后端接口能通，比如http://localhost:8080/api/device/list能正常返回JSON，说明后端OK，再调前端。

联调时最容易出的问题是地址写错。Android模拟器访问本机后端要用10.0.2.2而不是localhost；真机调试通常需要让手机和电脑连同一个局域网，然后填电脑的局域网IP。小程序开发者工具里默认不校验合法域名，开发阶段直接填http://localhost:8080也能通，但手机预览小程序时，localhost指向的是手机自己，必须改成电脑的局域网IP。

提示：源码里的后端默认端口是8080，如果被占用，改成其他端口时要同步修改三处——application.yml里的server.port、小程序里的request baseURL、Android端的Retrofit baseURL。漏改任何一个都是联调不通的根源。

6.3 我排过的三个高频坑

第一个坑是数据库初始化。很多项目提供的是SQL脚本，你要在MySQL里先手动建库，再执行.sql文件。如果直接拿Navicat跑，注意选择UTF-8编码，否则中文容易乱码。库名和用户名密码如果不一致，记得改application.yml。

第二个坑是Redis没设置密码时连接失败。默认本机Redis是没密码的，但application.yml里如果你用了spring.redis.password=123456这种配置，本地又没有这个密码，启动时可能不报错，但登录时永远不成功。排查思路是先关掉密码配置，跑通后再按需加上。

第三个坑是小程序的上传图片接口，报错是服务器返回的URL开头带了localhost而不是局域网IP。这个问题的根源是后端文件上传接口返回的访问地址拼错了，需要检查application.yml里的文件访问前缀配置，把IP换成当前电脑的局域网IP或者域名。这同时也是你部署到真机演示时最容易出画蛇添足问题的点。

7. 源码讲解怎么配合论文和答辩材料

所有源码拿到手之后，不要直接开背代码，你需要把源码"翻译"成答辩能讲的故事。这一节我结合自己辅导过的学生情况，说说这份源码和配套的论文/文档怎么配合使用最高效。

7.1 需求分析部分直接引用实体模块

论文里的需求分析，最好别空谈"本系统旨在提高医院设备管理效率"这种废话。你就把系统拆成模块讲：面向护士的扫码报修流程、面向工程师的工单接单与回填流程、面向设备科的台账管理与审批流程，然后每个流程描述清楚参与角色、前置条件、基本流程、异常分支。这些材料在源码和演示里完全能对应上，老师一看就知道系统思考过业务流程，不是凭空捏造的。

7.2 设计部分重点讲清楚两张图

画系统架构图的时候，把Android管理端、微信小程序、Spring Boot后端、MySQL和Redis的关系画清楚。画功能结构图的时候，按照"终端-角色-功能"三层展开，别把所有功能堆在一个矩形里。这两张图是论文的门面，也是答辩讲解的主线，源码里凡是涉及模块划分的地方都跟这两张图保持一致，答起来自然流畅。

答辩时老师最爱问的问题其实就是几个方向：一是"系统的权限是怎么控制的"，你可以把JWT拦截器代码往上翻一翻；二是"维修状态转成已完成以后，设备库存状态怎么同步"，你就讲设备状态和工单状态如何在Service层保持一致性；三是"你这个项目的难点在哪里"，建议大家不要说太多技术术语，而是说清楚两个业务细节：扫码报修省去了科室打电话报修的流程、设备维护保养计划能做到自动提醒。这种"技术+场景"并重的回答，比背一堆IDE快捷键有说服力得多。

提醒：代码讲解视频是配合答辩准备的，用它做复习提纲就够了。开口讲之前，自己找一个完整业务链在本地跑一遍——从小程序扫码报修，到Android管理端审批，再到小程序验收，全程录屏一次，比你背一天的PPT都管用。

我个人的体会是，毕设项目最忌讳的是"什么都想展示但每个功能都残缺"。这套系统能在工作量、技术栈深度、演示效果之间取得平衡，靠的正是把核心流程做完整而不是无限铺功能。如果你手头已经拿到了这套源码，建议先按上面第6节的步骤把它跑起来，再顺着工单这条主线把所有角色走一遍。等你亲手把一套完整的业务链跑通，后面做论文、做PPT、应对答辩都会顺很多。