伊凹遥1. 项目核心需求与功能拆解
1.1 宿舍管理系统到底在管什么
先说结论：学生宿舍信息系统，本质上是一个围绕“人-房-事”三条主线展开的业务管理系统。人，指的是学生、宿管员、辅导员这三类角色；房，就是楼栋、楼层、房间、床位这四级物理资源；事，则包括入住分配、调宿退宿、报修登记、卫生检查、晚归记录、访客登记这一大串日常事务。
很多同学拿到这类题目第一反应是“不就是对学生表做增删改查吗”，这个理解会直接导致设计阶段就跑偏。你仔细想一下：光是一个“学生入住”动作，背后就要联动宿舍楼的剩余床位、房间的当前入住人数、学生的学籍状态、入住记录的历史留存，至少涉及四张表的写操作。如果一开始没把这些关系理清楚，代码写到最后一定是一团乱麻。
所以我在动手前习惯先画一张业务流程图，把每个角色的操作路径标出来。比如学生端能做什么：查看自己分配的宿舍、提交报修申请、填写晚归登记。宿管端能做什么：分配房间、处理报修、录入卫生检查分数、登记访客。辅导员端能做什么：查看所带学生的住宿情况、导出统计报表。把这些角色权限和对应操作列清楚，数据库表的设计其实就自然浮出水面了。
1.2 功能模块与技术选型怎么对齐
这个项目的标准功能模块划分一般是这样的：
管理系统侧（后台管理端）的核心模块包括：学生信息管理（学号、姓名、院系、班级、联系方式）、宿舍楼栋管理（楼栋名称、楼层数、房间总数、宿管联系方式）、房间床位管理（房间号、可住人数、已住人数、床位列表）、入住分配管理（按照院系或班级进行分配、手动调整）、调宿退宿审批、报修工单管理（报修人、报修内容、处理状态、处理结果）、卫生检查评分（检查日期、评分项、总分、备注）、晚归记录登记、公告通知发布。
用户侧（学生端）的模块则精简很多：个人信息查看、我的宿舍信息、提交报修申请、查看报修处理进度、公告浏览。
针对这套业务，技术选型上我推荐的是经典组合，也就是标题里这套：SpringBoot + Vue + MyBatis + MySQL。很多人纠结要不要换成Redis做缓存、要不要上RabbitMQ做消息队列，我建议是没必要。宿舍管理系统的并发量属于典型的校园内部系统级别，峰值也就是几百人同时在线，关系型数据库完全扛得住。把核心业务逻辑写清楚、把表结构设计合理，远比堆砌中间件有意义。你要是真觉得想加亮点，可以加一个EasyExcel做学生信息的批量导入导出，这个在答辩时候是非常好讲的加分项。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术选型与版本坑位盘点
2.1 SpringBoot版本选择与JDK兼容
热词里有“springboot版本太高”这条，这绝对是新手最容易踩的深坑。SpringBoot 3.x是2022年底发布的，它有一个硬性要求：必须搭配JDK 17及以上版本。但很多学校机房或者你自己电脑上装的是JDK 8，这时候如果你直接去start.spring.io生成一个默认版本的项目，大概率就是SpringBoot 3.2.x，然后本地编译直接报错，因为你根本没有JDK 17。
我的建议是稳妥优先：用SpringBoot 2.7.x版本。这是2.x系列的最后一个稳定分支，官方维护周期长，社区资料最丰富，网上搜到的教程绝大多数都基于这个版本系列。具体来说，我用的是2.7.18，搭配JDK 8，这个组合在当前阶段是最稳的，不需要额外装新环境，遇到问题也好查解决方案。
另外，版本选择还牵扯到依赖兼容问题。比如你用了SpringBoot 3.x，那MyBatis的starter也得用专门适配新版的那条坐标线，MyBatis-Spring-Boot-Starter的3.0版本才是适配SpringBoot 3的。很多同学版本不匹配，启动直接报错，第一反应是自己代码问题，其实根因是starter版本不对。你到Maven仓库拉依赖的时候，一定要看清楚依赖说明里写的适配范围，不要无脑选最新版。
2.2 MyBatis和MyBatis-Plus到底选哪个
这是很多准备动手的人卡住的地方。我直接给结论：如果这个项目是你用来学习底层原理的，用纯MyBatis，写XML映射文件的过程能帮你彻底理解SQL和Java对象之间的映射关系；如果这个项目你更看重开发效率和答辩演示效果，用MyBatis-Plus，单表CRUD真的可以不用写SQL。
我个人在宿舍系统这个项目里推荐MyBatis-Plus，理由很简单：这个系统的单表操作占比极高，比如学生信息的增删改查、公告的增删改查、房间信息的更新，如果用纯MyBatis写，你光处理这些基础CRUD就得写两百多行XML。用MyBatis-Plus的BaseMapper，这些全部内置了，开发效率提升不是一点半点。
但是请注意，MyBatis-Plus也有它自己的坑。热词里那条“mybatis plus 查询 禁用逻辑删除”就是典型。MP默认的逻辑删除机制是在配置了@TableLogic注解后，所有查询会自动拼接上deleted = 0条件。但有些场景你确实需要查出来已经被逻辑删除的数据，比如管理员要恢复一条误删的学生记录。这时候直接用MP自带的selectList是查不出来的，你得自己写SQL，或者在配置里临时关闭逻辑删除。解决办法是写一个自定义Mapper方法，SQL里手动忽略逻辑删除字段。这个点虽然不起眼，但你在答辩时候能说出来，绝对是加分项。
2.3 Vue环境配置与脚手架搭建
前端部分，我建议用Vue 2 + Element UI的组合。我知道2025年Vue 3已经是主流，但这里我要说句实在话：Element UI的组件丰富度和稳定性在管理后台场景下依然很能打，而且Vue 2的教程铺天盖地，遇到问题好查。如果你对Vue 3的Composition API很熟，用Element Plus也没问题，但新手我不建议一边学项目一边学新语法，容易两头顾不上。
环境配置这里有个前置条件：Node.js版本。Vue 2的脚手架Vue CLI对Node版本有要求，实测Node 16以下是安全的，Node 18以上有些旧版本CLI会报错。我的建议是装Node 14.21.3或16.20.2，然后用npm配置淘宝镜像源来加速依赖安装。指令很简单：npm config set registry https://registry.npmmirror.com。装完镜像源，执行npm install -g @vue/cli，然后vue create dormitory-web就能生成前端工程了。
3. 核心模块的落地实现
3.1 数据库表结构设计的先后顺序
表结构设计是整个项目的地基，这个阶段偷懒后面一定返工。我按照业务依赖顺序给你排一下设计优先级：
第一优先级是基础数据表：学生表、宿舍楼表、房间表。学生表的核心字段包括学号（建议设为唯一索引）、姓名、性别、院系、专业、班级、手机号、身份证号（加密存储）、入住状态。房间表的核心字段包括房间编号、所属楼栋ID、楼层、朝向、可住人数、已住人数、备注。注意，房间表里存一个“已住人数”，这个字段看似冗余，但它在宿舍分配时的作用非常大——你要查某个楼栋还有多少个空床位，直接SUM(可住人数 - 已住人数)聚合一下就行，不必每次都做多表关联。
第二优先级是关联业务表：入住记录表、报修表、卫生检查表、晚归记录表。入住记录表记录每个学生从入住到退宿的完整生命周期，字段包括记录ID、学生ID、房间ID、入住时间、退宿时间、入住状态。这里的关键是把退宿时间设计成可空的，方便统计当前在住人数。
第三优先级是辅助表：公告表、访客登记表、系统用户表。系统用户表不需要太复杂，字段有ID、用户名、密码（BCrypt加密）、角色（学生/宿管/辅导员）。
这张顺序表的作用是：建表的时候按依赖关系来建，先建没有外键依赖的表，再建有外键依赖的表。MySQL里虽然不一定强制启用外键约束（很多生产环境反而禁用外键），但逻辑上的关联关系必须通过字段设计体现出来。
3.2 登录认证与权限控制怎么落地
登录模块是答辩必问的点，这里我建议用JWT，而不是Session。JWT的核心思路是：用户登录成功后，后端生成一个签名字符串返回给前端，前端存在本地（localStorage或pinia/vuex里），之后每次请求都把这个token放在请求头的Authorization字段里，后端通过拦截器解析token来识别用户身份。
代码实现上分为三步。第一步是生成token的工具类，用io.jsonwebtoken库，设置过期时间一般定为2小时，超过2小时前端会收到401状态码，然后引导用户重新登录。第二步是写一个拦截器，继承HandlerInterceptor，在preHandle方法里从请求头取token并解析，解析失败直接返回401。第三步是在SpringBoot的配置类里注册这个拦截器，并设置放行路径（比如登录接口、静态资源），其余路径全部拦截。
这里有个细节要提醒：前端开发模式下，跨域请求会先发送一个OPTIONS预检请求，这个预检请求不带token，如果你的拦截器把所有请求都拦了，前端会一直报跨域错误。解决办法是拦截器里判断，如果是OPTIONS请求直接放行，或者在后端CORS配置里设置allowCredentials(true)配合allowedOriginPatterns("*")。
3.3 宿舍分配的三种策略与实现逻辑
宿舍分配是这个系统的业务核心，也是答辩时候最能体现设计能力的地方。我总结了三种分配策略，你可以按需选择：
第一种是按院系分配法。入学的时候，新生数据按照院系分类，然后按照院系内学生的学号顺序，依次扫描房间表，找到同性别、同院系且未满员的房间进行分配。这种方案实现简单，但容易造成某个院系的学生全挤在一层楼。
第二种是随机分配法。把所有空床位汇总到一个列表里，然后循环遍历学生列表，每次取随机数来分配床位。这种方案能避免新生扎堆，但会带来一个管理问题：学生之间完全不认识，班委通知不好传达。
第三种是按班级连续分配法。这也是我更推荐的方式。核心逻辑是：先查出某院系下的所有班级，再查出该班级的人数，然后根据班级人数计算出需要几个相邻的房间，优先分配同楼层的连续房间。这种方案兼顾了归属感和集中管理，实际操作中也是宿管最喜欢的模式。
在技术实现上，我建议把分配算法单独封装成一个服务类，不要写在Controller或者Mapper里。接口设计上，入参是一个包含院系、性别、人数等条件的请求对象，出参是分配结果列表。分配过程中要注意事务控制：先查询可用房间列表并加行锁（SELECT FOR UPDATE），然后逐条更新房间已住人数，再插入入住记录表。如果中间任何一步失败，事务回滚，避免出现房间人数和实际记录不一致的数据错乱。
3.4 报修流程状态机设计
报修模块虽然简单，但把状态流转设计清晰了，代码会好写很多。我把报修单的状态定义为四态：待受理、处理中、已完成、已关闭。流转规则是：学生提交报修后状态为待受理；宿管认领并开始处理则变为处理中；处理完成由宿管标记为已完成；已关闭则是超过一定时间未处理自动触发，或者管理员手动操作。
数据库层面，报修表的核心字段包括报修ID、学生ID、房间ID、报修类别（水电/门窗/网络等）、问题描述、图片附件URL、状态、提交时间、受理时间、完成时间、处理备注。这里我给每个状态变更节点都配上对应的时间字段，方便后期做服务响应时长的统计。
前端实现上，学生端报修提交页面至少包含三个字段的填写：报修类别选择、问题描述输入、图片上传。图片上传我建议直接用后端接口接收MultipartFile，存储到本地磁盘的一个upload目录，然后把文件访问路径存到数据库。这种方式不需要额外引入OSS服务，部署答辩演示完全够用。注意上传文件大小要在SpringBoot配置里做限制，默认1MB的上限经常不够用，我一般设置为10MB，并且对上传文件做类型白名单校验。
4. 前后端联调与跨域问题实战
4.1 开发环境的跨域配置
前后端分离项目，联调阶段第一关就是跨域。开发环境下前端跑在8080端口，后端跑在8081端口（我习惯把后端端口改成8081，避免和其他本地项目冲突），浏览器会拦截前端发出的跨域请求，这时候必须在前端或后端做跨域处理。
我的做法是后端统一处理。定义一个CorsConfig类，实现WebMvcConfigurer，重写addCorsMappings方法，配置允许的来源、请求头和方法。配置代码很简短，核心就几行：
java复制@Configuration
public class CorsConfig implements WebMvcConfigurer {
@Override
public void addCorsMappings(CorsRegistry registry) {
registry.addMapping("/**")
.allowedOriginPatterns("*")
.allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
.allowedHeaders("*")
.allowCredentials(true)
.maxAge(3600);
}
}
注意allowedOriginPatterns("*")和allowedOrigins("*")的区别。当前端开启了withCredentials（携带cookie凭证）时，allowedOrigins("*")会被浏览器拒绝，必须用Pattern形式。虽然我们用的JWT不依赖cookie，但统一写成Pattern更省心。
4.2 前端请求封装与接口规范
联调阶段浪费时间的另一大元凶是接口路径或者参数名对不上。我建议在项目一开始就约定好接口返回的统一格式。我的做法是定义一个Result对象，包含code、message、data三个字段。code为200表示成功，500表示业务异常，401表示未认证。后端所有接口统一返回Result对象，前端通过axios的响应拦截器统一处理。
前端请求封装上，我在src/utils/request.js里创建一个axios实例，设置baseURL为/api，同时设置拦截器：请求拦截器从localStorage里取token并加到请求头，响应拦截器判断返回值里的code，如果不是200就弹出错误提示，如果是401就清理登录状态并跳转到登录页。
这里有个Vue CLI环境变量的小技巧：开发环境下，前端请求地址是http://localhost:8081/api，生产环境可能变成http://your-server-ip:8081/api。我建议在项目根目录创建.env.development和.env.production两个文件，分别定义不同的VUE_APP_BASE_URL变量，这样切换环境的时候不用改代码。
4.3 Vue路由与页面权限控制
前端路由的核心是把页面和URL对应起来，同时要考虑权限控制。我的做法是：在路由表里给每个页面配置meta字段，里面放一个roles数组，标明哪些角色可以访问这个页面。然后在路由的beforeEach守卫里做校验：判断当前用户角色是否在目标页面的roles列表里，如果不在，重定向到403页面。
具体页面设计上，我建议后台管理的页面结构是左侧菜单栏加右侧内容区。左侧菜单按照功能模块划分：仪表盘、学生管理、楼栋管理、房间管理、入住管理、报修管理、卫生检查、公告管理。每个菜单项对应一个路由。学生端的页面则简单很多，通常是首页（个人信息）、我的宿舍、维修申请、公告列表。
路由懒加载这个点值得提一下：如果所有页面组件都用静态import引入，打包出来一个chunk会有几百KB甚至上兆，首次加载时白屏时间很长。改成动态import的写法，按路由拆包，初次只加载当前页面需要的js文件，体验完全不一样。写法也很简单，把import StudentList from '../views/StudentList.vue'改成const StudentList = () => import('../views/StudentList.vue')即可。
5. 常见问题与排查技巧实录
5.1 MyBatis动态SQL的坑：if标签判空与字符串比较
热词里“mybatis if test indexof”这条，背后其实是一个经典坑：在if test里做字符串比较时，单引号和双引号的语义搞反了。MyBatis的OGNL表达式里，test="status == '1'"这种写法，外层用双引号、内层用单引号，这是正确的。如果你写成test='status == "1"'，很可能得到一个不可预料的解析结果。
还有更隐蔽的坑：当你的参数是一个Long类型，写test="studentId != null and studentId != ''"，这个判断本身没问题，但注意如果studentId是数字类型，不要加第二个判空条件，因为数字类型不会等于空字符串，加上了反而在某些版本里会走一个隐式类型转换导致SQL拼接异常。
另一个高频问题是<if test="name != null and name != ''">里变量名写错。MyBatis的OGNL是从参数对象的属性名去取值，如果你的实体类属性叫stuName，但是XML里写的是name，这里不会给你报错，只会静默地跳过条件，然后你查询结果不精确时排查半天，最后才发现是拼写不一致。这个问题的排查思路只有一个：把MyBatis的日志级别调到DEBUG，在控制台直接看最终生成的SQL长什么样。
5.2 MySQL 8.0安装配置与连接坑
热词里“mysql安装配置教程”和“mysql workbench使用教程”出现频率很高。MySQL 8.0和之前5.7版本相比有几个重点差异，新手容易在这里被绊倒。
第一是认证插件的差异。MySQL 8.0默认的认证插件是caching_sha2_password，而SpringBoot项目里用的MySQL驱动版本如果太老，连接时会报Unable to load authentication plugin 'caching_sha2_password'。解决办法是换新驱动，用mysql-connector-java 8.0.33（Maven中央仓库里现在推荐的是com.mysql:mysql-connector-j这个坐标，注意groupId变化了），或者降级用户的认证方式为mysql_native_password。
第二是时区问题。JDBC连接串里加上serverTimezone=Asia/Shanghai，否则你插入数据时发现时间比当前时间少了8个小时。我习惯把连接串完整写成：jdbc:mysql://localhost:3306/dormitory?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true。前面的和后面的参数都别删，每个都有它存在的意义。
第三是安装时的端口占用。MySQL默认3306端口，很多机器上这个端口可能被其他服务占了，安装到最后一步起服务时直接失败。解决方法是安装时自定义端口，或者用命令行先查一下占用情况：Windows下netstat -ano | findstr 3306，查到占用进程号后去任务管理器里结束对应的进程。
5.3 MyBatis-Plus逻辑删除与批量插入的两个实用点
逻辑删除的坑前面提过，这里具体说说批量插入。MyBatis-Plus自带的saveBatch方法在数据量不大时用着没问题，但如果你要一次性导入几千条学生数据，默认的批量插入策略会有性能瓶颈。原因在于它默认的批量插入实际上是循环单条插入，逐条提交，效率很低。
解决方法是自定义一个批量插入SQL，在XML里写foreach语法：
xml复制<insert id="batchInsertStudents">
INSERT INTO student (stu_no, name, gender, department, class_name, phone)
VALUES
<foreach collection="list" item="item" separator=",">
(#{item.stuNo}, #{item.name}, #{item.gender}, #{item.department}, #{item.className}, #{item.phone})
</foreach>
</insert>
注意批量插入时，JDBC连接串一定要加上rewriteBatchedStatements=true这个参数，否则MySQL驱动默认不会真正批量执行，性能提升有限。加上这个参数后，几千条数据的插入时间能从十几秒降到一两秒，效果非常明显。
5.4 SpringBoot项目本地运行与打包部署
开发完成后，部署环节也是容易出问题的地方。我建议本地运行阶段用IDE直接启动SpringBoot的main方法，前端用npm run serve起开发服务器。这时的联调地址是：前端页面http://localhost:8080，后端接口http://localhost:8081/api。
正式环境的部署方案我用的是：后端打包成jar包，用mvn clean package -Dmaven.test.skip=true跳过测试直接打包，然后用java -jar dormitory-system.jar启动；前端在项目根目录执行npm run build，生成的dist目录里的静态文件，用Nginx托管。
这里有个要提醒的：前端打包后访问后端接口时，如果后端不在同一台机器上，需要在Nginx配置里做反向代理。配置写法类似这样：
nginx复制server {
listen 80;
server_name localhost;
location / {
root /usr/share/nginx/html/dist;
index index.html;
}
location /api/ {
proxy_pass http://127.0.0.1:8081/api/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
这样配置后，前端打包产物里的请求路径只要保持/api/xxx的相对形式，就可以不区分开发环境和生产环境，自动化切换后端地址。
6. 写在项目答辩之后的几点体会
这个项目最大的价值，不在于技术栈有多新，而在于它把一套完整的业务闭环从头到尾打通了。从表设计到后端接口，从权限控制到前端页面，从本地联调到部署上线，每一步都是实际工作中会遇到的真实场景。做项目的时候多问自己几个为什么——为什么这个字段要建索引，为什么这个接口要加事务，为什么这里要用拦截器而不是过滤器——把这些问题想明白了，答辩的时候自然游刃有余。
我个人实际操作中还有一个感受，就是写代码前一定要把完整的数据流转路径在纸上走一遍。比如我要实现一个退宿功能，我得在学生端发起申请，宿管端审核，审核通过后更新房间已住人数、关闭入住记录、更新学生入住状态，这一串动作里任何一步漏了，数据就会出现不一致。把这些路径在动手前理清楚，写代码的时候基本就是按图索骥，不会出现“写完发现逻辑有漏洞”的情况。
最后再分享一个小技巧：开发过程中务必学会用Git管理代码，每次完成一个功能模块就提交一次。这不仅是良好的工程习惯，也是答辩时可以展示的亮点——把项目从零到一的提交记录给老师看，比你说多少句“我亲手做的”都有说服力。