企业官网建设流程全解析

实验室里那张纸质借用登记簿，是让我决定认真做这个毕设的最直接原因。每到期末，设备借用高峰一来，登记表上写错、漏记、代签的情况特别多，还回来的设备放错位置更是家常便饭。我所在的实验室长期以来就是靠管理员人工核对台账，一台投影仪、一套传感器套件，从借出到归还中间经历了谁、什么时候借的、什么时候该还，这些信息几乎没有可靠的沉淀。所以今年的毕业设计，我选了基于Spring Boot的实验设备借用平台，目标很明确：把设备信息、借用审批、归还确认、逾期提醒、统计报表全部流程化、线上化。这篇博客打算从需求分析、技术选型、核心功能实现、数据库设计、踩坑记录、部署与答辩准备这几个角度完整复盘一遍。如果你也在做实验室管理系统、企业资产借用平台这类题目，或者就想看看一个SSM/Spring Boot毕设项目到底该怎么一步步落地，这篇内容应该能帮你少走不少弯路。

1. 项目定位与核心需求分析

1.1 实验室设备管理到底难在哪

很多同学拿到类似题目，第一反应就是“做一个增删改查系统”。实际上如果只停留在增删改查，答辩时很容易被追问到无话可说。设备借用平台的核心难点在于“借”和“还”这两个动作背后，涉及完整的状态变化和责任追踪。

拿最常见的场景来说：学生A在系统中提交借用申请，选择设备、填写借用时间段，管理员审批通过后，学生到实验室领取设备，管理员确认出借。此时设备状态从“可借用”变成“已借出”。等到归还时，管理员检查设备是否完好，系统登记归还时间，设备重新变为“可借用”。如果学生没有按时归还，系统要能识别出逾期状态，并且给管理员和学生相应的提醒。

这套流程看起来简单，但细琢磨会发现几个真实痛点：

• 库存串扰问题：同类设备往往有多台，如果申请时只填设备名称，不绑定具体编号，归还时无法准确对账。
• 时间冲突问题：借用周期可能重叠，同一台设备在同一时间段不能被两个人同时借走。
• 责任人模糊问题：设备损坏、丢失后，如果没有准确的借用记录和审批留痕，追责就会变得非常困难。

这些问题一开始就应该写进需求文档里，而不是等到开发完再来补。我在需求阶段反复和实验室管理员确认场景，最终把核心业务流程固定成了“设备管理—借用申请—审批—出借—归还—异常处理—统计报表”这样一条清晰的主线。

1.2 角色划分与功能需求梳理

按照实际使用场景，我设计了三种角色：

功能模块上，我并没有贪多。整体划分成六个大的模块：设备信息管理、借用申请管理、审批出借管理、归还管理、用户与权限管理、统计与报表。除此之外，系统还需要一个必要的操作日志功能，记录谁在什么时间修改了设备状态，这对实验室这种需要追溯责任的场景很有价值。

这里要提醒一句：毕设的系统规模控制在“能用、能讲、能扩展”这个范围最合适。如果你把消息队列、分布式事务这些技术硬塞进去，不仅开发周期拉长，答辩时也容易被老师追问到死角。凡是当前流程不紧急需要的技术栈，都不应该出现在第一版系统里。

2. 技术选型与系统架构

2.1 为什么用的是Spring Boot而不是别的框架

现在毕设管理系统的主流选项无非这几类：Spring Boot、SSM、前后端不分离的JSP/Servlet方案，甚至还有Python Flask、Django的方案。我最终选型Spring Boot，核心原因有这么几个。

第一，Spring Boot大幅简化了配置。SSM时代需要手写大量的XML配置，每个框架的配置版本还对不上，经常出现今天能跑、明天环境一换就挂的问题。Spring Boot用自动配置和约定优于配置的方式，把多数场景的连接配置、序列化配置、事务配置都帮我们处理好了，能够把主要精力放回到业务逻辑上。

第二，Spring Boot的生态成熟度非常高。做毕设需要用到的安全框架、持久层框架、模板引擎、接口文档工具，都能很容易集成到Spring Boot体系里。遇到问题在网上可以找到海量的解决方案，这一点对时间紧张的毕设来说很关键。

第三，也是比较现实的一点：招聘和面试环境下，Spring Boot几乎是Java后端开发的行业标杆。用这个技术栈完成毕设，哪怕项目本身不复杂，至少能证明你熟悉现代化的Java工程实践。

