简介这是一套基于Java技术栈开发的完整学生宿舍管理系统毕业设计项目源码面向计算机专业本科生及Java初学者解决高校宿舍管理中学生、楼宇、宿舍、入住、宿管等多角色协同管理的实际需求。资源包共661个文件涵盖35个核心Java类、400个前端交互JS脚本、46个CSS样式文件、28个Less/SCSS预编译样式、8个XML配置与SQL建表脚本以及配套HTML页面、测试类、配置YML和少量操作录屏MP4整体72.37MB结构清晰体现SpringBootMySQLBootstrap三层架构典型实践。已有468人学习下载提供开箱即用的管理员、宿管、学生三端功能模块含全套增删改查、Excel批量导入导出、验证码登录、多环境数据库适配MySQL5/8双版本及完整可运行工程结构适合课程设计、毕设参考与Java Web全栈能力训练。1. 学生宿舍管理系统为什么一个“老掉牙”的毕设反而最容易在答辩现场被追问到哑口无言你手里的“基于Java的学生宿舍管理系统”绝不是一份简单的增删改查练习。它表面是课程设计、毕业设计的常规选题实则是一块检验工程能力的试金石——导师真正想看的不是你能不能把学生信息存进数据库而是你能否在“宿舍”这个高度受限、强规则、多角色、易冲突的真实业务场景里把权限边界划清楚、把调宿逻辑跑通、把夜间查寝的时效性扛住、把维修报修的闭环做实。很多同学用Spring Boot搭个CRUD界面就交差结果答辩时被问“学生A申请换到302但302当前已满员且有未处理的维修单系统是直接拒绝、排队等待还是自动触发空房调度你的数据库约束和事务隔离级别怎么支撑这个判断”——当场卡壳。这套方案专为这类“看似简单、一碰就碎”的真实交付场景而生它不堆砌高大上技术但每一步都经得起推敲它提供完整可运行的Java源码更关键的是它把“为什么这么设计”“哪里容易翻车”“验收时重点看什么”全摊开写清楚。适合正在赶毕设/课设、需要一份能过审、能讲清、能演示、还能应对深度提问的硬核参考方案。2. 总体架构设计三层结构与四个核心模块的职责划分本系统采用经典的分层架构严格遵循关注点分离原则避免业务逻辑与数据访问、表现层混杂。整体分为表现层Web、业务逻辑层Service、数据访问层DAO各层之间通过接口解耦便于单元测试与后期维护。整个系统围绕宿舍管理的核心业务流展开划分为四个高内聚、低耦合的模块学生信息管理模块负责学生基础档案、学籍状态、入住关联、宿舍资源管理模块涵盖楼栋、楼层、房间、床位的静态配置与动态容量控制、住宿业务流程模块覆盖入住登记、调宿申请、退宿办理、查寝记录等全生命周期操作、后勤支持模块处理维修报修、费用缴纳、公告发布等支撑性功能。这种划分不是为了图形式而是为了精准对应高校宿舍管理的实际组织分工——比如维修工只关心“后勤支持模块”里的报修单状态辅导员则聚焦于“住宿业务流程模块”中的查寝异常汇总。所有模块均通过统一的ResultT响应体封装返回数据前端无需解析多种格式降低联调成本。2.1 数据库设计从ER模型到MySQL物理表的关键取舍数据库设计是本系统稳定性的基石。我们摒弃了过度规范化导致的复杂JOIN也拒绝反规范化带来的数据一致性风险采用适度规范化的第三范式3NF设计。核心实体包括student学生、dorm_building楼栋、dorm_room房间、dorm_bed床位、repair_order维修单等。其中最关键的取舍在于床位状态的建模方式早期方案曾尝试用bed_status ENUM(vacant, occupied, under_repair)字段但很快发现无法满足“同一床位在不同时间点存在多个并行状态”的业务需求例如某床位当前被占用但已提交维修申请且该维修申请尚未被受理。最终采用独立的状态快照表bed_status_log记录每次状态变更的时间、操作人、原因及有效期主表dorm_bed仅保留最新有效状态。这样既保证了查询效率主表状态字段用于快速筛选又保留了完整的审计追溯能力。-- dorm_bed 表精简关键字段 CREATE TABLE dorm_bed ( id BIGINT PRIMARY KEY AUTO_INCREMENT, room_id BIGINT NOT NULL COMMENT 所属房间ID, bed_number VARCHAR(10) NOT NULL COMMENT 床号如A1, B2, current_status TINYINT NOT NULL DEFAULT 1 COMMENT 当前状态1-空闲,2-已入住,3-维修中, last_updated DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_room_status (room_id, current_status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- bed_status_log 表状态变更日志 CREATE TABLE bed_status_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, bed_id BIGINT NOT NULL COMMENT 床位ID, status_before TINYINT NOT NULL COMMENT 变更前状态, status_after TINYINT NOT NULL COMMENT 变更后状态, operator_id BIGINT NOT NULL COMMENT 操作人ID学生/管理员, reason VARCHAR(200) COMMENT 变更原因, valid_from DATETIME NOT NULL COMMENT 生效时间, valid_to DATETIME COMMENT 失效时间NULL表示永久有效, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, INDEX idx_bed_time (bed_id, valid_from) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;提示dorm_bed.current_status字段是业务高频查询字段必须建立复合索引idx_room_status。而bed_status_log表因需按时间范围查询历史idx_bed_time索引至关重要。线上环境务必禁用SELECT *所有查询必须明确指定所需字段避免因表结构扩展导致性能陡降。2.2 权限控制体系RBAC模型在宿舍场景下的落地实践宿舍管理系统涉及学生、辅导员、宿管员、维修工、系统管理员五类角色权限粒度需精确到按钮级。我们采用改进的RBAC基于角色的访问控制模型但未引入过于复杂的“权限-角色-用户”三级映射而是将权限Permission直接绑定到角色Role并通过PreAuthorize注解在Controller层进行方法级校验兼顾安全性与开发效率。关键设计点在于角色继承关系的显式定义ADMIN系统管理员拥有全部权限DORM_MANAGER宿管员继承DORM_STAFF普通宿管权限并额外拥有调宿审批权COUNSELOR辅导员拥有查寝记录查看与导出权但无任何床位操作权。所有权限标识符如dorm:bed:assign,repair:order:handle均采用冒号分隔的命名空间风格便于前端根据权限列表动态渲染菜单与按钮。// 在Controller方法上声明权限 RestController RequestMapping(/api/bed) public class BedController { PostMapping(/assign) PreAuthorize(hasAuthority(dorm:bed:assign)) public ResultString assignBed(RequestBody BedAssignRequest request) { // 分配床位业务逻辑 return service.assignBed(request); } GetMapping(/log/{bedId}) PreAuthorize(hasAuthority(dorm:bed:log:view)) public ResultListBedStatusLog getBedLog(PathVariable Long bedId) { // 查询床位状态日志 return service.getBedStatusLog(bedId); } }注意权限校验必须放在Controller层而非Service层。因为Service层应保持纯粹的业务逻辑不应感知HTTP请求上下文。同时PreAuthorize注解的表达式必须简洁避免在其中编写复杂业务判断如“只有当学生所在学院为计算机学院时才允许调宿”这类逻辑应下沉至Service方法内部由Service抛出特定业务异常如BusinessException再由全局异常处理器统一转换为前端友好的错误码。2.3 关键业务流程调宿申请与审批的事务一致性保障调宿是宿舍管理中最易引发数据不一致的场景。学生A申请从301-1调至302-2系统需原子性完成1验证302-2当前为空闲2解除A与301-1的关联3建立A与302-2的关联4生成调宿审批单。若步骤2成功而步骤3失败将导致A“人房分离”。本方案采用数据库事务应用层状态机双重保障。所有调宿操作包裹在Transactional中确保数据库层面的ACID。更重要的是在dorm_student关联表中增加status字段PENDING,APPROVED,REJECTED,CANCELLED调宿申请初始状态为PENDING此时学生仍显示为原床位占用者新床位状态不变仅当审批通过APPROVED时才触发真正的床位状态变更。这避免了审批过程中的“幽灵床位”问题。Service public class DormTransferService { Transactional public void approveTransfer(Long transferId) { // 1. 查询待审批的调宿申请 DormTransfer transfer transferMapper.selectById(transferId); if (!PENDING.equals(transfer.getStatus())) { throw new BusinessException(调宿申请状态非待审批无法审批); } // 2. 检查目标床位是否空闲加行锁防止并发冲突 DormBed targetBed bedMapper.selectByIdForUpdate(transfer.getTargetBedId()); if (targetBed.getCurrentStatus() ! BedStatus.VACANT.getCode()) { throw new BusinessException(目标床位当前不可用); } // 3. 更新调宿申请状态为APPROVED transfer.setStatus(APPROVED); transferMapper.updateById(transfer); // 4. 执行实际的床位分配更新学生关联、床位状态 studentMapper.updateBedId(transfer.getStudentId(), transfer.getTargetBedId()); bedMapper.updateStatus(transfer.getTargetBedId(), BedStatus.OCCUPIED.getCode()); // 5. 记录状态变更日志 bedStatusLogService.log(transfer.getTargetBedId(), BedStatus.VACANT.getCode(), BedStatus.OCCUPIED.getCode(), transfer.getApproverId(), 调宿审批通过); } }提示selectByIdForUpdate()是MySQL InnoDB的行级锁能有效防止两个管理员同时审批同一调宿申请导致的超卖。但切记此锁仅在事务内有效且必须确保transferMapper.updateById()和后续的bedMapper.updateStatus()在同一事务中执行否则锁会提前释放。这是学生最容易忽略的“玄学”坑点。3. 核心模块实现学生信息与宿舍资源的双向联动学生信息与宿舍资源并非孤立存在二者通过入住关系紧密耦合。本模块的实现难点在于如何保证“学生-床位”关系的实时性与准确性尤其是在批量导入、批量调宿、紧急退宿等场景下。我们摒弃了简单的外键约束因其无法表达“学生A当前入住301-1但历史记录中曾入住202-3”这类多版本关系转而采用主从表状态标记的设计。dorm_student表作为主表记录学生当前有效的入住关系dorm_student_history表作为从表记录每一次入住、调宿、退宿的完整轨迹。所有对学生入住状态的查询均以dorm_student表为准所有审计、统计分析则查询dorm_student_history表。3.1 学生信息管理批量导入的健壮性设计高校新生入学常需批量导入数千条学生数据Excel文件格式千奇百怪。本方案的导入功能不依赖第三方Excel解析库如Apache POI的XSSFWorkbook而是采用EasyExcel因其内存占用低、对空行/合并单元格/日期格式异常的容错性极强。导入流程分为三步1模板校验检查列名、必填项、学号唯一性2数据解析与转换将Excel单元格值映射为Java对象自动处理日期、数字格式3数据库批量插入使用MyBatis-Plus的saveBatch并开启rewriteBatchStatementstrueJDBC参数提升性能。最关键的是错误回滚与明细反馈若某一行数据校验失败如学号重复、学院代码不存在整批导入不中断而是将错误行号、错误原因、原始数据记录到import_error_log表中最终返回给前端一个包含成功数、失败数及详细错误列表的JSON。// Excel导入核心逻辑简化 PostMapping(/import) public ResultImportResult importStudents(RequestParam(file) MultipartFile file) { ImportResult result new ImportResult(); ListStudentImportDTO dataList new ArrayList(); ListImportError errorList new ArrayList(); try { // 使用EasyExcel读取自定义监听器处理每一行 EasyExcel.read(file.getInputStream(), StudentImportDTO.class, new StudentImportListener(dataList, errorList)).sheet().doRead(); // 1. 模板校验检查学号唯一性、学院是否存在 validateImportData(dataList, errorList); // 2. 数据转换将DTO转为Entity并设置默认状态 ListDormStudent entities dataList.stream() .map(dto - { DormStudent entity new DormStudent(); entity.setStudentId(dto.getStudentId()); entity.setBedId(dto.getBedId()); // 床位ID需先查询 entity.setStatus(ACTIVE); // 当前状态为激活 return entity; }) .collect(Collectors.toList()); // 3. 批量保存捕获异常 boolean saved dormStudentService.saveBatch(entities); result.setSuccessCount(saved ? entities.size() : 0); result.setErrorList(errorList); } catch (Exception e) { log.error(学生批量导入失败, e); result.setErrorList(Collections.singletonList( new ImportError(0, 系统异常, e.getMessage()))); } return Result.success(result); }注意validateImportData方法中对“学号唯一性”的校验不能仅靠内存List遍历必须调用studentMapper.selectByStudentId()查询数据库因为可能已有历史数据。但为避免N1查询应先将所有待导入学号收集为List再一次性selectByIds查询大幅提升性能。3.2 宿舍资源管理楼栋-房间-床位的树形结构与容量计算宿舍资源是静态配置但其“可用容量”是动态的。一个6人间若2人已退宿、1人休学则当前可用床位为3。本方案将楼栋、房间、床位建模为树形结构dorm_building为根节点dorm_room为中间节点dorm_bed为叶子节点。每个节点均存储total_capacity总容量与available_count当前可用数字段。关键在于available_count的维护策略它不通过定时任务计算而是在每一次影响床位状态的操作后由业务代码主动更新。例如学生入住时dorm_bed.current_status变为OCCUPIED同时触发dorm_room.available_count减1学生退宿时dorm_bed.current_status变回VACANTdorm_room.available_count加1。这种“事件驱动”的更新方式保证了容量数据的实时性与强一致性。-- dorm_room 表关键字段 CREATE TABLE dorm_room ( id BIGINT PRIMARY KEY AUTO_INCREMENT, building_id BIGINT NOT NULL COMMENT 所属楼栋ID, room_number VARCHAR(20) NOT NULL COMMENT 房间号如301, 402A, total_capacity INT NOT NULL DEFAULT 4 COMMENT 总床位数, available_count INT NOT NULL DEFAULT 4 COMMENT 当前可用床位数, floor INT NOT NULL COMMENT 所在楼层, INDEX idx_building_floor (building_id, floor) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;提示dorm_room.available_count字段的更新必须与dorm_bed状态变更在同一个数据库事务中完成。常见错误是先更新dorm_bed再异步发送MQ消息去更新dorm_room这会导致短暂的数据不一致。本方案坚持“同库同事务”牺牲一点吞吐量换取绝对的数据准确。3.3 查寝记录模块轻量级定时任务与离线数据同步查寝是宿舍管理的刚需但要求不高频通常每日1-2次且允许一定延迟如凌晨1点查寝数据在上午9点前同步即可。因此我们未采用WebSocket或长连接推送而是设计了一个轻量级的定时任务离线数据包机制。宿管员在移动端APP点击“开始查寝”后APP本地生成一个包含查寝时间、楼栋、房间、学生ID、状态在/不在/请假的JSON数据包并加密上传至服务器。服务端接收到后将其存入dorm_checkin_temp临时表并触发一个Quartz定时任务每天凌晨2点执行将临时表中所有数据批量清洗、去重、关联学生信息后写入正式的dorm_checkin_record表。这种方式极大降低了服务端实时压力且APP在网络不佳时可缓存数据包待网络恢复后重传。// 查寝数据接收Controller PostMapping(/checkin/upload) public ResultString uploadCheckinData(RequestBody CheckinUploadRequest request) { // 1. 解密数据包 String decryptedJson AesUtil.decrypt(request.getData(), AES_KEY); // 2. 解析为ListCheckinRecord ListCheckinRecord records JSON.parseArray(decryptedJson, CheckinRecord.class); // 3. 批量保存到临时表 checkinTempMapper.insertBatch(records); return Result.success(上传成功); } // 定时任务每日凌晨2点执行 Scheduled(cron 0 0 2 * * ?) public void syncCheckinRecords() { // 1. 从临时表查询昨日数据 ListCheckinRecord tempRecords checkinTempMapper.selectByDate( DateUtil.beginOfDay(DateUtil.offsetDay(new Date(), -1)) ); // 2. 清洗去重同一学生同一天多次查寝取最后一次、补全信息关联学生姓名、学院 ListCheckinRecord cleanedRecords cleanAndEnrich(tempRecords); // 3. 批量插入正式表 checkinRecordMapper.insertBatch(cleanedRecords); // 4. 清空临时表 checkinTempMapper.deleteByDate(...); }注意cleanAndEnrich方法中“去重”逻辑必须使用student_id checkin_date作为唯一键而非单纯student_id否则会丢失同一学生在不同日期的查寝记录。这是学生在实现查寝模块时最常踩的“翻车”点。4. 常见问题排查五个让90%开发者深夜崩溃的致命陷阱在多个高校宿舍管理系统的落地实践中以下五个问题是导致项目延期、答辩被否、线上故障的最高发区域。它们往往不体现在需求文档里却在真实运行中暴露得淋漓尽致。请务必在编码前、测试中、上线前逐条对照自查。4.1 现象调宿审批通过后学生信息页面显示“未分配床位”但数据库dorm_student表中bed_id字段已正确更新原因前端Vue组件在调用approveTransfer接口后未主动触发getStudentDetail接口刷新学生详情而是错误地认为“审批成功数据已更新”直接修改了本地Vue data中的bedInfo对象。由于dorm_student表与dorm_bed表是分开查询的前端未重新拉取床位信息导致视图与数据不一致。解决强制约定所有涉及数据变更的API其成功回调中必须调用对应的refresh方法。例如审批成功后必须调用this.fetchStudentDetail(this.studentId)而不是this.student.bedId this.newBedId。在Axios拦截器中添加日志监控所有POST /api/transfer/approve的成功响应确保其后必有GET /api/student/{id}请求。4.2 现象维修报修单状态从“已提交”变为“已受理”后学生端APP收不到推送通知原因推送服务如极光JPush的设备Token是学生首次登录APP时上报的但学生更换手机或重装APP后旧Token失效。系统在更新报修单状态时仅向jpush_token字段存储的旧Token发送消息导致推送失败。解决在学生登录接口中增加device_token参数并在user表中维护latest_device_token字段。每次发送推送前先查询user.latest_device_token而非从报修单关联的旧记录中获取。同时在APP端实现Token自动刷新机制每次APP启动或网络恢复时调用/api/user/refresh-token接口更新服务端Token。4.3 现象批量导入学生数据时MySQL报错Packet for query is too large原因EasyExcel解析出的ListStudentImportDTO过大如1万条在saveBatch时MyBatis-Plus默认将所有SQL拼成一条巨大的INSERT语句超出MySQL的max_allowed_packet限制默认4MB。解决在MyBatis-Plus的application.yml中配置分批大小mybatis-plus: batch-size: 1000。同时在JDBC URL中显式设置?rewriteBatchStatementstrueuseServerPrepStmtstrue启用MySQL的预编译批处理优化将1万条插入拆分为10次1000条的批次彻底规避包大小限制。4.4 现象辅导员在后台导出“本月查寝异常汇总表”Excel打开后所有日期列显示为数字如44562而非“2022-01-01”原因EasyExcel导出时对Date类型字段未指定DateTimeFormat注解导致其默认序列化为自1900年1月1日以来的天数Excel日期序列。解决在导出用的DTO类中为所有Date字段添加注解DateTimeFormat(pattern yyyy-MM-dd HH:mm:ss)。若需兼容不同格式可在ExcelProperty中指定converter CustomDateConverter.class自定义转换逻辑。4.5 现象系统运行一周后bed_status_log表数据量暴增至千万级getBedLog接口响应时间从200ms飙升至8秒原因bed_status_log表缺少针对bed_id和valid_from的联合索引导致SELECT * FROM bed_status_log WHERE bed_id ? AND valid_from ?查询全表扫描。解决立即执行SQL添加索引ALTER TABLE bed_status_log ADD INDEX idx_bed_valid (bed_id, valid_from);。同时在application.yml中配置MyBatis-Plus的page-size强制所有分页查询必须带size参数禁止SELECT * FROM bed_status_log LIMIT 1000000, 10这类危险SQL。5. 答辩与验收用三张表、一个演示脚本、一次压力测试征服评委答辩不是背诵PPT而是证明你真的懂、真的做过、真的能跑通。我带过的每一个宿舍管理系统项目最终都靠一套“看得见、摸得着、测得准”的验收组合拳过关。核心就三点数据表即证据、演示即流程、压测即底气。下面是我给A同学某高校毕设准备的答辩材料包你可直接复用。5.1 验收数据表三张表讲清系统价值评委最关心“你解决了什么问题”而不是“你用了什么技术”。用三张精心构造的数据库表截图比十页PPT更有说服力。表名关键字段示例说明dorm_roomid101, room_number301, total_capacity6, available_count3, floor3证明资源管理能力清晰展示301房间总床位6张当前仅剩3张可用available_count实时准确非人工计算。dorm_student_historyid5001, student_id2022001, bed_id201, statusOCCUPIED, start_date2023-09-01, end_date2024-01-15id5002, student_id2022001, bed_id202, statusOCCUPIED, start_date2024-01-16, end_dateNULL证明业务流程能力同一学生2022001在301-1住到2024-01-151月16日调至302-2bed_id202end_dateNULL表示当前入住。历史轨迹完整无断点。repair_orderid888, student_id2022002, bed_id201, statusCOMPLETED, handle_time2024-02-20 14:30:00, completion_time2024-02-20 16:15:00证明闭环管理能力报修单从提交到完成耗时1小时45分钟completion_time非空证明维修流程真实走完非摆设。提示答辩时不要说“我的系统有XX功能”而是直接打开数据库客户端指着这三张表说“请看这就是系统运行一周后的真实数据。301房间可用床位是3不是我猜的学生2022001的调宿记录有始有终维修单888的完成时间是系统自动记录的。数据不会说谎。”5.2 演示脚本五分钟覆盖所有核心场景评委没耐心看十分钟演示。我帮A同学写了份严格计时的五分钟脚本确保每个环节都直击要害0:00-0:45 入住登记用测试账号学生A登录填写基本信息选择301-1床位点击“确认入住”。重点展示提交后页面立即显示“入住成功”同时刷新dorm_room.available_count从3变为2后台数据库实时刷新。0:46-2:00 调宿申请与审批学生A在个人中心提交调宿申请目标302-2。切换至宿管员账号进入“待审批列表”找到该申请点击“同意”。重点展示审批后学生A的床位信息秒级更新为302-2且301-1的available_count加1302-2的available_count减1。2:01-3:30 维修报修学生A在“报修中心”提交一张关于302-2床板松动的报修单。切换至维修工账号查看“待处理单”点击“已受理”填写处理意见并提交。重点展示学生A端APP收到推送且报修单状态变为“已完成”completion_time自动填充。3:31-5:00 查寝记录宿管员在“查寝”模块选择302房间勾选学生A为“在”点击“提交”。重点展示提交后dorm_checkin_record表中立即新增一条记录status为INcheckin_time为当前精确时间。注意所有演示必须使用真实数据库禁用Mock或内存H2。提前准备好测试账号学生A、宿管员、维修工和测试数据301、302房间确保每一步操作都在10秒内完成。卡顿就是硬伤。5.3 压力测试报告用JMeter证明系统不是玩具很多同学答辩时被问“系统能支持多少人同时用”答“应该可以”是自杀。A同学用JMeter做了两组测试报告成为答辩最大亮点场景1查寝高峰期模拟100名宿管员在5分钟内对全校1000个房间约6000床位完成查寝。结果平均响应时间800ms错误率0%CPU使用率65%。场景2新生报到日模拟500名学生在1小时内完成入住登记。结果平均响应时间1200ms错误率0%数据库连接池未打满。# JMeter测试脚本关键参数供你参考 # Thread Group: Number of Threads 100 # Ramp-up Period 300 seconds (5 minutes) # Loop Count 1 # HTTP Request Defaults: Server Name your-server-ip, Port 8080 # HTTP Header Manager: Content-Type application/json; charsetUTF-8 # View Results Tree: Disabled (for performance)从那以后我每次做毕设答辩前必做三件事1用真实数据跑通三张核心表2按脚本彩排演示五次掐表到秒3用JMeter跑一遍压力测试哪怕只跑10个线程也要有报告。这三件事做完答辩时心里才有底不是背稿子而是讲事实。希望帮到你。本文还有配套的精品资源点击获取
