企业官网建设流程全解析

每年到这个时候，毕设群里问得最多的一个问题就是："老师，我这个系统怎么做才能过？"单说"器材管理"四个字，网上随便一搜能翻出十几套代码，但真正把借还流程、报修状态、审批链路想清楚的其实没几个——大部分项目是给器材表做了一套增删改查，套了个管理系统壳，点到为止。

今天这篇博客，我想以"springboot实验室硬件器材智能管理平台"为线索，从头到尾拆一遍这类系统应该怎么做。不只是贴代码，而是把选题背景、技术选型、数据库设计、核心业务逻辑、答辩问题全部串起来聊聊。尤其是后端技术栈围绕springboot展开的部分——为什么用它、版本怎么选、表怎么建、借出归还的并发怎么处理，这些才是毕业设计能不能拿高分的分水岭。

这个题目适合谁？适合那些想做一个"既不难到写不完、也不浅到像课设"的Java Web毕设的同学。它的业务复杂度刚好卡在CRUD之上、微服务之下：有状态流转、有审批节点、有库存事务，一个人用Spring Boot Plus一套前端完全啃得动，但做出来的东西又能讲出深度。你只要把器材状态的每一次流转都写清楚，把借还的并发控制做到位，答辩的时候就不是老师问你，而是你带着老师走。

1. 为什么选"器材管理"这个题目：看似常规实则暗藏门道

很多同学听到"器材管理"第一反应是"太普通了"。确实，图书管理、设备管理、仓库管理这类题目在毕设里占了半壁江山。但普通不代表简单，反而说明这类系统的业务模型成熟、需求边界清晰，是最适合做成"完整闭环"的一类题目。实验室硬件器材管理和图书管理的本质区别在于：器材有生命周期，有维修、报废、巡检、借用损耗，这些状态不是一条直线走到底，而是存在多路径流转的。

1.1 实验室器材管理的真实痛点

先站在用户角度想想，一个没有管理系统的实验室现在是怎么管器材的？

管理员拿着一个Excel表，记录每台设备的存放位置、使用人、状态。学生想借一台万用表，得先问管理员"这表在不在"，管理员翻半天表说"在"，学生填个纸质登记簿，走了。过了一周，隔壁实验室的人来借，管理员又去翻，发现那台万用表已经被借走了，但登记簿上写的归还日期早就过了，设备在谁手里完全不知道。再往后设备坏了，管理员在Excel里把状态改成"维修"，但修了多久、花了多少钱、修完能不能用，全靠记忆。

这些场景映射到系统里，就是三件事：设备状态要实时可查，借用记录要可追溯，维修/报废流程要有闭环。而这三个需求恰好对应了数据库设计的三个核心表：器材表、借出记录表、维修记录表。系统解决的就是"管理员不用追着Excel问，学生不用跑三趟就为确认设备在不在"的问题。

1.2 系统需要覆盖的功能边界与核心角色

不要一上来就想着把所有功能都做进去，先划边界。这个平台需要覆盖的核心功能有四个模块：器材信息管理（包括分类、存放位置）、借用归还管理（申请、审批、归还登记）、维修报废管理（报修、维修记录、报废）、系统基础管理（用户、角色权限、数据统计）。再往下拆，每个模块都有独立的业务闭环。

角色方面我建议设计成三类：管理员（实验室负责人）、教师、学生。三类角色的权限层级很清晰：管理员能管所有东西，教师能发起借用申请和报修，学生只能借用和查看自己的记录。这种"三角色+分层权限"的设计在答辩时特别好讲，因为你只需要把权限表设计清楚，就能解释系统的安全性——这一点很多毕设做得非常弱，直接所有用户都是admin角色，这会在答辩时被问倒。

1.3 怎么让"智能"名副其实而不是噱头

标题里有"智能"两个字，很多同学就在题目里堆"智能"，但做完系统里面一点不智能。这其实是答辩最容易翻车的地方——老师会问你："你这个系统智能在哪里？"