我不用微服务架构，也不引入Spring Cloud，原因很简单：实验室设备借用的业务量根本没有到需要分布式部署的程度。一个单体应用搭配合理的缓存、索引，完全够用。强行上微服务反而会增加复杂度，让整个系统变得没法解释清楚。

2.2 前端、数据库与权限方案

前端方案我选择了Vue加Element Plus。Vue负责组件化和路由逻辑，Element Plus提供现成的表格、表单、弹窗、日期选择器等组件，开发效率非常高。前后端通过JSON进行数据交互，使用Axios封装统一的请求工具，可以集中处理响应码和错误提示。

数据库用的MySQL，这个没什么争议，属于毕设场景下的标准选择。为了提升查询性能，我加了一层Redis缓存做热点数据的读取优化，同时用Redis存储某些临时状态和验证码数据。Redis这里的使用要克制，不能让缓存成为数据一致性的风险点。设备库存、借用状态这类核心数据仍然以数据库为准，Redis只缓存分类列表、设备列表这种变更不频繁的数据。

权限控制用的是JWT加Spring Security的组合。用户登录成功后拿到Token，后续每次请求带上Token，后端通过过滤器校验身份和角色权限。相比传统的Session方式，JWT更适合前后端分离项目，也不需要考虑跨域下Session共享的问题。

这里说一下我的实践经验：如果你对Spring Security的过滤器链不太熟，可以先不引入它，直接用拦截器加自定义注解的方式做权限控制。Spring Security虽然功能强大，但它的开发模型比较重，配置稍微出错就会出现路径放行异常，排查成本并不低。我的做法是用一个简单的JWT拦截器判断登录状态，再用Spring AOP校验角色权限，一样能完成需求，并且代码逻辑更容易给别人讲清楚。

2.3 工程结构如何组织才清晰

项目工程结构直接决定代码可维护性和答辩时老师的第一印象。我按常见的分层架构组织结构：

src/main/java/com/example/labequipment/ ├── controller // 接收前端请求，返回统一响应体 ├── service // 业务逻辑层，处理核心流程 ├── mapper // 数据访问层，对接MyBatis的Mapper接口 ├── entity // 数据库实体类 ├── dto // 数据传输对象，用于前端入参校验 ├── vo // 视图对象，用于接口返回 ├── config // 配置类，包括跨域、拦截器、缓存配置等 ├── common // 公共类，包括统一返回结果、异常处理、常量等 ├── annotation // 自定义注解 ├── aspect // AOP切面，用于操作日志和权限校验 └── utils // 工具类

包结构分清楚有一个很大的好处：每当新加一个功能，你能准确知道该改哪个位置。比如要给设备增加维修状态，改动点在entity的新增字段、mapper的SQL、service的维修流程方法、controller的新增接口，逻辑上是顺着一条线下来的，不会东改一下西改一下。

后端使用的框架是MyBatis。虽然MyBatis-Plus在毕设项目里很流行，能省掉大量单表CRUD代码，但我个人建议在核心业务查询上仍然手动写SQL。原因在于设备借用系统中最关键的几个查询，都涉及多表关联、状态条件、时间段重叠判断，这些逻辑放在XML里写清楚，反而更直观，也更容易调试。

3. 核心功能设计与实现细节

3.1 设备信息建模与状态流转

设备是整个系统的核心资源。我设计设备表时，不仅存了设备名称、型号、规格、所属实验室、购买日期、设备照片，还增加了以下几个比较关键的字段：

• 设备编号：每台设备资产编号是唯一的，相当于设备的身份证号。这种做法的好处是，当实验室有3台相同型号的万用表时，借用的具体是哪一台，归还时扫码或按编号确认就能精确对账。
• 状态字段：可借用、已借出、维修中、已下架。
• 当前存放位置：比如“A栋305-柜3”，方便线下取放设备时快速定位。
• 累计借用次数：这个字段可以在报表里统计设备利用率，也能辅助判断设备是否需要维护。

设备状态不应该允许任意跳变。比如“已借出”的设备不能直接改成“维修中”，必须先走归还流程，再登记送修。状态流转的控制逻辑我写在Service层，用一个状态机方法判断当前状态与目标状态是否合法。这样做的好处是，即使管理员误操作或者黑客伪造请求，也无法绕过业务规则篡改设备状态。

下面是我在代码里维护状态流转的核心方法：

