Spring Boot学生宿舍管理系统：源码解析、部署与答辩指南

又到了毕设季，后台经常收到这类私信：老师，我选题选了springboot学生宿舍管理系统，源码也拿到了（就是带编号25537的那套工程），但压根不知道从哪看起，跑起来全是报错，答辩也不知道该怎么讲。说实话，学生宿舍管理系统在Java毕设里属于“常青树”级别的题目，每年都有一堆人选，每年也都有人在同样的几个地方栽跟头。我自己陆陆续续帮人改过好几套类似的工程，从最开始对着源码发懵，到后来闭着眼睛都能把环境配好、把逻辑讲顺，中间踩过的坑比代码量还多。这篇文章我就把这类项目的来龙去脉、技术选型、核心功能实现、跑通部署步骤、答辩问到的重点一次讲透。不管你是拿到25537那套源码，还是打算从零手写一个，下面的内容都能让你少走很多弯路。

1. 为什么我建议毕设选“学生宿舍管理系统”：三个月选题纠结后的总结

1.1 这个系统到底在管什么

很多同学一听到“宿舍管理系统”就觉得是“简单版增删改查”，选这个题纯粹因为听起来好做。真拿到需求才发现，它比想象中完整得多。一个宿舍管理系统要管的事情包括：学生基本信息、宿舍楼栋与房间床位、入住/调宿/退宿、维修报修、卫生检查、晚归登记、公告发布、角色权限。从业务复杂度来看，它刚好处于“认认真真能做完，又不至于做到一半失控”的区间。

和常见的“员工管理”“图书管理”这种单表CRUD不同，宿舍管理天然带着“状态流转”和“数据关联”。比如一个学生入住，背后不只是往学生表里插一条记录，还要判断目标宿舍有没有空床位、床位占用数要不要更新、历史分配记录要不要留档。这种业务逻辑一旦想清楚，你的代码结构、数据库设计、答辩素材就全都有了。所以我一直觉得，这个题目是性价比很高的毕设选择。

1.2 三类用户三种视角：需求拆解的正确姿势

做任何一个系统，第一步都不是写代码，而是搞清楚“谁在用”。宿舍管理系统的用户基本可以分成三类：

• 系统管理员：管理宿舍楼栋、宿管员账号，查看全校宿舍使用情况，发布校级公告，拥有最高权限。
• 宿管员：负责日常宿舍分配、处理学生报修、登记晚归情况、录入卫生检查结果，权限集中在“日常事务处理”。
• 学生：查看自己的宿舍信息、提交维修申请、查看公告和卫生检查结果，权限最单一。

这三类角色的划分会直接影响你的数据库设计和接口设计。比如学生表、宿舍表、用户表怎么关联，哪些接口需要校验权限，前端菜单位置怎么摆，统统由角色模型决定。很多拿到源码的同学一上来就盯着代码看，这是效率最低的方式。正确顺序是：先看需求文档或README里对三种角色的描述，再看数据库表结构，最后才是代码。

2. 技术栈选定与项目骨架设计：Spring Boot 生态下的最稳组合

2.1 选型理由：为什么是 Spring Boot + MyBatis + MySQL

这套技术栈在毕设里堪称“标准答案”，不是因为它多前沿，而是因为它足够稳。

• Spring Boot：解决了传统SSM项目大量XML配置的痛点。起步依赖、自动装配、内嵌Tomcat，几行配置就能跑起来一个Web服务，非常适合课程设计和毕业设计的时间节奏。
• MyBatis：半自动ORM框架，SQL由自己写，多表关联和复杂统计查询非常灵活。宿舍管理的“查空床位”“统计入住率”这类SQL，用MyBatis写起来比JPA直观得多，面试时也更容易讲清楚。
• MySQL：经典关系型数据库，生态成熟，学习资料多，任何一个云服务器都能轻松部署。

前端方面要分情况：如果源码工程里带vue目录，说明是前后端分离写法；如果不带，后端可能在src/main/resources/templates下用 Thymeleaf 模板。就答辩演示而言，我更建议最终部署时把Vue构建后的静态文件放进Spring Boot的static目录，只用8080一个端口，避免现场开两个服务的尴尬。

