Java医院设备管理系统：从增删改查到全流程状态管理设计与实现

每年毕业设计季，“计算机毕业设计 java 医院设备管理系统”这个选题几乎都会出现在各大选题清单里。它看起来像一套普通的增删改查系统，但真正要做出一个“信息化管理平台”的完整闭环、在答辩现场扛住老师的追问，里面涉及的需求分析、状态机设计、事务与数据一致性、统计报表实现，都远不是教科书上那几个CRUD例子能覆盖的。

这篇文章不打算给你讲空泛的理论，而是直接按我做这类项目时的思路，把这个题目拆开揉碎，从需求边界、技术栈选型、数据库设计、核心代码落地，到开发排期、演示准备、答辩追问，完整走一遍。无论你是准备用Spring Boot + Vue自己写，还是打算基于若依这类脚手架二次开发，这篇文章都能给你一份能直接照着做的路线图和避坑清单。

1. 医院设备管理系统这个毕设题，到底考的是什么

先想明白一件事：老师出这个题，不是在考察你“会不会写登录注册”，而是在看你对一个行业场景的理解能不能转化成系统设计。

1.1 场景真实需求与普通进销存系统的差异

很多人一听“设备管理”，第一反应就是“不就是资产台账吗？增删改查、导出Excel就行了”。如果你这么理解，做得再细也就是一个进销存系统，答辩时很容易被问到“你和超市商品管理系统有什么区别”。

医院设备管理系统之所以单独成为一个题目，是因为它有一个非常明显的行业特征：设备全流程管控。一台医疗设备从采购申请、到货入库、科室领用、日常保养、故障维修、定期盘点，到最后报废处置，是一条完整的状态流转链。系统要解决的核心问题不是“记录设备存在”，而是“每台设备当前在哪个环节、由谁负责、状态如何、下一步应该走到哪里”。

这背后对应的技术点是状态机设计、操作留痕、流程审批、数据统计。这四点恰恰是区分一个“演示型CRUD”和“工程化项目”的关键。

1.2 这个题目能覆盖哪些高频技术点

从毕设和面试的角度，这个题目覆盖的知识面非常合理：

• 后端框架：Spring Boot的核心用法、分层架构（Controller/Service/Mapper）
• 持久层：MyBatis Plus的条件构造器、分页查询、逻辑删除、自动填充
• 权限控制：基于角色（管理员、设备科人员、普通科室用户）的接口权限
• 数据库设计：多表关联、枚举字段、时间字段、唯一索引
• 事务管理：设备状态流转时多张表更新的原子性
• 定时任务：保养提醒、保修到期提醒，Spring Schedule就能实现
• 报表统计：按设备类型、状态、科室维度的统计SQL与图表展示

这套组合拳练下来，做完这个项目之后，Spring Boot的核心知识点基本都能摸到，而且能在简历上写“基于状态机的全流程设备管控”这种有含金量的描述，比单纯写“实现了XX管理系统的增删改查”要好看得多。

2. 需求边界与模块划分：不要让系统变成“大杂烩”

毕设最容易犯的错就是需求膨胀。今天加一个固定资产折旧，明天加一个采购审批工作流，最后开发到一半发现做不完，只能草草收尾。这里我建议你严格按“必须做”“建议做”“有余力再做”三个梯队来规划。

2.1 三类角色与权限模型

医院的设备管理场景，至少涉及三类人，角色划分不必过度复杂：

权限模型推荐用RBAC，也就是“用户-角色-权限”三层。毕设阶段不需要做到按钮级细粒度权限，做到“登录后根据角色显示不同菜单、后端根据角色拦截接口”就够了。用Spring Security或者拦截器+自定义注解都可以，前者后续在简历上更好写，但学习成本略高；后者实现快、容易讲清楚，看你自己的时间。

2.2 全流程闭环的必做模块

设备全生命周期这条主线才是系统的灵魂，建议至少包含六个模块：