public void changeEquipmentStatus(Long equipmentId, EquipmentStatus targetStatus) { Equipment equipment = equipmentMapper.selectById(equipmentId); if (equipment == null) { throw new BusinessException("设备不存在"); } EquipmentStatus current = equipment.getStatus(); if (!EquipmentStatusTransitions.isValid(current, targetStatus)) { throw new BusinessException("当前状态[" + current.getDescription() + "]不允许变更为[" + targetStatus.getDescription() + "]"); } equipment.setStatus(targetStatus); equipmentMapper.updateById(equipment); // 记录操作日志 operationLogService.record("设备", equipmentId, current.getDescription() + " -> " + targetStatus.getDescription()); }

实际开发中有个容易忽略的点：管理员手动修改设备状态之后会直接覆盖数据库状态，导致后续流程紊乱。所以我特意加了一层限制，管理端虽然提供状态调整功能，但只允许在“设备下架”“设备送修”“重新上架”这几个合法动作之间切换，借用和归还引发的状态变化必须由对应流程接口触发。

3.2 借用归还的状态机设计

借用申请从创建到归档，我定义了六种状态：

• 待审批：学生提交申请后的初始状态，此状态下学生可以主动撤销。
• 已通过：管理员审批通过，等待学生线下领取设备。
• 已驳回：管理员拒绝申请，需要填写驳回原因。
• 借用中：设备已实际出借，学生领取设备后状态生效。
• 已归还：设备归还完毕，本次借用流程正常结束。
• 已逾期：超过应还日期仍未归还，系统自动标记。

流程节点上，我严格控制操作顺序。审批通过之后，系统会自动判断设备在借用时间段内是否可借，同时把对应的设备库存占用掉。这里有一个关键点：审批通过只是占用了设备，但设备状态是否变为“已借出”，取决于管理员是否点击了“确认出借”。

这个设计容易被忽略，却非常贴近实际场景。学生可能审批通过后一直不来领取设备，如果审批通过就改变设备状态，设备会被白白锁定。我的方案是：审批通过后设备进入“预占”状态，如果在有效领取时间内没有确认出借，系统自动释放占用。这个“预占—释放”机制让整个流程更能应对现实中的不确定性。

审批通过的方法大概是这样的逻辑：

@Transactional public void approveApplication(Long applicationId, Long approverId) { BorrowApplication application = applicationMapper.selectById(applicationId); if (!application.getStatus().equals(ApplicationStatus.PENDING)) { throw new BusinessException("当前申请状态不可审批"); } // 检查设备在申请时间段内是否可用 boolean available = checkEquipmentAvailable(application.getEquipmentId(), application.getStartTime(), application.getEndTime()); if (!available) { throw new BusinessException("该设备在此时间段已被占用，无法审批通过"); } application.setStatus(ApplicationStatus.APPROVED); application.setApproverId(approverId); application.setApproveTime(LocalDateTime.now()); applicationMapper.updateById(application); // 插入借用明细记录，此时借用记录的status为“待领取” borrowRecordMapper.insert(BorrowRecord.buildPending(application)); }

之所以把借用记录和申请分开设计，是因为一次申请可能对应一台设备，但未来可能扩展成“一次申请多台设备”。拆开之后，申请单负责流程审批，借用记录负责设备的状态追踪，职责更清晰。

3.3 借用冲突与数量校验

借用冲突是这类平台最容易出问题的地方。假设设备E在3月1日到3月5日已经被某同学借用，另一位同学提交了3月3日到3月8日的申请，如果系统不做重叠校验，就会出现同一台设备同时被两个人借用的荒唐情况。

检测时间段重叠的核心SQL其实很简单：

SELECT COUNT(*) FROM borrow_record WHERE equipment_id = #{equipmentId} AND status IN ('PENDING_TAKE', 'BORROWING') AND #{startTime} < end_time AND #{endTime} > start_time

这个SQL的逻辑是：只有当新申请的开始时间小于已有记录的结束时间，并且新申请的结束时间大于已有记录的开始时间时，才说明两者有重叠。注意这里必须是严格的 “<” 和 “>”，不能等号。我一开始写成了 “<=” 和 “<=”，结果明明边界上不冲突的两个借用也被判为冲突，最后排查半天才发现是边界判断的逻辑问题。

在多台同类设备的情况下，还需要考虑数量校验。比如设备某种类型总共有5台，当前有3台被借出，那么新的申请最多只能再借走2台。我会在审批时先统计该类型设备的已占用数量，再和申请数量比较，如果可借数量不足就直接驳回。

并发场景下，简单的select再update存在“超卖”风险。两个人同时提交申请，可能同时通过校验。我的方案是：核心借用的校验和占用操作放在一个事务里，使用数据库的行锁或者“乐观锁版本号”来控制并发。

@Select("SELECT * FROM equipment WHERE id = #{id} FOR UPDATE") Equipment selectByIdForUpdate(Long id);

在事务方法中先执行这样一条带“FOR UPDATE”的查询，就能把对应设备行锁住，直到事务提交或回滚时才释放。这样即使并发请求同时进来，也只会有一个事务能成功完成校验和更新，另一个因为拿不到锁，会等到前一个事务结束之后再重新判断状态。

3.4 逾期判断与自动提醒

实验室设备晚归还几天，表面上问题不大，但会影响后续同学的借用计划。所以系统需要自动识别逾期借用，并给相关用户发送提醒。

逾期判断的逻辑我放在了两个地方：一是查询时动态计算，二是定时任务批量扫描。

查询时动态计算很简单，查询当前借用中记录的SQL里加一个判断条件：

SELECT * FROM borrow_record WHERE status = 'BORROWING' AND end_time < NOW()

扫描到逾期记录之后，把状态更新为“已逾期”，同时给对应学生发送站内消息提醒。定时任务我使用的是Spring自带的@Scheduled注解：

@Scheduled(cron = "0 0 2 * * ?") public void scanOverdueRecords() { List<BorrowRecord> overdueList = borrowRecordMapper.selectOverdueRecords(); for (BorrowRecord record : overdueList) { record.setStatus(BorrowStatus.OVERDUE); borrowRecordMapper.updateById(record); messageService.sendOverdueNotice(record); } }

cron表达式设置成每天凌晨两点执行，是为了避开业务高峰期。定时任务执行时机可以灵活，但千万不能设置太频繁，否则会造成无意义的数据库压力。

定时任务有三个坑需要特别提醒：

• 如果部署了多个实例，@Scheduled任务会在每个实例上都执行一遍，产生重复消息。解决方案是使用分布式锁，或者在配置里控制只有一台机器开启任务。毕设阶段单机部署通常不会遇到，但如果未来扩展，这个点必须注意。
• 任务执行失败要有Log记录。我加了异常捕获和运行日志，方便排查“为什么某天逾期记录没有正常更新”。
• 定时任务里“更新状态”和“发消息”要放在同一个事务里，避免状态已更新但消息没发出去的数据不一致情况。

4. 数据库设计与查询优化

4.1 核心表结构设计思路

数据库设计是整个项目的基石。表结构如果设计得不合理，后面每写一个功能都会觉得很别扭。我设计的核心表主要有这几张：

用户表（user）包含用户ID、用户名、密码（加密存储）、姓名、学号/工号、所属学院、角色类型、手机号、邮箱、创建时间。密码加密我使用了BCrypt算法，绝不能明文存储。学号字段建议加唯一索引，因为学号是定位用户身份的最稳定字段。

设备分类表（equipment_category）包含分类ID、分类名称、分类描述。分类表和设备表是一对多关系。之所以单独拆表，是为了统计报表时能按类型聚合数据。

设备表（equipment）包含设备ID、设备编号、设备名称、型号、规格、分类ID、所属实验室、存放位置、状态、采购价格、购买日期、当前借用人ID、累计借用次数、设备照片URL、备注、创建时间、更新时间。设备编号要加唯一索引。

借用申请表（borrow_application）包含申请ID、申请单编号、申请人ID、申请说明、申请起始时间、申请结束时间、申请状态、审批人ID、审批时间、审批意见、创建时间。这张表的主流程是审批过程。

借用记录表（borrow_record）包含记录ID、关联的申请单ID、设备ID、借用人ID、出借管理员ID、应还时间、实际借出时间、实际归还时间、归还管理员ID、归还时状态、设备状态备注（正常/损坏）、状态。这张表对应具体的设备借用周期。

操作日志表（operation_log）包含日志ID、操作人ID、操作类型、操作对象类型、操作对象ID、操作内容、操作时间、IP地址。记录关键操作，用于审计追溯。

消息通知表（message_notification）包含消息ID、接收人ID、消息标题、消息内容、消息类型、是否已读、创建时间。

这样一个表结构，基本覆盖了设备借用平台所需的全部数据场景。

4.2 索引与查询优化方案

表设计好之后，索引设计直接影响系统的查询体验。我在最初阶段走了弯路，把所有可能查询的字段都加了索引，结果写入速度和存储空间都有问题。后来调整成以下思路：

• 用户表：学号唯一索引，用户名唯一索引。
• 设备表：按设备状态查询非常频繁，所以状态字段加普通索引；设备编号加唯一索引；分类ID加普通索引，用于按分类筛选。
• 借用申请表：申请人ID加普通索引，申请状态加普通索引，创建时间加普通索引。因为需要按某个时间范围查询申请量，所以创建时间索引很有必要。
• 借用记录表：这是整个系统查询压力最大的表。设备ID加普通索引，借用人ID加普通索引，状态加普通索引，应还时间加普通索引。查询逾期记录时，“状态+应还时间”组合查询非常有效，可以用联合索引(status, end_time)。

统计报表是另一个查询压力点。比如按月份统计各学院借用次数，如果每次报表页加载都实时查全表，数据量大时响应会明显变慢。我用了两个办法：

• 避免COUNT(*)全表扫描，尽量走带索引的条件查询。
• 提前把统计数据聚合到一张报表表中，定时任务每个小时更新一次汇总数据，报表页直接查汇总表。

这个聚合思路在毕设规模下足够用，也容易向老师解释。

5. 实操中遇到的典型问题和排查方法

5.1 时间边界问题：LocalDateTime用了也踩坑

开发初期我使用的是Date类型，后来统一换成了Java 8的LocalDateTime。LocalDateTime确实比Date更直观，但它在实际项目中有几个容易踩的坑。

第一个坑是前后端的时间格式解析。前端传上来的时间是“2025-06-01 14:30:00”这样带T或者带空格的格式，如果后端的全局时间格式化配置不规范，接口会直接报错。我通过一个全局Jackson配置统一了时间格式，同时在前端也做了对应处理。

spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8

第二个坑是时间段重叠判断时，需要特别小心“当天开始、当天结束”的边界。比如借用时间是6月1日9点到6月1日12点，归还日期判断要精确到分钟，不能只比较到日期。我最后把设备借用时间粒度统一为分钟，所有比较都使用LocalDateTime的isAfter和isBefore方法。

第三个坑是默认时区。MySQL连接字符串里如果没有设置serverTimezone=Asia/Shanghai，在服务器上运行时可能出现时间差8小时的问题。这个坑很隐蔽，本地开发环境正常，部署到云服务器就出现时间错乱，排查了很久才发现是连接参数漏了时区配置。

5.2 事务失效与脏读

我在写借用流程时，最初把校验、改状态、插记录都写在service方法里，加了@Transactional注解，但实际测试时发现数据还是出现了不一致。排查之后确认是事务根本没有生效。

最常见的事务失效原因有两个。第一个是方法在同一个类内部调用，@Transactional没有经过代理对象，因此不会起效。比如我在BorrowApplicationServiceImpl里写了一个公有方法approveApplication，它内部调用了同一个类的私有方法updateEquipmentStatus，后者虽然加了@Transactional，但实际不会触发事务。解决方式是把事务方法拆到另一个Service类中，通过Spring注入的代理对象调用。

第二个是异常被吞掉。@Transactional默认只对RuntimeException和Error回滚，如果方法里捕获了异常并返回了错误信息，没有往外抛，事务就不会回滚。所以我在异常处理时统一抛出自定义的BusinessException，并且在全局异常处理器中统一转化成接口响应。

排查这个问题的过程中我养成了一个习惯：在事务方法执行完以后打印日志，核对数据库实际值，确认是否真的提交了。光靠肉眼读代码，很难发现自己调用自己这样的隐蔽问题。

5.3 前端联调跨域与Token刷新

前后端分离项目，联调阶段最常遇到的问题就是跨域。前端页面运行在8080端口，后端接口运行在8081端口，浏览器默认会拦截跨域请求。我在后端配置了全局跨域过滤器：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

这个配置能解决多数跨域问题，但如果开着allowCredentials(true)，allowedOriginPatterns就不能写成"*"，否则部分浏览器会直接拦截。排查联调问题时，建议先打开浏览器开发者工具看具体报错信息，再决定是加请求头还是调整跨域配置。

另一个我踩过的坑是Token过期后接口返回401，但前端没有做统一处理，用户看到的是满屏报错。后来我在Axios的响应拦截器里统一判断HTTP状态码，遇到401就跳转到登录页并清空本地Token。这个改动虽然小，但对演示时的体验提升非常明显。

6. 部署、文档写作与答辩准备

6.1 本机运行、打包与远程调试的路径

毕设交付通常要求代码能在别人电脑上顺利跑起来。为了达到这个目标，我整理了一份从零开始的环境启动文档，内容包含：JDK、MySQL、Redis、Node.js的版本要求和安装步骤，数据库脚本的执行顺序，后端配置文件中的数据库账号密码修改点，前端依赖安装命令，前后端启动命令。

后端打包成可执行jar包的方法很简单：

mvn clean package -DskipTests java -jar lab-equipment-platform.jar

实际部署到服务器时，我建议不要直接使用java -jar前台启动，因为关闭终端窗口服务就断了。更好的方式是使用systemd服务把jar注册成后台服务，这样即使服务器重启，服务也会自动启动。

这里多说一句“远程调试”。很多同学遇到部署后的问题，第一反应是让同学帮忙看代码。我的实际经验是：远程调试最有效的方式不是隔着屏幕发截图，而是给对方一个能复现问题的完整操作步骤，配合后端日志信息快速定位。所以我在每个核心Service方法里都加了足够的日志输出，尤其是审批、出借、归还这几个关键动作，会在日志里打印请求参数和操作结果。这样出了问题，翻日志比翻代码快得多。

6.2 毕业设计说明书重点写什么

说明书是毕设答辩的重要材料。我的写作经验可以浓缩成一句话：不要只写“做了什么”，更要写清楚“为什么这样做”。

说明书我分成了这样几章：

• 引言/背景：描述实验室设备管理现状和问题，引出系统的必要性。这里不要空谈建设意义，要结合真实的管理流程痛点来讲。
• 需求分析：角色划分、功能流程、用例图（尽量使用文本描述）、功能需求列表。
• 系统设计：系统架构图、功能结构、数据库ER图、表结构说明、接口设计。
• 系统实现：按模块介绍核心功能的实现思路，配上关键代码片段和截图。
• 系统测试：测试用例表、测试结果、典型问题修复记录。

回答老师问题时，重点放在几个方面。第一是需求的理解，为什么要做状态流转；第二是并发场景的解决思路，时间段重叠如何避免；第三是异常场景的考虑，比如审批通过后学生不来领取怎么办，逾期了怎么处理。只要这几个关键点上你能展示出独立的思考，老师的追问基本不会难倒你。

6.3 演示准备与讲解建议

答辩现场最忌讳的是照着PPT念功能列表。我的做法是准备一套固定的演示脚本，按照一个完整业务故事推进：

先用一段话引入场景，比如“现在实验室有一台光学显微镜被学生申请借用，我来演示完整流程”。然后在系统里走一遍：注册或登录学生账号，提交借用申请，切换管理员账号审批通过，回到学生账号模拟线下领取，管理员确认出借，演示设备状态如何变成已借出。接着再模拟归还过程，最后打开统计报表展示本月借用数据。

演示前一定要做的事是重置数据。不要把之前测试产生的脏数据留在页面上，否则老师看到一张乱糟糟的列表，第一印象就打折扣。我习惯准备一个初始化脚本，演示前执行一次，把设备状态、借用记录都恢复到干净状态。

关于讲解节奏，我的建议是每个功能点控制在1到2分钟。动作慢一点，屏幕上的每一步操作都配合讲解，宁可少演示一个功能，也不要语速飞快地跳来跳去。重点在审批流程、状态变化、逾期提醒和统计报表这几个有“含金量”的场景上停留足够时间。

说回开发体验。这个项目最让我意外的地方是，真正消耗时间最多的不是写代码，而是梳理清楚业务规则。设备状态怎么流转、审批通过后库存怎么占用、边界时间怎么判断，这些都是在代码之前就应该想明白的问题。如果你也在做类似的管理系统，我的建议是先在纸上把流程图画清楚，把每个状态的跳转条件和异常场景列出来，再动手写代码。设计草稿越细，后面返工越少。等到答辩结束回看整个项目，你会发现这几个月最大的收获不是那些CRUD代码，而是从需求拆解到完整交付的这套工程思维。