JavaWeb实验室管理系统：权限、冲突检测与并发避坑实战

简介：这份资源是一套面向高校研究生实验室场景的JavaWeb管理系统源码，适合计算机专业学生、JavaWeb初学者及需要课程设计或毕业设计参考的开发者。系统按教师与学生两类角色划分功能：教师端可查看学生工作汇报与代码、回复答疑、创建会议并组织公开汇报与讨论、处理请假等请求；学生端可浏览同学公开汇报与代码、参与进行中的会议讨论、创建并管理个人项目、上传代码与PPT汇报工作、查看消息回复。资源共246个文件，以62个java源文件与62个class编译文件为核心，辅以54个jar依赖包、24个jsp页面、16个xml配置及properties、图片等静态资源，压缩包约30.63MB，结构完整可直接导入运行。目前已有589人学习下载，可帮助读者理解角色权限划分、会议与汇报流程设计及Hibernate持久层实现，适合作为JavaWeb综合实践与二次开发的基础工程。

1. 从一张排班表说起：这套 JavaWeb 实验室管理系统到底解决什么问题

实验室里最容易被低估的活儿，是“协调”。导师临时要开组会，三个课题组的会议室撞在一起；设备借出去两周没人登记，回来时少了一根数据线；新入学的研究生要申请工位，翻遍聊天记录也找不到上一任是谁在用。这些事单看都不大，堆在一起就是典型的实验室管理黑洞。这套 JavaWeb 研究生实验室管理系统，核心就是把会议预约、设备借用、工位分配、成员与成果这几条线收进一个后台，用角色权限把导师、学生、管理员分开，让每一次预约和借用都留下可查的记录。它适合正在做 JavaWeb 课程设计或毕业设计的学生，也适合想给小型实验室搭一套内部工具的开发同学，技术栈是标准的 Servlet/JSP 或 Spring Boot + MyBatis + MySQL 组合，改起来门槛不高。

2. 需求与角色建模：先把四类用户和五条业务线钉死

2.1 四类角色与权限边界

做这类系统，最容易翻车的地方不是写不出页面，而是权限没想清楚，最后导师能看到别人的设备借用记录，学生能改会议时间。我一般会先把角色收敛到四类：系统管理员、导师、研究生、访客（或待审核成员）。管理员管账号、管基础数据、管全局日志；导师管自己课题组的会议、成员审批和成果审核；研究生发起会议预约、设备借用、工位申请；访客只有浏览公开信息的权限。

权限边界建议落到“数据行级”而不是“页面级”。也就是说，不是简单地判断“是不是导师”，而是判断“这条会议记录是不是属于我带的课题组”。实现上通常给用户表加一个group_id，所有业务查询都带上这个条件，避免越权。

这张表不是摆设，它直接决定后面每个 Controller 里那句if怎么写。很多同学做到一半发现“导师怎么也能借设备”，就是一开始没把动作和数据范围分开。

2.2 五条核心业务线的状态流转

会议预约、设备借用、工位分配、成员审批、成果登记，这五条线本质都是“带状态的申请单”。以会议预约为例，状态从“待审核”到“已通过”再到“已完成”或“已取消”，中间还可能被“驳回”。设备借用多一个“已归还”和“逾期”状态。工位分配则是“申请中—已分配—已释放”。

状态机最好在数据库里用一个小整型字段表示，而不是用字符串，方便索引和判断。下面是一个会议表的核心字段设计，其他几张表可以照这个思路套：

CREATE TABLE meeting ( id BIGINT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(120) NOT NULL, room_id BIGINT NOT NULL, group_id BIGINT NOT NULL, -- 所属课题组，用于行级权限 proposer_id BIGINT NOT NULL, -- 发起人 start_time DATETIME NOT NULL, end_time DATETIME NOT NULL, status TINYINT DEFAULT 0, -- 0待审核 1已通过 2已驳回 3已完成 4已取消 remark VARCHAR(255), created_at DATETIME DEFAULT CURRENT_TIMESTAMP );

group_id这一列是整套权限体系的锚点，所有列表查询都靠它过滤。status用TINYINT而不是VARCHAR，是为了后面做“待我审批”这类查询时能直接走索引。时间字段用DATETIME而不是字符串，冲突检测才能用 SQL 的时间比较，而不是在 Java 里解析字符串，这一点是血泪经验。

3. 总体架构与技术选型：为什么不用微服务，怎么分层才不返工

3.1 单体分层架构的取舍

