简介教学设备管理系统是一套源自《Visual C项目开发案例精粹》的软件应用案例面向正在学习C/MFC与数据库开发的读者帮助理解教育机构如何对设备信息、类别和借用归还记录进行数字化管理覆盖从设备档案录入、查询修改到借用归还的完整流程。系统覆盖了Access、SQL Server 2000/2005三种数据库的接入与切换并融入MFC界面构建、事务处理、权限设置、错误处理及性能优化等实际开发要点。压缩包内共235个文件包含72个.h头文件与66个.cpp源程序36个bmp位图和图标用于界面呈现还配有rc资源描述、dsp/dsw工程文件以及多套数据库备份mdb/mdf/ldf/sql整体约930KB适合按源码、资源、数据库分层对照研究。目前已有246人学习下载无论用于课程设计、毕业设计还是自主提升Windows桌面应用开发能力都能从这套真实项目中理解从界面到数据库落地的全过程获得完整的编码思路和排错经验。1. 教学设备管理系统为什么设备越管越乱问题不在台账而在流程做教学设备管理系统最常听到的诉求是“把台账理清楚”但真正跌过跟头的人都知道台账再清晰也拦不住设备悄悄消失。我在某高校实训中心帮忙落地过一套系统期末盘点时发现投影仪账上写着“在库”实际上已经被借走三个月没有归还记录——问题不在台账而在借用、归还、维修这些流程没有闭环。教学设备管理系统要解决的就是设备去哪了、谁在用、什么时候还、坏了谁修这四件事。它适合高校实验管理员、职业院校实训中心、培训机构的设备负责人也适合接这类外包项目的开发者参考。我会从表结构讲到流程实现再讲到上线后最容易翻车的几个地方。2. 先建模再写码台账、库存与状态机的边界怎么划2.1 设备编码规则决定系统上限先定编码再设计表设备编码是整个系统的地基它同时出现在盘点扫码、借用单引用、Excel导入导出、跨系统对账这些场景里。如果编码规则一开始定得随意后面所有功能都会跟着别扭。我见过直接用自增ID当设备编号的系统导出Excel后别人根本看不懂盘点时两个管理员对着“1024号设备”完全不知道是哪台机器。所以第一件事不是建表而是定编码规则。我常用的规则是“分类码4位 购置年份4位 流水号4位”共12位。分类码用字母数字组合表示设备大类AV代表音视频设备PC代表计算机LAB代表实验仪器。年份用四位数字避免跨世纪歧义。流水号按每个分类每年从0001开始重新计数而不是全库累计这样编码更短也更符合管理直觉。生成代码看起来是这样public String generateDeviceCode(String categoryCode, LocalDate purchaseDate, long sequence) { // 分类码4位 年份4位 流水号4位例如 AV-2023-0042 String year String.valueOf(purchaseDate.getYear()); String seq String.format(%04d, sequence); return categoryCode - year - seq; }这里有个容易被Excel坑的细节12位编码如果中间不带分隔符导入Excel时会被自动转成数字前导零丢失2023-0001直接变成1。所以我建议编码里保留“-”分隔符而且导入模板的编码列必须设置成文本格式。如果项目对编码有唯一性要求数据库字段上直接加唯一索引兜底不要只靠业务代码判断。校验编码的正则也很简单^[A-Z0-9]{4}-[0-9]{4}-[0-9]{4}$放在后端接口入口处统一拦截。流水号的生成要注意并发和跨年重置。常见做法是数据库表里记录每个分类码和年份的当前最大流水号生成新编码时在事务内对这条记录做行级锁更新。Redis的INCR也可以但事务性不如直接锁表记录稳妥。跨年时年份变化流水号自动归零程序里不要手动维护这个逻辑否则第二年开机第一件事就是修编码。2.2 五张核心表从设备档案到借用记录的关系设计设备管理系统的表结构并不复杂核心就五张表设备档案表、设备分类表、借用记录表、维修单表、盘点任务表。用户表属于基础框架不算业务核心。先把每张表的职责说清楚。表名职责关键字段equipment设备档案一台设备一行记录当前状态code、category_id、name、location、status、org_id、purchase_dateequipment_category设备分类树形结构用于筛选和编码前缀code、name、parent_idborrow_record借用流水一次借还一条记录device_id、borrower_id、approver_id、borrow_time、expect_return_time、actual_return_time、statusrepair_order维修流水一次报修一条记录device_id、reporter_id、assignee_id、fault_desc、repair_result、statusstocktaking_task盘点任务与盘点明细一对多task_name、status、executor_id、finished_time设计上最关键的一点是设备档案表只存当前状态所有历史行为全部放在流水表里。很多人一开始图省事在设备表上直接加一个“当前借用人”字段借出时改一下归还时再改回来。表面上简单但实际上把这个字段当成事实来源后一旦有人忘记归还登记设备表里的“当前借用人”就漂移了而且没有任何日志能回溯是谁改的、什么时候改的。正确做法是借用记录表里存完整流水查询设备当前是谁在用的时候按设备ID查最新一条status为“使用中”的借用记录即可。考虑到列表页频繁查最新记录会多一次关联查询可以在设备表上冗余一个current_borrow_id字段借用审批通过时回填归还验收时清空。但这个冗余字段必须和借用记录表的更新放在同一个事务里否则会出现设备表显示“已借出”但回归记录为空或者反过来。我的经验是第2章就把这个冗余字段设计进来比后面发现性能问题再补要省事得多。2.3 状态机建模可借、占用、维修、报废的流转规则设备的生命周期状态必须提前定义清楚否则后面流程代码会写成一团乱麻。我在这类系统里常用的状态是五档在库、已借出、维修中、已报废、异常待处理。状态字段用整数存接口返回时再翻译成文案而不是直接存中文。枚举定义如下public enum DeviceStatus { IN_STOCK(0, 在库), BORROWED(1, 已借出), REPAIRING(2, 维修中), SCRAPPED(3, 已报废), ABNORMAL(4, 异常待处理); private final int code; private final String desc; DeviceStatus(int code, String desc) { this.code code; this.desc desc; } public int getCode() { return code; } public String getDesc() { return desc; } }状态的迁移不是随意乱转的要做一张合法迁移表来约束。这张表的本质就是业务规则它决定了哪些操作是允许的哪些操作是非法流程。当前状态触发动作目标状态在库借用审批通过已借出在库报修单创建维修中已借出使用中报修或归还验收不合格维修中维修中维修完成并通过验收在库在库 / 已借出盘点盘亏确认异常待处理异常待处理确认报废已报废为什么要显式做状态机因为接口层如果不校验迁移合法性前端按钮随便点或者数据被手动改掉都会留下脏数据。比如设备已经进入维修中但借用审批接口只看当前状态是不是“在库”那就会把一个维修中的设备借出去设备现在在哪根本没人知道。把状态机收敛在服务层之后非法迁移直接抛异常前端根据返回的状态码提示“当前设备状态不允许此操作”比在SQL里到处补条件要可靠得多。3. 借还与报修两个核心流程的最小实现3.1 借用单流程从申请到归还的代码骨架借用归还流程是教学设备管理系统使用频率最高的路径也是流程上最容易出洞的地方。我按五步来设计接口提交申请、审批、签收、归还、验收。每一步的职责如下。接口入参要点核心动作POST /api/borrow/applydeviceId、borrowerId、expectReturnTime校验收件人身份创建待审批借用单POST /api/borrow/approveborrowId、approveResult审批通过时锁定设备拒绝时直接关闭单据POST /api/borrow/signborrowId、signerId确认设备已实际领取备注外观情况POST /api/borrow/returnborrowId、returnTime、checkItems校验设备状态更新归还时间POST /api/borrow/acceptborrowId、acceptorId、photos验收外观功能通过后设备回在库不通过则创建维修单审批通过是整个流程的关键点因为这里最容易出现“一台设备同时借给两个人”的并发问题。代码上要用条件更新来控制设备状态的原子切换。我一般这么写Transactional public void approve(Long borrowId, Long approverId) { // 先查借用单信息确认单据还在待审批状态 BorrowRecord record borrowMapper.selectById(borrowId); if (record null || !PENDING.equals(record.getStatus())) { throw new BizException(借用单不存在或已处理); } // 条件更新只有当设备当前是在库状态时才能改成已借出 int rows equipmentMapper.updateStatusByIdAndFromStatus( record.getDeviceId(), DeviceStatus.BORROWED.getCode(), DeviceStatus.IN_STOCK.getCode()); // 影响行数为0说明设备已经被别人抢先借走或状态已变 if (rows 0) { throw new BizException(设备已被其他人借走或状态已变更请刷新后重试); } // 设备锁定成功后再更新借用单状态 record.setStatus(APPROVED); record.setApproverId(approverId); record.setApproveTime(new Date()); borrowMapper.updateById(record); }这段代码的关键在于updateStatusByIdAndFromStatus这个条件更新它把“检查状态”和“更新状态”合成了同一条SQL在数据库层面做到了原子操作。只要影响行数为0就说明状态已经不是“在库”直接报错。注意事务边界两步更新必须在一个事务方法里否则设备状态更新成功但借用单更新失败事务回滚后状态还是不一致。归还的代码逻辑正好相反。归还时设备必须要处于“已借出”状态才能回到在库否则说明流程有问题。归还时要顺便处理一下超期标记如果实际归还时间晚于预计归还时间在借用记录上打一个overdue标记后续统计逾期率直接用这个字段不用临时算。这个细节对第4章的使用率统计很有用建议现在就留好字段。3.2 报修闭环维修单与设备状态如何联动报修流程相对简单但同样要跟设备状态产生联动不能独立地走一遍“填单、维修、完事”。设备报了修设备本身应该立刻进入“维修中”状态防止维修期间再被借走。很多系统只建了一张维修单设备状态纹丝不动结果设备被报修人放在走廊里系统里还显示“在库”下一个老师又申请借用审批人又批了设备去向直接变成悬案。创建维修单时的关键代码是这样Transactional public Long createRepairOrder(RepairOrder order) { // 插入维修单状态为 REPORTED repairMapper.insert(order); // 不管设备当前是在库还是已借出都要锁定为维修中 int rows equipmentMapper.updateStatusByIdAndFromStatus( order.getDeviceId(), DeviceStatus.REPAIRING.getCode(), DeviceStatus.BORROWED.getCode()); if (rows 0) { // 设备不是在已借出状态尝试从在库状态进入维修中 rows equipmentMapper.updateStatusByIdAndFromStatus( order.getDeviceId(), DeviceStatus.REPAIRING.getCode(), DeviceStatus.IN_STOCK.getCode()); } if (rows 0) { throw new BizException(设备状态不允许报修当前可能已报废或正在维修中); } // 如果设备处于借用状态要把对应的借用单提前终止 BorrowRecord activeBorrow borrowMapper.findActiveByDeviceId(order.getDeviceId()); if (activeBorrow ! null) { activeBorrow.setStatus(RETURNED_IN_ADVANCE); activeBorrow.setActuallyReturnTime(new Date()); activeBorrow.setRemark(设备报修提前终止借用); borrowMapper.updateById(activeBorrow); } return order.getId(); }需要注意的是代码里先尝试从“已借出”迁移再尝试从“在库”迁移这个顺序是有原因的。设备如果处于借用状态说明有人正在使用要先把借用单提前终止避免使用记录一直挂着。维修完成后必须由设备管理员验收验收通过后设备状态统一回到“在库”维修单状态变为“FINISHED”。这里不允许维修工自己把维修单关掉否则“修好了”没有任何依据。维修流程里还有一个容易踩的坑维修单和借用单各自维护状态业务逻辑很容易写岔。我的习惯是维修单状态只维护单据本身的流转REPORTED、REPAIRING、FINISHED、CLOSED设备状态单独维护。两者通过设备ID关联但不同步更新。什么时候联动呢只有两个点创建维修单时锁设备验收通过时解锁设备。中间过程不要去动设备状态减少状态机出错的面积。3.3 前端列表接口返回什么字段才能让列表不踩坑设备列表页是系统里访问量最大的页面这个接口设计得怎么样直接影响前端开发效率和运行性能。很多人只返回设备表字段让前端自己去猜状态、自己去拼当前使用人信息结果前端代码里塞了一堆硬编码的状态映射后端状态枚举一改前端列表跟着崩。我建议列表接口返回的VO包含两类内容设备基础信息和“最新业务状态摘要”。给个JSON示例{ id: 1024, code: AV-2023-0042, name: 激光投影仪, location: 实训楼A-301, status: 1, statusText: 已借出, currentUser: 张老师, expectReturnTime: 2025-06-30, categoryName: 音视频设备 }这里的statusText必须由后端返回而不是前端根据status去翻译。原因很简单状态文案在多端要统一小程序、PC后台、H5各自写一套映射后面改文案就要改三处。currentUser是当前借用人的姓名通过冗余字段或子查询获取。expectReturnTime如果为空说明设备不在借用状态前端不用展示。分页参数建议统一为pageNum、pageSize、keyword、categoryId、status、location。keyword默认同时模糊匹配code和name比如输入“AV”就匹配出所有音视频设备的前缀编码。location用于按教室或楼栋过滤这个字段后端直接拼SQL条件即可。前端拿到status后按钮的显隐规则如下status为0时展示“借出”和“报修”status为1时展示“归还”status为2时只展示“维修中”标签status为3时按钮全部灰置。这些规则最好也由后端返回一个allowedActions数组字段前端直接遍历渲染彻底避免前后端对状态理解不一致。4. 盘点与统计报表系统能不能撑过第二学期看这里4.1 盘点任务生成未盘到设备的差异SQL与复核流程管理系统的上线热潮过去之后真正决定系统能不能长期存活的是盘点功能。很多系统上线第一学期没做过盘点第二学期设备账目就对不上了管理员对系统的信任直接崩塌。盘点功能的业务流程并不复杂创建任务、生成盘点明细、扫码盘点、提交结果、处理差异。核心难点在于差异判断和复核。我按批次盘点的方式来设计每批盘点限定一个范围某个教室、某个分类或某个实验室。生成盘点明细时把该范围内所有未报废的设备全量捞出来生成待盘点项。盘点人拿着手机逐台扫码扫到的设备标记为“已盘”没扫到的自然就是差异。判断哪些设备没被扫到的SQL这么写SELECT e.id, e.code, e.name, e.location FROM equipment e LEFT JOIN stocktaking_item si ON si.equipment_id e.id AND si.task_id #{taskId} WHERE e.status ! 3 -- 排除已报废设备 AND si.id IS NULL -- 该设备没有被盘点 AND e.location #{location}; -- 限定本次盘点范围这段话的要点在LEFT JOIN的条件上。如果把si.task_id #{taskId}放到WHERE里结果就变成内连接查出来的是“有盘点记录但可能属于其他任务”的数据范围就错了。这个SQL查出的是本次任务没扫到的设备但没扫到不代表丢失有可能是盘点人漏扫了。所以差异处理前一定要有一次复核重新去现场找一遍确认找不到后再标记为盘亏。盘亏确认后设备状态改成“异常待处理”并在盘点任务里生成一条盘亏记录后续走报废或继续追查流程。盘点还有一个实操细节盘点任务不要允许删除只能关闭。管理员容易手滑创建错任务如果允许物理删除盘点记录的历史审计就断了。做法是任务状态加一个“已作废”作废不影响已盘点数据的留存。4.2 使用率统计两种口径之间的差距与选型设备使用率是领导最爱看的数据也是争议最大的数据。最常见的口径是“借用天数比例”一台设备在统计周期内被借出的天数除以总天数。SQL大概是这样的SELECT d.id, d.name, ROUND(SUM( DATEDIFF( IFNULL(br.actual_return_time, NOW()), br.borrow_time ) ) / 30 * 100, 2) AS borrow_rate FROM equipment d LEFT JOIN borrow_record br ON br.device_id d.id AND br.status IN (USING, RETURNED) AND br.borrow_time DATE_SUB(NOW(), INTERVAL 30 DAY) GROUP BY d.id, d.name;这个口径的问题在于设备借走了并不代表真的在用。投影仪借走一个月没开机统计上这台设备使用率是100%实际上就是闲置。计算机机房更典型老师整学期预约了机房但一半课程没来上按借用天数统计机房使用率高得吓人实际情况完全不是这样。更准确的口径是“真实使用时数”需要额外的数据来源智能插座记录设备通电时间、PC客户端上报开机时长、机房课表系统对接实际排课课时。这三种方式成本差别很大。智能插座适合投影仪、功放这类不易嵌入软件的设备PC类设备直接在客户端埋点统计就够。对于预算有限或者不想依赖硬件的项目我建议用三个辅助指标组合评估借用次数、累计借用天数、超期次数。借用次数反映设备的流动性超期次数反映管理压力三者结合比单一使用率更有参考价值。给领导展示的时候明确标注口径是“借用口径”而不是“实际用时”避免数字失真带来的信任危机。4.3 大数据量导出Excel异步任务与权限脱敏设备管理系统的导出功能看起来简单实际上是最容易踩坑的环节。系统用了半年之后设备数据轻松超过几千甚至几万条再加上借用记录和维修记录同步导出十几万行数据到Excel。如果直接在请求线程里查询组装数据轻则接口超时重则内存溢出拖垮应用。我经历过一次管理员点了导出整个系统卡了三十秒其他老师正在操作借用的请求全部排队课堂节奏直接被打断。我的方案是“异步导出 任务状态查询 文件下载”三段式。请求进来后先返回一个taskId后台线程负责查询数据、写Excel、把文件路径写入导出任务表。前端每隔两秒轮询导出任务状态任务完成后拿到文件地址再下载。这样即使数据量很大用户感知到的也只是“导出需要一点时间等一会再下”。文件保留24小时后由定时任务清理避免临时文件堆积占满磁盘。导出还要注意权限边界。普通管理员只能导出自己权限范围内的设备数据校级管理员才能导全部数据。实现上就是导出任务的查询SQL自动带上org_id过滤条件复用列表页的数据权限逻辑。导出内容里凡涉及教师个人信息的地方手机号、证件号这些字段默认脱敏只有校级管理员可以勾选“导出明文”并且明文导出行为要写审计日志。这个细节在安全评估的时候会帮助企业避免很大麻烦。5. 权限、并发与责任认定多用户同时操作时的5个避坑记录5.1 两个管理员同时审批一台设备借给了两个人现象两位老师先后申请借用同一台投影仪两个审批人分别在各自电脑上点击通过系统同时生成了两单有效的借用记录设备被两个人约定在同一时段使用。原因审批接口的实现是先查询设备状态为“在库”然后更新为“已借出”。这两个操作之间有时间差A审批人查询完还没更新B审批人紧跟着也查到“在库”两个请求都通过了校验。解决利用条件更新把“查询校验”和“状态变更”合成一个原子操作也就是第3章里的updateStatusByIdAndFromStatus。只有影响行数大于0才说明当前请求真正抢到了设备否则直接拒绝。这是并发修改里最基本的乐观锁用法但在实际项目里很多人一开始不会写等到数据对不上才回来补。这条算是血泪经验比任何理论提醒都有效。5.2 借用单卡在请假的管理员那里流程彻底挂起现象老师提交了借用申请审批人是某位实验管理员结果这位管理员休年假一周申请单一直停在“待审批”状态设备用不了流程像死了一样。原因审批节点绑定了具体账号没有备用处理机制。人不在岗流程就停摆。解决审批节点不要绑定账号要绑定角色。比如“实验室审批人”这个角色下挂了三个人单子只要推给角色角色下任何一人都能处理。如果机构实在只有一个人负责就要配置超时自动转审。做法是定时任务扫描超过24小时未审批的申请单转给该部门的备用审批人如果备用审批人也没处理再过24小时自动退回。实现示意如下Scheduled(cron 0 0 1 * * ?) public void autoTransferOverdueApproval() { ListBorrowRecord overdueList borrowMapper.findPendingOlderThan(24L); for (BorrowRecord record : overdueList) { Long backupUserId userMapper.findBackupApprover(record.getOrgId()); if (backupUserId ! null) { record.setApproverId(backupUserId); record.setRemark(审批超时自动转交给备用审批人); borrowMapper.updateById(record); } else { record.setStatus(REJECTED); record.setRemark(审批超时系统自动退回); borrowMapper.updateById(record); } } }注意cron表达式每天凌晨1点跑一次周期太长可以改成每4小时一次。findPendingOlderThan(24L)的参数单位是小时具体阈值可以根据学校作息调整但不要小于8小时否则晚间提交的申请单第二天一早就被自动退回老师体验极差。5.3 批量导入800台设备编码重复导致全部回滚现象第一次批量导入设备时Excel里有800行数据跑到第327行报错“设备编码重复”整个事务回滚前面326条也全部没导入成功管理员以为导入成功了一部分实际上一条都没有。原因导入程序没有做前置校验直接在逐行插入时暴露错误。Excel内部存在重复编码或者与数据库中已有数据撞了编码。解决把导入改成“先预校验再批量插入”的流程。预校验包括内存中的Set去重检查Excel内部有没有重复编码再查一次数据库检查这些编码是否已存在。校验阶段返回一个错误报告列出所有有问题的行号、编码和错误原因让管理员在原Excel上改好再上传。最后数据库设备编码字段加唯一索引作为兜底即使程序里有逻辑漏洞数据库也不会产生重复数据。批量插入用批量SQL但中间任何一行失败都不允许部分成功必须整体回滚并告知用户失败原因。校验逻辑单独写一个service方法把错误收集到List里全部检查完再返回而不是一遇到错误就中断。5.4 归还时才发现设备损坏管理员和老师各执一词现象归还投影仪时管理员发现外壳裂了借用老师坚持说“拿来的时候就是坏的”管理员说“出库时检查过没问题”谁也没有证据最终只能不了了之。原因借出签收和归还验收都没有留痕缺乏客观记录出了纠纷只能靠口头回忆。解决借用签收时就要求借用人确认设备外观状态归还时必须走验收步骤。验收页面固定三个检查项屏幕或镜头外观、外壳是否有磕碰、配件是否齐全。每一项选择“正常”或“异常”异常时强制上传照片。验收记录和照片关联到借用单ID上后续创建维修单时直接把验收记录作为附件引用。这个流程会增加借用人的一点操作成本但极大地降低了管理员的沟通成本。我见过因为一次2万元的投影仪损坏纠纷学校设备处花了一下午去查监控最后没结果的例子——有验收照片的话十分钟就能定性。5.5 普通教师能看到全校设备库存并且能导出现象普通教师登录系统后设备列表页显示的是全校所有设备包括其他实验室的设备位置、责任人、借用记录还可以一键导出Excel。原因权限设计只区分了“教师”“管理员”这样的角色但没有做数据范围隔离。角色决定了能不能访问这个菜单数据范围决定了能看到哪一部分数据两者是独立的维度。解决设备表加org_id字段表示设备归属的部门或实验室。用户表也挂org_id。查询列表和导出时强制在SQL上追加org_id条件。角色权限的控制方法如下。角色数据范围可执行操作普通教师本人发起的借用记录申请借用、报修实验室管理员本实验室设备审批、签收、归还、验收、盘点院系设备管理员本院系下属所有实验室设备创建维修单、批量导入、导出校级管理员全校设备查看全局统计、系统配置、导出明文报表数据权限的过滤条件最好写进MyBatis的拦截器或者在Service层统一加条件不要每个查询接口自己拼SQL否则后面的开发者漏写一个接口就又是一个漏洞。权限和导出都要有操作日志记录谁在什么时间导出了什么范围的数据。6. 让老师愿意用设备二维码与移动端扫码的落地技巧6.1 从PC后台到设备二维码的改动清单设备管理系统上线一段时间后最大的问题往往是“管理员在用老师不用”。老师上课前想借个设备还得打开电脑、登录系统、找设备、填申请单一套流程走下来快十分钟。对老师来说这个成本太高了很多人宁可发微信找人问也不愿意登录系统。所以我后来每套系统都会加一个二维码落地动作给每台设备生成一张二维码标签贴在设备醒目位置老师手机扫一下就可以直接操作。二维码内容存的是设备编码而不是数据库自增ID。原因有两点一是设备编码本身就是业务唯一标识打印在标签上即使系统更换这串编码也能作为追溯依据二是数据库ID在测试环境和生产环境对不上导数据时容易乱套。生成二维码的Java代码示意如下import com.google.zxing.BarcodeFormat; import com.google.zxing.client.j2se.MatrixToImageWriter; import com.google.zxing.common.BitMatrix; import com.google.zxing.qrcode.QRCodeWriter; // 二维码内容指向设备详情页参数用设备编码而非数据库ID String content http://设备管理系统域名/dev?code equipment.getCode(); BitMatrix matrix new QRCodeWriter().encode( content, BarcodeFormat.QR_CODE, 300, 300); MatrixToImageWriter.writeToPath( matrix, PNG, Paths.get(/labels/ equipment.getCode() .png));300×300像素的二维码图片打印成三四厘米见方的不干胶标签扫码识别率完全没有问题。打印用普通不干胶标签打印机就行打印后加一层覆膜防止磨花。张贴位置选设备正面的右上角避开散热孔和铭牌。投影仪、功放这类设备的二维码标签最容易磨损建议每学期巡检时检查一遍掉了及时补贴。扫码后打开的是H5详情页页面上展示设备状态、当前位置、当前使用人和预计归还时间底部按钮根据设备状态动态显示“立即借用”或“立即报修”。点击借用只需要填写预计归还日期不用再重复录入设备信息。提交后审批依然在PC后台完成。这一套改动省去了老师找设备编码、打开电脑、登录系统的过程把操作入口从后台上搬到了设备实物上。这个方案的教训是我自己踩出来的第一版系统功能很全但老师根本不登录PC后台成了管理员专用的“账本工具”对一线教学没有价值。后来做了二维码入口使用率才算真正起来。我现在做任何管理系统都默认带上扫码入口因为它解决的问题不是效率而是使用意愿。希望帮到你。本文还有配套的精品资源点击获取