基于Java的学生宿舍管理系统：从数据模型到事务控制的完整实现

简介：这是一套面向高校计算机专业学生与Java初学者、可用于毕业设计或课程实训的学生宿舍管理系统完整项目源码。系统前端基于Bootstrap搭建管理界面，后端采用SpringBoot框架与MySQL数据库，按管理员、宿管、学生三类角色划分权限：管理员可对学生、楼宇、宿舍、入住、宿管及管理员信息进行增删改查与Excel导入导出，宿管负责学生、宿舍与入住管理，学生端则提供学生与宿舍信息查询，功能闭环完整，便于二次开发与答辩演示。资源包共661个文件，以js、css、less、scss等前端资源为主，辅以35个java源文件、40个class编译文件及xml、yml配置、sql脚本与html页面，压缩包约72.37MB，并附MySQL5与MySQL8两套可运行项目版本。目前已有469人学习下载，适合需要完整管理系统方案、权限设计与导入导出实现思路的读者参考借鉴。

1. 从一次宿舍分配翻车说起：这套 Java 管理系统到底解决什么问题

每年新生入学前，宿管科最头疼的不是床位不够，而是信息对不上。我见过一个真实场景：某高校用 Excel 管宿舍，三张表分别记入住、调宿、退宿，结果一个学生调了两次宿舍，三张表各写各的，最后查他到底住哪，得打三个电话确认。这不是段子，是很多学校宿舍管理的日常。基于 Java 的学生宿舍管理系统，要解决的核心就是这件事——把学生、楼栋、房间、床位、入住记录这几类数据放进一个统一的数据模型里，让分配、调宿、退宿、查询都走同一套逻辑，而不是靠人脑对账。这套方案适合正在做毕业设计或课程设计的学生，也适合需要给中小规模宿舍场景搭一套可交付管理后台的开发者。关键词里的项目源码、java源码、毕业设计、管理系统，落到实际就是一套能跑起来、能演示、能答辩的完整工程。

2. 需求拆解与技术选型：为什么是 Java + 关系型数据库这套组合

2.1 先把角色和用例理清楚

宿舍管理系统的需求看着杂，其实角色就三类：学生、宿管员、系统管理员。学生关心的是「我住哪、能不能申请调宿、水电费交了没」；宿管员关心的是「这栋楼哪些床位空着、谁该退宿了、报修处理到哪一步」；管理员关心的是「楼栋房间数据维护、账号权限、统计报表」。把这三类角色的用例画出来，功能模块自然就分出来了：学生信息管理、楼栋房间管理、床位分配管理、调宿退宿管理、报修管理、费用管理、统计查询。这里有个血泪经验——很多毕设翻车不是因为功能少，而是因为一开始没把「床位状态」这件事想清楚。床位不是简单的「有人/没人」，它至少有四种状态：空闲、已分配、待退宿、维修中。状态没定义好，后面调宿逻辑一定乱。

2.2 技术选型：够用、好演示、能讲清楚

这套系统我一般推荐的技术栈是 Spring Boot + MyBatis + MySQL + Thymeleaf 或 Vue 前端，JDK 用 8 或 17 都行。为什么不是更花哨的微服务？因为毕设和课设的验收场景是「一个人能讲明白、一台机器能跑起来」，微服务拆分只会让答辩时被追问「你这个服务注册中心干嘛用的」而答不上来。Spring Boot 的好处是内嵌 Tomcat，打成 jar 包双击就能跑，演示成本极低。MyBatis 比 JPA 更适合这类系统，因为宿舍管理的查询大量是「按楼栋查空床位」「按学号查入住记录」这种条件组合查询，手写 SQL 反而更直观，答辩时也能讲清楚每条 SQL 在干什么。数据库选 MySQL 是因为关系模型天然适合「学生-床位-房间-楼栋」这种层级关系，外键约束能帮你兜住一部分脏数据。

提示：如果导师明确要求前后端分离，前端用 Vue 加 Element UI，后端只出 REST 接口，这样答辩时能多讲一块「接口设计」，但工作量会翻倍，自己掂量。

2.3 数据库设计：四张核心表撑起整个系统

数据模型是这套系统的地基。核心表我一般设计成四张：学生表、楼栋房间表、床位表、入住记录表。注意床位和入住记录要分开——床位是物理资源，入住记录是历史流水，一个床位可以有多条入住记录（换人住过），但同一时刻只能有一条有效记录。这个设计点答辩时很加分，因为它体现了你对「状态」和「历史」的区分。

-- 床位表：物理资源，状态字段是关键 CREATE TABLE bed ( id BIGINT PRIMARY KEY AUTO_INCREMENT, room_id BIGINT NOT NULL COMMENT '所属房间', bed_no VARCHAR(10) NOT NULL COMMENT '床位编号，如 A/B/C/D', status TINYINT DEFAULT 0 COMMENT '0空闲 1已分配 2待退宿 3维修中', UNIQUE KEY uk_room_bed (room_id, bed_no) ); -- 入住记录表：历史流水，退宿时只改状态不删记录 CREATE TABLE checkin_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, student_id BIGINT NOT NULL, bed_id BIGINT NOT NULL, checkin_time DATETIME NOT NULL, checkout_time DATETIME DEFAULT NULL, status TINYINT DEFAULT 1 COMMENT '1在住 0已退宿', INDEX idx_student (student_id), INDEX idx_bed (bed_id) );