2.2 项目目录结构与源码组织（附25537）

拿到25537这套源码后，先别急着跑，先花十分钟看清目录结构。一个标准的 Spring Boot 后端工程通常是这样的：

src/main/java/com/xxx/dormitory/ ├── controller/ // 接口层，接收前端请求 ├── service/ // 业务逻辑层，处理核心规则 ├── mapper/ // MyBatis的数据访问接口 ├── entity/ // 实体类，对应数据库表 ├── config/ // 配置类，如拦截器注册、跨域配置 ├── interceptor/ // 登录权限拦截器 └── common/ // 统一返回结果、异常处理等 src/main/resources/ ├── mapper/ // MyBatis的XML文件 ├── static/ // 静态资源，Vue打包后的文件在这里 ├── templates/ // Thymeleaf模板（如有） └── application.yml // 核心配置文件

源码包里的sql或db文件夹通常会放数据库脚本，README文件会写启动步骤。我的建议是：先读 README，再导数据库，最后启动后端。顺序反了，很容易在缺SQL文件、端口冲突这类低级问题上耗掉一整天。

2.3 数据库表设计：8张核心表撑起全部业务

数据库是整个系统的地基。很多人觉得表设计就是“把字段列出来”，其实不然。宿舍管理系统的核心表至少包含下面这些，表设计合理，代码写起来才顺。

这里有两个设计细节值得注意。第一，登录用户和业务资料要分开，sys_user管登录，student_info管学生业务数据，两者通过username或user_id关联，避免一个表既管认证又管业务导致字段混乱。第二，宿舍表要有used_beds字段，也就是当前已入住人数，分配宿舍时先校验“已住人数是否小于床位数”，再决定是否允许入住。这个字段就是宿舍分配业务的核心。

3. 核心功能是怎么一步步做出来的：从学生入住到离校全流程

3.1 学生信息与宿舍分配：最难的不是CRUD，是状态流转

学生管理模块表面上看是增删改查，但真正有含金量的是“宿舍分配”这个动作。我见过不少同学把分配宿舍写成“直接update学生表的dormitory_id”，结果超员、重复分配、退宿后床位不减这类问题一个接一个。

正确的分配逻辑应该包含下面几步：

1. 校验学生是否存在，且当前没有宿舍或允许调宿 2. 校验目标宿舍是否存在，且 used_beds < bed_count 3. 事务内执行： - 宿舍表 used_beds 加 1 - 学生表 dormitory_id 写入目标宿舍 - allocation_log 插入一条分配流水 4. 提交事务，返回分配结果

调宿则是“释放原宿舍 + 分配新宿舍”的组合操作，释放时used_beds减 1，分配时再加 1。退宿更要多想一步：不仅要释放床位，还要把学生状态改成“已离校”。这些操作统统一句话都行，但必须加@Transactional注解，否则中途报错会出现“床位减了、学生没更新”的脏数据。

3.2 报修与卫生检查：给管理员留出“处理闭环”

报修模块刚接触的人容易做成“学生提交一个表单，管理员看一眼，完事”。如果只是这样，答辩时基本会被问住。老师大概率会问：报修处理完怎么标记？整个流程怎么闭环？

所以报修表一定要有status字段，建议用枚举或固定字符串：待处理、处理中、已完成。学生提交报修后，宿管或管理员可以更新状态并填写处理结果，同时记录处理人handler_id和处理时间handle_time。列表查询时，学生只能看自己的报修，宿管能看到本楼栋报修，权限不同，查询条件不同，这就把前面第二章的角色模型落到了代码里。

卫生检查的思路类似。宿管录入检查结果时，按楼栋房间维度记录check_date、score、result，学生可以按自己的宿舍查询近期检查记录。这里可以顺手做一个“今日未检查宿舍列表”的统计接口，逻辑不复杂，但答辩演示时很有画面感，属于性价比很高的加分功能。

3.3 晚归登记与公告：把高频需求做成最简单的接口

如果说宿舍分配是系统的“难点”，晚归登记和公告就是“高频但简单”的功能，适合用来理解Spring Boot接口的完整套路。