1. 设备台账管理：设备编号、名称、分类、型号、生产厂家、购入日期、价格、保修截止日期、存放科室、当前负责人、当前状态。
2. 设备分类管理：树形结构，比如“影像设备-B超”“检验设备-生化分析仪”，用于后续分类统计。
3. 采购/入库管理：登记采购信息（供应商、采购单号、采购日期），并将设备状态置为“待领用/在库”。
4. 领用/调拨管理：科室领用设备，记录领用人和领用时间，设备状态变为“在用”；科室间调拨则变更归属科室。
5. 维修与保养管理：设备报修、维修中、维修完成恢复可用；保养计划与保养记录，生成下次保养时间。
6. 报废管理：申请报废、审批通过后设备状态变为“已报废”，并保留历史记录。

这六个模块串起来之后，任意一台设备都能查出一条完整的时间线：什么时候买的、谁在用、修过几次、每次保养什么时间做的、最后怎么处置的。把这条线讲清楚，项目就基本立住了。

2.3 加分项：报表统计和提醒功能

如果时间允许，再加两样东西，系统立刻就有了“平台级”的感觉：

• 统计仪表盘：首页展示设备总数、在用数、维修中数、月维修费用；按科室统计设备数量；按类型统计设备数量。用ECharts出柱状图和饼图就足够。
• 提醒功能：设备保修即将到期、保养时间快到的设备自动生成提醒，登录后在首页展示列表。实现上用Spring Schedule写个定时任务，每天扫一次数据库即可，代码量不大但效果很好。

这两项功能技术难度不高，却是系统里最容易在答辩时“亮”的部分，而且能体现你在需求分析时考虑到运维场景，而不仅仅是“能增删改查”。

3. 技术栈与数据库设计：先把根基打牢

技术选型的逻辑是：尽量主流、控制复杂度、能讲得清楚。不推荐在毕设里引入微服务、分布式事务这些重技术，不需要，也讲不清。

3.1 技术栈怎么定才算合理

我给一个稳妥的组合：

• 后端：JDK 1.8或11、Spring Boot 2.7.x、MyBatis Plus 3.5.x、MySQL 8.x
• 权限：Spring Security + JWT，或者拦截器 + JWT，二选一
• 定时任务：Spring Schedule，不需要引入XXL-Job
• 前端：Vue 2 + Element UI（上手最快）或 Vue 3 + Element Plus；如果前端基础弱，也可以用Thymeleaf+模板渲染，但答辩效果会打折扣
• 报表图表：ECharts

为什么不推荐Spring Boot 3.x？因为JDK版本要求高，部分教程和第三方适配资料还集中在2.x，遇到问题很难搜到对应答案，毕业设计阶段没必要在这个地方增加不确定性。

为什么不推荐Shiro？不是不行，而是Spring Security + JWT的组合在简历上更常见，面试官也更熟悉，后期聊权限方案时话题更顺。

3.2 数据库设计：核心表与关键字段

数据库设计是这个项目的根基，表设计不合理后面写代码会非常痛苦。最核心的表可以控制在一张用户表 + 六张业务表 + 若干字典表。

用户表 sys_user：

sql复制CREATE TABLE sys_user (
  id            BIGINT PRIMARY KEY AUTO_INCREMENT,
  username      VARCHAR(50) NOT NULL UNIQUE COMMENT '登录名',
  password      VARCHAR(100) NOT NULL COMMENT 'BCrypt加密后的密码',
  real_name     VARCHAR(50) COMMENT '姓名',
  role          TINYINT NOT NULL DEFAULT 3 COMMENT '1管理员 2设备科 3普通用户',
  department_id BIGINT COMMENT '所属科室id',
  status        TINYINT DEFAULT 1 COMMENT '1启用 0禁用',
  create_time   DATETIME,
  update_time   DATETIME
);

设备台账表 device_info 是整张系统的主表，字段设计上特别要注意 status 这个字段：

