Java毕业设计：中小型医院医疗器械管理系统开发全解析

每年答辩季前，总有一大批计算机专业的学生在同一个问题上反复纠结：手里这个毕设题目，到底怎么做才能既顺利过审，又让自己真正学到东西。Java中小型医院医疗器械管理系统，是近几年出现频率非常高的一个选题，它不像图书管理、商城系统那样烂大街，但难度又恰好卡在本科生能独立完成的范围里，更重要的是业务链条足够长——设备台账、出入库、领用归还、维修保养、报表统计全都有，随便挑一个方向都能在论文里写出东西。这篇文章就把这个题目的拆解过程、功能设计、数据库建模、核心代码、技术栈扩展和答辩准备完整捋一遍，不管是正在选题目，还是已经选了类似题目的同学，都可以参考。

1. 为什么选中医疗器械系统当毕设，而不是图书管理或购物商城

1.1 “中小型医院”这个限定，直接把复杂度锁死在了舒服的位置

很多同学选毕设题目时有个误区：觉得题目越复杂越能体现水平。但实际上，本科生毕设的时间是有限的，三四个月里还要应付课程、实习和找工作。如果选一个核心链路特别长的系统，比如大型医院的全院信息系统，光需求梳理就要花半个月，最后代码堆到十几万行，答辩老师一问三不知反而扣分。而砍掉门诊挂号、医生工作站这些外围功能，聚焦“医疗器械”这一个垂直领域，业务规模就变成了“中小型医院”的体量：科室数量控制在几十个以内，设备数量几百到上千，库存流转频率不高，完全不需要引入微服务、分布式事务、消息队列那些重型技术。

这个复杂度用单体应用其实就够了，Spring Boot + MyBatis + MySQL 可以非常舒服地跑完整条链路。对于大部分学生来说，这种“有点挑战但不是天坑”的粒度是最理想的。你既不会因为功能太多导致做不完，也不会因为功能太少导致论文没东西写。而且毕业后出去面试，中小型医院管理系统里的设备状态流转、维修工单流程、库存扣减这些业务，跟真实企业项目的逻辑是接近的，聊起来也不尴尬。

1.2 对比常见选题，这个题目赢在业务有真实约束

图书管理系统的问题是业务太弱，所有操作基本上就是增删改查，答辩时很难讲出亮点。购物商城的难点在支付和库存并发，但模拟支付又很假，评委经常追问“你这个支付安全怎么做”，很难收场。而医疗器械管理系统的特点是每一个业务动作都有真实世界的规则约束：设备领用要有状态变化，维修要有流程审批，报废要有审批。这些约束天然就是论文里的“业务合理性分析”，也是代码里可以用状态机、事务和权限控制来体现工程能力的地方。

评委拿到这种题目，不会问“为什么要做这个功能”，因为医院设备管理的需求是实打实存在的，一抓一大把。他更可能问的是“你这个功能边界是怎么定的”，比如一台设备在维修中能不能被领用，保修到期提醒是怎么算出来的。这些问题只要你深入想过，就能聊出很多内容。而如果做的是纯CRUD系统，评委想追问都不知道往哪个方向问。

1.3 它天生兼容好几种技术栈的扩展方向

标题里提到的可做方向很多：Java、PHP、小程序、数据可视化、爬虫等等。我后面梳理这套系统时发现，它之所以能横向扩展，是因为核心业务模型是稳定的：设备、科室、厂商、入库、领用、维修，不管前端是网页还是小程序，后端是Java还是PHP，这套数据关系都不会变。所以本科阶段选这个题目，相当于给自己留了一条后路——如果后来发现Java的某些框架学不动，换成PHP去重写，业务逻辑也还是那一套。

这一点在选题目时非常重要，尤其是那些技术栈还没有定下来，或者导师只给了个方向的同学。你不需要在刚开始做就决定最终用哪个语言写，可以先把这个题目的业务逻辑梳理清楚，然后根据自己的技术情况选择最合适的落地方案。这也意味着，如果你看到一套别人用Java写的源码，但你擅长的是PHP或小程序，你不需要推倒重来，只需要做技术迁移，业务部分可以完全保留。

2. 从科室需求倒推功能模块：设备台账、出入库、维护保养、预警提醒

2.1 先画角色，再画功能