晚归登记的接口核心就三件事：按学号或姓名选择学生、填写晚归原因和返回时间、保存记录。没有复杂的状态流转，但要注意晚归记录属于“宿管员操作”，接口路径应该放在宿管权限下，比如/manager/late/record，而不是/student/late/record。

公告模块由管理员或宿管发布，学生端按发布时间倒序查看，支持置顶与未读标识更好。这两个功能做的时候不要单独写“孤儿代码”，尽量复用已经抽好的工具类，比如统一返回结果Result.success()、分页查询封装PageResult、当前登录用户工具类CurrentUser.get()。代码复用得越好，后期维护越轻松，答辩时也能多说两句设计思路。

3.4 权限控制：用拦截器实现的角色隔离

宿舍管理系统建议不要直接上 Spring Security，虽然它是标准安全框架，但对毕设项目来说配置成本偏高、概念偏多，答辩时反而容易把自己绕进去。更稳妥的方案是 HandlerInterceptor 拦截器配合 Session：登录成功后把用户信息放进 Session，拦截器里校验是否登录、是否拥有某角色权限。

public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); Object user = session.getAttribute("currentUser"); if (user == null) { response.sendRedirect("/login"); return false; } return true; } }

然后在配置类里注册拦截器，并放行登录接口和静态资源：

registry.addInterceptor(new AuthInterceptor()) .addPathPatterns("/**") .excludePathPatterns("/login", "/static/**", "/error");

如果你想要更现代一点，可以升级成 JWT Token 方案，把前后端分离做得更彻底。不过那属于扩展功能，后面我单独讲。基础版本用拦截器完全足够，也好答辩。

4. 把源码跑起来：环境、配置、启动、部署一条龙

4.1 环境准备：JDK / Maven / MySQL 的版本避坑

很多同学把源码跑不起来的原因根本不是代码问题，而是版本不匹配。这一点我必须反复强调。拿到25537源码后，第一步打开pom.xml看spring-boot-starter-parent的版本号：

• 如果父工程版本是2.x（比如2.7.x），建议使用JDK 8 或 11，MyBatis 起步依赖用mybatis-spring-boot-starter的 2.x 版本，Lombok 用 1.18.x。
• 如果父工程版本是3.x（比如3.2.x），必须使用JDK 17+，原来的javax.servlet包全部变成了jakarta.servlet，MyBatis 起步依赖也要换到 3.x。

最典型的错误是：电脑里装了 JDK 17，启动一个 Spring Boot 2.2 的老项目，控制台刷一堆“非法反射访问”警告，或者干脆起不来。反过来，JDK 8 去跑 Spring Boot 3 的项目，直接报UnsupportedClassVersionError。这两种情况我都遇到过，解决方法只有一个：先确认版本矩阵，再动手配置。

4.2 配置文件与数据库初始化

数据库连接一定是第一个要改的地方。打开application.yml，把数据库地址、用户名、密码改成你自己的：

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/dormitory?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false username: root password: 123456

这里有三个容易踩的小坑：URL中必须带serverTimezone=Asia/Shanghai，否则MySQL 8大概率报时区错误；字符集要统一utf8mb4，不然中文可能出现乱码；先执行SQL脚本再启动服务，Spring Boot默认不会自动建表，跳过导库直接启动，启动不会报错，但一访问功能就全是表不存在的500。

4.3 启动项目与 IDEA 运行配置

用IDEA打开工程后，等右下角Maven导入完成，找到带@SpringBootApplication的主类，右键 Run 即可。如果IDEA没有自动生成Spring Boot运行配置，可以手动创建：Run -> Edit Configurations -> + -> Spring Boot，选择启动主类。

调整端口是高频操作。共有三种改法，效果等价：

方式一：改 application.yml 里的 server.port 方式二：运行配置的 VM options 填 -Dserver.port=8081 方式三：运行配置的 Program arguments 填 --server.port=8081

我实际测试下来，方式三最直观，适合临时改端口验证；方式一适合最终确定端口后固化配置。如果改了端口后端无反应，先确认改的是不是IDEA当前正在运行的那个模块的配置文件。

