1. 这个系统为什么年年有人做年年有人喊难每到了课程设计和毕业设计的季节技术社区里就会出现大量求学生宿舍管理系统源码的帖子。说实话这道题看起来简单和做起来麻烦的落差比想象中要大得多。表面上看就是几个增删改查页面学生信息、宿舍信息、报修记录。但真正动手做的时候权限怎么划分、床位状态怎么流转、同一个床位会不会被两个人同时选中、统计报表里的数字怎么算才说得清这些细节会把一个简单系统硬生生拖成日夜赶工项目。我去年帮一个朋友完整做了一套基于SpringBoot和Vue的学生宿舍管理系统从数据库设计到前端页面再到部署上线前后搭进去一个周末加几个晚上。这篇文章就把整个开发过程中的决策逻辑、踩坑点和最终方案完整复盘一遍。不涉及具体商业代码但每一个设计思路和实现方案你都可以直接复制到自己的项目里。适合正在做课设或毕设、想从能跑进化到能讲的同学也适合刚接触前后端分离架构、想找一个完整案例练手的开发者。1.1 一份需求清单先搞清楚宿舍管理系统到底管什么在动手写代码之前我习惯先把需求掰开揉碎。学生宿舍管理系统通常涉及三类角色系统管理员、宿管员、学生。以最常见的课设要求为例核心功能基本跑不出这几个模块基础信息管理楼栋管理、宿舍管理、床位管理、学生信息录入与维护。宿舍分配业务学生入住分配床位、退宿释放床位、调宿申请与审批。日常事务管理卫生检查打分、报修登记与处理进度、晚归或请假登记。查询与统计按楼栋、学院、班级查学生统计入住率、报修处理率等。系统管理账号管理、角色权限控制、密码修改、登录日志。这里有一个非常重要的认知这些功能里真正有技术含量的不是增删改查而是床位的状态流转和权限控制。床位不是简单的一个字段它有空闲、已入住、维修中三种状态而且同一个学生不能同时占两个床位两个管理员也不能同时把同一个床位分给不同的人。如果不提前设计好数据模型和更新逻辑后面做分配功能时会不停地返工。1.2 这篇博文的定位不是源码搬运而是设计思路的完整复盘我清楚很多人搜学生宿舍管理系统源码就是想要一份能直接交差的东西。但我更建议你把这篇内容当成设计文档级别的实战笔记来看。我会详细说明为什么选SpringBoot而不选SSM数据库表为什么要那样建用户登录的token到底是怎么流转的前端打包之后怎么丢进SpringBoot的静态目录里以及哪几个位置最容易在答辩现场被老师一句话问住。就算你最后不用我这里的方案沿着这套思路去拆解任何一份开源源码你也能在很短时间内看懂它、改进它并写好配套文档。下面进入正题。2. 翻开一份能跑的源码SpringBootVue的骨架到底长啥样我见过太多课设项目前端是一个HTML页面套着一堆jQuery后端是Servlet加JDBC代码全堆在Controller里。能跑但答辩老师只要问一句如果并发50个人同时选床位怎么办基本就卡壳了。用SpringBoot加Vue做前后端分离不是为了赶潮流而是这两个框架恰好都满足课设场景里最重要的三个要求学习成本可控、资料足够多、架构经得起追问。2.1 前后端分离的本质两个项目还是一个项目先把这个问题讲透。前后端分离在物理上通常是两个独立的工程一个是SpringBoot的Maven工程一个是用Vue CLI或Vite创建的Node前端工程。后端只提供HTTP接口、返回JSON前端只管渲染页面和交互二者通过Axios之类的HTTP客户端通信。一个标准的目录结构长这样dormitory-system/ ├── backend/ # SpringBoot后端工程 │ ├── src/main/java/com/dorm/ │ │ ├── controller/ # 接收请求返回JSON │ │ ├── service/ # 业务逻辑 │ │ ├── mapper/ # 数据访问层 │ │ ├── entity/ # 实体类 │ │ ├── config/ # 配置类跨域、拦截器等 │ │ └── common/ # 统一返回结果、异常处理 │ └── pom.xml ├── frontend/ # Vue前端工程 │ ├── src/ │ │ ├── views/ # 页面级组件如DormitoryManage.vue │ │ ├── components/ # 复用组件 │ │ ├── router/ # 路由配置 │ │ ├── api/ # 封装请求 │ │ └── store/ # 全局状态管理 │ └── package.json └── sql/ # 数据库脚本.sql分这么清楚有个实打实的好处你可以在一个端口只开后端用Postman调接口也可以只开前端用Mock数据调试样式。调试效率比单体应用高很多出问题时也能快速定位是接口的问题还是页面的问题。2.2 技术选型背后的真实理由很多人选型时看哪个流行选哪个我建议看哪个对当前项目收益最高。给课设做选型时我考虑过三个问题第一为什么后端用SpringBoot而不是SSMSSM五年前是主流但配置一堆XML光Spring和MyBatis整合就够新手喝一壶。SpringBoot把自动配置内化你只要引入依赖、写几个注解就能跑起来。而且市面上绝大多数课设代码、博客、视频教程都基于SpringBoot遇到问题搜得到答案这一点在赶工期时能救命。第二为什么ORM层选MyBatis-Plus这里说句实在话学生宿舍管理系统的数据查询复杂度不高大部分是单表操作加简单条件查询。MyBatis-Plus提供了一整套单表CRUD方法连SQL都不用写内置分页插件也很方便。相比原生MyBatis要手动维护XML效率高出不止一点。但它不是万能药后面讲多表联查时你会看到什么时候该放弃它、直接手写SQL。第三为什么前端选Vue而不是React对做课设的同学来说Vue的中文资料和Element UI/Element Plus这类现成组件库是核心优势。你不需要自己手写一个好看的后台管理界面直接拿组件库拼页面一天的活儿能缩到两小时。这不是投机取巧而是工程上正常的复用思维。2.3 版本选择SpringBoot、JDK、Vue三者搭配是最大的坑我见过太多人死在这上面所以单独拉一节说。搜索热词里springboot版本太高能上热搜真不是没道理。现在常见的搭配有两套项目保守方案推荐课设用较新方案JDK1.817SpringBoot2.7.x3.xMyBatis-Plus3.5.x3.5.x注意兼容Vue2.6 Vue CLI3.x ViteUI库Element UIElement Plus两套方案都能做出完整项目但如果你用新教程配合老代码或者反过来多半会撞上javax和jakarta的报错。SpringBoot 3.x把javax.servlet改成了jakarta.servlet很多老代码的import javax.*直接失效。所以我的建议是项目开始之前先定死版本清单写进文档里。这一步能帮你省掉后面至少两天的排错时间。3. 数据库是整套系统的地基表结构与初始化数据怎么设计说句可能得罪人的话我看了不少课设源码很多能跑的系统数据库表设计是站不住脚的。要么把所有信息塞进一张大宽表要么外键关系混乱要么字符集不是utf8mb4导致中文乱码。数据库设计得不好后面每个功能写起来都别扭。3.1 核心表的关系网用户、学生、宿舍、楼栋先理清核心实体。以我常用的方案为例最终表控制在10张以内但关系清晰sys_user账号表存登录名、密码BCrypt加密、角色admin/manager/student和学生表是一对一或一对零。t_student学生表存学号、姓名、性别、学院、班级、手机号、当前宿舍ID其中学号是天然的业务主键。t_building楼栋表存楼栋名称、可容纳人数等。t_dormitory宿舍表存楼栋ID、房间号、楼层、床位数、当前已住人数。t_bed床位表把床位单独拆一张表。宿舍和床位是一对多每个床位有独立的状态字段。这样做的好处是分配时可以精确到床位而不是只能整个宿舍一起分配也为后续调宿、退宿留出了清晰的状态流转空间。至于业务表常见的有t_repair报修、t_hygiene卫生检查、t_leave请假或晚归登记、t_transfer调宿申请。它们都有共同点一个业务主键、一个关联的外键字段、一个状态字段、一条时间线。这里我特别想强调一点外键到底加不加。课设里我建议不加数据库外键约束而是把关联关系放在代码层维护。原因有二第一MyBatis-Plus这种框架对数据库外键没有特殊支持真正维护关系的是业务代码第二有外键约束后做删除和批量初始化数据时会遇到一堆顺序依赖的麻烦。但不加外键不代表不设计关系关系在表和字段层面就已经定了外键约束只是物理层的保护。3.2 一份能从头执行到底的SQL建库、建表、灌数据源码数据库文档三件套里数据库往往是最容易被忽略、最后又最影响验收的一环。我给你一个建议交付的SQL脚本必须是从头到尾能完整执行的包含建库、建表、插入初始化数据三个部分。很多同学导出数据库时只导出了表结构和业务数据评审老师拿到手根本起不来。我的SQL脚本按这个顺序组织先建库CREATE DATABASE dormitory DEFAULT CHARACTER SET utf8mb4;。注意字符集指定utf8mb4光写utf8在MySQL 5.7之后依然可能出问题。按依赖顺序建表sys_user→t_building→t_dormitory→t_bed→t_student→ 各业务表。插入初始化数据至少包含一个admin账号、一个宿管账号、两三个学生账号以及几条楼栋和床位数据。这里有个经验初始化数据的密码记得统一比如都是123456并且用同一种加密算法生成方便演示时登录。不要在文档里写密码请自行查看这种话那等于给验收环节添堵。3.3 让统计报表不那么难写的两个小技巧宿舍系统很难避开统计功能入住率、各楼栋人数、报修完成率。如果每次统计都要在代码里写一大段循环去查数据库既慢又丑。我常用的做法是两个层面配合一是增加冗余字段。在t_dormitory表里放一个已住人数字段每次分配或退宿时在同一个事务里同步更新床位状态和宿舍已住人数。查询汇总时直接对已住人数求和不需要实时count床位表。你可能会问冗余字段不怕数据不一致吗怕所以在同一个事务内更新t_bed和t_dormitory一致性就有保证。二是复杂统计直接用SQL的GROUP BY加聚合函数不要在Java代码里算。比如按楼栋统计人数一行SQL就能解决SELECT b.id, b.name, COUNT(s.id) AS stu_count FROM t_building b LEFT JOIN t_student s ON b.id s.building_id LEFT JOIN sys_user u ON s.student_no u.username WHERE u.role student AND s.status 1 GROUP BY b.id, b.name;这种SQL写完放进Mapper的Select注解里比在Service层写循环高效得多答辩时也更讲得清楚。4. 从学生端到管理端权限与核心业务模块的实现逻辑骨架和数据库搭好之后该解决系统怎么运转的问题了。这一章讲三个核心实现逻辑分别对应三个最容易答辩翻车的点登录鉴权、宿舍分配、状态类业务流转。4.1 登录鉴权前后端分离下我是谁的问题传统单体应用可以用Session前后端分离后我更推荐用JWT做无状态鉴权。流程很简单用户输入账号密码后端校验通过后生成一个JWT字符串里面带上用户ID和角色通过接口返回给前端。前端把token存起来之后每次请求都在Header里带上Authorization: Bearer token。后端写一个拦截器统一拦截除登录接口之外的请求解析并校验token通过后放行不通过返回401。注意几个细节。密码不要明文存储用BCrypt或MD5加盐。课设用BCrypt更显专业Spring Security里自带BCryptPasswordEncoder但不想引入完整Security框架的话也可以单独引入Spring Security Crypto的依赖只拿它的加密工具类。token有效期建议设24小时引入Redis做黑名单会更专业但对课设场景来说属于超纲也容易把自己绕晕可以不引入。拦截器的实现参考这样Component public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); // 校验token合法则把用户信息放入request上下文 // 不合法则返回401并终止请求 return true; } }记得在配置类里注册拦截器并且放行/api/login和静态资源路径。这个配置遗忘率非常高很多人部署后页面打不开就是因为静态资源被拦截器拦了。4.2 宿舍分配床位状态机和并发问题宿舍分配是整个系统里业务逻辑最像样的部分也是答辩老师最喜欢深挖的地方。一个学生申请入住时怎么保证他拿到的床位真的是空的如果两个管理员同时操作会不会把同一个床位分给两个人我的方案是给床位加状态字段并在分配事务里做条件更新。床位的状态机是0-空闲可以被分配1-已入住不可分配2-维修中不可分配分配的核心逻辑是先根据宿舍ID查可用的空闲床位然后用带状态条件的SQL去更新boolean success bedMapper.updateByCondition( // 设置新状态 new Bed().setStatus(1).setStudentId(studentId), // 条件为床位ID匹配且当前状态为0 new LambdaQueryWrapperBed() .eq(Bed::getId, bedId) .eq(Bed::getStatus, 0) ) 0;关键在于WHERE id? AND status0。如果返回更新行数为0说明床位已经被别人抢走了本次分配失败重新选择床位即可。这其实就是乐观锁的思路不需要引入分布式锁用数据库自带的行锁就能解决。调宿和退宿都是在这个状态机上做流转。退宿把床位状态还原为空闲同时清空学生ID关联。把关键约束放在数据库字段和更新条件里比在Java代码里写一堆if-else要稳得多。4.3 报修、卫生检查这类状态流转业务怎么做学生报修→宿管查看→维修处理→学生确认这类流程本质上就是一张表加上一个状态字段的流转区别只在于哪个角色能改状态。实现时我建议统一返回格式{ code: 200, message: 操作成功, data: {} }前端用Axios统一拦截解析code并做提示后端用RestControllerAdvice做全局异常处理。这样一来报修模块、卫生模块、请假模块都可以复用同一套结构和逻辑代码量能压缩不少。表单提交前前端做一次必填校验和手机号格式校验后端接口再做一次非空和长度校验双保险。千万别只做前端校验因为接口是可以被直接调用的。这是一个非常基础但常见的扣分点。5. 把前端打包塞进SpringBoot从本地联调到服务器部署代码写完了最折腾人的其实是怎么让前后端真正跑在一起。我见过太多项目在本地跑得好好的一到部署就崩。这一章把联调、跨域、部署三个环节说透。5.1 跨域问题前端端口和后端端口八字不合的根源开发环境下前端跑在localhost:8080后端跑在localhost:9090端口不同浏览器的同源策略就会拦下请求这就是跨域。解决办法有两种第一种后端直接加CORS配置类允许前端地址访问。写一个WebMvcConfigurer配置类重写addCorsMappings方法允许所有来源和所有请求方法即可。这种方式简单直观适合课设。第二种前端用Vite或Vue CLI的代理功能把/api开头的请求代理到后端地址。开发期用代理更接近生产环境改接口地址时不用动前端代码。这两种方式我都试过开发期推荐代理生产期推荐直接打包进后端同源部署整个系统只有一个地址没有跨域问题。5.2 两种打包部署方式先看懂再选择第一种是Vue打包放进SpringBoot。在frontend目录执行npm run build得到dist目录把里面的静态文件复制到后端src/main/resources/static下然后重新打包后端的jar。这样整个系统只有一个jar包里面既包含后端接口也包含前端页面。部署时用java -jar dormitory.jar就能跑非常省事。对应的前端请求接口的地址不要写死成http://localhost:9090/api应该用相对路径/api这样在同一个Tomcat下才不出问题。第二种是前后端分离部署。后端jar包跑在9090端口前端dist目录交给Nginx托管Nginx配置反向代理把/api请求转发给9090的SpringBoot进程。这种部署方式更贴近真实企业环境适合在文档里写未来可扩展性也方便把静态资源独立管理。但如果你在校期间没有云服务器用第一种方式就足够了。这里直接给出一份Nginx静态托管加反向代理的关键配置server { listen 80; server_name your_domain_or_ip; root /usr/share/nginx/html/dist; index index.html; location /api/ { proxy_pass http://127.0.0.1:9090; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }5.3 部署时的常见问题端口、数据库连接、配置文件部署踩坑主要集中在三件事端口被占用Linux服务器上用netstat -tlnp查端口找到占用8080或9090的进程处理掉。Windows下对应的是netstat -ano加任务管理器但服务器大概率是Linux。数据库连接不上大概率是数据库地址写成了localhost而客户端和数据库不在同一台机器。把application.yml里的url改成服务器的IP或内网地址并确认3306端口在防火墙或安全组里放行。配置文件分环境我的习惯是application-dev.yml和application-prod.yml两套配置启动时用--spring.profiles.activeprod指定。课设虽然不强制但这个习惯写在文档里评委印象分会高不少。6. 配套文档怎么写答辩才不至于一问三不知标题里的三件套源码和数据库都聊完了最后说文档。我见过不少学生代码写得不错文档却很糟糕答辩时只能干巴巴地说我用了SpringBoot和Vue。文档其实是给评委的第一印象在答辩中占的比重有时候比代码本身还高。6.1 课设文档的黄金结构从需求到验证一脉相承不要从网上下一个万能模板套上去而是围绕逻辑主线自证合理性。我的建议顺序是需求分析把系统用户和用例列清楚。学生能干什么、宿管能干什么、管理员能干什么。这是整份文档的根基。系统设计画整体架构图前后端分离、标注技术栈再加数据库ER图和表结构说明。表结构说明要包含字段名、类型、是否主键、含义。评委不一定逐行看代码但会扫一眼表设计是否合理字段命名是否规范。核心模块设计选两三个最能体现技术能力的模块深入写比如宿舍分配的并发控制、JWT鉴权流程。这里是你得分的地方一定要把为什么这么设计写出来。系统实现与测试贴关键界面截图和接口测试结果顺带写一个简单的测试用例表比如测试正常分配、测试重复分配、测试权限拦截。总结与展望一两句话带过即可重点是实现了什么、还能优化什么。不要写我相信该系统具有良好的应用前景这种空话改成后续可引入消息队列处理报修通知这种具体方向。6.2 答辩演示的节奏核心链路优先别从登录页开始讲20分钟答辩演示是很多同学忽略的环节。我的经验是按核心链路演示不要按菜单顺序演示。菜单顺序演示的问题在于讲者容易陷入一个个页面的截图流评委听不出业务闭环。核心链路演示则不一样第一步用管理员账号登录展示学生信息和楼栋宿舍列表说明数据如何录入。 第二步走一遍学生入住分配床位的完整流程顺便展示床位状态的实时变化。这里是体现数据库设计和业务逻辑的最好时机。 第三步用学生账号登录演示提交一条报修再切回宿管账号处理这条报修只讲状态流转。 第四步打开统计页面展示入住率和报修处理率解释这两组数据是怎么算出来的。整个演示控制在5到8分钟评委对系统业务闭环的感知会非常清晰。接着你再讲设计亮点JWT、乐观锁、统一异常处理基本就是顺着你的节奏走了。6.3 三件套交付前最后花半小时自查一遍交付前的自查清单我整理一份直接可用的SQL脚本能不能从空数据库直接完整执行不报错初始账号是否能正常登录角色是否正确前端打包后的静态文件是否已经放进了SpringBoot的static目录能不能在只装JDK和MySQL的环境下用一条java -jar命令把系统跑起来文档里的截图是不是最新界面的截图有没有残留旧版页面外键、时区、字符集、跨域这些配置是否在文档中有说明这半小时的检查能帮你避免很多老师当场打开却发现跑不起来的尴尬场景。我做课设和帮朋友验收项目时每次都跑一遍这个流程。最后再说一个小习惯在SQL脚本和接口路径的命名上尽量保持规整和语义化接口统一用/api前缀表名统一用t_开头。你说不上这是哪个大功能但评委翻代码时视觉上的规整会潜移默化地影响他对你代码质量的判断。这些细节积累起来就是同一套功能有人被夸工程化意识强有人被批这是玩具项目的根本区别。