做这种管理系统，第一件事不是写代码，而是搞清楚有哪几类人会用这个系统。医疗器械管理涉及的岗位大概是这几类：

• 系统管理员：负责科室、用户、权限的初始化配置，一般不参与具体业务流程。
• 设备科操作员：核心使用者，负责设备入库、台账录入、信息修改。
• 科室使用人：领用设备、归还设备、上报故障。
• 维修工程师：接收报修单、填写维修结果。
• 院领导或管理层：看报表，不看单据细节。

每一类角色能看到的菜单和数据权限都不一样。这个角色矩阵就是后面设计权限表、操作日志表的基础。很多学生的毕设只有“管理员”和“普通用户”两种角色，那在这个题目里就有点说不过去，因为设备的“使用”和“管理”本身就是分离的，你至少要把“科室用户”和“设备科操作员”分开，才能体现出系统的业务价值。这样划分角色之后，权限控制也能讲得更深入，而不是一句“admin有全部权限，user只有查看权限”就带过去。

2.2 设备台账：先把主表字段定清楚

核心表是一张设备信息表，字段设计时建议参考医疗器械管理的常见维度：设备编码、设备名称、设备分类、型号规格、生产厂商、供应商、出厂编号、购置日期、价格、保修截止日期、存放科室、当前状态、备注。这里要特别提醒：设备编码一定要用业务编码，不要用数据库自增主键去展示。设备编码要能体现分类和序号，比如“DX-2024-001”，这个编码规则在论文里写一段说明，显得很专业，还能顺带讲一下唯一索引的用途。

设备状态字段建议用int类型，用数字表示，比如0等于闲置、1等于在用、2等于维修中、3等于报废。为什么不直接用字符串？因为状态流转会非常频繁，用数字配合常量类可以避免字符串拼写错误，而且状态变更记录里只存一个int，将来做统计报表时也方便。这个点在答辩时经常被问到，提前想好例子就能答得顺畅，比如“维修中的设备不能直接被领用，因为它在状态机上不允许从维修中跳到在用以外的路径”。

2.3 出入库与领用归还：库存逻辑别硬编码

医疗器械和普通商品库存的不同在于，它更强调设备是跟着科室走的。设备从采购入库开始，就有了生命周期：入库登记、库房存放、科室领用、科室归还、维修、报废，每一步都对应一张单据。所以在设计时，我会把“库存”抽象成两层：一个是库存表，只记录当前数量；一个是出入库或领用归还的单据表，记录每一次流水。这样做的好处是，如果发现设备数量对不上，可以查流水找原因，而不是只能看到一个总数。

单据表基本字段包括：单据编号、关联设备、类型（入库、出库、领用、归还、调拨）、数量、操作人、关联科室、操作时间、备注。这里有一点要注意：数量字段不要写成“正数就是入库，负数就是出库”，最好用operation_type字段来区分类型，quantity统一存正数，这样后续做统计时不需要对正负号做特殊处理，语义更清晰。

2.4 维修与保养：流程状态是系统亮点

报修流程是这套系统里最有“流程感”的部分。科室发现设备故障后提交报修单，设备科操作员审核后指派维修工程师，工程师填写维修结果，设备科最终确认关闭工单。每一单都要记录报修时间、故障描述、报修科室、维修人、维修费用、完成时间结论。保养模块可以做计划管理：每台设备根据类型设置保养周期，系统按时提醒。这里提醒一句：保养记录和维修记录建议分开两张表，虽然都是“对设备的一次操作”，但业务性质完全不同，混在一张表里以后做统计会很别扭。

维修和保养分开之后，你还能在论文里分别画流程图。维修走的是“报修-派单-处理-验收”的审批链，保养走的是“计划-执行-记录”的周期链。两条线互相独立，视觉上就很清晰，答辩时讲起来也能体现出你对业务理解得比较透，而不是照着代码念。

2.5 预警提醒：让系统从“记录工具”变成“管理工具”

很多学生的毕设做完就是个CRUD，答辩时老师觉得功能太浅。要提升一个档次，最简单有效的方法就是加预警。医疗器械管理里有几个天然预警点：保修期还剩30天、保养计划到期、维修工单超48小时未完成、设备库存低于最低库存值。这些提醒不需要引入消息队列，最简单的方式就是写一个定时任务，每天晚上扫一遍数据库，把符合条件的记录插入提醒表。页面右上角做一个铃铛菜单，点进去看到未读提醒。