实际上，"智能管理平台"的"智能"在毕业设计层面可以体现在几件具体的事情上：一是临期归还自动提醒，系统根据借出记录的预计归还日期，自动生成待办提醒或邮件通知；二是设备利用率统计，知道哪些设备长期闲置，哪些设备供不应求；三是库存预警，当某类器材的可借数量低于阈值时自动提示管理员补购。也就是说，"智能"是通过定时任务、数据聚合、消息推送这些具体技术落地的，而不是空喊一个词。这部分做到两三处就足够支撑题目里的"智能"了。

2. 技术选型与架构设计：Spring Boot为主心骨的取舍逻辑

这篇博客的主题是"springboot实验室硬件器材智能管理平台"，那技术选型的核心就围绕Spring Boot来展开。但选型不能只说"因为大家都在用"，要把每个选择的理由讲清楚。毕设答辩时老师最常问的就是"你为什么用这个技术而不用那个"，这需要你在写文档之前就想明白。

2.1 为什么是Spring Boot而不是SSH或者SSM

如果你是几年前问这个问题，主流答案可能是SSM（Spring + SpringMVC + MyBatis）。那时候搞个SSM框架要写一堆XML配置文件，数据源、SqlSessionFactory、事务管理器一个个配，项目还没开始写代码就搭了大半天环境。而Spring Boot把"约定优于配置"用到了极致：内嵌Tomcat，直接跑一个main方法就能启动项目；自动装配帮我们把各种Bean的注册处理掉；Spring Boot Starter让我们引入依赖时只需要一个坐标。

更实际的原因是：现在网上能找到的教程、开源项目、面试题，绝大多数是基于Spring Boot的。你遇到问题去CSDN或GitHub上搜，答案基本都能直接对上。用SSM的话，版本兼容问题和配置问题会浪费大量时间，而这些时间和毕设的deadline过不去。记住，毕业设计选工具的第一原则是"生态成熟度"，而不是"技术新旧"。Spring Boot 2.x至今仍然是最稳妥的毕设选择，不是因为3.x不好，而是因为2.x的资料量、踩坑记录、兼容性验证都沉淀得足够厚。

2.2 配套技术栈的选择：ORM、前端、权限

后端框架定了Spring Boot，配套的技术栈也要考虑清楚。ORM层面我建议直接用MyBatis Plus而不是原生MyBatis。原因有三点：第一，单表CRUD不需要手写XML，BaseMapper直接给到了增删改查的通用方法；第二，条件构造器QueryWrapper做多条件筛选非常顺手，器材列表按名称、状态、分类筛选，只需要链式调几行代码；第三，分页插件PageHelper或者MyBatis Plus自带的PaginationInnerInterceptor都集成简单，毕设的分页列表功能两小时搞定。而原生MyBatis的优点是SQL可控、优化空间大，但毕设阶段你的数据量到不了需要人工优化SQL的地步。

前端方面，如果不擅长写页面，直接使用Vue + Element UI的经典组合，或者更省事一点，用Thymeleaf加Bootstrap做服务端渲染。但我要提醒一点：如果你的题目描述里带了"平台"两个字，那用前后端分离（Vue + Spring Boot）会更匹配题目的完成度。前后端分离意味着你需要额外处理跨域、登录Token、接口文档，这些工作量会增加，但在答辩时作为"亮点"讲出来效果完全不同。你甚至可以讲：前端通过Nginx部署、后端打包成Docker容器，系统具备基本的可部署性——这句话的价值比一个漂亮的按钮大得多。

权限控制的实现方式也要提前考虑。最简单的方案是使用Spring Security + JWT做登录认证和权限控制。但也有个务实的做法：如果你对Spring Security的过滤器链机制不熟，用拦截器（HandlerInterceptor）加自定义注解也能实现角色权限校验。拦截器的原理很简单：在请求进入Controller之前，从请求头里取出Token，解析出用户角色，判断当前请求的接口是否有权限。毕业设计用拦截器完全够用，而且更容易在答辩时把流程讲清楚。Spring Security的认证流程是"过滤器链中的一层一道"，很多人讲不明白反而露怯。选自己掌握的方案，不要为了炫技选不熟悉的技术。