4.4 打包部署：vue 前端打进 Spring Boot 的常见操作

如果你拿到的是前后端分离版本，前端目录下通常有vue文件夹。本地开发时，前端用npm run dev起在8081端口，后端在8080，中间靠代理转发请求。但答辩现场开两个进程风险太高，所以强烈建议把前端打包后塞进Spring Boot的静态目录，只运行一个jar包。

操作步骤大致如下：

cd vue npm install npm run build # 将 dist 目录下的内容复制到后端 src/main/resources/static/ 下

复制完成后，在后端工程目录执行打包：

mvn clean package -DskipTests java -jar target/dormitory-0.0.1-SNAPSHOT.jar

浏览器访问http://localhost:8080就能看到完整系统。这里需要注意：前端axios请求的baseURL建议写成相对路径/api，后端Controller统一加/api前缀，这样打包后是同源访问，不会触发跨域。如果前端路由用了 history 模式，刷新页面会404，最简单的方法是把路由改成 hash 模式，或者后端加一个页面回退的转发配置。这点在我经手的源码里出现频率很高，提前处理好能省很多麻烦。

5. 我在这个项目里踩过的坑：版本、依赖、端口、路径

5.1 springboot 版本太高引发的连环问题

我不止一次提醒过版本问题，因为它真的太常见了。有次帮同学调一个宿舍管理系统，他电脑装的是JDK 17，源码用的是 Spring Boot 2.5，启动时报了一堆莫名奇妙的警告，代码能跑但控制台惨不忍睹。还有一次更离谱，他为了“追新”把项目强行升到 Spring Boot 3.2，结果原来是javax.annotation.PostConstruct的注解全部消失，各种依赖报红。最后全团队折腾两天才把版本回滚。

这里放一个版本匹配参考表，是我实际跑通过的组合：

拿到源码第一步就是核对这张表。版本匹配，项目就成功了一半。

5.2 Maven 依赖冲突与下载慢

Maven 依赖冲突的典型表现是：编译通过，一运行就NoClassDefFoundError或ClassNotFoundException。遇到这种问题，别瞎猜，直接用命令看依赖树：

mvn dependency:tree

重点看有没有同一个类出现在多个不同版本的jar里。最常见的冲突源是fastjson和jackson同时存在，或者commons-io版本不一致。解决办法也很直接：在pom.xml的依赖中排除冲突版本，或统一用父工程管理的版本号。

下载慢的问题国内很常见。在 Maven 的settings.xml里配置阿里云镜像，速度能从“装一天”变成“十分钟”：

<mirror> <id>aliyunmaven</id> <mirrorOf>*</mirrorOf> <url>https://maven.aliyun.com/repository/public</url> </mirror>

5.3 前端静态资源 404 与端口配置

前端页面能打开，但接口请求全挂在404或跨域上，这是毕设现场最常见的翻车点。根源基本出在“路径不统一”。开发时前端8081、后端8080，跨域靠代理；部署时静态文件又进了后端，代理配置反而失效。

我的建议是：开发环境和部署环境用同一套相对路径。开发时 vue.config.js 里配代理，把/api转发到http://localhost:8080；部署时静态文件由Spring Boot托管，前端请求相对路径/api，后端接口天然同源。这样一来，打包前后不需要改前端任何代码。如果还是出现404，先检查dist复制的位置对不对，static目录要在src/main/resources下，不是项目根目录。

5.4 时间字段与 JSON 返回格式的坑

这个坑隐蔽但一定会踩：后端用的是LocalDateTime，默认序列化后可能是"2025-01-01T12:00:00"这种带T的格式，甚至在某些版本下直接变成数组。前端一看时间显示就直呼“坏了”。

解决方法有两种，推荐第二种。第一，在实体类时间字段上加注解：

@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss") private LocalDateTime createTime;

第二，在application.yml里全局配置LocalDateTime的格式，用spring.jackson相关配置虽然对java.util.Date直接生效，但对LocalDateTime需要配合 JavaTimeModule，最简单稳妥的做法还是字段注解。另外，数据库查询时也确认jdbc:mysql连接串带了serverTimezone=Asia/Shanghai，否则可能出现“数据库时间比本地慢了8小时”的灵异现象。