这个功能做起来不难，但会在演示时非常出彩，评委一眼就能看出来“这个系统真的有在管事”，而不是傻傻地记录数据。而且提醒模块还能承载一些扩展点，比如按角色区分提醒范围，或者用websocket做实时推送，这些都是论文里的“系统亮点”素材，可以先用基础版实现，有精力再加码。

3. 数据库是毕设的半条命：表结构设计要能从第一次答辩讲到最终答辩

3.1 十张左右核心表，足够撑起一个完整演示

很多同学一上来就设计二十多张表，显得很努力，但实际上很多表之间没有强业务关联，反而让答辩老师怀疑你是不是为了凑表数而硬加的。我会建议核心表控制在十张左右：用户表、角色表、用户角色关联表、科室表、设备分类表、设备信息表、库存表、出入库或领用归还流水表、报修工单表、保养计划表、提醒表、操作日志表。这样一共十二张，已经非常完整了。如果还要做权限，可以再拆出菜单表和角色菜单关联表，但注意，表数量多不代表设计好，关键在于每张表之间的关系清晰，外键逻辑能讲通。

这个数据量放到中小型医院也是匹配的，几十个科室、上千台设备，数据规模不会夸张到需要分库分表。你把表结构设计得“够用但在关键位置留了扩展余地”，这个尺度最能得到评委认可。

3.2 设备信息表的建表语句示例

直接给一段SQL示例，你可以在建表基础上做调整：

CREATE TABLE `device_info` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键', `device_code` varchar(32) NOT NULL COMMENT '设备编码', `device_name` varchar(128) NOT NULL COMMENT '设备名称', `category_id` int(11) NOT NULL COMMENT '设备分类ID', `model` varchar(64) DEFAULT NULL COMMENT '型号规格', `manufacturer` varchar(128) DEFAULT NULL COMMENT '生产厂商', `supplier` varchar(128) DEFAULT NULL COMMENT '供应商', `factory_no` varchar(64) DEFAULT NULL COMMENT '出厂编号', `purchase_date` date DEFAULT NULL COMMENT '购置日期', `price` decimal(12,2) DEFAULT NULL COMMENT '购置价格', `warranty_expire` date DEFAULT NULL COMMENT '保修截止日期', `dept_id` int(11) NOT NULL COMMENT '存放或使用科室ID', `status` int(11) NOT NULL DEFAULT '0' COMMENT '状态 0闲置 1在用 2维修中 3报废', `create_time` datetime NOT NULL COMMENT '创建时间', `update_time` datetime NOT NULL COMMENT '更新时间', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='设备信息表';

注意几个细节：价格字段用decimal不要用float，因为金额计算会涉及精度问题。所有时间字段不要用varchar存，虽然确实有些学生图省事这么干，但答辩老师问“按月份统计设备购置金额”这种SQL时就会露馅。每个表最好都有create_time和update_time，这在答辩时也可以说是遵循了一种数据规范，表示了每一行数据的生命周期。

3.3 流水表设计：一条流水就是一个业务事件

出入库和领用归还的流水表可以命名为device_stock_log，字段如下：id、log_no（流水号）、device_id（关联设备）、operation_type（操作类型，用int枚举）、quantity（数量）、operator_id（操作人）、source_dept_id（来源科室）、target_dept_id（目标科室）、remark、create_time。这个表不需要把主外键做得很死，因为设备表中的status会根据流水变化，但流水表本身更多承担审计职责。

流水号建议做成“日期加自增ID”的格式，比如20251201-001。一方面看起来规范，另一方面方便按日期去查，论文里能写“单号具有唯一性与可追溯性”。这些细节不需要写很多代码，但体现了你确实做过实际的业务系统，而不是只会调框架接口。

3.4 报修工单表的状态机设计

报修工单表通常有这几个状态：待派单、维修中、待验收、已关闭、已撤销。这其实就是一个状态机。在表设计时，除了status字段本身，还要加一个last_update_time，用来在列表页显示“这个工单停留在当前状态多久了”，配合超时预警。我的一个习惯是，不在代码里到处写死状态数值，而是定义常量类：

public class RepairStatus { public static final int WAIT_ASSIGN = 1; public static final int REPAIRING = 2; public static final int WAIT_ACCEPT = 3; public static final int CLOSED = 4; public static final int CANCELED = 5; }