sql复制CREATE TABLE device_info (
  id                 BIGINT PRIMARY KEY AUTO_INCREMENT,
  device_code        VARCHAR(50) NOT NULL UNIQUE COMMENT '设备编码',
  name               VARCHAR(100) NOT NULL COMMENT '设备名称',
  category_id        BIGINT COMMENT '设备分类id',
  model              VARCHAR(100) COMMENT '规格型号',
  manufacturer       VARCHAR(100) COMMENT '生产厂家',
  supplier           VARCHAR(100) COMMENT '供应商',
  purchase_date      DATE COMMENT '购入日期',
  price              DECIMAL(12,2) COMMENT '金额',
  warranty_end_date  DATE COMMENT '保修截止日期',
  department_id      BIGINT COMMENT '当前归属科室',
  current_user_id    BIGINT COMMENT '当前负责人',
  status             TINYINT NOT NULL DEFAULT 0 COMMENT '0在库 1在用 2维修中 3已报废',
  remark             VARCHAR(500),
  create_time        DATETIME,
  update_time        DATETIME,
  deleted            TINYINT DEFAULT 0 COMMENT '逻辑删除标记'
);

维修记录、保养记录、报废申请、领用记录这类“流水表”则统一带上 device_id 外键和各自的关键字段，例如：

sql复制CREATE TABLE device_repair_record (
  id              BIGINT PRIMARY KEY AUTO_INCREMENT,
  device_id       BIGINT NOT NULL,
  repair_no       VARCHAR(50) COMMENT '维修单号',
  fault_desc      VARCHAR(500) COMMENT '故障描述',
  apply_time      DATETIME COMMENT '报修时间',
  complete_time   DATETIME COMMENT '维修完成时间',
  repair_company  VARCHAR(100) COMMENT '维修单位',
  repair_fee      DECIMAL(12,2) COMMENT '维修费用',
  status          TINYINT DEFAULT 0 COMMENT '0维修中 1已完成'
);

这里有个设计原则：流水表只增不改，用状态字段标记流程进度。这样一台设备维修三次，就会有三条维修流水，随时能查历史，而不是在设备表上把“维修中/已维修”这种状态反复覆盖。

3.3 设备状态的统一管理与流转

设备状态是整个系统的“心脏”，建议用常量类或枚举统一管理，而不是在代码里散落写 1、2、3 这种魔法数字。

java复制public class DeviceStatus {
    public static final Integer IN_STORAGE = 0;  // 在库
    public static final Integer IN_USE = 1;      // 在用
    public static final Integer REPAIRING = 2;   // 维修中
    public static final Integer SCRAPPED = 3;    // 已报废
}

状态流转必须设定边界，不能任何状态都能跳到任何状态。合法流转如下：

• 0 在库 → 1 在用：科室领用
• 1 在用 → 2 维修中：设备报修
• 2 维修中 → 1 在用：维修完成，恢复使用
• 1 在用 → 3 已报废：报废审批通过
• 2 维修中 → 3 已报废：维修评估后确认无法修复，走报废

这些限制不能在页面层做，必须在Service层做校验，否则前端绕过页面直接调接口就会把数据搞乱。这也是答辩时一个很好的提问点。

4. 核心业务代码的落地写法：从增删改查到状态流转

下面给几个关键代码片段和设计思路，这些都是我在项目中实际验证过的写法，你可以直接参考。

4.1 设备台账的增删改查与逻辑删除

MyBatis Plus的BaseMapper已经提供了基础的CRUD，我们实际要做的就是在Service层补充查询条件和业务校验。

设备信息实体类核心字段：

java复制@TableName("device_info")
public class DeviceInfo {
    @TableId(type = IdType.AUTO)
    private Long id;

    private String deviceCode;
    private String name;
    private Long categoryId;
    private String model;
    private String manufacturer;
    private LocalDate purchaseDate;
    private BigDecimal price;
    private Long departmentId;
    private Long currentUserId;
    private Integer status;

    @TableField(fill = FieldFill.INSERT)
    private LocalDateTime createTime;

    @TableField(fill = FieldFill.INSERT_UPDATE)
    private LocalDateTime updateTime;

    @TableLogic
    private Integer deleted;
}

几个关键点：

