医院设备管理系统Java毕设：全流程管控设计与实现

医院设备管理系统这个题目，在Java毕业设计里算得上是个“常青树”。每年选题季都有大量同学在它和“xx管理系统”之间犹豫，但说实话，真正能把设备“全流程”讲清楚、把维修保养这些业务节点做成闭环的毕设，其实不算多。很多人的系统说白了就是一套设备信息的增删改查，档案有了、表出来了，可一旦老师问“一台设备从报修到报废，你的系统是怎么跟踪的”，立刻就露馅了。

这篇内容我就以“医院设备信息化管理平台”为载体，把这类全流程管控系统的选题思路、功能设计、数据库建模、核心代码实现以及答辩注意事项完整拆一遍。适合正在准备Java毕业设计的学生，也想用Spring Boot做企业级信息化项目练手的开发者参考。我会把业务逻辑和技术方案结合起来讲，不绕弯子，直接告诉你哪些地方值得做深、哪些地方点到为止，以及怎么用有限的代码量把“全流程管控”这个点真正立起来。

1. 选题价值与整体设计思路

1.1 为什么医院设备管理系统值得做

先聊选题价值。很多同学选管理系统类题目时有个误区，觉得“图书馆管理”“宿舍管理”这类系统业务简单、代码好写，选它比较稳妥。但这类系统的弊端也很明显：业务单薄，模块撑不起来，写到后期发现除了CRUD没有实质内容，论文也不好展开。

医院设备管理系统恰恰相反，它属于行业内真正有信息化的痛点领域。三甲医院的设备总数动辄上万台，小到血压计、大到CT机，分布在全院几十个科室，采购、入库、领用、维修、保养、计量、报废，每一环都要记录在案。传统纸质台账最大的问题在于“数据孤岛”：维修记录在维修工手里、资产账目在财务手里、使用情况在科室手里，盘点时全靠人肉对账，效率和准确性都很难保证。

这套系统把设备的全生命周期数据集中起来，科室可以随时查到自己名下设备的档案和维修历史，设备科能统一安排保养计划，维修工程师能在线上接单、填写维修记录，管理员通过报表掌握全院设备分布和维修成本。这种“一个平台管全院设备”的业务闭环，天然适合作为毕业论文的选题——它既有业务深度，又有技术踩坑点，还方便做功能演示。

1.2 毕设层面的定位与取舍

做毕业设计和做商用系统是两码事，你的目标不是把系统做到三甲医院能上线的程度，而是让评委老师认可你的业务理解、技术运用和工程设计能力。所以切忌一上来就想做全做完整，什么AI预测性维护、物联网设备监控、RFID自动盘点全加上，最后哪个都做不深。

我建议把系统的核心定位在“全流程管控”四个字上：以设备档案为基础，以维修、保养、巡检、报废这些动态业务为主线，配合统计报表和权限管理。技术难点围绕设备状态流转、工单状态机、定时任务生成保养提醒、多条件组合查询这些点展开。这样既覆盖了信息化管理系统最典型的业务场景，又能把Spring Boot、MyBatis Plus、MySQL这些主流技术栈用扎实。

至于RFID、大屏可视化、移动端扫码这类亮点功能，可以作为扩展方向放在系统的后期规划里，或者在能力允许的情况下做一个简单的二维码查看设备档案功能，作为加分项，但不要让它喧宾夺主。核心永远是“流程完整、逻辑严谨、演示流畅”。

1.3 技术栈选型的理由

技术栈我推荐用Spring Boot + MyBatis Plus + MySQL + Vue（或Thymeleaf）的组合。选这套方案不是因为它最前卫，而是它对毕设场景最友好。

Spring Boot简化了配置和部署，不再需要写一堆XML配置文件，内置Tomcat让项目在答辩演示时能快速启动，稳定性也有保障。MyBatis Plus在MyBatis基础上解决了单表CRUD的重复劳动问题，分页插件、代码生成器、逻辑删除这些都内置好了，可以把更多精力放在业务逻辑而不是持久层样板代码上。数据库用MySQL，免费、通用、资料多，遇到问题搜索一下基本都能找到答案。

前端的选择上，如果你熟悉Vue且时间充裕，就做前后端分离，Vue3 + Element Plus，项目结构更清晰、界面更现代，答辩时也更有说服力。如果你时间紧张或者对前端不太熟，直接用Thymeleaf服务端渲染做单体项目也能完成，只是界面效果会低调一些。有一点要注意：不管选哪种前端方案，RESTful接口设计都要规范，试卷答辩时老师很可能会抽查接口的返回格式和状态码定义。