这样在写SQL的where条件时，看到的是RepairStatus.REPAIRING，而不是裸的数字2，代码可读性会好很多，也方便以后扩展状态。

3.5 外键到底建不建

我的建议是：逻辑外键可以有，但物理外键不要滥用。举个例子，device_info里的dept_id会关联科室表，你在表结构文档里写清楚“dept_id关联科室表的id”就够了，但不要真的去建立FOREIGN KEY约束。原因很简单：毕设系统里经常要做删除和批量导入操作，物理外键会带来很多麻烦，一旦数据有误，排查起来也很痛苦。如果你担心答辩老师追问，可以这样解释：为了保证系统在高并发写入时的性能，外键约束放在应用层做校验。这个说法是成立的，而且不少真实项目也确实是这么做的。

4. 核心代码实现：状态流转、库存扣减和报表导出的关键写法

4.1 状态流转：用状态机而不是if-else堆

设备状态的改变是系统里最核心的业务规则。比如一台设备不能被直接删除，只能先报废，报废前不能在库里被领用。如果只是简单地在Controller里写if-else，代码会越来越乱。最直观的做法是定义状态流转Map，只允许合法的流转路径：

private static final Map<Integer, List<Integer>> DEVICE_STATUS_FLOW = new HashMap<>(); static { DEVICE_STATUS_FLOW.put(DeviceStatus.IDLE, Arrays.asList(DeviceStatus.IN_USE, DeviceStatus.SCRAPPED)); DEVICE_STATUS_FLOW.put(DeviceStatus.IN_USE, Arrays.asList(DeviceStatus.IDLE, DeviceStatus.REPAIRING)); DEVICE_STATUS_FLOW.put(DeviceStatus.REPAIRING, Arrays.asList(DeviceStatus.IN_USE, DeviceStatus.IDLE, DeviceStatus.SCRAPPED)); }

在service层进入状态修改前，先判断当前状态和目标状态是否在合法路径里，如果不在就抛业务异常。这样做有两个好处：一是避免非法的状态跳跃，二是论文里可以画一张状态流转图，非常直观，答辩时能讲清楚“为什么维修中的设备不能被领用”。

4.2 库存扣减：事务和行锁是必答点

领用和归还涉及库存变化，如果并发操作，容易出现超领问题。在Java后端里的简单做法是用事务加行锁：