2.3 版本选择的教训：别让"版本太高"成为毕设拦路虎

这里要重点提一下"springboot版本太高"这件事，因为这是毕设开发中真实高频出现的问题。有的同学习惯打开Spring Initializr直接选最新版本，结果Spring Boot 3.x要求JDK 17以上，而电脑上默认的是JDK 8，项目起不来；还有一些老教程里的代码基于2.x，到了3.x就出现Jakarta命名空间变更（javax改成jakarta），Maven里依赖坐标对不上，浪费两三天排查。

我的建议是：如果是第一次写Spring Boot项目，直接选定2.7系列版本（比如2.7.18），配JDK 8或者JDK 11，把MyBatis Plus、MySQL驱动、Lombok、Validation这些依赖装在pom里面。2.7版本处于2.x的最后一个稳定分支，既避开了3.x的新坑，又能兼容绝大多数网上的教程和代码示例。如果一个项目已经把登录、权限、CRUD都写完了，不要轻易升级Spring Boot版本——升级带来的收益是零，但踩坑的风险是百分之百。这个原则不只在毕设阶段通用，放到实际工程项目里同样成立：线上系统不会因为"框架有了新版本"就贸然升级。

3. 数据库设计的核心：器材状态机与五张核心表

业务功能理清楚了，技术栈定好了，接下来最关键的环节就是数据库设计。这一步决定系统的上限。很多毕设失败不是因为代码写不出来，而是表结构设计得太随意，后面写业务逻辑的时候这里改那里改，最后代码像打补丁一样堆叠起来。器材管理系统的核心是"器材状态"，所以数据库设计首先要定义清楚状态机。

3.1 器材状态的四种流转路径

一台硬件器材从进实验室到最终报废，它的一生大概会经历这样几种状态：

• 在库可用（AVAILABLE）：器材在库房或存放位置，状态正常，可以被借用。
• 已借出（BORROWED）：器材被用户借走，尚未归还。
• 维修中（REPAIRING）：器材出现故障，已提交报修单，正在维修。
• 已报废（SCRAPPED）：器材无法修复或超出经济维修价值，人工报废。

这四种状态不是任意互转的，而是有严格的流转路径。在库可以借出变成已借出；已借出归还后回到在库；在库发现故障可以报修变成维修中；已借出使用期间损坏也可以报修变成维修中；维修中修好之后回到在库；维修中经检测无法修复则报废；在库设备年限过久也可以直接报废。

这个状态机的设计价值在于：它让系统的每个业务操作都有据可依。你在后端写借出接口时，第一步不是判断用户有没有权限，而是判断器材当前状态是不是AVAILABLE——只有在这个状态下才能发起借出流程。同理，报修接口只允许在AVAILABLE和BORROWED两种状态下发起。状态机说白了就是给数据流建立规则，让系统不允许"非法操作"。

3.2 核心表结构设计与字段解释

基于状态机和业务需求，系统至少需要五张核心表。我不打算贴完整的建表SQL，而是把每张表的关键字段和设计逻辑说清楚，你照着自己的业务微调即可。

第一张表是器材表（equipment）。id是主键；equipment_code是器材编号，这个字段要做唯一索引，因为它是器材的"身份证号"，在实体实验室里通常由资产编码规则生成，比如"LAB-DMM-001"；name是器材名称；category_id关联器材分类表，分类表独立一张（equipment_category），包含仪器仪表、电子元件、计算机设备等类别；location_id关联存放位置表，精确到房间和柜位；status是当前状态，建议用int存储（0在库、1借出、2维修、3报废），而不是直接存字符串——int存储空间小、查询快，而且可以配合枚举类在后端做状态判断。还要有price（采购价格）、purchase_date（采购日期）、warranty_end（保修截止日期）。