这个体量的系统，上微服务是给自己找麻烦。实验室管理系统的并发量撑死几十人同时在线，单体应用加一个 MySQL 完全够用。我一般会按经典三层来分：Controller 层负责接收请求和参数校验，Service 层放业务规则（比如会议冲突检测、设备库存扣减），DAO/Mapper 层只做数据访问。前端用 JSP 或 Thymeleaf 服务端渲染，配合少量 Ajax 做局部刷新，比前后端分离省掉一整套鉴权和跨域配置。

分层的关键是“业务规则只写在 Service 层”。很多课设翻车在 Controller 里直接写 SQL 判断，结果会议冲突逻辑在三个地方各写一遍，改一处漏两处。下面是一个 Service 层冲突检测的写法，逻辑集中，Controller 只负责调它：

public boolean hasConflict(Long roomId, LocalDateTime start, LocalDateTime end, Long excludeId) { // 同一会议室，时间区间重叠即冲突：已有.start < 新.end 且 已有.end > 新.start String sql = "SELECT COUNT(*) FROM meeting WHERE room_id = ? " + "AND status IN (0,1) AND id <> ? " + "AND start_time < ? AND end_time > ?"; int cnt = jdbcTemplate.queryForObject(sql, Integer.class, roomId, excludeId == null ? -1L : excludeId, end, start); return cnt > 0; }

这段 SQL 的重叠判断是区间相交的标准写法，status IN (0,1)表示只和“待审核、已通过”的会议比，已取消和已驳回的不占会议室。excludeId用于编辑场景，排除自己这条记录，否则改个标题都会提示冲突。参数顺序要和占位符一一对应，start和end在最后两个问号处是反着传的，这是区间相交公式决定的，写反了就会漏判。

3.2 技术栈与目录结构

技术栈建议锁定在 Spring Boot 2.x + MyBatis-Plus + MySQL 8 + Thymeleaf，JDK 用 8 或 11 都行，别追新版本，课设环境往往装的是老 JDK。目录按模块分包，而不是按技术分层平铺，这样后期加功能不用满项目找文件：

src/main/java/com/lab/ ├── common/ # 统一返回、异常、拦截器 ├── auth/ # 登录、权限注解、会话 ├── meeting/ # 会议预约 ├── device/ # 设备借用 ├── seat/ # 工位分配 ├── member/ # 成员与审批 └── report/ # 统计报表

每个模块内部再分 controller/service/mapper/entity，模块之间通过 Service 接口调用，不直接跨模块查对方的表。这条纪律听起来啰嗦，但等到你要把“设备借用”和“成员审批”串起来做提醒时，就知道它省了多少事。

4. 核心模块落地：会议预约、设备借用与工位分配怎么实现

4.1 会议预约的冲突检测与审批流

会议模块是整个系统的门面，也是最容易出 bug 的地方。除了上面说的区间重叠检测，还要处理“同一发起人同一时段不能开两个会”和“会议室容量与参会人数匹配”。参会人建议单独建一张meeting_attendee关联表，而不是在会议表里存逗号分隔的用户 ID，后者查询“我参加了哪些会”时只能全表扫描。

审批流用状态字段驱动即可，不需要引入工作流引擎。导师在“待我审批”列表里看到本组的待审核会议，点通过就把status改成 1，驳回改成 2 并写remark。这里有个细节：审批动作要校验操作人确实是该会议所属组的导师，否则学生伪造一个请求就能自己批自己。校验放在 Service 层，用group_id和当前登录用户比对。

public void approve(Long meetingId, Long operatorId, boolean pass, String remark) { Meeting m = meetingMapper.selectById(meetingId); User op = userMapper.selectById(operatorId); // 只有本组导师或管理员能审批 if (!"ADMIN".equals(op.getRole()) && !( "TUTOR".equals(op.getRole()) && op.getGroupId().equals(m.getGroupId()) )) { throw new BizException("无权审批该会议"); } m.setStatus(pass ? 1 : 2); m.setRemark(remark); meetingMapper.updateById(m); }

这段代码的重点不在更新，而在那两行权限判断。op.getGroupId().equals(m.getGroupId())用equals而不是==，因为Long在超出缓存范围后==比较的是引用，这是个经典坑，答辩时被问到能加分。

4.2 设备借用的库存扣减与逾期提醒

设备借用的核心是“不能超借”。设备表里放total和available两个字段，借出时available减一，归还时加一，扣减要用带条件的更新语句防止并发超借：

UPDATE device SET available = available - 1 WHERE id = #{deviceId} AND available > 0;

这条语句返回受影响行数，为 0 就说明库存不足，Service 层据此抛异常回滚。不要先SELECT再UPDATE，两个请求同时查到available=1就会都借出去，这是并发场景下最常见的翻车点。

逾期提醒不需要上定时任务框架，用一个每天凌晨执行的@Scheduled方法扫一遍status=借出 AND due_time < NOW()的记录，把状态改成“逾期”并给借用人插一条站内消息即可。简单、够用、好演示。

4.3 工位分配与成员审批的联动

工位分配和成员审批最好联动：新成员入组审批通过后，自动给他生成一条“待分配工位”的申请，管理员在工位地图上点选空位完成分配。工位表加一个user_id字段，为空表示空闲，分配就是把这个字段填上，释放就是置空。用一张表表达“工位—人”的当前关系，比单独建分配历史表简单，历史记录可以另建一张日志表补上。

成员审批则要注意“重复申请”和“跨组申请”。同一个人对同一课题组只能有一条待审核记录，用唯一索引(user_id, group_id, status)在数据库层兜底，比在代码里查一遍再插更可靠。

5. 避坑与排查：这类系统最容易翻车的五个地方

5.1 时间字段用字符串存，冲突检测全乱套

现象是会议冲突时有时无，改个时区就全错。原因是把start_time存成了VARCHAR，比较时按字典序走，“9:00”居然大于“10:00”。解决办法是数据库统一用DATETIME，Java 侧用LocalDateTime，前后端传参统一yyyy-MM-dd HH:mm:ss格式，在全局配置里注册一个转换器，别在每个 Controller 里手动解析。

5.2 权限只做页面隐藏，接口裸奔

现象是学生把按钮藏了，但直接调接口照样能删别人的会议。原因是权限判断只写在 JSP 的if里，后端没校验。解决办法是把权限校验下沉到 Service 层或拦截器，所有写操作必须校验“当前用户是否有权操作这条数据”，页面隐藏只是体验优化，不是安全边界。

5.3 设备库存先查后改，并发下超借

现象是两个人同时借最后一台设备，都成功了。原因是SELECT和UPDATE分开执行。解决办法是用UPDATE ... WHERE available > 0这种带条件的原子更新，判断受影响行数，或者给设备行加悲观锁。课设演示时可以用两个浏览器同时点，能复现的问题才讲得清。

5.4 关联查询 N+1，列表页越翻越慢

现象是会议列表每行都要单独查一次发起人姓名和会议室名，数据一多页面卡死。原因是循环里调 Mapper。解决办法是用 MyBatis 的关联查询或手写JOIN，一次把需要的字段带出来，或者用批量查询按 ID 集合一次捞回再在内存里拼。

5.5 删除用物理删除，历史记录对不上

现象是删了一个用户，他发起的会议全变成孤儿数据，报表统计直接报错。原因是DELETE真删了。解决办法是加deleted逻辑删除字段，查询统一带deleted = 0，MyBatis-Plus 有现成的逻辑删除配置，一行注解搞定。这条在答辩时被问到“数据怎么保证可追溯”，是标准答案。

6. 验收与答辩：怎么用一份可复现的演示脚本证明系统真的能用

验收不是把功能点念一遍，而是让评审看到“边界情况也处理了”。我一般会准备一份 8 分钟的演示脚本，按角色切换走一遍完整链路：管理员建课题组和账号 → 导师审批一名新成员入组 → 该成员申请工位并被分配 → 发起一次会议预约 → 另一个学生预约同一会议室同一时段被系统拦截 → 导师审批通过 → 借一台设备并演示库存减一 → 模拟逾期提醒。每一步都提前准备好数据，避免现场手忙脚乱。

答辩提问高频集中在三处：权限怎么防越权、并发怎么防超借、冲突检测的 SQL 为什么这么写。前两个上面已经给了答案，第三个建议把区间相交的四种情况画在纸上（新会议完全在左、完全在右、包含、被包含），说明start < end AND end > start一个条件就覆盖了全部重叠情形，比逐个if判断优雅得多。

验收标准可以列成一张自查表，交付前逐项打勾：

最后说个习惯。我每次交这类系统前，都会用一个全新的数据库从零跑一遍建表和初始化脚本，再按演示脚本完整走一遍，任何一步需要“手动改数据库”才能继续，就说明流程有断点，必须补代码而不是补说明。这套动作救过我两次答辩，也让我养成了“演示路径必须是代码能走通的路径”这个执念。希望帮到你。

本文还有配套的精品资源，点击获取