一个小建议：如果打算快速搭底子，RuoYi框架的若依前后端分离版本可以省下权限管理、代码生成这些基础模块的开发时间。但用框架不等于抄框架，你需要在文档里讲清楚框架本身的设计思路，不然答辩时老师问“Spring Security的过滤器链是怎么工作的”就答不上了。

2. 核心功能模块与全流程业务拆解

2.1 设备档案管理：全流程的数据地基

设备档案是整套系统的“地基”，所有维修、保养、巡检、报废操作最终都要落到某一台具体设备上。档案模块除了基础CRUD，还要特别注意两个设计点：设备分类的树形结构和一物一码的台账唯一性。

设备分类建议设计成树形结构，比如“医学影像类-超声诊断设备-彩色多普勒超声”，这样既支持按大类统计，又能精确到二级三级分类。数据库里用parent_id自关联字段实现树形结构，在MySQL里就是一张表加一个pid字段，查询时递归组装成树。这里要注意，如果设备量很大、层级很深，递归查询的性能会是个隐患，但毕设数据量完全不用担心。

每台设备要有唯一的设备编号，这是设备档案的核心标识。编号规则可以按“分类码+科室码+流水号”生成，比如YXYX-FSK-0001。生成逻辑最好放在后端统一处理，避免用户随便填导致重复。我在代码实现里习惯用一个自定义的编号生成器，核心逻辑就是根据分类和科室查流水号，生成后写入数据库，再加个唯一索引兜底，这个写法下面会更详细地讲。

关于“一物一码”，毕设阶段最经济的做法是给每台设备生成二维码标签，科室扫码就能跳到设备详情页。二维码用ZXing库生成PNG图片，存到服务器指定目录，前端展示标签打印预览。能做成扫码查看设备信息，其实已经比大多数纯CRUD的毕设有亮点了。

2.2 维修工单：状态机驱动的闭环流程

设备管理里最能体现“全流程”的模块就是维修工单。它的流程是这样：科室发现设备故障，录入报修单，描述故障现象、设备编号、紧急程度；设备科的调度人员审核后派单给某个维修工程师；工程师接单后到现场处理，填写维修内容、更换配件、维修费用；维修完成后提交给报修科室验收，科室确认故障解决后关单，整个工单才算走完。

这个流程的本质是一个状态机：待派单 → 维修中 → 待验收 → 已完成，中间还有“已驳回”和“已关闭”这两个终止或回退状态。实现方式可以简单点，用status字段存数字：0待派单、1维修中、2待验收、3已完成、4已驳回。每次状态变更时，后端校验当前状态是否允许做这个操作，比如“待派单”状态下不能直接填验收结果，“维修中”状态下不能再次派单。

前端根据不同的状态展示不同的操作按钮，后端在Service层写状态校验逻辑，双层控制才能保证流程不被跳步。我在后面会给出一个最简的updateStatus方法，这套状态校验思路如果能在论文的“状态图设计”部分用标准状态机图描述，是一个很不错的加分项。

2.3 保养与巡检：定时任务驱动的计划性工作

设备不能坏了才修，日常保养和巡检是医院设备管理的重点。这个模块的核心在于“计划性”：设备科提前制定每个设备的保养周期（比如半年保养一次）、巡检周期（比如每月一次），系统每天检查一遍哪些设备的保养计划已经到期或即将到期，然后生成待办任务。

技术上用Spring的@Scheduled定时任务就能实现，每天凌晨执行一次任务，扫描保养计划表，把到期设备的记录插入到任务表中，同时在系统首页的待办中心里提示设备科处理。如果想让演示效果更好，可以再加一个“距离保养剩余天数”的查询条件，设备列表上能看到“即将到期”“已过期”这些预警状态。

这里要提醒一个细节：因为毕设的演示数据通常是导入或模拟的，如果保养周期设成半年，演示时看到的效果就是“没有任何到期设备”。所以设计时要留一个“手动触发到期检查”的按钮，演示前把某台设备的保养日期改成昨天，点一下检查，马上能看到预警效果。这种演示细节想得越周到，答辩时越不慌。

2.4 计量校准与报废管理：行业特色功能