第二张表是借出记录表（borrow_record）。id主键；equipment_id关联器材表；user_id关联用户表；borrow_date（借出日期）、expected_return_date（预计归还日期）、actual_return_date（实际归还日期）这三个日期字段是核心。status用来说明记录状态：0借出中、1已归还、2逾期归还。注意，逾期不是一个独立状态，而是在"借出中"且当前日期晚于expected_return_date时计算出来的派生状态，所以我们用定时任务扫表，把满足条件的记录标记出来即可，不需要让它单独占一个状态位。

第三张表是维修记录表（repair_record）。id；equipment_id关联器材；report_user_id是报修人；report_reason是故障描述；repair_status（0待维修、1维修中、2维修完成、3无法修复报废）；repair_company（维修单位）、repair_cost（维修费用）在维修完成后填写；create_time和finish_time记录时间。

第四张表是用户表（sys_user），包含账号、密码、姓名、角色（0管理员、1教师、2学生）、所属院系/课题组。密码存储必须加密，用BCrypt或者MD5加盐都行，答辩时能说清楚加密方式就行。

第五张表是审批记录表（approval_record）。这里我不建议把审批字段塞进借出记录表，而是单独建一张通用的审批表，包含business_type（业务类型：借出申请/报废申请）、business_id（对应业务表的id）、approver_id（审批人）、approve_result（同意/拒绝）、approve_comment（审批意见）、create_time。这样设计的好处是：以后如果要扩展报修审批或者购买审批，不需要动表结构，直接加一个business_type就行。

3.3 为什么这样设计：冗余与规范的平衡

有个问题值得展开讲一下，就是"为什么不把借出人直接写在器材表里"。很多同学会觉得：器材表加一个current_user_id字段，记录当前谁借了器材，查询不就很方便吗？这个设计在读写并发小的场景下没毛病，但问题出在历史追溯上。如果器材表只有current_user_id，那这台器材过去被谁借过、借了几次、每次都借了多久，就完全没有记录。所以正确做法是把"当前状态"放在器材表快速查询，把"完整历史"放在借出记录表里做追溯。查询当前借出人时，只需要关联borrow_record表中status=0的记录即可。这就是"冗余与规范"的平衡：器材表冗余一个当前状态字段，提升查询效率；而借出的明细历史单独建表，保证数据完整性。

同理，器材表里也不需要存一个"累计借出次数"字段。这个数据完全可以通过统计借出记录表得到，而且如果每次借出还要去更新器材表里的次数，等于把简单业务复杂化，还会带来并发更新问题。记住一个原则：能通过查询计算出来的数据，优先查询计算；查询有性能瓶颈时，再加冗余字段。毕设阶段的数据量远到不了需要大量冗余的程度。

4. 核心业务模块的实现：借出、归还、报修的完整链路

表结构定下来之后，实际的编码工作就相对清晰了。这一节我重点讲三个模块的实现思路和代码逻辑，因为这是整个系统的核心价值所在，也是答辩时最能体现"这是你自己做的东西"的部分。

4.1 借出流程：审批驱动下的状态变更

借出流程我建议设计为"申请—审批—取用"三步，而不是学生登录系统后点一下"借出"就把器材status改成已借出。为什么？因为器材是公共资源，需要有管理员或教师的审批环节来确认"这台设备确实可以借给你"。加了审批环节后，系统的权限层次和业务复杂度都上了一个台阶，答辩时能讲的东西也多了。

流程具体是这样的：学生在前端选择要借的器材，填写预计归还日期和使用用途，提交借出申请（此时生成一条borrow_record记录，status是待审批）。管理员收到审批待办，在列表里看到申请的器材、申请人和用途，点击同意后，后端做三件事：一是把approval_record插入一条记录；二是把器材状态从AVAILABLE变成BORROWED；三是把borrow_record的状态从待审批变成借出中。这三步必须放在同一个事务方法里，否则会出现器材状态改了、借出记录还是待审批的不一致情况。

核心Service代码里，借出接口的骨架大概是这样的：