6. 答辩被问到的高频问题与三个可落地的扩展方向

6.1 答辩前必须想清楚的五个问题

答辩时老师未必会把你写的每个功能都过一遍，但一定会挑几个“为什么这么设计”来问。下面这五个问题是宿舍管理系统里的高频考题，提前想清楚，答起来会很顺。

问题一：为什么选择 Spring Boot？答：Spring Boot 提供了起步依赖和自动装配，能快速搭建独立运行的Web服务；内嵌Tomcat让部署变成“一个jar包”，简化了传统SSM繁琐的配置流程。

问题二：为什么用 MyBatis 而不是 JPA？答：宿舍管理涉及多表查询、统计SQL，MyBatis 可以精确控制SQL，排查性能问题和调试更直观，而且和 MySQL 配合成熟，学习曲线也比较平滑。

问题三：权限控制是怎么做的？答：登录后用户信息存入 Session，通过拦截器对/admin/**、/manager/**、/student/**等路径做登录校验和角色校验，未登录或越权访问会被拦截并跳回登录页。

问题四：宿舍分配如何避免超员？答：宿舍表维护了bed_count和used_beds字段，分配前先校验used_beds < bed_count，分配和床位更新放在同一个事务里，保证数据一致性；同时还会校验学生是否已有宿舍，防止重复分配。

问题五：报修状态是怎么流转的？答：报修单使用状态字段标记“待处理、处理中、已完成”，每次状态变更都要记录处理人和处理时间，形成一个完整闭环。

这五个问题能答顺，答辩基本稳了。

6.2 扩展方向：Redis缓存 / JWT登录 / 文件上传 / WebSocket

如果想把项目做出亮点，不必堆功能，选一个方向做透就够。下面四个扩展方向都是基于Spring Boot生态的常见操作，热搜里提到的 MinIO、JWT 也都在里面。

方向一：Redis缓存热点数据。宿舍余位、公告列表这类“读多写少”的数据，可以缓存到Redis，减少MySQL压力。实现就是在Service层查数据前先查缓存，没有再查库并回填，或者直接用@Cacheable注解。

方向二：JWT替换Session。改造登录接口，登录成功后返回一个token，前端存到localStorage，后续请求在Header里带token，后端通过拦截器解析token得到用户信息。这样系统就彻底从“有状态”变成“无状态”，更适合前后端分离。

方向三：MinIO对象存储。报修图片、学生头像别往本地磁盘塞，接一个MinIO服务更规范。核心三步：加minioJava SDK依赖；配置 endpoint、accessKey、secretKey、bucket；Controller接收MultipartFile后调用上传方法，返回文件访问URL。热搜里“minio加入到springboot”指的就是这件事，加完之后数据库里只存图片路径，不存二进制。

方向四：WebSocket实时提醒。学生提交报修后，宿管端页面可以实时弹出新报修提醒。实现方式是后端起一个/ws的 WebSocket 端点，前端订阅并重绘列表，代码不多但演示效果很抢眼。

6.3 给后来者的几个实操建议

最后说几句掏心窝子的话。第一，拿到源码25537这类工程后，先跑通，再看代码，别倒过来。项目能跑起来，你的信心就建立了一半。第二，把数据库脚本和测试数据当成一等公民对待，每次改表都重新跑一遍脚本，造几组典型数据，比如满员的宿舍、待处理的报修单，这样演示时才不会临场造数据。第三，写一个README，把启动步骤、账号密码、核心功能入口写清楚，答辩前照着自己写的README完整走一遍流程。第四，不要追求功能多，追求一个功能做得深。比如只做报修模块，但把图片上传、状态流转、历史记录、楼栋筛选全部做完整，老师会觉得你真的理解了业务。

我个人的体会是，宿舍管理系统最大的价值不在于技术多难，而在于它逼着你把“数据表设计、角色权限、状态流转、系统部署”这一整条链路走通。这些能力在你今后的开发工作里是每天都要用的。把它认真做完，答辩不仅不会慌，甚至还能成为你简历上第一个拿得出手的完整项目。