• 金额字段用BigDecimal，禁止用double/float，财务数据不能有精度损失。
• @TableLogic逻辑删除后，MyBatis Plus的selectById、deleteById都会自动拼接deleted=0条件，物理删除不再发生，维修记录和领用记录才能安全保留外键。
• 分页查询统一用MyBatis Plus的分页插件，注意在配置类里注入MybatisPlusInterceptor，否则Page对象返回的数据永远只有一条。

java复制@Configuration
public class MybatisPlusConfig {
    @Bean
    public MybatisPlusInterceptor mybatisPlusInterceptor() {
        MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor();
        interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL));
        return interceptor;
    }
}

设备编码唯一性校验必须做。录入时先按deviceCode查一次，查到了直接抛异常。结合逻辑删除有个坑：同一编码的设备被逻辑删除后，如果再插入同编码设备，唯一索引仍然会冲突，所以”设备编码+deleted“的查询条件要处理好，更稳妥的方案是给device_code建唯一索引时把deleted也纳入，或者在删除时给编码加后缀如_del_{id}。

4.2 维修流程：状态联动与事务处理

设备维修是状态流转最典型的一个场景，包含两步数据变更：改device_info的状态、插入一条维修流水。这两步必须在一个事务里，否则可能出现设备状态改了、流水没插上，或者流水插了、设备状态没改的脏数据。

java复制@Service
public class DeviceRepairServiceImpl implements DeviceRepairService {

    @Autowired
    private DeviceInfoMapper deviceInfoMapper;

    @Autowired
    private DeviceRepairRecordMapper repairRecordMapper;

    @Override
    @Transactional(rollbackFor = Exception.class)
    public void applyRepair(RepairApplyForm form) {
        DeviceInfo device = deviceInfoMapper.selectById(form.getDeviceId());
        if (device == null) {
            throw new BizException("设备不存在");
        }
        if (!DeviceStatus.IN_USE.equals(device.getStatus())) {
            throw new BizException("仅“在用”状态的设备可以报修");
        }

        device.setStatus(DeviceStatus.REPAIRING);
        deviceInfoMapper.updateById(device);

        DeviceRepairRecord record = new DeviceRepairRecord();
        record.setDeviceId(form.getDeviceId());
        record.setFaultDesc(form.getFaultDesc());
        record.setStatus(0);
        record.setApplyTime(LocalDateTime.now());
        repairRecordMapper.insert(record);
    }
}

这里的核心逻辑是：先查设备，校验当前状态，再更新状态，再插入流水。事务用@Transactional(rollbackFor = Exception.class)，必须要写rollbackFor，因为Spring默认只对RuntimeException回滚，如果业务方法抛出的是自定义受检异常，不加这个参数事务就不会回滚。

维修完成的逻辑类似，把设备状态改回IN_USE，同时把维修流水状态置为已完成，补上完成时间和维修费用。事务再加一层：判断维修流水必须存在且当前状态是维修中，否则直接抛异常。

4.3 统计报表的实现思路与SQL示例

报表统计不要想着在Java代码里做内存计算，直接SQL聚合是最简单高效的方式。三个常用报表：

按设备状态统计：

sql复制SELECT
  CASE status
    WHEN 0 THEN '在库'
    WHEN 1 THEN '在用'
    WHEN 2 THEN '维修中'
    WHEN 3 THEN '已报废'
  END AS statusName,
  COUNT(*) AS cnt
FROM device_info
WHERE deleted = 0
GROUP BY status;

按科室统计设备数量：

sql复制SELECT d.name AS deptName, COUNT(di.id) AS deviceCount
FROM sys_department d
LEFT JOIN device_info di ON d.id = di.department_id AND di.deleted = 0
GROUP BY d.id, d.name;

按类型统计：

sql复制SELECT c.name AS categoryName, COUNT(di.id) AS deviceCount
FROM device_category c
LEFT JOIN device_info di ON c.id = di.category_id AND di.deleted = 0
GROUP BY c.id, c.name;

这里推荐把统计SQL都写到Mapper的XML里，用<select>返回一个List<Map<String, Object>>，前端拿到直接渲染ECharts。SQL能完成的聚合不要搬到Java里循环累加，一个是代码丑陋，另一个是数据量大时效率完全不在一个量级。

