简介：本资源是一套面向计算机专业本科生的毕业设计与课程实践项目——基于SSM（Spring+SpringMVC+MyBatis）框架开发的高校宿舍管理系统，聚焦校园信息化管理痛点，解决宿舍分配、费用收缴、报修响应、访客登记等核心业务场景，适合作为期末大作业、课程设计或初级Java全栈开发学习载体。压缩包共1050个文件，含144个Java后端逻辑类、61个JSP前端页面、242个JS交互脚本、125个CSS样式文件及2个SQL建库脚本（含完整表结构与初始化数据），辅以论文.doc、说明文档.txt和汇报PPT，覆盖开发、部署、演示全流程；包体大小为12.96MB。已有43人下载学习，提供开箱即用的可运行工程，含模块化分层代码结构、响应式前端界面与清晰注释，便于理解MVC架构落地细节、数据库事务处理及前后端协同逻辑。 做宿舍管理系统这个题目，前前后后我接过不下十次。从学生时代自己做课设，到后来带团队给一些高校做后勤信息化改造，SSM这套组合拳打下来，算是把宿舍管理的那些弯弯绕绕摸了个透。今天借着"基于SSM的高校宿舍管理系统设计"这个项目，把从架构设计到实际编码、再到前后端联调和问题排查的完整链路，一次性讲清楚。
如果你正准备做类似课题，或者手里已经有一个半成品的SSM项目正在调试，这篇文章会比较适合你。我会把项目里最容易踩坑的几个地方——比如宿舍分配的逻辑设计、多条件查询的SQL写法、拦截器放行规则、以及Vue3对接SSM时的跨域和Session问题——全部摊开来说。
1. 项目概述：SSM宿舍管理系统到底在解决什么问题
1.1 宿舍管理业务的真实痛点
很多人一听到"宿舍管理系统"就下意识觉得，这不就是个增删改查吗？把学生信息导进去，分个房间，完事了。真做过这个项目才发现，宿舍管理远没有表面上那么简单。
先说一个很容易被忽略的典型场景：新生入学季，几百上千个学生需要在几天内完成入住登记。如果靠宿管阿姨拿个Excel表手动安排，会出现什么情况？房间重复分配、楼层人数严重不均、有人分配到已经损坏无法入住的床位、退宿信息没有及时更新导致空床位统计失真。任何一个问题在开学高峰期都会被放大成投诉事件。
所以做宿舍管理系统，第一要务不是"实现某个功能"，而是把"宿舍资源"这一个核心概念管理好。什么叫资源管理？就是你能随时回答这些问题：当前哪栋楼哪个房间还有空床位？空床位的具体位置是哪里？已经入住的学生的住宿信息是谁、什么时候登记、什么时候变更的？除了住宿安排，日常的报修、来访登记、卫生评比要不要纳入系统，也决定了系统的复杂程度。
我这个项目里做的，是一个覆盖学生端、宿管端、管理员端三个角色的完整闭环。学生可以在线查看自己的住宿信息、提交报修申请、查询电费余额；宿管可以管理管辖楼栋的入住情况、处理报修、登记来访；超级管理员负责系统全局配置，包括楼栋房间的维护、宿管账号的分配、基础数据的导入导出。这一套做完，才算真正把宿舍管理的日常业务给接住了。
1.2 SSM技术选型的理由
SSM指的是Spring + SpringMVC + MyBatis这三个框架的组合，在Java Web领域算是一套非常经典的技术栈。虽然现在Spring Boot已经很普及，但SSM作为校招笔试、课程设计、毕业设计的高频考点，依然有大量项目在使用，原因很实际。
第一，Spring的IoC和AOP机制把对象的创建和管理统一接管了。你做业务代码的时候不需要再到处new对象，哪个Service需要用到哪个Mapper，声明一下就注入进来，代码的可维护性一下子提升很多。第二，SpringMVC的请求处理链路很清晰，从前端发来的请求经过DispatcherServlet分发到对应的Controller方法，参数绑定、JSON返回这些操作都有现成的注解，写起来效率很高。第三，MyBatis把SQL语句和Java代码分离，搞复杂查询的时候，直接写SQL比操作JPA那种全自动ORM要灵活得多。
还有一个很现实的原因是学习成本。这套技术栈的组成部分都是模块化的，每一步都有非常成熟的文档和案例，哪怕是初学者照着经典教程一步步搭也能跑起来。对于课程设计或者毕业设计这种需要从零写一个完整系统的场景，SSM的稳定性和社区的丰富程度，都决定了它是一个不会出错的稳妥选择。
2. 系统整体架构与功能模块拆解
2.1 前后端模块划分
拿到项目需求之后，我习惯先把整个系统按"使用对象"和"业务场景"两个维度做一个功能清单，再根据清单去拆模块。宿舍管理系统从使用对象维度来看，无非是学生、宿管、系统管理员这三种角色，而从业务场景维度来看，可以拆成六大核心模块。
基础信息管理这个模块是用来维护宿舍楼的楼栋信息、房间信息、床位信息。比如一栋宿舍楼有六层，每层二十个房间，每个房间住四个人，这些信息就是整个系统的地基。然后是学生信息管理模块，用于维护学生的基本信息，包括学号、姓名、学院、专业、联系方式，以及和他的住宿信息之间的绑定关系。住宿管理是核心模块，实际涉及入住登记、退宿登记、调宿申请和审批这些操作。报修管理覆盖学生提交报修单、宿管派单处理、维修完成确认这一整条链路。来访登记模块用来记录外来人员的进出情况，用于安全追溯。最后是系统管理模块，负责用户账号维护、角色权限管理、操作日志记录。
一个值得强调的经验是：功能模块的划分不要直接对应数据库的表，而是要对应"业务动作"。比如入住登记这个动作，会同时影响到学生信息表、床位状态表、入住记录表三张表的数据，如果你只说它是一个"增删改查"功能，写代码的时候就很容易漏掉数据一致性的处理。
2.2 角色权限的设计思路
权限控制是管理系统绕不开的话题，宿舍管理系统虽然业务不复杂，但三种角色的数据权限边界必须划分清楚。
我的做法是采用基于SpringMVC拦截器配合Session做简单的角色校验。具体来说就是：登录成功之后，把当前用户的信息和角色编码存到Session里面，然后定义一个拦截器，在请求到达Controller之前检查当前请求的URL前缀和用户角色是否匹配。比如以 /admin/ 开头的接口只允许管理员访问，以 /dorm/ 开头的接口只允许宿管访问，以 /stu/ 开头的接口只允许学生访问。
如果请求路径对应的权限和当前用户的角色不匹配，直接拦截并返回一个提示页面或者JSON错误信息。这里有一个比较容易踩坑的地方，就是登录接口本身、静态资源路径、以及一些公共的查询接口，必须在拦截器配置里明确排除掉，否则就会出现"页面样式丢了"或"还没登录就跳转登录页死循环"这种诡异问题。
Session这一块在使用前后端分离部署的时要特别小心，因为你把前端页面托管到Nginx、后端跑在Tomcat上，这俩是不同的域名或端口，浏览器会拦住跨域的Cookie写入，导致Session一直获取不到。后面我会专门讲一下这个问题的解决方案。
3. 数据库设计：宿舍管理系统的地基
3.1 核心表结构设计
数据库设计做得好不好，直接决定了后面写SQL的时候是享受还是折磨。宿舍管理系统的核心表我一般会设计七个：用户表、学生信息表、宿舍楼表、房间表、床位表、入住记录表、报修表，另外加上一个操作日志表用于记录关键操作。
用户表主要保存登录账号信息，字段包括用户ID、用户名、密码（注意存储的是加密后的密文）、角色编码。学生信息表则保存学生的详细资料，学号作为唯一键，同时关联用户ID。这里有一个设计上的细节：不要把学生的所有字段堆在用户表里面，因为不是所有用户都是学生，宿管和管理员没有学号、学院这些属性，拆开建表更符合关系数据库的范式。
宿舍楼表和房间表是一对多的关系，宿舍楼表记录楼栋编号、名称、楼层数，房间表则记录所属楼栋、房间号、房间类型、容纳人数、已住人数、房间状态。房间状态我记得做了三个取值：正常、维修中、已停用。为什么要单独做状态而不是只在查询的时候过滤？因为维修中的房间不能安排新入住，但是已经住着的人不需要搬出来，这种状态用布尔字段是表达不清楚的。
床位表是很多人会忽略的一张表。有些设计图省事，房间表里直接用一个"已住人数"字段控制是否住满，不单独建床位表。这种做法在简单查询的时候确实快，但一旦遇到调宿、退宿这种要求精确到"哪一个床位空出来"的场景就麻烦了。所以我还是建议单独建一张床位表，字段包括床位ID、所属房间ID、床位编号、床位状态。
入住记录表是整个系统里最重要的流水表。字段包括记录ID、学生ID、房间ID、床位ID、入住时间、退宿时间、入住类型。为什么要保留这个表？因为它让系统具备了追溯能力。比如查某个房间曾经住过哪些人、某学生大一住哪个寝室大二有没有换过寝室，这些历史信息对辅导员做管理非常有价值。
报修表字段就比较直观了：报修单号、报修人ID、房间ID、报修类型、报修描述、提交时间、处理状态、处理人ID、处理时间、处理备注。报修类型我会做成一个字典值，比如水电、门窗、网络、家具，这样后续如果要按类型统计维修频次，一条SQL就能出来。
3.2 关键SQL的设计思路
表设计好了以后，我建议先把最难的那几条查询SQL写出来，因为它们决定了很多功能能不能实现。
第一个是"可用床位查询"，用于入住登记时展示当前哪些房间还有空床。这条SQL需要关联宿舍楼表、房间表、床位表，过滤条件是两个：房间状态为正常，床位状态为空闲。实际写出来大概是这个意思：先在床位表里按房间ID分组统计空闲数量大于0的房间，再去关联查询房间和楼栋信息。
第二个是"入住信息联查"，学生端要展示的是"我住在哪个楼栋、哪个房间、哪个床位"，这条SQL关联用户表、学生信息表、入住记录表、房间表、楼栋表五张表。注意入住记录要加上"退宿时间为空"这个条件，否则查出来的可能是学生历史住过的寝室而不是当前寝室。
第三个是"宿舍空置率统计"，用于管理员端看板展示。按楼栋分组，统计房间总数、已住人数、总床位数、空闲床位数。这种统计数据其实是面向展示的，如果每次刷新页面都实时去查，数据量大了以后性能会明显下降。我的建议是加一个定时任务，每天凌晨跑一次统计，把结果存入一张报表缓存表，页面直接查缓存表即可。
4. SSM框架集成与核心功能实现
4.1 搭建SSM开发环境
SSM项目搭建，说简单也简单，说复杂也复杂。简单是因为步骤固定，复杂是因为框架版本冲突的问题能让人排查到崩溃。我把自己实际用的一套稳定版本组合列出来供参考：Spring使用的是5.x版本，SpringMVC跟随Spring版本走，MyBatis用的是3.5.x，MyBatis-Spring适配包用2.0.x，数据库连接池用Druid，数据库用MySQL 5.7或者8.0都可以。
搭建步骤就是标准流程：创建一个Maven Web项目，在pom.xml里引入相关依赖，配置web.xml加载Spring容器和SpringMVC的DispatcherServlet，然后编写Spring的applicationContext.xml配置数据源、事务管理、MyBatis的SqlSessionFactory和Mapper扫描，再编写SpringMVC的配置文件开启注解驱动、配置视图解析器和静态资源映射。
这里有一个很多新手会翻车的点：Spring容器和SpringMVC容器的关系搞不清。SpringMVC的配置文件里如果扫描了Service或者Mapper的注解，就会导致事务失效、Bean重复创建等问题。我的习惯是SpringMVC的配置只管Controller的扫描，Service、Mapper、数据源这些都留给Spring的配置文件去扫描。这样做的好处是容器职责分明，排错的时候很省心。
4.2 登录与权限拦截的代码实现
登录功能是每个系统的门面，也是踩坑重灾区。我在这个项目里采用的是比较传统的Session方案，流程是这样的：用户在登录页面输入用户名和密码，前端把表单数据Post提交到登录接口，后端根据用户名查出用户记录，把数据库里存的密码（MD5加盐之后的密文）和用户输入的密码加密结果做对比，匹配则登录成功，把用户信息存入Session然后跳转到对应角色的首页。
密码加密这一块，尽量不要用明文。虽然这只是个课设项目，但养成良好的安全习惯很重要。MD5本身有彩虹表攻击的风险，加盐之后安全性会好很多。我会在用户注册或初始化密码的时候生成一个随机盐值，存储时保存salt和md5(password + salt)两个值，校验的时候用同样的规则再算一遍即可。
拦截器的实现我前面提到了，这里再说一下拦截器配置的细节。SpringMVC配置里用mvc:interceptors注册自定义拦截器，同时用mvc:exclude-mapping排除不需要拦截的路径。常见需要排除的路径有：登录接口、注册接口、静态资源如js和css文件、验证码接口。如果漏配了静态资源，你会发现自己辛辛苦苦写的页面样式全乱了，而且报错信息还不会直接告诉你原因。
一个小技巧：在拦截器的preHandle方法里，判断Session为空的时候不要立即重定向到登录页，而是先判断当前请求是不是AJAX请求（可以通过请求头X-Requested-With判断），如果是AJAX请求就返回一个401状态码，否则才重定向。这样做的好处是前后端分离后，前端能根据状态码统一跳转到登录页，而不是在页面里嵌入一段重定向的HTML。
4.3 宿舍分配与调宿换寝功能实现
宿舍分配是整个系统里业务逻辑最重的一个模块。新生入学的批量分配和单个学生的调整入住，这两种场景逻辑是不同的。
先看新生批量分配。基本流程是：根据新生的性别和学院信息，获取符合条件的楼栋列表，然后逐栋楼逐个房间查找空床位进行分配。分配时要考虑同学院学生尽量住在一起，这个需求光靠SQL不太好实现，所以我的做法是在Service层做分配逻辑，通过代码遍历优先安排同学院学生相对集中的楼层。每分配一个学生，就要对床位表执行一次状态更新，并且写入一条入住记录。为了保证批量分配中途不出现部分成功部分失败的情况，整个过程要加事务控制，任何一个环节抛异常就回滚。
再看单个调宿。学生发起调宿申请，填写目标楼栋或目标区域，等待管理员审批。管理员审批时可以查看当前目标区域的空床位列表，选择一个新的空闲床位完成分配，然后系统自动把原有床位状态改为空闲，新床位状态改为占用，并新增一条入住类型为"调宿"的入住记录。
宿管端还有一种常见操作是手工调整床位，比如某学生实际住的位置和系统记录不一致，宿管可以直接修改。我会建议在这种修改操作上额外记录操作日志，包括操作人、操作时间、修改前后数据的对比，方便日后追溯。
4.4 报修管理流程实现
报修模块虽然不复杂，但涉及状态流转。状态我设计了四个：待处理、处理中、已完成、已驳回。学生提交报修，状态为待处理；宿管接单并派给维修人员（在这个系统里可以简化为宿管自己处理），状态变为处理中；维修完成之后宿管在系统里标记完成，状态变为已完成。如果报修内容描述不清或者不在职责范围内，宿管可以驳回并填写驳回原因。
在报修的列表查询上有一个效率优化的点：学生端只查自己提交的报修，宿管端只查自己管辖楼栋的报修，管理员端可以查所有报修。这三类查询对应着不同的SQL过滤条件，如果写成三个Mapper方法分别查询，代码会冗余但可读性高。我的做法是写一个通用的分页查询方法，通过动态SQL根据传入的角色和用户ID拼接过滤条件，一个方法搞定三种场景。
5. Vue3连接SSM框架的前后端分离实践
5.1 接口设计与跨域处理方案
项目做完了基础功能之后，很多同学会问要不要把前端重写成Vue。我的建议是：如果是课设，保持原来的JSP或者HTML模板完全够用；如果是想提升项目含金量，或者你本身就在学Vue3，那可以尝试做一版前后端分离的改造。
前后端分离之后遇到的第一道坎就是跨域。后端接口跑在localhost:8080，前端开发服务器跑在localhost:5173，两边端口不同，浏览器就会触发同源策略限制。解决方案很标准：在后端加CORS配置。在SpringMVC里可以通过实现WebMvcConfigurer接口的addCorsMappings方法，对所有接口开放跨域访问，指定允许的来源、方法、请求头。要注意的是allowCredentials要设置为true，这样前端请求才能携带Cookie，Session才能维持。
Session共享的问题前面也提到了，前端开发时需要配置代理把请求转发到后端。Vite的配置文件里可以配置server.proxy，将 /api 前缀的请求转发到 http://localhost:8080 。这样在浏览器里看请求是同源的，规避了Cookie跨域的限制，后端代码几乎不用改动。
5.2 Vue3前端接口调用封装
Vue3里调用后端接口，主流方案是Axios。我会在src目录下建一个request工具模块，创建一个axios实例，设置baseURL为 /api，然后添加请求拦截器和响应拦截器。请求拦截器里可以做Session超时前的处理，比如从localStorage读取token并附加到请求头上；响应拦截器里统一处理后端返回的状态码，如果返回401就直接跳转到登录页。
后端接口返回的数据格式一定要约定一致。我在这个项目里统一返回一个Result对象，包含code、message、data三个字段。code为200表示成功，其他值表示各种错误。前端响应拦截器判断code的值，不为200就弹出一条错误提示。这样写的好处是前端处理逻辑统一，不需要每个页面单独判断返回值状态。
后端Controller的写法要注意结合SpringMVC的注解。Controller方法上使用@ResponseBody或者类上使用@RestController，返回的Java对象会自动被Jackson序列化成JSON。这里经常遇到的一个问题是日期字段的格式化，Java返回的Date类型默认序列化出来是一串时间戳，前端不太好处理。解决办法是在日期字段上使用@JsonFormat注解，指定pattern为"yyyy-MM-dd HH:mm:ss"，这样前端拿到的就是标准字符串格式。
6. 项目运行调试与常见问题排查实录
6.1 SSM项目常见运行问题汇总
做SSM项目的过程中，有几个经典报错几乎每个开发者都会遇到，我把它们的排查思路整理出来方便你对照处理。
第一个是启动Tomcat时报ClassNotFoundException或者NoClassDefFoundError。这种问题九成是Maven依赖冲突或者依赖没有打包到WEB-INF/lib目录。排查思路是先看pom.xml里有没有重复引入不同版本的同一个库，比如Spring的多个模块版本不一致；再看IDEA里项目的Artifacts配置，确认"Build on make"和"Include in project build"是否勾选。还有一个比较隐蔽的问题是本地仓库里的jar包损坏，这个可以通过删除.m2目录下对应文件夹后重新构建来解决。
第二个是访问页面报404，但是控制台没有任何异常。优先检查SpringMVC的注解扫描路径是否覆盖了Controller类所在的包，再检查前端请求的URL和Controller的RequestMapping值是否完全一致。这里要注意SpringMVC的路径匹配是精确的，比如 @RequestMapping("/student/list") 必须通过 /student/list 访问，末尾多了斜杠都不行。
第三个是MyBatis执行SQL报BindingException，提示Invalid bound statement。这个问题的根因是Mapper接口和Mapper XML文件没有正确绑定。检查三件事：XML文件的namespace是否是接口的全限定名；接口方法名和XML中statement的id是否一致；applicationContext.xml中MapperScannerConfigurer的basePackage是否指向了Mapper接口所在的包。还有一个常见疏漏：XML文件放在resources目录下没问题，但如果你放在了java目录下，Maven默认不会把它打包到classes，需要在pom.xml里加resource配置把xml文件包含进来。
第四个是数据库连接相关的CommunicationsException或者Connection refused。检查数据库服务是否启动、连接URL里的IP和端口是否正确、账号密码是否有权限访问目标库。Druid连接池配置时还要注意驱动类名和URL的对应关系，MySQL 8.0需要加上时区参数serverTimezone=Asia/Shanghai，否则报时区错误。
6.2 项目性能与安全性的进阶建议
如果这个项目不只是为了交差，而是想真正完善成一个"像样的系统"，站在面试官或者评审老师角度，有几个点是值得花时间打磨的。
性能方面，列表页的分页查询必须做好。MyBatis分页建议使用PageHelper插件，起来非常方便。但要注意PageHelper使用时一定要在紧跟着的查询语句之前调用PageHelper.startPage方法，中间不能插入其他SQL操作，否则分页就会失效。另外，如果某个页面要展示的关联数据比较多，尽量用一条联表SQL而不是在Java代码里循环查询，原因很简单：一次数据库往返的开销远大于SQL本身的计算开销。
安全性方面，除了前面说的密码加密存储之外，还要做到SQL注入防护。MyBatis的#{}预编译机制本身就防御了SQL注入，但如果你图省事在SQL里用了${}拼接，就会把注入风险带进来。我的建议是：所有用户传入的参数一律使用#{}，如果需要动态排序字段，可以通过白名单校验后再拼接。XSS攻击的防护可以在前端做输入过滤，在后端可以引入一个过滤器对请求参数做转义处理。
还有一个很容易被忽略的点：文件上传功能。如果系统里涉及学生头像上传、报修图片上传，一定要限制上传文件类型和大小，上传目录不要放在Web应用的根目录下，最好用UUID重命名文件并单独存储，防止路径穿越和恶意文件上传。
让我最后再多说一句关于答辩或者演示时的准备心得。代码能跑通只是基本要求，真正拉开差距的是你对项目细节的理解深度。面试官问"宿舍满了怎么办""并发入住会不会超分""调宿如何保证数据一致性"这些问题时，你能不能说清楚背后的逻辑，这才体现你是否真的懂这个项目。所以做项目不要急着写代码，先把数据流和业务边界理清楚，后面所有的代码都是水到渠成的事情。
本文还有配套的精品资源，点击获取
