实验室预约这件事在高校里绝对算高频痛点。我做过一版SpringBoot开放式实验室预约管理系统之后最大的感受是这个题目放到计算机毕业设计里属于实用性很强、工作量适中、答辩又容易讲清楚的项目类型。整套系统以SpringBoot为核心配合MyBatis-Plus和MySQL把学生在线预约、教师审批、管理员配置实验室和开放时间、设备台账管理、使用率统计这些场景全部串起来就是一套完整的高校实验资源在线预约平台。这篇我直接把当时做智慧实验室共享预约系统时踩过的坑、设计上的权衡以及能直接落地的核心代码写出来给正在做类似毕设或者课程设计的同学一个参考。1. 项目定位与需求拆解1.1 实验室预约为什么必须做成系统先想清楚一个前提实验室预约不是“在线填表”这么简单。传统方式无非是微信群接龙、纸质登记本、或者实验室门口贴张表自己签名运行一段时间问题会非常集中——时间冲突靠人工核对管理人员一天要翻好几次记录设备被谁用坏了无从追溯开放时间一变靠口头通知根本覆盖不到所有人。做成系统之后核心解决的是三件事第一实验室的时间资源透明化谁在哪个时间段用了哪个实验室一条记录就能查清楚第二冲突检测由程序代替人肉核对提交预约的同时就能判断这个时间段是否可用第三审批留痕教师批没批、为什么拒全部可追溯。第三点尤其重要实验室的开放时间通常由院系制定教师审批时需要看到申请目的和实验类型否则批不批的判断没有依据。从毕设角度讲这个选题还有个好处业务逻辑足够立体但又不至于像电商秒杀那样复杂。它天然分角色、分状态、分资源维度非常适合展示一个完整项目的架构成型过程。1.2 三类角色与权限边界系统里一定要有学生、教师、管理员这三个角色缺一个这个题目的“管理系统”属性就不完整。学生角色做的事情是查看实验室列表、查看实验室开放时间、查看可预约的设备、发起预约、取消未审批的预约、查看自己的预约历史和审批结果。注意学生不需要“编辑实验室”的权限也不应该能看到其他所有人的预约详情。教师角色做的事情是审批分配给自己的预约申请、查看自己管辖实验室的使用情况、维护实验教学计划。这里的管辖关系值得细化——是绑定到具体某几个实验室而不是全院所有实验室所以设计时要加一个“教师-实验室”的关联关系。管理员角色做的事情是用户管理含封禁/启用、实验室信息与开放时间配置、设备台账管理、全系统的预约统计。管理员的权力边界可以比教师更顶层但具体实验室的使用审批权仍然应该下放给教师。这些边界意味着后端接口必须做角色校验不能只靠前端隐藏按钮。我第一次做的时候前端把管理入口藏掉了结果有人直接用URL调接口照样能访问管理接口后来才补上服务端拦截这个教训后面细说。1.3 核心业务流程与状态流转把业务链路画出来系统的骨架就有了。一次完整的预约流程是这样的学生登录系统 → 浏览实验列表与开放时间 → 选择某个实验室与某个时间段 → 填写实验类型、实验人数、用途说明 → 提交申请 → 状态变为“待审批” → 教师登录后看到待办列表 → 审批通过或拒绝 → 学生收到结果通知 → 预约日期到达后按预约使用实验室 → 实验结束后管理员或教师标记“已完成”。与这个流程对应预约记录必须有一个状态字段我建议至少定义这几个状态值待审批、已通过、已拒绝、已取消、已完成、已失效。被拒绝和取消是不同的语义被拒绝是教师主动驳回已取消是学生在尚未使用前主动放弃已完成意味着这次预约真实发生了可以在统计中计入使用率已失效则是预约日期已过但未完成、也未取消的状态这个状态适合后续跑定时任务批量处理。状态机的清晰程度直接决定后面代码好不好写。我见过很多同学一上来就在Controller里直接改状态结果后面的统计和权限判断全部乱掉。核心原则是状态变更必须走Service层的统一方法不能在各处随意set。2. 技术栈选型与数据库设计2.1 技术栈为什么这么选毕设项目的技术选型有个隐藏原则不要为了炫技选冷门框架评委关注的是你能否把常见技术用出规范度。SpringBoot MyBatis-Plus MySQL这套组合几乎是目前高校毕设里最稳的方案。SpringBoot的优势不用多说自动配置、内嵌容器、起步依赖让项目能在短时间内跑起来。MyBatis-Plus则解决了单表CRUD的重复劳动BaseMapper提供了基本的增删改查配合代码生成器能快速创建实体和Mapper。很多人纠结用JPA还是MyBatis我的建议是如果你的核心操作是和数据库表字段打交道并且希望SQL可控MyBatis-Plus更顺手。前端方面Vue Element UI新一点的可以用Element Plus足够覆盖管理后台类页面表格、表单、日期选择器、弹窗这些都是现成的。如果不想把精力耗在前端可以直接用轻量级的模板化后台但要保证接口联调正常。关于Redis和JWTJWT建议使用因为前后端分离场景下不需要服务端session用户角色信息可以直接放在token里。Redis可选用在验证码缓存上如果不想引入额外服务验证码可以后端生成后返回前端演示够了。我在项目里用Redis做了登录token的存储和校验实践中挺方便。2.2 核心数据表结构与关键字段数据库设计在整个项目中占一半的分量。表的数量不用太多至少这几张能撑起整个业务用户表userid、username、passwordBCrypt加密存储、real_name、role、phone、email、status、create_time。status字段用于账号启用和禁用。实验室表labid、lab_no、lab_name、description、location、capacity、status、open_start_time、open_end_time。capacity决定预约人数上限status表示实验室是否对外开放预约。实验室开放时间表lab_time_slot这个可选。如果要求按星期自定义开放时段建议拆一张子表字段包括id、lab_id、weekday、start_time、end_time星期几分别配置灵活性会高出很多。设备表deviceid、lab_id、device_name、device_no、status、maintenance_time。设备归属于某个实验室预约实验室内时间段时如果需要连带预约设备再单独一张预约设备关联表。预约记录表lab_reservation字段是全部的观察核心我用表格列清楚。字段名类型说明idbigint主键user_idbigint预约学生IDlab_idbigint实验室IDreserve_datedate预约日期start_timetime开始时间end_timetime结束时间purposevarchar实验用途student_countint实验人数statusvarchar待审批/通过/拒绝等auditor_idbigint审批人IDaudit_commentvarchar审批意见audit_timedatetime审批时间create_timedatetime提交时间update_timedatetime更新时间审批记录表audit_log做一份操作流水谁在什么时间做了哪些审批动作答辩时把审计日志拿出来展示是明显的加分项。要注意reserve_date和start_time、end_time分开存储而不是合并成两个datetime。分开存更容易做按日查询时间维度也清晰。2.3 SpringBoot项目基础搭建项目创建我没有用脚手架网站直接在IDE里用Spring Initializr生成。关键依赖如下spring-boot-starter-webmybatis-plus-boot-startermysql-connector-java注意版本和MySQL版本匹配jjwtJava JWT库spring-boot-starter-validation参数校验lombok减少实体类样板代码spring-boot-starter-data-redis可选application.yml里要注意这么几点数据源的时区参数serverTimezoneAsia/Shanghai否则日期时间比北京时间差8小时开启MyBatis-Plus日志开发阶段能看到完整SQL文件上传、Jackson序列化配置也需要提前放置否则前端收到的Long类型ID会丢精度。另外MyBatis-Plus一定要加分页插件不加的话Page对象只会返回全量后内存分页数据量不大时看不出来数据一多会出问题。3. 核心功能设计与实现要点3.1 登录鉴权与角色控制登录流程本身不复杂关键在于用户身份在后续请求中的传递。JWT的结构是Header.Payload.Signature我习惯只往Payload里放userId、username、role三个字段不放敏感信息。Token有效期建议设长一些比如24小时避免演示答辩时突然过期尴尬。后端拦截器里处理逻辑很简单从请求头Authorization取出token解析成功就把当前用户信息塞进ThreadLocal方便后续Service层直接拿。同时校验用户是否仍在启用状态如果账号被封即使token没过期也要拒绝访问。角色校验我用的是自定义注解加拦截器在需要教师权限的接口上标注RequireRole(TEACHER)拦截器里统一检查比在每个Controller里手动判断简洁得多。首次提交代码时我把角色校验漏在了Controller外面后来测试发现校验逻辑不统一重构了一轮才理清。3.2 预约时间槽与冲突检测整个系统最容易出bug的地方就在这里。要判断一个时间段是否冲突核心是分析两个开区间[left1, right1)和[left2, right2)是否有重叠区域。有重叠的充要条件是left1 right2 且 left2 right1。放到SQL里翻译成select count(*) from lab_reservation where lab_id #{labId} and reserve_date #{date} and status in (PENDING,APPROVED) and start_time #{endTime} and end_time #{startTime}注意这里把“待审批”状态的记录也纳入冲突检测。有人会疑惑待审批还没生效凭什么占住时间但实际运行中你会发现如果不让待审批记录占坑学生会不断提交同一时间段的预约等教师逐个审批时已经乱套了。所以只要预约状态没有被取消就应该参与冲突计算。除了跨预约冲突还要校验预约时间段是否落在实验室开放时间内以及实验人数是否超过实验室容量。这两个校验看起来简单但参数边界很容易错——我遇到过学生预约的结束时间正好等于开放时间上限结果判断成超时的边界问题。3.3 审批流程与状态机设计审批场景里教师看到的待办列表本质是查预约记录表中status为待审批、且该实验室属于当前教师管辖的记录。审批动作需要开启事务把状态改为已通过或已拒绝同时写入audit_log表。为了让系统更完整可以做一个定时任务预约日期已过但状态仍然是待审批的自动置为已失效状态为已通过但过了日期没有标记完成的也可以自动置为已完成。这里需要引入Spring自带的Scheduled注解默认是单线程串行执行定时任务量不大足够用。这个定时自动状态流转是很多同学忽略的部分但恰恰是它能体现“系统”而不仅是“网页”的价值。论文里还能顺带写一笔“Scheduled定时任务的使用”内容更丰富。4. 实操过程与关键代码实现4.1 预约Service核心代码预约接口是我写的最多版本的一个方法最终稳定版是这个思路。先接收DTO然后做三层校验参数合法性、实验室状态、冲突检测最后插入记录。Transactional(rollbackFor Exception.class) public Result createReservation(ReservationDTO dto, LoginUser user) { // 1. 基础校验 if (dto.getStartTime().isAfter(dto.getEndTime())) { return Result.fail(预约开始时间不能晚于结束时间); } if (dto.getStudentCount() null || dto.getStudentCount() labMapper.selectById(dto.getLabId()).getCapacity()) { return Result.fail(实验人数超过实验室容量); } // 2. 校验实验室是否开放 Lab lab labMapper.selectById(dto.getLabId()); if (!OPEN.equals(lab.getStatus())) { return Result.fail(该实验室当前不可预约); } // 3. 冲突检测 Integer conflict reservationMapper.countConflict( dto.getLabId(), dto.getReserveDate(), dto.getStartTime(), dto.getEndTime() ); if (conflict ! null conflict 0) { return Result.fail(该时间段已有预约请重新选择); } // 4. 组装插入 Reservation reservation new Reservation(); reservation.setUserId(user.getId()); reservation.setLabId(dto.getLabId()); reservation.setReserveDate(dto.getReserveDate()); reservation.setStartTime(dto.getStartTime()); reservation.setEndTime(dto.getEndTime()); reservation.setPurpose(dto.getPurpose()); reservation.setStudentCount(dto.getStudentCount()); reservation.setStatus(PENDING); reservationMapper.insert(reservation); return Result.success(reservation); }有一个细节用了Transactional后冲突检测和插入是同一个事务但默认隔离级别下并发请求仍然可能同时通过冲突检测。稳妥的办法是在预约表加一条唯一约束或者对同一个实验室的同一日期做SELECT ... FOR UPDATE行锁。毕设场景通常不会出现并发测试但要能说出这个解决思路面试和答辩都加分。4.2 管理端统计与可视化统计功能是加分项。至少做两部分实验室使用率和一个时间段的预约趋势。使用率的计算思路是某实验室在指定月份内预约成功的时段数占可预约时段总数的比例。可预约时段总数可以从开放时间表推算比如工作日每天开放8小时、按1小时为一个预约槽则一天最多8个时段。用ECharts展示时我推荐两个图表折线图展示近14天全院预约数量变化饼图展示各实验室预约次数占比。对应的SQL都很简单select reserve_date, count(*) as cnt from lab_reservation where status in (COMPLETED,APPROVED) and reserve_date between #{startDate} and #{endDate} group by reserve_date order by reserve_date统计页面不需要实时性查询时直接压到MySQL也能承受。如果数据量大了再考虑把统计结果缓存到Redis。4.3 前端页面与接口联调前端和后端联调时最容易出问题的是跨域和Token传递。后端使用CorsFilter统一处理跨域白名单allowedOrigins按需设置开发阶段放行所有来源上线前收紧。自定义请求头Authorization也必须在allowedHeaders里声明这里漏掉的话每次请求都会因为跨域而失败。axios请求拦截器统一加上tokenaxios.interceptors.request.use(config { const token localStorage.getItem(token); if (token) { config.headers.Authorization token; } return config; });后端返回统一使用Result包装体包含code、message、data三个字段前端按code判断业务成功或失败。前后端约定好响应结构调试效率会提升很多不要一会儿直接返回对象一会儿返回Map。5. 常见问题与排查经验5.1 时间比较的类型问题Java端LocalTime和MySQL的time类型映射没问题但要避免把时间用字符串传到SQL里比较。MyBatis-Plus对LocalTime支持良好Mapper层直接传LocalTime即可。另外数据库字段建议用DATETIME存完整时间TIME存时段不要都用VARCHAR存。5.2 并发预约导致重复占位即便没有真实并发压力代码里也要有兜底。我的方案是给lab_reservation表加了一个uname_date_lab的唯一索引同一用户同一天不能对同一实验室重复提交。同时冲突检测SQL中的状态过滤要准确已拒绝和已取消的不参与占用。否则教师拒绝之后学生重新提交会被自己早先的失败预约挡住。5.3 拦截器放行路径的坑登录、注册、验证码这几个路径一定要在拦截器里放行。最典型的问题登录接口写的是/user/login拦截器里面放行的是/login结果前端调login接口时token还没生成被拦截器拦住反复报401。排查方法也很简单把拦截器预检路径打成日志一层一层看。5.4 MyBatis-Plus字段填充失效如果用了自动填充create_time和update_time记得写MetaObjectHandler的实现类并注册成Bean。没有这个步骤insert时的时间字段会一直是null数据库非空约束直接报错。这类问题报错时一眼不一定能想到建议先检查控制台有没有MP的警告日志。5.5 前端日期格式与后端解析不一致Element UI的DateTimePicker默认格式是yyyy-MM-dd HH:mm:ss后端如果用LocalDateTime接收需要在字段上加JsonFormat或者全局配置Jackson格式否则解析会报异常。我当时因为前端传了ISO带T的字符串后端解析直接500改全局Jackson配置后解决。6. 从毕设到真实项目的差距6.1 答辩评分关注点与加分项评审老师阅项目无数最关注的是三块表结构是否合理、权限是否有边界、异常是否可控。数据库里所有时间字段都用datetime、state字段没有枚举约束、用户表直接明文存密码这些在评委眼中都是致命扣分点。密码一定要用BCrypt加密Spring Security里的BCryptPasswordEncoder或者jBCrypt库都可以。异常处理建议写一个全局异常处理器用RestControllerAdvice统一捕获业务异常和参数校验异常不要写一堆try-catch把Controller搞得很臃肿。答辩放代码时代码整洁度和异常处理的完整度比功能数量更能打动评委。6.2 后续扩展方向系统做完基础功能后可以预留几个扩展方向这些可以在论文总结里提但要有分寸。方向一是增加微信小程序端学生在小程序里预约审批照旧在PC端这种场景在实际高校中很常见。方向二是扫码签到预约通过后生成二维码实验楼门口扫码记录实际到馆情况配合定时任务统计违约记录。方向三是设备借用联动预约实验室时同时勾选要用哪些设备设备修改为占用状态避免同一批设备在一个时间段内被两个实验室预约走。这些扩展不用真做太多挑一两个写出设计思路即可但核心系统本身要保证运行稳定。我个人做完这套系统后最大的体会是实验室预约系统的难点不在CRUD而在边界条件的处理。时间段重叠判断、状态流转、权限穿透、并发兜底任何一个地方考虑不周都会在使用中暴露出明显问题。建议把冲突检测和状态流转写成单元测试覆盖住答辩现场拿测试结果出来比嘴说“系统很稳定”有说服力得多。还有一个提醒不要临近答辩还在加花哨功能先把核心流程跑稳那些次要功能砍掉几个都比全是半成品强。