@Transactional public void approveBorrow(Long borrowRecordId, Long approverId, boolean approved) { BorrowRecord record = borrowRecordMapper.selectById(borrowRecordId); if (record == null || !record.getStatus().equals(BorrowStatus.PENDING)) { throw new BusinessException("借出申请不存在或已处理"); } // 保存审批记录 ApprovalRecord approval = new ApprovalRecord(); approval.setBusinessType(BusinessType.BORROW); approval.setBusinessId(borrowRecordId); approval.setApproverId(approverId); approval.setApproveResult(approved ? ApproveResult.APPROVED : ApproveResult.REJECTED); approvalMapper.insert(approval); if (approved) { // 修改器材状态：在库 -> 已借出 Equipment equipment = equipmentMapper.selectById(record.getEquipmentId()); if (!equipment.getStatus().equals(EquipmentStatus.AVAILABLE)) { throw new BusinessException("器材当前不在库，无法借出"); } equipment.setStatus(EquipmentStatus.BORROWED); equipmentMapper.updateById(equipment); // 更新借出记录状态 record.setStatus(BorrowStatus.BORROWING); record.setBorrowDate(new Date()); record.setExpectedReturnDate(record.getExpectedReturnDate()); borrowRecordMapper.updateById(record); } else { record.setStatus(BorrowStatus.REJECTED); borrowRecordMapper.updateById(record); } }

这段代码里有两个关键点。第一，@Transactional保证审批记录、器材状态、借出记录三个更新操作要么全部成功，要么全部回滚。第二，在修改器材状态前，再做一次状态校验，看器材当前是否是AVAILABLE。这个校验叫乐观锁思路，防止的是"并发"场景——比如两台设备同时被两个学生申请，都通过了管理员审批，但实际只有一台在库，这时另一个审批应该失败。如果你只在前端做状态展示，不在后端做状态校验，就会出现超借。

4.2 归还流程：逾期判断与器材检查

归还流程相对简单，但有两个细节容易忽略。

第一个细节是"逾期判断"。学生归还器材时，系统应该根据expected_return_date自动判断是否逾期，并在归还记录上标记，把借出记录状态改成"已归还"或"逾期归还"（实际归还日期晚于预计归还日期时标记为逾期）。这个判断逻辑不要在用户点击归还的时候临时算，而是在写归还接口时，先读取出expected_return_date，和当前日期比较后再更新状态。

第二个细节是器材检查。归还时管理员应该检查器材是否外观完好、能正常开机。这个动作落到系统里，就是归还接口需要管理员填写一个"归还备注"，记录"外观完好"或"存在故障"。如果备注里说有故障，那归还流程还要联动触发维修流程——器材状态不是返回AVAILABLE，而是直接进入REPAIRING。这一步能体现你对业务流程的理解深度。

归还方法的逻辑类似于：

@Transactional public void returnEquipment(Long borrowRecordId, Long operatorId, String returnRemark) { BorrowRecord record = borrowRecordMapper.selectById(borrowRecordId); if (record == null || !record.getStatus().equals(BorrowStatus.BORROWING)) { throw new BusinessException("没有找到该借出中的记录"); } Equipment equipment = equipmentMapper.selectById(record.getEquipmentId()); Date now = new Date(); if (now.after(record.getExpectedReturnDate())) { record.setStatus(BorrowStatus.OVERDUE_RETURNED); } else { record.setStatus(BorrowStatus.RETURNED); } record.setActualReturnDate(now); record.setReturnRemark(returnRemark); borrowRecordMapper.updateById(record); // 根据检查结果决定器材状态去向 if (returnRemark.contains("故障") || returnRemark.contains("损坏")) { equipment.setStatus(EquipmentStatus.REPAIRING); } else { equipment.setStatus(EquipmentStatus.AVAILABLE); } equipmentMapper.updateById(equipment); }

if条件用contains判断备注内容其实不太优雅，更合理的做法是加一个returnGoodCondition布尔字段，管理员勾选"是否完好"，代码里用布尔值判断。这个细节你在设计表结构的时候就要想到，不要在写代码时临时加字段。

4.3 报修流程：从用户提交到维修闭环

报修流程同样是一个闭环。用户（学生或教师）在系统里提交报修单，填写器材ID和故障描述。系统收到报修单后，把器材状态改为REPAIRING。维修人员可以是校内技术员，也可以是外部维修公司。维修完成后，管理员在系统里录入维修结果：维修成功，器材状态回到AVAILABLE；无法修复，器材状态变为SCRAPPED，同时生成报废记录。

这里值得注意的一点是：报修单的创建入口不只属于管理员，所有登录用户都应该可以提交。因为实际场景中，学生借设备用着用着发现坏了，他应该能直接发起报修，而不是通知管理员再由管理员操作。这就是角色权限中的"发起者"和"执行者"分离，是业务流程设计上比较成熟的做法。

报修模块的代码逻辑和借出审批类似，核心是一个状态转换加一条记录插入。我建议把"报修单状态"和"器材状态"分开存，不要混在一起。报修单状态记录的是维修流程本身走到哪一步（待受理/维修中/已完成），器材状态则是设备当前的库存状态。举个例子：设备报修了，报修单状态是"待受理"，器材状态是"维修中"；开始维修了，报修单状态变成"维修中"，器材状态不改变——已经维修中的设备不能再被其他人报修，这个控制通过器材状态来判断即可。

4.4 事务与并发控制的核心：防止同一台器材被重复借出

这是整个开发过程中最容易出错、也最值得单独提出来讲的部分。我做这个系统时第一次测试就遇到了一个问题：两台电脑同时提交借用同一台示波器的申请，管理员分别审批通过，结果后来的审批也成功了——一个器材被借出去两次。问题的根源在于：第一步读取器材状态时，两台请求都读到了AVAILABLE，然后各自把状态写成了BORROWED，互相覆盖。

解决方案有几种层次。最简单的是在器材表加一个乐观锁字段version。在更新器材状态前，先把version取出来，update语句里带条件"where id = ? and version = ?"，如果影响行数为0，说明version变了，就抛异常让请求失败。MyBatis Plus里用@Version注解配合OptimisticLockerInnerInterceptor插件就能实现。这个方案不需要锁表，并发性能好，代码改动量小。

另一种方案是用悲观锁，在事务里对器材表的这一行加锁：select * from equipment where id = ? for update。for update是数据库层面的行级锁，其他事务想对这一行做更新就得排队等待。这种方案逻辑上更稳，但要注意SELECT必须包裹在事务方法里，否则查完锁就释放了，等于没锁。

对毕设系统来说，我推荐用乐观锁方案。悲观锁虽然直观，但实现时容易因为事务边界问题弄出"锁了个寂寞"的情况，而且答辩时老师问"HikariCP连接池死锁"相关问题，你不一定招架得住。乐观锁加一个version字段，一行注解加一个拦截器搞定，但你能把这个机制讲清楚，就已经比很多同学强了。

5. 让系统"看起来真能用"的加分项：消息提醒、审计与数据看板

毕设的评分往往不全在功能实现上，"完成度"和"细节"同样重要。同样的器材管理功能，有人做出来像课设，有人做出来像商用系统，差距就在细节的处理上。这一节讲三个能明显提升系统完成度的加分项，每个的代码难度都不高，但在答辩现场展示出来效果完全不同。

5.1 临期归还提醒与消息通知

借出去的器材，过几天就到归还日期了，管理员应该自动收到提醒，这样他可以去催还或准备对接。实现方式上，我建议在Spring Boot中启用@Scheduled定时任务，每天上午9点跑一次扫描：查出所有status=BORROWING且expected_return_date在三天之内的借出记录，生成待办提醒给管理员。

消息触达可以用两种方式：一种是在系统站内信/待办表里生成一条待办记录，管理员登录后看到一个红点；另一种是接入邮箱或QQ邮件通知，直接把提醒发送到管理员邮箱。第一种实现成本低，但"智能感"弱一些；第二种能讲故事，但需要你自己有一个SMTP邮箱服务，并在配置文件里设好邮箱授权码。优先做站内待办，时间富余再加邮件。站内待办的实现思路是建一张notification表，包含user_id、title、content、status（未读/已读）、create_time。定时任务查到逾期列表后，批量插入notification记录即可。

顺带一提，这个@Scheduled定时任务也可以用来做"库存预警"——统计某类器材在库数量低于阈值时生成补货建议。这一处又是"智能"这个词的落地体现，答辩时直接说"系统通过定时扫描和自动通知，实现了临期催还和低库存预警"——老师听起来就觉得你是真的在做系统，而不是写CRUD。

5.2 操作审计日志的设计

第二个加分项是审计日志。现在很多系统做了登录功能，但完全没有记录"谁在什么时候做了什么操作"。审计日志是一个系统成熟度的重要标志。实现上可以用Spring Boot的AOP思想写一个切面，在需要记录的操作方法上加自定义注解@AuditLog，方法执行后自动把用户、操作类型、方法参数、执行时间写入日志表。

实战中更简单的做法是定义一个LogAspect类，用@Pointcut扫描所有controller包下的方法，通过Method.getAnnotation解析出操作方法描述，作为日志的action字段入库。注意，审计日志和异常日志要分开，审计日志只关心业务操作，比如"张三借出了示波器"、"李四提交了报修单"；异常日志则是技术层面的错误堆栈，用于排查问题。表结构差异很大，不要混在一张表里。

审计日志的价值在答辩时怎么讲？只要提一个场景就足够：系统里一台价值五万的设备报废了，管理员想知道是谁发起的报废操作、审批人是谁、报废理由是什么。有审计日志就能完整追溯这个操作链路，没有审计日志就全靠猜。这个回答比"我加了日志功能记录操作"这种答案高一整个层次。

5.3 简易统计看板：器材利用率与报修率

最后说一下数据看板。

很多毕设里都有"统计报表"模块，但做得好的不多。核心问题在于：用什么数据、用什么方式展示、数据结论有什么业务含义。我个人建议不要做花哨的ECharts大屏，而是做四个有明确业务含义的统计卡片和一个简单趋势图：

• 器材总数、在库数量、借出数量、维修中数量：一眼看清当前整体状况。
• 热门器材Top5：根据借出记录统计哪些器材被借得最多。
• 各分类器材占比：用饼图展示不同类别器材的数量比例。
• 每月借出/归还趋势：用折线图展示近六个月的借还数量。

统计数据的SQL不难，核心是几个Group By和Count。比如热门器材Top5：

SELECT e.name, COUNT(b.id) AS borrow_times FROM borrow_record b LEFT JOIN equipment e ON b.equipment_id = e.id GROUP BY b.equipment_id, e.name ORDER BY borrow_times DESC LIMIT 5

需要注意的是：统计接口的性能优化在这个阶段不需要过度追求，但如果器材表的数据量大，建议给borrow_record表的equipment_id字段加普通索引，让Group By不扫全表。数据看板的"输出"形式是要放在答辩PPT里的，用静态图不如直接在系统里打开看板做演示，因为是实时数据，更可信。

6. 开发中的血泪经验与答辩高频问题

最后这一节，我把自己做这类系统时踩过的坑、总结的经验以及答辩现场的高频问题一起列出来。这些内容都是我真实经历过的，希望能帮你避开不必要的麻烦。

6.1 最容易踩的五个坑

第一个坑是Spring Boot版本与JDK版本不匹配导致的启动失败。前面已经重点说过，建议直接用2.7.x配JDK8/11。如果你已经在用3.x，注意JDK要升到17，否则启动时一堆莫名其妙的报错。

第二个坑是MyBatis Plus的逻辑删除与状态字段混淆。很多同学为了"软删除"给表加了deleted字段，逻辑删除后查询自动过滤没问题，但要注意：逻辑删除只适用于删除，不适用于状态变更。器材报废应该用status字段记录成SCRAPPED，而不是把这条记录delete掉。删除记录意味着器材消失，但报废器材的历史借出记录、维修记录都需要关联，不能物理消失。

第三个坑是日期格式处理。前端传过来的日期字符串默认是"yyyy-MM-dd HH:mm:ss"，而后端实体类的Date类型在接收时如果没有配置Jackson格式，就会解析失败或显示成时间戳。建议在application.yml里统一配置：

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

另外，数据库时区也要配置好，MySQL连接串后面加serverTimezone=Asia/Shanghai，否则插入的时间会因为时区问题差8个小时。

第四个坑是前后端联调时的跨域配置。前后端分离项目里，Vue跑在8080端口，Spring Boot跑在8081端口，两者一联调必跨域。解决办法是给后端写一个CorsConfig配置类，或者使用@CrossOrigin注解加在Controller上。注意全局配置要留意放行的方法类型，否则PUT、DELETE请求会被拦。

第五个坑是Maven依赖冲突。典型的现象是引入了Spring Security后，启动时报ClassNotFoundException: javax.servlet.Filter，多半是servlet-api的scope或版本冲突。解决办法是检查pom里是否手动引入了servlet-api、tomcat-embed-core等冲突依赖，移除多余的那个。还有一个常见冲突是Lombok版本和JDK版本不匹配，比如JDK 17配Lombok版本过低会报Caused by: java.lang.ClassCastException。遇到这种情况，把Lombok升级到1.18.30以上即可。

6.2 答辩时老师一定会问的方向

答辩问答环节其实有规律可循。准备这些问题的答案，比你多写一万字论文更有用。

第一个高频问题是："这个系统的数据表为什么这么设计？"准备思路：说出器材状态机模型、借出记录表的历史追溯价值、审批记录表的通用性设计。只要把这三点讲清楚，老师就不会觉得你是随手建的表。

第二个高频问题是："借出和归还的并发性怎么保证？"准备思路：讲乐观锁version字段机制，或者悲观锁select for update，再解释一下为什么选乐观锁（更高的并发性能、代码简洁、适合本系统场景）。

第三个高频问题是："系统安全性是怎么保障的？"准备思路：密码加密存储、登录Token校验、接口层拦截器做权限过滤、SQL层面使用预编译参数防注入。这四点中的任何一点展开讲，都能讲很长时间。

第四个高频问题是："你有没有遇到什么问题，怎么解决的？"这个问题其实是在考察你项目的真实性。建议准备一个真实踩坑案例。上面提到的并发重复借出就很适合，你可以完整讲述一遍排查流程：现象复现、定位到并发覆盖、加version乐观锁、再次并发测试通过。讲这个故事的时候，老师能明确感受到这是你亲手写过的系统。

第五个高频问题是："和市面上的实验室管理系统相比，这个系统的优势在哪？"不要回答"我的系统功能更全"，而是说"我的定位是轻量级、聚焦核心链路，从借用申请到审批、归还、报修形成闭环，并且加入了临期提醒和设备利用率统计，让管理成本降低"。记住，功能数量不是优势，业务闭环和细节体验才是。

结语：做好一个系统，比做完一个系统更重要

整个项目做下来，我最真实的感受是：毕业设计的第一步不是写代码，而是把业务边界和状态流转想清楚。器材管理这个题目看起来普通，但它天然具备了状态机、审批流、并发控制、定时任务、消息通知这些完整业务系统的必备基因。你把Spring Boot讲透，把器材状态流转讲明白，把持乐观锁写对，把消息提醒做出来，这就已经是一个完整、可用、有亮点的毕业设计了。

最后分享一个实用的小建议：开发的时候务必给每个接口写一条简单的Postman测试用例，尤其是借出审批、归还、报修这三个核心链路。别等到答辩前一天才拿浏览器狂点页面，一旦发现事务回滚问题，你会后悔没有早点做接口测试。系统的核心链路用接口测试验证通过的信心，和页面点出来的信心，完全不是一个量级。