@Transactional public void receiveDevice(Integer deviceId, Integer deptId) { DeviceStock stock = stockMapper.selectByDeviceIdForUpdate(deviceId); if (stock.getQuantity() < 1) { throw new BusinessException("库存不足"); } // 更新库存、插入流水、更新设备状态 }

这里的selectByDeviceIdForUpdate会带上for update，锁住对应行，防止两个用户同时领用同一台设备。这个知识点很多学生听过但没在项目里用，写进去就能体现你确实考虑过并发问题。虽然毕设系统体量小，并发量几乎为零，但你要让评委知道你具备这个意识。同时，事务保证每个操作要么全部成功，要么全部回滚，不会出现“库存扣了但流水没记”的情况。

4.3 报表导出：用EasyExcel处理Excel，用ECharts处理图表

医疗器械管理系统免不了要做报表。最简单的方案是把查询结果展示在表格里，但毕设要想加分，还得能导出Excel和看图表。导出Excel我推荐用EasyExcel，它对POI的封装很友好，代码量小：

@GetMapping("/export") public void export(HttpServletResponse response) throws IOException { List<DeviceReportVO> list = deviceService.getDeviceReport(); EasyExcel.write(response.getOutputStream(), DeviceReportVO.class) .sheet("设备台账") .doWrite(list); }

只要在VO上用@ExcelProperty注解标好表头，一行代码就能导出。图表部分可以用后端返回JSON数据、前端用ECharts渲染的方式。这样职责清晰：后端只负责统计，前端只负责画图。而且报表接口是天然的可视化扩展点，后面如果想把题目改成数据可视化方向，这部分代码可以直接复用。

4.4 定时提醒：Spring自带的@Scheduled就够用

保养到期提醒没必要上Quartz，Spring Boot自带的定时任务完全够用。在启动类加@EnableScheduling，然后在某个定时任务类里写方法：

@Scheduled(cron = "0 30 1 * * ?") public void dailyCheck() { List<DeviceInfo> devices = deviceMapper.selectWarrantyExpireSoon(30); for (DeviceInfo device : devices) { remindMapper.insert(RemindUtil.createWarrantyRemind(device)); } }

这段代码的意思是每天早上1点30分执行一次，查一下保修期还有30天到期的设备，插入提醒表。做的时候注意一个细节：如果定时任务重复执行，提醒表会插重复数据。解决方案是在提醒表里加一个biz_type和biz_id字段，插入前先查一下是否已有未读的同类型提醒。这个细节写进论文，体现的是你考虑到了实际运行中的问题。

5. 一套Java系统怎么适配PHP、小程序和数据可视化题目

5.1 业务模型与技术栈解耦：能换技术栈的底气来自分层

为什么要强调业务模型稳定？因为如果代码是把业务逻辑全部焊在页面模板里，那换技术栈等于重写。但如果你做了Controller、Service、Mapper的分层，那Java换成PHP，只需要保证接口路径和参数名不变，前端页面可以直接复用。所以选这个题目做毕设，一开始就不要疯狂追求某个框架的奇技淫巧，而是把核心业务的服务层整理干净。我见过有学生用Spring Boot写完之后，又把Service层几乎原封不动地用PHP实现了一遍，只改了语法，前后不到两个星期就能跑通。

5.2 Java转PHP：类型丢失后的防御式写法

如果最终要做成PHP方向，最常见的问题是Java里的强类型到了PHP里变成弱类型，导致有些问题直到运行时才暴露。比如Java里int类型的status，到了PHP里可能是字符串“1”，在做判断时要用严格比较，也就是多一个等号。再比如Java的MyBatis可以自动处理null，PHP里查出来的字段可能不存在。建议在PHP里写一个简单的模型基类，统一做字段默认值处理，避免页面上报一堆未定义索引的警告。这些细节如果不处理，演示时一旦出了故障，会显得系统不够稳定。

5.3 Java转小程序：后端API化是前提

小程序端的毕设通常需要一个后端提供接口。如果你已经用Java写好了一套系统，只要把Controller层的返回统一成JSON格式，并把原来页面渲染的逻辑换成小程序页面，就能很快完成适配。关键在于接口设计时要统一返回结构：

{ "code": 0, "message": "success", "data": { "list": [] } }

统一结构的好处是，无论前端是网页还是小程序，解析逻辑都是同一套。小程序里推荐用uni-app，因为可以同时编译成微信小程序、H5和App，答辩时展示起来非常灵活。这里要注意：小程序端的登录不能直接用Session，建议改用token方式，这也可以作为答辩里的一个扩充点。

5.4 数据可视化方向：把报表模块独立放大

如果你把毕设题目定成“医疗器械数据可视化分析”，那就不需要完整做所有业务功能，而是把系统里的设备台账数据拿出来，做几个维度的分析：设备总价值趋势、科室设备分布、设备分类占比、故障率TOP10、保修到期分布。技术栈可以用Flask加ECharts，或者Spring Boot加Vue加ECharts。这样做的优势是演示效果特别强，一个屏幕全是大屏图，视觉冲击力够。

要注意的是，数据可视化题目很容易被质疑“数据哪来的”。所以自己造数据时一定要写清楚生成逻辑，或者从公开的采购公告里整理一部分示例数据。最好在论文里写明白：抽样数据规模是多少、清洗规则是什么、哪些字段来自原始数据，哪些字段是派生计算出来的。这一步做扎实了，数据可视化方向就不会显得空。

5.5 爬虫与数据采集：合规优先，实用至上

标题里提到爬虫方向也可以做，但我要多说一句：这个和医疗器械管理关联起来的话，最合理的场景是爬取公开的医疗设备招标采购公告，分析市场价格和品牌分布。这属于公开信息，使用时注意频率和站点规则，不要爬取任何需要登录才能访问的非公开内容。如果你不想碰爬虫，可以退一步做“数据采集”，也就是自己写一个脚本从CSV或Excel表格导入设备信息，这在毕设里也完全够用了，而且没有任何风险。

爬虫方向和这个系统结合，建议做成“数据采集 + 数据导入 + 数据分析”的完整链路：爬虫负责下载公开PDF或网页数据，解析后存入设备信息表，然后通过报表模块展示。这套流程既能体现爬虫能力，又不偏离医疗器械管理的核心业务。

6. 演示录像该录什么，答辩怎么讲，源码怎么学才不会翻车

6.1 拿到一套现成源码，先当用户再当开发者

网上确实能找到不少毕设源码包和演示录像，获取门槛不高。但很多同学下载后第一件事是改名字、删注释、打算直接应付交差，这是一个大坑。因为答辩老师不是不看代码的，他随便问一个字段含义，如果你没跑过系统、没看过SQL，很容易当场卡壳。我的建议是：拿到源码后，先按照说明文档把项目跑起来，把演示录像完整看两遍，然后把自己当成使用者，把核心流程走一遍。接着看代码，至少搞懂device_info、device_stock_log和repair_order这三张表对应的代码是怎么写的。能独立讲清楚这些，你就能掌握主动权。

6.2 二次开发找这三个发力点，改动小效果好

如果觉得直接拿来的系统不够有个人特色，建议做三个小改动：

• 把设备分类改成你自定义的分类体系，比如“诊断类、治疗类、康复类、辅助类”，理由是贴合中小型医院实际分类标准。
• 给列表页增加一个筛选组合，例如“按科室加按状态加按分类”的条件组合查询。
• 在首页加两张图表，一张按科室统计设备数量，一张按月份统计设备购置金额。

这三个改动覆盖了功能、查询、展示三个维度，而且都不会破坏原有架构。改完之后，论文里和答辩PPT里都有可讲的增量内容，也不会被怀疑是直接抄的。关键是自己动手改过，别人问到细节时你能答出来。

6.3 录制演示录像的脚本：七分钟讲完一条完整业务链

如果老师要求交演示录像，或者你自己想留底，建议按下面的顺序录：

1. 登录系统，展示角色切换。
2. 进入设备台账，搜索一台设备，展示详情。
3. 做一次新设备入库操作，填写信息并提交。
4. 做一次科室领用，让设备状态从闲置变成在用。
5. 模拟一次故障报修，走完报修工单的完整流程。
6. 查看保养提醒列表，演示提醒生成。
7. 打开报表页面，切换图表筛选条件。

这个顺序恰好是一条完整的业务链：从入库到使用到维修到统计。录的时候不要开太多弹窗，鼠标动作别太快，关键操作可以放慢一点，后期不用剪辑，一口气录完即可。建议用系统自带的录屏工具，分辨率保持1366乘768以上。录像里出现报错不可怕，可怕的是报错之后手忙脚乱，所以提前跑完整流程很重要。

6.4 答辩必被追问的五个问题与应答思路

根据答辩现场的情况，这套系统最容易被追问的是下面这几个：

这些问题考察的核心其实不是系统有多庞大，而是你有没有认真思考过业务逻辑。提前准备好这些应答思路，能让你在现场不那么紧张。

6.5 论文写作的功能分配

最后说下论文。系统业务写清楚后，论文结构一般就是绪论、需求分析、系统设计、系统实现、系统测试这几大章节。重点花在需求分析和系统设计上：把角色用例图、功能模块图、业务流程图和数据库实体关系图画清楚，这些图比文字更能撑起篇幅。实现章节按“设备管理模块”“库存管理模块”“维修管理模块”“报表模块”这样分模块写，每个模块先写功能描述，再放核心代码片段，最后写运行效果。测试章节简单写上功能测试和部分接口测试即可，不用追求全覆盖，但测试用例表要规范。

论文里不建议大段粘贴代码，而是挑关键方法贴，每个代码片段下面必须有解释。尤其是状态机、事务和定时任务这三块，一定要写出“为什么这样实现”，这是拉开差距的地方。如果时间紧张，可以先按模块把功能描述写清楚，最后再统一补代码解释。

最后再分享一个经验：不要觉得选了个常见题目档次就不够，关键是你要能把自己业务边界讲清楚。我见过不少学生项目做得花里胡哨，答辩时却说不出一个功能背后的设计理由；反而是老老实实把一条设备生命周期走完的人，最容易被评委认可。与其纠结题目新不新颖，不如先把这套系统里的每一张表、每一个状态、每一次流转都吃透。做到这个程度，不管是用Java、PHP还是小程序来交，最后结果都不会差。