4.4 保养提醒功能：Spring Schedule一小时内搞定

保养提醒的实现方式很简单：在设备表上加一个next_maintain_time字段，每次录入保养记录时自动把下次保养时间算好（比如按“季度保养”推三个月）。每天凌晨跑一次定时任务，筛选出距下次保养时间不足7天且状态为“在用”的设备，插入提醒消息表即可。

java复制@Component
public class MaintainRemindTask {

    @Autowired
    private DeviceInfoMapper deviceInfoMapper;

    @Autowired
    private RemindMessageMapper remindMessageMapper;

    @Scheduled(cron = "0 0 8 * * ?")
    public void remindMaintain() {
        LocalDate today = LocalDate.now();
        LocalDate threshold = today.plusDays(7);

        List<DeviceInfo> list = deviceInfoMapper.selectList(
            new LambdaQueryWrapper<DeviceInfo>()
                .eq(DeviceInfo::getStatus, DeviceStatus.IN_USE)
                .eq(DeviceInfo::getDeleted, 0)
                .isNotNull(DeviceInfo::getNextMaintainTime)
                .le(DeviceInfo::getNextMaintainTime, threshold)
        );

        for (DeviceInfo device : list) {
            RemindMessage msg = new RemindMessage();
            msg.setDeviceId(device.getId());
            msg.setDeviceName(device.getName());
            msg.setType(1);
            msg.setContent("设备[" + device.getName() + "]将在"
                    + device.getNextMaintainTime() + "到达保养时间，请及时安排保养");
            remindMessageMapper.insert(msg);
        }
    }
}

记得在启动类或配置类上加@EnableScheduling，否则这个注解不会生效，我就见过有人在这里卡了一晚上。

5. 四周开发排期与真实踩坑记录

毕设开发最怕超期。给你一个可执行的四周方案，每天保证3到4小时，完全来得及。

5.1 可执行的四周开发计划

这四周里，第3周是最容易延期的一周，因为状态流转涉及的代码量比普通CRUD多不少。如果中间时间紧张，优先保状态流转和演示数据，做不完的统计报表可以先用一个简单的数据接口顶着。

5.2 演示数据怎么造才显得真实

答辩演示时最尴尬的事就是数据“假大空”：设备名称全是“设备1”“设备2”，科室全是“A科室”，一看到就没有说服力。

演示数据至少要达到这种真实感：

• 设备名称用真实设备名：多参数监护仪、高端彩色多普勒超声诊断系统、全自动生化分析仪、呼吸机、除颤仪
• 科室用真实医院科室：心内科、呼吸科、ICU、手术室、放射科、检验科
• 生产厂家和供应商用行业常见名称，不必精确但要有认知度
• 价格数值合理：监护仪2到5万，彩超几十万到百万级，生化分析仪几十万
• 维修记录要有时间跨度：某台设备是半年前买的、两个月前修过一次、上个月做过保养，这样屏幕上展示设备时间线时才丰满

最好再准备一两条“有意思”的数据，比如一台设备修了三次、维修费用加起来快赶上设备价格的20%，这类数据讲故事效果很好，答辩时能顺便聊出“设备维修策略”的话题，直接拉高整个问答环节的深度。

5.3 真实开发中踩过的一些坑

这里写几个我实际踩过、并且辅导过的学生也经常踩的坑，有些问题排查起来非常浪费时间：

坑一：MyBatis Plus分页不生效。 表现是selectPage查出来的records全表返回或total为0。基本原因就是缺少MybatisPlusInterceptor的Bean配置。网上教程版本很杂，一定要确认自己的MyBatis Plus版本，3.5.x的分页插件配置方式就是我在前面写的那种，旧版的PaginationInterceptor已经废弃了。

坑二：时间字段差8小时。 数据库存进去是早上8点，页面显示却是凌晨0点。解决方案：数据库连接串加serverTimezone=Asia/Shanghai，Spring Boot用Jackson统一序列化日期格式时指定time-zone=GMT+8。前端的格式化也要统一，建议后端直接返回格式化后的字符串，避免前端各写各的。

