1. 这个项目解决的核心问题：VR/仿真设备为何需要一套租赁系统
虚拟实验室这个概念这几年被反复提及，但真正落地的场景往往比想象中复杂。某高校仿真实训中心引进了三十多台高配置设备，有头戴式显示终端、力反馈手套、三维扫描仪，还有一批数值计算工作站，总价值接近七位数。设备到位之后问题立刻冒出来了：课程集中时设备不够用，课余时间又大量闲置；学生借用靠一张纸质登记表，设备在哪、谁在用、什么时候还，全靠负责老师跑过去现场看。更头疼的是设备损坏后找不到责任人，维护成本一年下来高得离谱。
我参与开发这套Spring Boot设备租赁管理系统的出发点，就是把这些混乱的流程数字化。标题里的“虚拟实验室”指的不是字面上的模拟环境，而是面向虚拟仿真实验教学场景的实体设备池。系统要管的不只是“谁借了哪台设备”，还包括实验室空间预约、设备状态流转、超时违约处理、维护周期提醒，以及按课程或实验项目统计使用率。
这套系统适合谁参考？一类是正在做毕业设计或课程设计的计算机专业学生，Spring Boot加Java Web是最经典的技术组合，拿来作为选题骨架非常合适；另一类是高校或培训机构的实验室管理人员，想用低成本方案替换纸质登记流程。整个项目从需求分析到数据库设计，再到核心业务逻辑和部署，都有完整链路，不是网上那种只有增删改查的半成品。
2. 技术选型背后的取舍逻辑：为什么是Spring Boot而不是别的
选技术栈这件事，很多文章喜欢直接列一张表完事，但实际动手选型时是有明确理由的，尤其是考虑到这个系统的使用环境和维护者水平。
2.1 为什么Spring Boot是这届管理系统的“标配”
虚拟实验室设备租赁系统本质上是典型的CRUD加业务状态流转应用，并发量不高，用户角色清晰，业务流程固定。Spring Boot在这个场景下的优势有三点：第一，它内置了Tomcat，打包成JAR直接能跑，不需要额外配置外部容器，这对实验室老师来说友好得多；第二，Spring家族生态成熟，Spring MVC做接口分层、Spring Data JPA或MyBatis操作数据库、Spring Security做权限控制，全部无缝衔接；第三，社区资料极其丰富，踩坑时搜一下基本都能找到答案。
如果用更重的Spring Cloud体系，服务拆分、注册中心、配置中心这些概念对这个体量的项目是纯粹的负担；如果回到传统的SSH组合或者纯Servlet，开发效率又太低。我个人的判断是，这个项目的最佳区间就在Spring Boot单体应用这一档，既能体现Java Web的完整知识点，又不会因为过度设计导致项目失控。
2.2 前端层和数据库的实际搭配
前端方面，很多人纠结要不要用Vue。我的建议是：如果是毕业设计，用Thymeleaf服务端渲染就够了，理由很现实——答辩时老师关注的是业务逻辑和数据库设计，前端花太多时间反而挤压了核心模块的精力；如果目标是把系统真正投入使用，可以考虑Vue加Element UI前后端分离，但工作量会多出大概一倍。我这个项目采用的就是Thymeleaf加Bootstrap的组合，所有页面走服务端渲染，权限控制也放在后端拦截器里，对于内部管理系统来说这种模式反而是最稳妥的。
数据库选型没什么悬念，MySQL 8.0加InnoDB引擎，事务支持完善，InnoDB的行级锁在设备被多人同时预约时能有效避免数据错乱。连接池用HikariCP，Spring Boot 2.x以上版本默认集成，性能足够。
表结构设计中有一个容易被忽略的点：设备主表最好不要直接放所有属性，而是要拆出一张设备类型表。原因很简单，VR头显需要管理的字段（分辨率、刷新率、定位方式）和三维扫描仪（扫描精度、扫描范围）完全不同，硬塞进同一张表会导致大量字段闲置。拆表之后再通过关联关系扩展属性，灵活度会高很多。
3. 数据库设计的核心：设备、订单、排期三张表如何联动
设备租赁系统的数据模型是整个项目的重中之重。我见过不少失败的实现，问题大多出在订单表和排期表混在一起，导致一个设备被重复预约、归还时间算不清楚。这里把我的设计思路拆开讲。
3.1 核心表结构及关键字段设计
用户表（sys_user）需要区分三种角色：系统管理员、实验室老师、普通学生用户。我用role字段来区分，1表示管理员，2表示教师，3表示学生。注意学生用户关联到班级和学号，因为后续统计使用率和违约情况时，按班级维度的报表是刚需。
设备类别表（device_category）存放分类信息。设备信息表（device_info）是最核心的表，除了常规的设备名称、型号、位置，重点放在status字段上，我用tinyint表示：0为已下架、1为可预约、2为已借出、3为维修中、4为已预约未取走。为什么需要这么细的状态区分？因为租赁流程中预约和实际取走之间存在时间差，如果只有“可借”和“不可借”两个状态，那些预约了却没来拿设备的“爽约”情况根本没法追踪。
租赁订单表（rental_order）的设计要特别细心，几个重要字段如下：
| 字段名 | 类型 | 说明 |
|---|---|---|
| order_no | varchar(32) | 订单编号，采用日期+随机数生成 |
| user_id | int | 借用人ID |
| device_id | int | 设备ID |
| lab_id | int | 实验室ID |
| plan_start_time | datetime | 计划借用开始时间 |
| plan_end_time | datetime | 计划归还时间 |
| actual_start_time | datetime | 实际取走时间 |
| actual_return_time | datetime | 实际归还时间 |
| status | tinyint | 0待取走 1使用中 2已归还 3超时未还 4已取消 5违约结束 |
| deposit | decimal | 押金金额 |
| rent_fee | decimal | 实际租金 |
排期表（device_schedule）是我比较自豪的设计。这张表不直接参与订单查询，而是记录每台设备在某个时间段是否被占用。每条记录包含设备ID、开始时间、结束时间、关联订单号。任何新预约生成前，系统先查这张表，存在重叠时段就拒绝预约。这张表可能会比较大，但因为只查重叠区间，索引设计到位之后，毫秒级响应毫无压力。
3.2 为什么必须单独建一张排期表而不是查订单表
很多人会想当然地认为：查订单表里同一设备在时间区间内有没有未结束的订单不就完了吗？理论上可以，但实际上有几个坑：第一，订单表会越积越大，全表扫描判断重叠会越来越慢，而且重叠判断的逻辑很可能写出不带索引的SQL；第二，取消的订单、异常订单混在里面，查询条件一多就容易出错；第三，订单表语义是“一个完整的租赁合同”，而排期表语义是“设备在某时间粒度上的占用”，两者职责不同，后面做可视化日历排期时，排期表的查询性能优势非常明显。
排期表加上device_id和时间段的联合索引（device_id, start_time, end_time），重叠查询只需要一条SQL：
SELECT id FROM device_schedule WHERE device_id = #{deviceId} AND status = 1 AND start_time < #{planEndTime} AND end_time > #{planStartTime} LIMIT 1;这里的时间重叠判断逻辑是：两个区间[a,b]和[c,d]重叠的条件是 a<d 且 c<b。这是我踩坑踩出来的教训，新手经常写错成“完全包含”或“端点不相交”，导致明明冲突了还放行，设备被两个人同时预约。
4. 核心业务模块的实现细节：从预约到归还的完整链路
系统的业务链路看着长，拆开看其实就是几个状态机在流转。把所有状态梳理清楚，代码写起来就会很顺。
4.1 预约环节：如何防止“超卖”
设备预约是这个系统最容易被并发打穿的地方。两台设备同一天被同一个时间段预约，如果接口不做控制，两张订单都能成功创建，数据库层面就会出现矛盾。我在这一块用了双保险。
第一层是排期表唯一性约束。前面说的排期表插入时，先执行重叠查询，查不到冲突才允许插入。这里注意必须在同一个事务里完成“查询-插入”，并且用排期表的主键ID做行锁，或者直接用事务隔离级别保证不会有两个事务同时查到“无冲突”。
第二层是业务层的分布式锁兜底。用Redis的SETNX命令，以设备ID加时间段为key，设置过期时间五分钟，抢不到锁的直接返回“该时段已被预约”，避免大量请求同时打到数据库。
预约成功后订单状态置为0，表示待取走。订单里同时生成一个随机四位数取件码，学生到实验室后向值班老师出示取件码，老师在小程序或后台确认后，设备状态从“可预约”变为“已借出”，订单状态从“待取走”变为“使用中”。
4.2 归还环节：自动计算费用与违约处理
归还流程相对简单，老师扫码或手动选择订单点击归还。系统读取表里的实际归还时间，与计划归还时间比较，计算是否超时。如果按小时计费的模式，超时部分的单价要设置成正常价格的1.5倍，这种规则写在配置表里，不要硬编码。
如果超时超过24小时还没有归还动作，后台定时任务会扫描所有状态为“使用中”或“已预约”的订单，把超时未还的订单状态改为3，同时将设备状态强制改为“可预约”——因为设备实际在库里可能早就被学生悄悄放回来了，只是没人点归还按钮，通过定时任务把状态自动修正，能省去管理员大量手工干预。
归还时还要检查设备外观。我在设备表里加了一个health_status字段，正常情况下是1，如果归还时发现外观损坏，teacher端可以手动标记为2，设备状态同步变为“维修中”，同时生成一条维修记录，关联到对应订单。这个设计让“谁弄坏设备”这个问题有了数据支撑，不再靠口头扯皮。
4.3 实验室空间的独立预约逻辑
虚拟实验室除了设备，还有空间资源。某些实验必须在特定的沉浸式房间进行，房间配了投影矩阵和专业音频设备。实验室预约和设备租赁是两个独立的业务模块，共用一套排期思想，但数据是分开的。
实验室表（lab_info）中的status字段表示开放状态，预约生成的是一条lab_reservation记录。因为实验室本身不产生租金，主要是按时间段控制人数和场次，所以费用计算这块比较轻，重点在于同一时间段只能有一个班级使用。我设置了预约人数上限，预约时传入预期人数，超出当前容量直接前端报错，从源头避免拥挤问题。
5. 权限控制与消息通知：管理系统最容易忽略的两块拼图
很多课程设计项目做到能跑就跑，但一个真正能交付给实验室使用的系统，权限和通知绝不能省，否则管理员会被琐事淹没。
5.1 Spring Security还是自定义拦截器
这个项目里我用的是Spring MVC拦截器加注解的方式做权限控制，没有引入Spring Security。原因很务实：角色只有三种，接口路径规则清晰，用拦截器已经足够；引入Spring Security后配置复杂度上了一个台阶，对于毕业设计和中小型系统来说有点杀鸡用牛刀。
拦截器统一校验用户会话，然后根据请求路径前缀做角色匹配：
@Component public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); User user = (User) session.getAttribute("loginUser"); if (user == null) { response.sendRedirect("/login"); return false; } String uri = request.getRequestURI(); if (uri.startsWith("/admin/") && !RoleEnum.ADMIN.getCode().equals(user.getRole())) { response.sendError(403); return false; } if (uri.startsWith("/teacher/") && RoleEnum.STUDENT.getCode().equals(user.getRole())) { response.sendError(403); return false; } return true; } }这样写的好处是一眼能看懂，答辩时也容易讲清楚。如果是正式商用，建议还是切到Spring Security，它能处理更细粒度的方法级权限，但那是另一个话题了。
5.2 基于事件驱动的通知模块
设备预约成功、归还确认、超时提醒这些事件，需要一个统一的渠道触达用户。我实现了一个简要的通知中心：领域事件发生后，调用通知服务，通知服务根据事件类型决定推送方式——站内信是默认的，对于紧急情况（比如超时未还），额外发送邮件。短信网关因为要接入第三方服务，涉及签名审核和资费，我留了接口，后续替换即可。
关键代码如下，事件类型枚举定义在常量类中，通知服务接收事件后走不同的模板：
public void sendRentalEvent(Integer orderId, Integer eventType, Integer userId) { RentalOrder order = orderMapper.selectById(orderId); Integer targetUserId = userId != null ? userId : order.getUserId(); String message = NotificationTemplate.build(eventType, order); notificationMapper.insert(new Notification(targetUserId, message, 0)); if (eventType == NotificationType.OVERTIME.getCode()) { mailService.sendOvertimeMail(userService.getEmail(targetUserId), order.getOrderNo(), order.getPlanEndTime()); } }通知模块的价值在后期统计时体现得特别充分。因为每个站内信都关联了订单ID和事件类型，数据库里天然留下了一条审计日志。管理员月底处理违约纠纷时，直接按学生ID拉通知列表，就能还原整个借用过程中发生了哪些事件，谁超时、谁取消、谁未取件，一目了然。
6. 部署上线与性能优化：从开发机到实验室服务器的实战经验
项目写完之后，真正的考验才开始。我们在实验室的一台旧服务器上部署了这套系统，期间踩了不少坑，有些问题比较典型。
6.1 服务器环境搭建与部署步骤
服务器是四核八线程，16G内存，Ubuntu系统。MySQL和Redis都是通过Docker启动的，应用服务直接用Maven打成JAR包运行。部署步骤整理如下，照着做基本不会出错：
- 服务端安装JDK 17，配置JAVA_HOME环境变量
- 通过Docker运行MySQL 8.0，设置字符集为utf8mb4，挂载数据目录和配置文件
- 通过Docker运行Redis 7，用于Session共享和分布式锁
- 在MySQL中创建数据库和账号，并执行项目里的schema.sql和data.sql初始化脚本
- 编译打包：mvn clean package -Dmaven.test.skip=true
- 启动服务：nohup java -jar system.jar --spring.profiles.active=prod > logs/run.log 2>&1 &
生产环境的application-prod.yml里需要重点关注数据库连接池和Redis连接池的配置：
spring: datasource: url: jdbc:mysql://localhost:3306/lab_rental?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai hikari: maximum-pool-size: 10 minimum-idle: 2 connection-timeout: 30000 redis: host: localhost port: 6379 timeout: 3000ms lettuce: pool: max-active: 8 max-idle: 8第一版上线时踩过数据库连接的坑：默认连接池没做限制，高峰时连接数打满，MySQL直接拒绝连接。调低最大连接数并开启keepalive之后问题解决。
6.2 性能调优：哪些优化真的有效
设备列表页和订单列表页是访问最频繁的页面，一开始直连数据库，数据量几百条时还好，等订单积累到几千条后查询明显变慢。我做了三个优化，按收益排序：
第一是索引优化。这是性价比最高的手段，订单表里state和user_id组合索引、排期表里device_id和时间段组合索引、通知表里user_id和status索引，加上之后核心查询基本都在毫秒级。
第二是查询优化。列表接口分批加载数据，前端采用分页而不是一次性拉全量数据。这里有个容易忽略的点，分页查询最好走数据库端的分页（PageHelper或MyBatis的RowBounds），不要先把全量数据拉回来再在内存里截取。
第三是热点数据缓存。设备的当前状态被高频读取，存到Redis里，key设计成device:status:{deviceId}，状态变更时双写数据库和缓存。缓存和数据库的一致性在这个场景下要求不高，即使极端情况下缓存短暂过期，重新回源也是完全可接受的表现。
压测数据简单记录一下：用JMeter模拟200个并发用户同时提交预约请求，TPS稳定在300左右，事务成功率接近百分百，同一设备的冲突预约成功率控制在预期范围内，没有出现超卖。
6.3 定时任务的两个典型实践
系统里有两个定时任务是保证业务闭环必不可少的，没有它们，很多异常场景就断链了。
第一个是前面提到的超时未还扫描。Cron表达式：0 0 2 * * ?，每天凌晨两点跑一次。扫描条件是：订单状态为1（使用中）且计划归还时间早于当前时间超过24小时。扫描结果统一置为超时未还，并按规则产生违约记录。
第二个是清理过期未取走的预约订单。学生预约后不取走、也不取消，这种情况如果一直挂着，会阻塞其他同学预约同一设备。定时规则是每半小时扫描一次，把状态为0且创建时间超过2小时的订单自动取消，并释放对应时间段的排期记录。
这两个定时任务的实现都是基于Spring的@Scheduled注解，注意在启动类上加@EnableScheduling。定时任务执行时建议加分布式锁，避免多实例部署时重复执行。我们目前是单机部署，暂时没这个压力，但代码层面已经预留了实现位置。
7. 复盘：哪些设计走了弯路，哪些坚持是对的
整个项目从设计到上线大概用了六周，中间有几次比较大的返工，也有几处坚持住了之后验证效果不错的设计。
7.1 走过的弯路
第一处弯路是报表模块做得太重。一开始规划了近十种统计报表，结果做出来很多根本没人看，真正高频使用的只有设备使用率排行、学生借用排行、违约统计这三个。其他报表后来全部砍掉，只保留原始数据导出功能。现在回想，报表做之前真应该先问问实验室管理员每天会打开看的到底是哪几个页面。
第二处弯路是导入导出功能过度依赖第三方库。最初想用一个大而全的Excel处理库，结果引入之后不仅体积膨胀，导出大量数据时内存还爆了。后来改成轻量级方案，导出时用流式写入，效果稳定得多。
7.2 坚持下来且验证有效的设计
排期表的独立设计是我最坚持的一个决策。当时有同事觉得多一张表增加了冗余，后来联调测试发现，设备日历视图、碰撞检测、定时任务清理，全部都通过排期表完成，没有给订单表增加额外负担。这次经验也让我更坚定了一个想法：时间相关的业务，一定要有一张独立的排期结构，别贪图一时省事把时间塞进业务主表里。
另外事件驱动的通知设计越用越顺手。后面新增了“设备维修完成提醒”功能，只需要新增一个事件类型和对应模板，通知模块完全不用动，扩展成本极低。
7.3 对后续迭代的建议
如果这个项目要继续演进，我建议从三个方向入手。性能层面接入消息队列处理预约请求削峰，但目前瓶颈不明显，优先级可以放低；功能层面增加设备的实时使用情况大屏展示，配合排期表做可视化日历，这对实验室参观展示和日常管理都有价值；运营层面把设备借用数据按课程维度分析，反馈到实验教学排课，这是真正能让系统产生教学价值的功能。
写这套系统下来，最大的感触是：技术选型真的不是越新越复杂越好，把核心业务流程理清楚、把状态变化管明白，比炫技重要得多。也希望这个项目的经验能给正在做类似选题的人提供一些参考，少走几步弯路。
