简介基于Java的学生宿舍管理系统面向毕业设计、课程设计与Java Web学习者覆盖管理员、宿管、学生三类角色实现学生、楼宇、宿舍、入住、宿管及管理员的全流程管理支持增删改查、批量导入导出等操作。系统采用SpringBoot框架结合MySQL数据库前端基于Bootstrap搭建代码分层清晰SQL脚本可直接导入运行并附带针对MySQL5与MySQL8的修改版本便于不同环境快速部署。资源包整体约72.37MB共661个文件以js、css、java、xml、sql、html等类型为主涵盖前后端源码、数据库脚本、配置文件及说明文档目录结构完整。已有468人学习下载适合需要完成课设项目、快速理解宿舍管理业务逻辑或作为二次开发基础的开发者。1. 基于Java的学生宿舍管理系统先搞清楚它到底在解决谁的什么麻烦不少同学拿到“学生宿舍管理系统”这个题目时第一反应是“这不就是做个增删改查吗”。真开工之后才发现宿舍管理的核心难点根本不在CURD上而在于“床位状态的一致性”和“多个角色之间的流程协作”。同样是调宿管理员看的是“床位有没有释放”学生看的是“申请有没有被审批”辅导员看的是“这楼还有没有空床位”——三双眼睛盯着同一张表任何一端的数据不同步系统就是没法用的半成品。这篇方案帮你把它拆成一条能照抄的完整路径从需求角色划分、技术选型、数据库设计到报修/入住/调宿这些核心模块的落地实现再到验收答辩时的演示思路。适合正在做毕设或课设的学生照着搭也适合需要一个宿舍管理模块参考方案的开发者直接改。接下来按“先立需求、再给设计、最后落地验收”的顺序讲透。2. 需求分析与技术选型别再纠结框架先画出角色的边界2.1 三个角色各盯什么数据权限模型必须先于代码学生宿舍管理系统里的角色通常分为三类学生、楼栋管理员宿管、系统管理员。三者对数据的需求是完全不同的。学生关心“我的宿舍是哪间、室友是谁、报修进度到哪一步”宿管关心“这栋楼还有多少空床、今天有哪些访客登记、哪些宿舍卫生不合格”系统管理员关心“楼栋数据怎么维护、账号怎么分配、操作日志有没有留痕”。这三类关注点对应到系统里就是三套不同的数据视图。设计系统时我一般先画一张角色-权限-操作矩阵再去写代码。这张矩阵要明确一个问题每个角色能看哪些页面、能点哪些按钮、能改哪些字段。比如学生可以提交报修但不能把报修单指派给维修工宿管可以录入卫生检查结果但不能修改学生的个人信息和楼栋床位总数。权限模型建议直接走RBAC基于角色的访问控制用user表、role表、menu表、user_role关联表和role_menu关联表来支撑。前端做路由级权限控制后端做接口级权限校验。这样设计的好处是后期如果需要加一个“保洁员”或者“维修工”的角色只需要在menu表和role关联表里配数据不用改代码结构。2.2 Spring Boot MyBatis-Plus Vue这套组合为什么是稳妥答案技术栈的选择不需要花哨选最稳妥、最成熟、资料最多的组合就行。后端用Spring Boot 2.7.x持久层用MyBatis-Plus权限认证用Spring Security JWT前端用Vue 2.x Element UI数据库用MySQL 5.7。这套组合在Java宿舍管理系统里是最主流的搭配遇到问题基本都能搜到解决方案比用冷门框架要省心得多。选Spring Boot的核心原因是它把配置简化到了极致内置Tomcat一个jar包就能跑起来。MyBatis-Plus比原生MyBatis多了一个条件构造器写单表查询时不需要写XML比如查询某个楼栋的空床位只需要LambdaQueryWrapperBed wrapper new LambdaQueryWrapper(); wrapper.eq(Bed::getBuildingId, buildingId) .eq(Bed::getStatus, EMPTY); ListBed emptyBeds bedMapper.selectList(wrapper);这段代码的逻辑是从bed表里查building_id等于传入值、status等于“EMPTY”的所有床位记录。LambdaQueryWrapper的好处是编译期就能检查字段名是否正确避免手写SQL字符串时打错列名导致运行期才报错。如果您习惯写XML也完全可以但MyBatis-Plus确实能让开发效率提升不少。前端用Vue 2 Element UI的原因也很实际Element UI的表格、表单、弹窗组件开箱即用宿舍管理系统的页面大多是标准的表格加表单交互用这套组件库能省掉大量UI工作量。页面布局用侧边栏导航顶部放用户信息和退出登录主体区域用router-view承载不同模块。2.3 为什么不用双端分离或者小程序方案有些同学看到“管理系统”就觉得要搞一个专门的管理端加一个学生端App其实大部分宿舍管理系统的使用场景都在PC上。宿管和系统管理员需要用PC操作学生虽然偏好移动端但让学生装一个App的成本太高浏览器里打开前端页面也一样能提交报修、查卫生成绩。如果确实需要移动端体验更合理的做法是做一个简化版的H5页面而不是维护两个独立的工程。在Vue工程里增加一个手持端路由布局复用后端的同一套接口开发成本增加不大却能让学生省掉下载安装的步骤。毕设答辩时这也是一句能加分的表述“系统支持响应式布局移动端通过浏览器直接访问核心功能”。这是性价比最高的移动端方案小程序反而因为审核、发布、调试的链路太长不适合课设或毕设的节奏。3. 总体设计宿舍管理系统的模块划分与数据库核心表3.1 模块地图与数据流转路径系统的总体功能结构可以划分为七个模块系统管理、基础数据维护、住宿管理入住/退宿/调宿、报修管理、卫生检查、来访登记、统计看板。每个模块不是一个孤立的页面集合而是有一条清晰的数据流转链理解这条链对写代码和答辩都重要。住宿管理的数据从“楼栋-宿舍-床位”这张资源树开始。管理员先维护好5号楼、6号楼这样的楼栋数据再到每栋楼下建宿舍房间再到每个房间里分配床位。学生注册后由宿管为该学生分配入住系统在bed表里把对应床的位置置为“占用”状态同时在入住记录表里写入一条check_in记录。退宿时反向操作释放床位记录退宿时间。报修管理是另一条独立的链路从学生提交申请开始报修单状态为“待处理”宿管将工单指派给维修工后变为“处理中”维修工完成维修后提交结果状态变为“待验收”宿管验收通过后状态变为“已完工”。整条流程中每一步都会在报修日志表里追加一条操作记录这样答辩时可以直接说“系统对报修全流程留痕”这个点展示出来是加分项。统计看板模块则负责把散落在各表的数据聚合成图表住宿率按“已占用床位数除以总床位数”计算各楼栋的报修数量按building_id分组统计卫生合格率按楼栋维度聚合。宿管打开首页就能看到一张图答辩时演示这个页面比演示CRUD要有说服力得多。3.2 数据库设计十二张核心表的字段清单与关系说明数据库设计是宿舍管理系统能不能落到实处的关键。这里给出十二张核心表的字段说明按业务域划分三组。用户与权限域user表id、username、password、nickname、phone、avatar、status、role_id、deleted、role表id、role_code、role_name、menu表id、parent_id、menu_name、path、component、icon、sort、visible、user_role表user_id、role_id。宿舍资源域dorm_building表id、building_no、building_name、floor_count、room_count、manager_id、dorm_room表id、building_id、room_no、floor、bed_count、room_type、status、dorm_bed表id、building_id、room_id、bed_no、status、student_id、version、student_info表id、student_no、name、gender、class_name、major、phone、bed_id、check_in_date、status。业务流转域check_in_record表id、student_id、bed_id、building_id、room_id、check_in_date、check_out_date、remark、operator_id、repair_order表id、order_no、student_id、building_id、room_id、description、images、type、status、assignee_id、create_time、complete_time、version、repair_log表id、order_id、operator_id、action、comment、create_time、hygiene_check表id、building_id、room_id、check_date、score、grade、problem_desc、inspector_id、rectify_status、visit_record表id、visitor_name、visitor_phone、student_id、building_id、room_id、visit_time、leave_time、reason、operator_id。这里重点说两个很容易忽略的细节。第一dorm_bed表里student_id这个外键设计成可空字段床位上没有住人时它就是NULL这比用“空字符串”表示空床位要规范得多。第二repair_order表里加了一个version字段这是乐观锁专用的解决多人同时操作同一张工单时的数据竞争问题后面写实现的时候会再展开。3.3 床位状态机为什么说这叫“一表定乾坤”宿舍管理系统最核心的业务规则是床位状态不允许随意跳变。我把床位状态设计成四个EMPTY空置、OCCUPIED已入住、MAINTENANCE维修中、LOCKED锁定。四个状态之间的转换关系是固定的EMPTY可以转为OCCUPIEDOCCUPIED只能转为EMPTY或MAINTENANCEMAINTENANCE只能转回EMPTYLOCKED是管理员手动控制的状态不允许业务接口绕过规则直接修改。这个状态机设计能让“入住、退宿、调宿”三个业务的代码都变得非常清晰。调宿的本质是先执行退宿OCCUPIED转EMPTY再执行入住EMPTY转OCCUPIED中间夹着一个事务。报修如果涉及维修床位则先要把床位状态置为MAINTENANCE防止系统把“维修中”的床位当作空床位分配给新生。实际开发时我通常会在服务层写一个状态流转校验方法所有调用方强制走这个方法不允许直接执行update语句改status字段。这样虽然多了一道方法调用但避免了“明明业务上不允许却因为某处漏了判断把已占用床位分配出去”的翻车事故。答辩时如果能把这个设计讲清楚比把代码跑起来更能体现系统设计能力。4. 核心模块实现从登录鉴权到业务闭环的关键代码4.1 JWT登录与接口权限控制的落地写法先看登录接口的整体流程。用户提交用户名密码后后端先校验验证码再比对密码校验通过后生成一个JWT令牌返回给前端。前端把token存到localStorage里每次请求都在axios拦截器中把token塞进请求头。后端用一个过滤器统一拦截所有非放行接口解析token并对当前用户做权限匹配。Token的生成逻辑放在工具类里核心代码如下public String createToken(User user) { long now System.currentTimeMillis(); long expire now EXPIRATION_TIME; return Jwts.builder() .setSubject(user.getUsername()) .claim(userId, user.getId()) .claim(roleCode, user.getRoleCode()) .setIssuedAt(new Date(now)) .setExpiration(new Date(expire)) .signWith(secretKey, SignatureAlgorithm.HS256) .compact(); }这段代码的含义是把用户名、用户ID、角色编码封装进JWT的claims里设置签发时间和过期时间用HS256算法做签名。过期时间一般设置为12小时太短会导致用户频繁重新登录太长又增加token被盗后的风险窗口。答辩时可以提一句“token过期时间是为了在安全性与易用性之间做平衡”。校验过滤器只需提取请求头中的“Bearer ”前缀字符串解析并校验签名通过后把userId放到请求上下文里。后端接口通过注解做权限控制比如“报修单指派”接口上标注 PreAuthorize(“hasRole(‘ADMIN’)”)宿管角色调这个接口就会直接被拒绝不需要在业务代码里手写角色判断。4.2 报修工单全流程状态流转与乐观锁防并发报修模块是展示系统业务含金量的地方因为它是唯一一个涉及“多个角色协作”的流程。学生填表单提交报修生成待处理状态的工单宿管在工单列表里看到所有待处理的单子点击指派给某个维修工维修工在自己的待办列表里接单完工后填写维修结果宿管验收并打分整个流程才结束。在报修处理代码上可以从业务的视角去观察而不是关心它是怎么实现的。把四个状态写成常量枚举PENDING待处理、PROCESSING处理中、COMPLETED待验收、FINISHED已完工。每一步流转都调用统一的状态更新方法Transactional(rollbackFor Exception.class) public void changeRepairStatus(Long orderId, String targetStatus, Long operatorId) { RepairOrder order repairOrderMapper.selectById(orderId); if (!ALLOWED_TRANSITIONS.get(order.getStatus()).contains(targetStatus)) { throw new BizException(非法的状态流转); } RepairOrder update new RepairOrder(); update.setId(orderId); update.setStatus(targetStatus); update.setVersion(order.getVersion() 1); int rows repairOrderMapper.update(update, new LambdaQueryWrapperRepairOrder() .eq(RepairOrder::getId, orderId) .eq(RepairOrder::getVersion, order.getVersion())); if (rows 0) { throw new BizException(工单已被其他操作员处理请刷新后重试); } RepairLog log new RepairLog(); log.setOrderId(orderId); log.setOperatorId(operatorId); log.setAction(CHANGE_STATUS); log.setComment(状态变更为: targetStatus); repairLogMapper.insert(log); }这里最关键的是乐观锁校验。update操作带上version条件如果影响行数为0说明这张工单在操作过程中被其他人改过了直接抛出异常让前端提示用户刷新重试。这个设计能解决一个很实际的冲突场景两名宿管同时打开同一张工单A先完成了指派B再点“开始处理”时B的更新就会失败系统提示他已经不是最新状态。如果不做这个校验B的更新会直接覆盖A的数据工单历史和实际状态就乱了。事务注解强制保证“更新工单状态”和“写入日志”要么都成功要么都回滚避免工单状态变了但日志没记录的“黑匣子”。4.3 住宿管理的三个接口入住、退宿、调宿的事务边界住宿管理模块里最容易出问题的是事务边界。拿调宿来说它的本质是“释放旧床位占用新床位修改学生记录”三个操作任何一个失败都会导致数据不一致。释放了床位但学生信息没更新或者学生信息更新了但旧床位还占着都会让统计页面出现数字对不上的尴尬情况。正常实现中调宿接口必须加Transactional并且把三个操作都用同一套Service方法串联起来Transactional(rollbackFor Exception.class) public void changeBed(StudentMoveRequest request) { Bed oldBed bedMapper.selectById(request.getOldBedId()); if (!OCCUPIED.equals(oldBed.getStatus())) { throw new BizException(原床位状态异常无法调宿); } Bed newBed bedMapper.selectById(request.getNewBedId()); if (!EMPTY.equals(newBed.getStatus())) { throw new BizException(目标床位不可用); } int oldRows bedMapper.update(null, new LambdaQueryWrapperBed() .eq(Bed::getId, oldBed.getId()) .eq(Bed::getStatus, OCCUPIED) .set(Bed::getStatus, EMPTY) .set(Bed::getStudentId, null)); int newRows bedMapper.update(null, new LambdaQueryWrapperBed() .eq(Bed::getId, newBed.getId()) .eq(Bed::getStatus, EMPTY) .set(Bed::getStatus, OCCUPIED) .set(Bed::getStudentId, request.getStudentId())); checkInRecordMapper.insert(buildMoveRecord(request)); }这段代码的严谨之处在于每一条update都带了eq条件也就是说“必须是床位当前状态匹配时才更新”。比如旧床位明明已经是EMPTY了却有人来执行调宿释放操作这条update影响行数为0说明数据已经被改过此时再执行后续的新床位占用就会产生错误数据。我在写这个接口时会把影响行数的判断补上一旦oldRows为0或newRows为0直接抛出异常触发事务回滚保证整体的一致性。入住和退宿同理退宿接口的释放操作也必须是OCCUPIED转EMPTY入住则是EMPTY转OCCUPIED。4.4 汇总统计关键SQL与慢查询优化统计看板需要的数据散落在多张表里。住宿率统计按楼栋分组查询语句SELECT b.building_name, COUNT(DISTINCT bed.id) AS total_beds, COUNT(DISTINCT CASE WHEN bed.status OCCUPIED THEN bed.id END) AS occupied_beds FROM dorm_bed bed LEFT JOIN dorm_room room ON bed.room_id room.id LEFT JOIN dorm_building b ON room.building_id b.id GROUP BY b.building_name;这条SQL的逻辑是先关联床位、房间、楼栋三张表然后按楼栋分组用COUNT分别统计总床位数和已占用的床位数。报表期数据量大时注意给dorm_bed表的status字段和room_id字段建联合索引否则GROUP BY会做全表扫描宿管打开看板页面时等待时间会很长体验很差。每栋楼的报修数量统计走的是另一张表按building_id分组计数卫生合格率按楼栋分组后计算成绩大于等于合格线分的占比。这些SQL都建议写成视图或者一份Mapper XML里的统计查询方便复用和答辩时展示SQL编写能力。4.5 前端页面与后端联调的关键约定前后端联调是很多同学的翻车高发地。最常见的问题是后端返回的数据结构和前端预期不一致比如分页接口后端返回的是Page对象前端却从res.data.rows里取值结果拿到undefined。解决办法是在项目开始前就约定一个统一的响应体public class ResponseResultT { private Integer code; private String message; private T data; }所有接口统一走这个响应格式前端用axios响应拦截器做统一处理成功时取data失败时弹出message。分页接口的data结构也固定为“{ total, records }”前端分页组件不需要针对每个页面重新适配。这个约定看起来简单却能让前后端联调阶段少掉大半的低级问题。前端列表页有一个通用套路用Object.assign合并查询参数请求接口后把返回的records赋给表格数据源total赋给分页组件的total属性。搜索条件的重置就是把这几个字段清空后重新请求第一页。这套写法在所有列表页复用开发效率会比每张页面单独写一套逻辑要高得多。时间充裕的情况下可以做几个mixin分别封装“列表逻辑”“表单弹窗逻辑”“删除确认逻辑”能显著减少重复代码。5. 开发中高频翻车的几个点现象、原因与解决办法5.1 退宿后床位状态没变事务内的查询缓存惹的祸现象是学生退宿后界面上宿舍列表里该床位还是显示已入住但数据库里查明明已经更新了。原因多半出在一个方法里先查了床位信息再执行更新更新后又在同一事务里用同一个mapper去查这条记录没有绕开MyBatis的一级缓存查到的是更新前的旧数据。解决办法是同一事务内的查询和更新使用独立的mapper调用或者在更新后显式调用SqlSession的clearCache()方法。更稳妥的做法是不要在同一事务里“先查再改再查”拆成两个事务方法中间走独立查询。这个坑在调用链长的情况下特别隐蔽排查耗时很长建议一开始就养成“事务方法尽量短平快”的习惯。5.2 报修单重复指派乐观锁没加就并发失控现象是两个人同时对同一张工单操作后保存的人覆盖前面人的指派结果工单被指派给了错误的维修工。原因很直接更新语句没有带version条件后执行的update无条件覆盖了前一条update。解决办法就是前面代码里展示的乐观锁写法update时同时带上id和version两个条件影响行数为0时说明数据已被修改抛异常让用户重试。另外要检查一下前端是否有防重复提交逻辑提交按钮在请求未返回前应该置灰禁用防止用户手快连点两次生成重复数据。5.3 列表查询慢LEFT JOIN关联了太多张表现象是宿舍列表或学生列表数据量到几千条后打开页面明显变卡。原因是列表查询一次性关联了user、student_info、bed、room、building五张表并且WHERE条件里的字段没有索引MySQL只能全表扫描再做嵌套循环关联。解决办法是拆开来看。列表页如果没有太多跨表字段展示减少JOIN数量只需要显示楼栋名称和房间号的列表可以用子查询或者提前在业务表里冗余一个building_name字段。给WHERE条件里的status、student_no、room_id这些字段都建上普通索引联合查询的响应时间通常能从秒级降到毫秒级。查询优化的一个基本心法是EXPLAIN一下执行计划看到type列是ALL的就优先优化。5.4 宿舍号排序乱了VARCHAR字段排序是按字典序现象是宿舍楼列表排序后出现“10号楼”排在“2号楼”前面的情况。原因是building_no字段用的是VARCHAR类型排序时按字符串字典序比较“10”比“2”小所以排前面了。解决办法有两个方向。一个是设计表的时候就把building_no设计成INT类型只存楼栋编号数字名称展示时再拼接“号楼”后缀。另一个是如果已经有字符串数据不想改表查询时用ORDER BY CAST(building_no AS UNSIGNED)做数值排序。这个问题在答辩演示时很容易被问到提前处理掉能避免当场尴尬。5.5 文件上传后访问不了本地存储路径没有做映射报修图片和学生头像上传后前端拿到了相对路径却打不开。原因是Spring Boot默认只映射静态资源目录上传到自定义目录的文件不会自动暴露成可访问的URL。解决办法是配置一个资源映射器将硬盘上的上传目录映射到虚拟路径“/files/**”并统一把文件访问URL改写成“http://服务器IP:端口/files/文件名”这种格式。同时注意上传目录不能放在项目的src目录下因为重新部署打包时会被清掉。应该放在服务器的一个独立目录比如“/data/upload”通过配置文件指定路径。6. 验收与答辩怎么把系统演示出“能落地”的效果6.1 用验收清单代替“我全部做完了”验收环节建议准备一份功能验收清单逐条过而不是在演示时临场点菜单。清单按业务域分组每组列“操作步骤、预期结果、实际结果”三列。演示时按住宿管理、报修管理、卫生检查、统计看板、权限管理这个顺序走每个域演示两个核心场景不要全量演示。准备演示数据的时候建议先通过后台造一批有代表性的数据5号楼有3个空床位6号楼满员报修模块有两张待处理工单、一张处理中工单、一张已完工工单卫生检查里有一个“不合格待整改”的宿舍。这样演示调宿时可以直接选择“6号楼满员所以只能调到5号楼”的真实业务场景而不是临时拼数据。6.2 演示路径埋点把“踩坑”变成“亮点”很多同学答辩时习惯把鼠标移到哪就点哪结果演示中途出了Bug越修越乱。我建议的方法是提前设定一条固定的演示路径并且针对每个操作预判一两个“如果这里出了问题我该怎么解释”。比较稳妥的做法是把容易出错的环节比如并发操作、大数据量查询放到主动展示环节里。比如可以自己在屏幕上打开两个浏览器窗口让两个账号同时对同一张工单操作提前演示乐观锁防冲突的机制并向评委解释这是在模拟真实场景下多名宿管同时处理工单的情况。把“听起来可能出问题”的设计主动展示出来往往比藏着掖着更得分。6.3 答辩中容易被问到的几个点评委最常问的问题集中在三个方面一是表结构设计为什么床位和房间分两张表而不是合在一张二是权限控制的实现方式前端隐藏菜单是不是就够了三是这套系统如果部署上线最担心哪里的性能问题。第一问可以从房间与床位的两种关系来回答一个房间包含多个床位且要支持“部分床位被占用时换房间”的场景。第二问要说明前端隐藏菜单只是交互层面的限制真正不可绕过的是后端接口上的权限校验。第三问如果还没做性能压测就诚实说“当前是作为毕业设计完善核心功能和设计文档性能优化方向我会优先关注报表统计的SQL上目前通过索引和分组查询做了基础优化”然后再展示一条优化后的SQL不要硬着头皮说系统“性能绝对没问题”。结尾说一句习惯性的建议。从那以后我每次做类似的带状态流转的管理系统都会强制自己先画一遍状态机图把所有可能的状态跳变列全再动手写Service层代码。这一步看起来多花半天时间实际上节省的是后期调试数据不一致的几天时间。宿舍管理系统虽然业务不复杂但把状态流转做严谨了换到工单系统、资产管理系统也照样能平移过去。希望这份方案能帮你在设计和答辩上少走一点弯路。本文还有配套的精品资源点击获取