计量校准是医院设备管理系统区别于普通企业资产管理系统的重要特征。医院里有大量强检设备，比如血压计、心电监护仪、除颤仪，这些设备必须按规定周期送计量院检测，确保数据准确。系统里可以做一个计量管理页面，记录每台设备的检定日期、有效期、检定单位、检定结论，到期前自动预警。这个功能的业务逻辑和保养计划很像，但数据字段不同，属于“换汤不换药”但很见业务功底的模块。

报废管理则是设备生命周期的终点。设备到达使用年限或损坏无法修复时，由使用科室发起报废申请，填写报废原因、设备状态、残值评估，设备科审核通过后，这台设备的状态从“在库/使用中”变更为“已报废”，从在用设备清单中移出，但档案和历史维修记录仍然保留。这里要注意的是，报废不等于删除，要用状态变更+逻辑删除的思路处理，保留完整的追溯链条。

2.5 统计报表：让数据可见

报表模块是很多毕设做得比较薄弱的环节，但其实它的业务价值很高。一个完整的医院设备管理系统至少应该有这几张核心报表：全院设备分类统计（饼图）、各科室设备数量分布（柱状图）、设备维修费用按月统计（折线图）、设备状态分布（仪表盘）。

数据接口写好之后，前端用ECharts渲染图表。前端定时从后端拉取统计数据，后端的SQL用GROUP BY按维度汇总。这块的整体体量不大，但对项目的“完整度”提升非常明显。你在论文的功能设计部分，可以用几张截图直观展示系统在辅助管理决策方面的能力，作为功能模块的补充说明。

3. 技术选型与数据库建模的核心细节

3.1 核心数据表设计：先搭骨架再谈实现

数据库设计是毕业设计论文的重头戏。根据上面的模块分析，核心表至少要有这些：

device_info表的DDL示例（关键字段）如下：