上面这段建表语句里，bed表的status字段是整个分配逻辑的开关，所有「查空床位」的查询都是WHERE status = 0。checkin_record表用checkout_time是否为空来判断是否在住，退宿时只更新这个字段和状态，绝不物理删除——这是很多同学容易犯的错，删了记录就查不到历史，统计报表直接废掉。uk_room_bed唯一索引防止同一个房间出现两个相同床位号，这是数据完整性的最后一道防线。

3. 总体架构与模块划分：三层结构怎么落到代码目录

3.1 分层结构：Controller 薄、Service 厚、Mapper 只做数据

后端按经典三层走：Controller 层只做参数接收和结果封装，不写业务判断；Service 层承载所有业务规则，比如「分配床位前要检查床位是否空闲、学生是否已有在住记录」；Mapper 层只负责 SQL。这个分工的意义在于，答辩时导师问「调宿逻辑在哪」，你能一句话指到 Service 的某个方法，而不是在 Controller 里翻半天。目录结构大致是这样：

src/main/java/com/dorm/ ├── controller/ # 接口层，按模块分：StudentController、BedController... ├── service/ # 业务层，接口 + impl 实现 ├── mapper/ # MyBatis 接口 ├── entity/ # 实体类，与表一一对应 ├── dto/ # 传输对象，如分配请求、统计结果 └── config/ # 权限拦截器、全局异常处理

3.2 床位分配的核心逻辑：一次事务里做完三件事

分配床位是整套系统最核心也最容易出 bug 的地方。合格的做法是把「校验床位空闲 → 写入住记录 → 更新床位状态」放在同一个事务里，任何一步失败全部回滚。下面这段 Service 代码是这套方案的关键实现：