坑三：JSON序列化循环引用。 设备关联了部门，部门又可能关联设备列表的字段，直接返回实体对象时容易出现各种嵌套。处理方式简单粗暴：返回前端的VO里只放需要展示的字段，关联信息在Service层通过查询拼装好，不要图省事直接返回Mapper查出来的实体。

坑四：事务没有生效但没报错。 最常见的原因是同类内部调用，比如DeviceRepairServiceImpl的方法a去调用同类方法b，b上有@Transactional，但方法a没有事务，通过this调用时事务注解是失效的。Spring事务是靠代理对象触发的，直接this.method()绕过了代理。解决方案：把需要事务的代码拆到另一个Service，或者在入口方法上直接加事务。答辩时这是老师喜欢追问的点，提前搞懂非常有价值。

坑五：改表结构后代码没同步。 开发期数据库表字段改动很频繁，今天给设备表加了next_maintain_time，忘了更新实体类；明天改了字段名，Mapper XML里的resultMap没同步，这类小问题特别消耗耐心。建议每改一次表结构，顺手把实体类、Mapper XML、前端表单三处一起检查一遍，固定这个习惯能省很多调试时间。

6. 答辩讲解重点与高频追问

最后说答辩。系统做得再好，讲不出来在毕业设计这个场景里等于白做。演示和讲解答辩时永远遵循一个原则：讲清楚一条完整业务链路，远胜于把每个页面都过一遍。

6.1 演示线怎么设计

不要打开系统就从登录页开始一寸一寸往下点，15分钟根本不够，也抓不住重点。设计一条“有故事”的演示线：

1. 登录进入首页，快速带过统计仪表盘，展示设备总数、各状态分布、维修费用趋势，证明系统有数据支撑能力；
2. 进入设备台账，挑一台设备，展示它的完整时间线：买来、领用、维修过两次、下个月需要进行保养；
3. 模拟报修流程：把某台在用设备报修，演示设备状态变为维修中，维修流水自动生成；
4. 维修完成，设备恢复“在用”，找到刚才的维修流水，展示维修费用和完成时间；
5. 切到提醒列表，展示那台设备即将到期，顺带说明定时任务如何每天扫描；
6. 打开统计报表，按科室和类型各看一张图，收尾。

这条线走下来，状态流转的每个环节都展示了，数据一致性、事务处理、定时任务、权限控制这些技术点也都被自然带出来了。

6.2 高频提问与应答思路

老师常见追问和对应的应答逻辑：

• “设备状态为什么不在前端控制？” 答：前端只能决定交互，不能决定数据正确性。状态流转必须在后端Service层做合法性校验，否则渠道绕过页面直接调接口，状态就能乱跳。
• “你在状态流转里如何保证数据一致？” 答：以维修流程为例，更新设备状态和新增维修流水放在同一个事务里，任何一个失败都整体回滚；同时每次状态变更都做前置状态校验。
• “设备编码重复怎么办？” 答：数据库层有唯一索引做兜底，业务层在插入前也做了重复校验，并且在逻辑删除场景下对编码做了特殊处理，避免逻辑删除后同编码插入冲突。
• “如果维修服务宕机了，正在处理中的维修单会怎么样？” 答：数据库已经持久化了报修信息和流水，重试或人工补偿后，把维修完成动作再次提交即可，整个流程天然支持断点恢复。
• “你的权限控制怎么做的？” 答：RBAC模型，登录后颁发JWT，后端拦截器校验Token和角色，不同角色能访问的接口集合不同，菜单也按角色渲染。

这些问题不需要你背标准答案，关键是真实理解系统的设计过程。你把前面第4章的代码逻辑吃透了，这些问题聊起来都有话说。

从我带项目的经验看，这个题目拿高分的关键永远不是脚手架多花哨、页面多炫酷，而是设备从入库到报废这条完整链路有没有闭环、状态边界有没有卡死、数据留痕能不能经得起追问。把这两点做到位，代码再朴素也能在答辩时站得住脚。