sql复制CREATE TABLE `device_info` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `device_code` varchar(50) NOT NULL COMMENT '设备编号',
  `category_id` bigint(20) NOT NULL COMMENT '设备分类ID',
  `dept_id` bigint(20) NOT NULL COMMENT '使用科室ID',
  `device_name` varchar(100) NOT NULL COMMENT '设备名称',
  `model` varchar(100) DEFAULT NULL COMMENT '规格型号',
  `manufacturer` varchar(100) DEFAULT NULL COMMENT '生产厂家',
  `purchase_date` date DEFAULT NULL COMMENT '购置日期',
  `price` decimal(12,2) DEFAULT NULL COMMENT '购置价格',
  `warranty_end` date DEFAULT NULL COMMENT '保修截止',
  `status` tinyint(4) NOT NULL DEFAULT '1' COMMENT '状态：0停用 1在用 2维修 3报废',
  `remark` varchar(500) DEFAULT NULL COMMENT '备注',
  `create_time` datetime DEFAULT CURRENT_TIMESTAMP,
  `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `deleted` tinyint(1) DEFAULT '0' COMMENT '逻辑删除',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_device_code` (`device_code`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='设备档案表';

设备状态字段我用tinyint类型存整数值。有个细节值得说明：设备状态的“维修中”和维修工单状态的“维修中”不是一回事，设备状态是设备当前的实体状态，工单状态是故障处理流程的状态。设备报修后，工单进入“维修中”，同时设备状态也要同步变为“维修中”；工单验收完成后，设备状态恢复为“在用”。这些状态的联动逻辑，是设备全流程管控的一个核心点，写代码时要格外注意。

3.2 状态流转逻辑：从状态字段到状态校验

维修工单的状态最典型，直接用int存状态其实是最实用的一种方式。状态枚举我习惯单独用一个枚举类维护，不要魔法值满天飞：

java复制public enum RepairStatus {
    PENDING(0, "待派单"),
    REPAIRING(1, "维修中"),
    PENDING_ACCEPT(2, "待验收"),
    COMPLETED(3, "已完成"),
    REJECTED(4, "已驳回");

    private final int code;
    private final String desc;

    RepairStatus(int code, String desc) {
        this.code = code;
        this.desc = desc;
    }
    // getter...
}

状态变更的核心方法可以这样设计：

java复制public boolean changeStatus(String orderNo, int targetStatus, Integer operatorId) {
    RepairOrder order = repairOrderMapper.selectByOrderNo(orderNo);
    if (order == null) {
        throw new BizException("工单不存在");
    }
    // 状态流转合法性校验
    switch (order.getStatus()) {
        case 0: // 待派单
            if (targetStatus != 1 && targetStatus != 4) {
                throw new BizException("待派单状态只能派单或驳回");
            }
            break;
        case 1: // 维修中
            if (targetStatus != 2) {
                throw new BizException("维修中状态只能提交验收");
            }
            break;
        case 2: // 待验收
            if (targetStatus != 3 && targetStatus != 1) {
                throw new BizException("待验收状态只能验收通过或退回重修");
            }
            break;
        default:
            throw new BizException("工单已结束，不可变更状态");
    }
    // 更新工单状态和操作人信息
    UpdateWrapper<RepairOrder> wrapper = new UpdateWrapper<>();
    wrapper.eq("order_no", orderNo).eq("status", order.getStatus());
    // 带状态条件更新，防止并发环境下状态被覆盖
    RepairOrder update = new RepairOrder();
    update.setStatus(targetStatus);
    int rows = repairOrderMapper.update(update, wrapper);
    return rows > 0;
}

注意到wrapper.eq("status", order.getStatus())这个细节了吗？这是乐观锁的思路，更新时带上当前状态作为条件，如果更新行数为0，说明数据已经被其他操作改过，就提示用户刷新后重试。这种写法在并发场景下能有效避免状态覆盖问题，也方便在论文里聊“并发控制”这个话题。除了维修工单，报废申请、设备调拨这些流程也都可以用同样的方式处理。

3.3 设备编号生成与文件上传的工程化实现

设备编号生成，我推荐写一个编号生成器组件。核心思路是在同一分类和科室内生成自增流水号，比如根据分类编码和科室编码查当天已有多少个这类设备，生成CAT-DEPT-0001。这里有一个常见陷阱：从库里查max(device_code)然后+1在并发场景下可能会重复，所以要配合唯一索引兜底，插入时如果违反唯一约束，就重新生成再插入一次，或者更规范的做法是建一张“编号流水表”，用数据库的行锁或INSERT ... ON DUPLICATE KEY UPDATE来保证并发安全。

文件上传也会用到。设备档案可能包含设备照片、铭牌照片、说明书PDF，这些建议统一走一个公共的文件上传接口，前端存返回的URL。上传文件的话，注意几个问题：建立白名单限制文件类型（images/*、application/pdf），限制文件大小（比如不超过10MB），文件名用UUID重命名防止中文乱码和路径穿越。文件存储到本地磁盘即可，在配置文件里使用环境变量指定存储路径，代码里不要写死绝对路径。

3.4 定时任务与消息提醒的用法

保养到期检查，用Spring的@Scheduled开个定时任务就够了。我用一个简单的示例说明：

java复制@Component
public class MaintenanceCheckTask {

    @Resource
    private MaintenancePlanMapper maintenancePlanMapper;

    @Scheduled(cron = "0 0 2 * * ?") // 每天凌晨2点执行
    public void checkMaintenanceDue() {
        // 查询所有保养计划，计算下次保养日期是否在预警范围内
        List<MaintenancePlan> plans = maintenancePlanMapper.selectList(
            new LambdaQueryWrapper<MaintenancePlan>()
                .eq(MaintenancePlan::getStatus, 1)
                .le(MaintenancePlan::getNextMaintenanceDate, DateUtils.addDays(new Date(), 7))
        );
        for (MaintenancePlan plan : plans) {
            // 生成一条待办提醒
            TodoTask task = new TodoTask();
            task.setBizType("MAINTENANCE");
            task.setBizId(plan.getId());
            task.setTodoContent("设备[" + plan.getDeviceId() + "]需要保养，计划日期：" + plan.getNextMaintenanceDate());
            todoTaskMapper.insert(task);
        }
    }
}

这里le方法和日期计算那行就是判断未来的保养日期在当前时间之后7天内的条件。你可以把这个逻辑按自己的需求调整，比如到期前30天就提醒。生成待办任务这一层抽出来做的好处是，首页的“待办中心”可以统一展示维修待派单、保养到期提醒、计量即将到期、报废待审核这几类任务，用户一登录就能看到今天要处理的事，非常直观，答辩演示效果也更好。

4. 开发过程中踩过的坑与排查技巧

4.1 MyBatis Plus 多表关联查询的典型误区

MyBatis Plus最大的优势是单表CRUD自动化，但很多同学把一个错误用法当成“正确姿势”：在实体类里加一个不属于本表的字段，直接写@TableField(exist = false)避免报错，然后在Service层手动去查关联表，结果就是N+1查询性能爆炸。

比如维修工单列表要同时显示设备名称和报修科室名称，正确做法是写一个VO类，用自定义SQL联表查询：

java复制@Mapper
public interface RepairOrderMapper extends BaseMapper<RepairOrder> {

    List<RepairOrderVO> selectRepairOrderVOList(@Param("param") RepairOrderQuery query);

    // XML或注解SQL
    @Select("<script>" +
            "SELECT r.*, d.device_name, d.device_code, dp.dept_name AS report_dept_name " +
            "FROM repair_order r " +
            "LEFT JOIN device_info d ON r.device_id = d.id " +
            "LEFT JOIN department dp ON r.report_dept_id = dp.id " +
            "<where>" +
            "<if test='param.status != null'>AND r.status = #{param.status}</if>" +
            "<if test='param.keyword != null'>AND (d.device_name LIKE CONCAT('%', #{param.keyword}, '%') OR d.device_code LIKE CONCAT('%', #{param.keyword}, '%'))</if>" +
            "</where>" +
            " ORDER BY r.create_time DESC" +
            "</script>")
    List<RepairOrderVO> selectPageVO(...);
}

用<script>标签实现动态SQL有点丑，如果是正式项目还是建议写Mapper XML文件。但无论哪种方式，核心思路是清晰的：查询界面要展示的信息如果跨了好几张表，就在SQL层一次性查出来映射到VO，不要在Java代码里循环查库。这个原则掌握了，多表查询的坑就绕开了一大半。

4.2 设备编号并发生成重复：唯一索引是最后防线

我在测试时遇到过这样一个场景：用脚本模拟多个线程同时录入新设备，一段时间后数据库里出现了两条重复的设备编号。问题就出在“查当前流水号并加1”这一步不是原子操作，两个线程同时拿到同样的值，生成了一样的编号。

解决方式有好几层。第一层是在数据库的device_code字段上建唯一索引，这是必须做的，它保证哪怕代码出现了并发问题，数据库层面也不会写入重复数据。第二层是调整生成逻辑，用一个独立的numbering_rule表来维护每个分类+科室的当前流水号，更新时用UPDATE ... SET current_no = current_no + 1 WHERE category_code = ? AND dept_code = ?这样的原子操作，让数据库来保证并发安全。还有个土办法，就是在编号里加入时间戳，比如年月日时分秒+三位随机数，撞车的概率几乎为零，但编号可读性会差点。毕设阶段我推荐第一种方案（唯一索引）加第二层（原子自增）组合使用，既有技术深度又稳定可靠。

4.3 树形结构查询的两种实现思路

部门表和设备分类表都是树形结构。树形查询有两种常用做法：第一种是查全表后在内存中组装成树，适合数据量小、层级少的情况；第二种是写递归查询。

如果数据量不大，直接查全表后在服务端用Stream组装是最高效的写法：

java复制public List<DeviceCategoryVO> buildCategoryTree() {
    List<DeviceCategory> allList = deviceCategoryMapper.selectList(null);
    Map<Long, List<DeviceCategoryVO>> groupByParent = allList.stream()
        .map(this::toVO)
        .collect(Collectors.groupingBy(v -> v.getParentId() == null ? 0L : v.getParentId()));
    List<DeviceCategoryVO> roots = groupByParent.getOrDefault(0L, new ArrayList<>());
    roots.forEach(root -> buildChildren(root, groupByParent));
    return roots;
}

这种组装方式的核心就是groupByParent这个Map：把每个节点按父ID分组，然后从根节点开始递归设置子节点。逻辑简单，代码量也少。

4.4 日期分组统计的边界问题

统计报表里最容易出bug的是按时间分组。有一个经典错误：用Java代码去遍历日期、然后逐天查数据库，这样性能差而且代码丑。正确思路是让数据库返回分组结果，利用DATE_FORMAT对日期格式化后分组：

sql复制SELECT DATE_FORMAT(create_time, '%Y-%m') AS month,
       COUNT(*) AS repair_count,
       IFNULL(SUM(cost), 0) AS total_cost
FROM repair_order
WHERE create_time >= #{startDate} AND create_time <= #{endDate}
GROUP BY DATE_FORMAT(create_time, '%Y-%m')
ORDER BY month

还有个更隐蔽的坑：如果某个月没有维修工单，GROUP BY的结果里根本不会出现这个月，报表曲线就会“断月”。解决方式是在Java里生成一个完整的月份列表，把数据库返回结果放进Map里，然后遍历月份列表做填充，缺失月份补0。别小看这个细节，很多线上报表系统都有这种“月历缺失”的问题。

4.5 权限控制：拦截器还是框架？

毕设系统的角色一般分为：系统管理员、设备科工作人员、维修工程师、科室普通用户。权限控制如果从零手写拦截器，逻辑确实不复杂，就是登录校验加角色判断。但如果你想在论文里写“采用Spring Security实现认证与授权”，就要保证自己真正理解框架的原理，否则答辩老师一句“Spring Security的过滤器链执行顺序是怎样的”就能问住你。

我的建议是：优先用RuoYi这类框架的权利管理部分（基于Spring Security + JWT），把用户、角色、菜单管理当作系统基础功能，把精力留给业务模块。如果时间非常充裕，可以考虑在权限的基础上加入更细粒度的数据权限，比如“维修工程师只能看到派给自己的工单，设备科能看到全部工单”。数据权限这个点做出来，在答辩中是非常好的技术亮点，而且实现并不复杂——在SQL层面根据当前登录用户的角色自动拼接查询条件即可。

5. 答辩必问高频问题与项目扩展方向

5.1 演示流程设计与核心问答准备

答辩演示的流程建议按业务故事线走，不要按菜单顺序走，这样评委的记忆点会更清晰。以一套比较成熟的演示流程为例，可以这样排：

1. 登录系统，展示首页设备总览和待办提醒，让评委先看到“系统有全景视图”。
2. 进入设备档案页面，演示设备的新增和二维码生成，用手机扫一下二维码可以直接看设备详情——这个动作现场效果很好，但要提前准备好可用的二维码打印机或手机扫码的条件。
3. 走一遍完整的维修流程：A科室发起报修 → 设备科派单给工程师 → 工程师在系统里接单并填写维修记录 → A科室验收关单。同时展示设备状态从“维修中”回到“在用”的变化。
4. 把某台设备的保养日期改成过期，手动触发保养检查任务，展示首页弹出保养提醒。
5. 打开报表页面，展示科室设备分布图、维修费用趋势图。
6. 最后可以提一句射频识别和移动端扫码的规划方向，作为“后期扩展”，点到为止。

老师常问的问题基本集中在：数据库为什么这样设计、状态流转是怎么控制的、并发问题怎么解决、权限是怎么实现的、这套系统相比传统管理方式的优势体现在哪。提前把这几块的思路准备通，基本就稳了。

5.2 三个低成本高回报的扩展方向

如果做完整套基础版之后还有时间，我优先推荐三个扩展方向，它们对现有代码改动不大，但对项目深度提升很明显。

第一个是微信小程序端扫码查看设备。后端提供两个接口（根据设备编号查详情、查询我的待办工单），小程序端用微信的wx.scanCode扫码后跳转详情页。这个功能适合现场演示，而且“移动端”这个技术在毕设答辩里天然自带加分属性。

第二个是设备调拨审批流程。院内设备在科室之间调拨是很常见的业务，做一个调拨申请单、设备科审批、调拨记录留痕的闭环。这个功能复用维修工单的状态流转模式，代码工作量不大，但能说明你对医疗业务的理解更深入。

第三个是数据大屏展示页面。用大屏展示设备总数、在用设备占比、本月维修次数、本月保养完成率这些关键指标。大屏的视觉冲击力比较强，放在演示开场页效果非常好。ECharts加一个全屏页面就能搞定，重点是布局和配色。

5.3 版本节奏控制建议

最后给一条实用建议：做毕设系统一定要学会控制节奏，不要因为追求完美而卡在某一个模块里出不来。建议把开发过程拆成三个阶段：前两周完成需求分析、数据库设计、项目骨架搭建；中间三周按设备档案、维修管理、保养巡检、统计报表的顺序完成核心功能；最后一周专门做演示环境准备、测试数据导入、答辩PPT和演示脚本。所有涉及“锦上添花”的功能，都放到核心功能全部通过自测之后再做。

说实话，每年都能看到一些同学在“报表图表太丑”“前端动画效果不好”这种表面上花掉大量时间，最后核心业务逻辑反而没写清楚，这是很典型的本末倒置。毕业设计最终考察的核心永远是：你在解决一个真实业务问题时，有没有形成完整的分析、设计、实现与验证链条。把这条链做实，远比一个花哨的动效重要得多。