@Service public class BedAllocateService { @Autowired private BedMapper bedMapper; @Autowired private CheckinRecordMapper recordMapper; // 分配床位：校验 + 写记录 + 改状态，同一事务 @Transactional(rollbackFor = Exception.class) public void allocate(Long studentId, Long bedId) { // 1. 查床位，加行锁防止并发重复分配 Bed bed = bedMapper.selectForUpdate(bedId); if (bed == null || bed.getStatus() != 0) { throw new BizException("该床位不可分配"); } // 2. 检查学生是否已有在住记录 int living = recordMapper.countLivingByStudent(studentId); if (living > 0) { throw new BizException("该学生已有在住床位，请先退宿"); } // 3. 写入住记录 CheckinRecord record = new CheckinRecord(); record.setStudentId(studentId); record.setBedId(bedId); record.setCheckinTime(new Date()); record.setStatus(1); recordMapper.insert(record); // 4. 更新床位状态为已分配 bedMapper.updateStatus(bedId, 1); } }

这段代码有三个设计点值得讲。第一，selectForUpdate是行级锁，防止两个宿管员同时给同一个床位分配不同学生——并发问题在演示时看不出来，但答辩时导师很爱问，你能答上「用行锁保证分配原子性」就是加分项。第二，countLivingByStudent这个校验防止一个学生被分到两个床位，这是业务规则，必须放在 Service 而不是数据库约束里，因为规则可能变。第三，@Transactional的rollbackFor = Exception.class确保任何异常都回滚，默认只回滚运行时异常，受检异常不回滚是个经典坑。

3.3 调宿与退宿：状态流转要画成一张图

调宿的本质是「先退旧床位、再分新床位」，但这两步必须在一个事务里，否则会出现学生旧床位退了、新床位没分上的空窗期。退宿则是把入住记录的checkout_time填上、status改为 0，同时把床位状态改回空闲。这里建议在文档里画一张床位状态流转图：空闲 → 已分配 → 待退宿 → 空闲，维修中可以从空闲进入也可以回到空闲。状态图不是给代码看的，是给答辩评委看的，它证明你想清楚了整个生命周期，而不是东拼西凑写功能。

4. 关键功能实现：查询、报修与权限这三块怎么落地

4.1 多条件组合查询：MyBatis 动态 SQL 的正确写法

宿舍管理里最高频的操作是「按楼栋 + 楼层 + 状态查床位」，条件可能只传一个，也可能全传。用 MyBatis 的<if>动态拼 SQL 是最顺手的做法：

<select id="selectBedsByCondition" resultType="BedVO"> SELECT b.id, b.bed_no, r.room_no, f.floor_no, bld.building_name, b.status FROM bed b JOIN room r ON b.room_id = r.id JOIN floor f ON r.floor_id = f.id JOIN building bld ON f.building_id = bld.id <where> <if test="buildingId != null">AND bld.id = #{buildingId}</if> <if test="floorNo != null">AND f.floor_no = #{floorNo}</if> <if test="status != null">AND b.status = #{status}</if> </where> ORDER BY bld.building_name, f.floor_no, r.room_no, b.bed_no </select>

<where>标签会自动处理第一个AND，避免拼出WHERE AND的语法错误，这是新手常踩的坑。排序字段按楼栋、楼层、房间、床位四级排，保证列表展示时同一房间的床位挨在一起，宿管员看着舒服。参数说明：buildingId是楼栋主键，floorNo是楼层号，status是床位状态，三个都可为空，为空则该条件不参与过滤。

4.2 报修管理：一个简单的状态机就够了

报修模块不需要复杂，但状态要清晰：待处理 → 处理中 → 已完成。学生提交报修单，宿管员接单改状态，完成后填处理结果。这里的关键是报修单要关联房间而不是床位，因为很多报修（比如灯坏了、门锁坏了）是房间级别的问题。表设计上加一个room_id外键和handler_id（处理人）字段，再加一个create_time用于按时间排序。别小看这个模块，答辩时它是体现「业务闭环」的好素材——从学生提交到宿管处理到完成归档，一条完整链路。

4.3 权限控制：三种角色用拦截器做粗粒度隔离

毕设场景下不必上全套 Spring Security，一个登录拦截器加角色判断就够用。登录成功后把用户角色放进 Session，拦截器里判断当前请求路径是否属于该角色可访问范围。学生只能访问自己的信息查询和报修提交，宿管员能访问分配和报修处理，管理员能访问所有。粗粒度但清晰，答辩时讲得明白比堆技术更重要。如果导师要求细粒度到按钮级，再考虑加注解式权限校验，但那是加分项不是必选项。

5. 避坑与常见问题：这几处翻车点我见得太多了

5.1 并发分配导致一个床位住两人

现象是演示时一切正常，但压力测试或两人同时操作时，同一个床位出现两条在住记录。原因是查询和更新之间没有锁，两个请求都查到床位空闲，都写了记录。解决办法就是 3.2 节里的selectForUpdate行锁，或者用数据库唯一约束兜底——在入住记录表上加一个「床位 + 在住状态」的部分唯一索引。我一般两个都上，锁保证逻辑正确，约束保证数据兜底。

5.2 退宿后统计报表数字对不上

现象是退宿操作做完，床位空了，但「历史入住人数」统计少了一个。原因是退宿时把入住记录物理删除了。解决方法是退宿只更新checkout_time和status，记录永远保留。统计「当前在住」用status = 1，统计「历史入住」用全表，两个口径分开。这个坑的本质是没区分「当前状态」和「历史流水」，设计阶段想清楚就不会踩。

5.3 中文乱码从数据库一路传到页面

现象是学生姓名在页面显示成问号。原因链条通常是：数据库字符集不是 utf8mb4、JDBC 连接串没指定编码、或者前端页面 meta 没声明。解决方法是建库时CHARACTER SET utf8mb4，连接串加useUnicode=true&characterEncoding=utf8，页面加<meta charset="UTF-8">。三处都对齐，乱码基本绝迹。这个坑不高级但极其常见，答辩前一定全链路检查一遍。

5.4 事务不生效导致半截数据

现象是分配床位时入住记录写进去了，但床位状态没改。原因多半是@Transactional加在了 private 方法上，或者同类内部方法调用绕过了代理。解决方法是确保注解加在 public 方法上，且通过注入的代理对象调用。另一个常见原因是异常被 catch 吞掉了，事务感知不到异常自然不回滚。记住一句话：事务方法里别随便 try-catch，要 catch 就记得重新抛出。

6. 验收与答辩：怎么把一套系统讲成一份可信的方案

验收这件事，我一般建议按「数据 → 流程 → 异常」三层来准备。第一层是数据层验收：打开数据库，现场演示建表语句、插入几条测试数据、跑一遍核心查询 SQL，证明数据模型是通的。评委看到你随手能写出联表查询，信任感立刻建立。第二层是流程层验收：按角色走完整链路——管理员建楼栋房间、宿管员分配床位、学生登录查自己的床位、学生提交报修、宿管员处理报修、学生退宿。一条链路走完，功能覆盖就讲清楚了。第三层是异常层验收：故意分配一个已占用的床位看是否报错、故意重复退宿看是否拦截、故意传空参数看是否友好提示。异常处理是区分「能跑」和「靠谱」的分水岭。

答辩陈述有个技巧：别按代码目录讲，按「问题 → 方案 → 证据」讲。比如「床位并发分配会出问题（问题），我用行锁加事务保证原子性（方案），这是代码和测试结果（证据）」。评委爱听这种结构，因为它证明你有工程判断力，而不是把功能堆完就完事。下面这张表可以帮你自查验收点：

最后说个我自己的习惯。早年做这类系统，我总想着功能越多越好，结果答辩时被问「你这个调宿和退宿的区别是什么」答得磕磕巴巴。从那以后我每次交方案前，都强制自己用一句话说清每个模块解决什么问题，说不清的就砍掉或者重做。这套宿舍管理系统看着功能不少，但核心就一句话：让每一张床位在任何时刻都有明确的状态和归属。把这句话讲透，比堆十个花哨功能都管用。希望帮到你。

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