1. 先弄清标题里的双技术栈SSM和Django为什么会同时出现每年毕业设计旺季我这边都会收到大量类似标题的项目基于JavaSSMDjango学生宿舍管理系统源码LW调试文档讲解等。第一次看到的朋友十有八九会愣一下SSM是Java后端框架组合Django是Python阵营的Web框架这俩怎么凑到一个标题里了是抄错了还是什么黑科技先解释这个疑虑因为弄明白这一点你才能真正理解这个项目的定位和价值。从交付物角度看标题里的源码LW调试文档讲解是关键词。LW在这里指论文部分团队把论文简称为LW取自论文拼音首字母也就是说这套资料包含完整源码、毕业论文文档、调试排查文档、录制讲解视频。这类项目最常见的用途是本科计算机专业的毕业设计、Java方向课程设计以及部分培训机构阶段性考核作品。而SSMDjango同时出现最常见的两种情况是第一种同一套宿舍管理业务分别用Java SSM和Python Django实现了两个独立版本源码包会拆成ssm_version和django_version两个目录第二种主版本用SSM做核心管理后台Django版本作为简化演示版或文档中作为框架对比分析章节出现。从专业角度说我更倾向于认为这是双技术栈独立实现。为什么有人愿意这么做因为宿舍管理系统是典型的CRUD业务系统它的表结构相对规整学生、宿舍、入住记录、报修工单、卫生检查、违纪记录。这套业务模型用任何主流Web框架都能落地非常适合在同一份文档中做技术对比。你以为这是工作量翻倍实际对过来人的经验来说SSM版本跑通之后Django版本照着表结构再建模一遍工作量并没有翻倍那么夸张反而能展现对前后端技术栈都有掌控力的亮点在答辩环节是个天然加分项。还有一个细节容易被忽略Django版本在学生群体中越来越流行。很多同学从Python入门编程到大二大三才补Java但Java又是课程考核主流。这个项目标题相当于给两条技术路线都留了入口你主学Java就吃透SSM版你主学Python就从Django版切入。无论哪条路线最终的业务理解是相通的。所以后续内容我会按一套需求、两条实现路径的思路来拆解。先讲清楚这个系统到底在管什么、表怎么设计再分别展开SSM和Django下的核心实现思路最后把调试文档里我总结出来的高频坑位和答辩应对策略一并分享。2. 宿舍管理系统的业务边界与数据库表设计2.1 系统角色与权限划分宿舍管理系统名义上叫学生宿舍管理实际使用场景里通常有三类角色。第一类是系统管理员一般由学生处或后勤信息中心老师担任负责楼栋、宿舍、床位的整体配置管理宿管人员和学生账号查看全校入住统计。第二类是楼管员/宿管阿姨角色负责日常业务操作入住登记、调宿、退宿、报修处理、查寝打分、违纪记录。第三类是学生角色登录后查看自己的住宿信息、缴纳记录、提交报修、查看公告。很多毕业设计版本只做了一个管理员管所有的模式这其实是不合格的。因为宿舍管理系统的业务特点是有角色的流程协作如果所有操作集中在单一用户身上答辩时评委第一个问题就是如何避免宿管阿姨权限过大职责如何区分所以正规的库表设计里至少要包含admin用户表并且带role字段区分超级管理员与普通宿管学生表独立一张通过账号字段关联登录认证。2.2 核心业务场景拆解把宿舍业务从头捋一遍其实就八个核心动作新生入学/新员工安排宿舍管理员为学生分配宿舍床位调宿学生申请或管理员主动调整宿舍退宿/毕业离校学生搬出释放床位资源日常查寝登记晚归、未归、违规用电器等情况宿舍报修学生提交报修管理员派单维修完成后确认归档卫生评比对宿舍进行定期打分生成优秀/不合格宿舍列表来访管理来访人员登记保障楼层安全公告通知宿舍停水停电、安全检查等通知下发。这些场景看起来简单落到数据库设计上却有讲究。最核心的坑是很多人把宿舍理解成一张静态表给每个宿舍一个已住人数字段每次入住退宿就手工加减。这种做法能跑但你没法回答一个数据完整性问题如果某次入住后进程中断已住人数和实际入住记录不一致怎么办所以标准做法是把宿舍表和入住流水表/住宿关系表分离宿舍表里的remaining_bed字段只作为冗余统计真正的数据事实以入住记录表为准。每次入住校验剩余床位时用统计SQL去算而不是直接信任冗余字段。2.3 核心表结构与字段设计我按实际项目的标准做法推荐一套9张核心表的设计这套结构在课设和毕设中属于内容充实且不过度设计的平衡点表名核心字段说明t_adminid, username, password, real_name, role, phone系统管理员/楼管账号role区分权限t_studentid, student_no, name, gender, class_name, phone, id_card, major, status学生信息status标记在校/离校t_dormitoryid, building_no, room_no, floor, unit_no, type, bed_total, remaining_bed, gender宿舍房间基础信息t_room_checkinid, student_id, dorm_id, checkin_time, checkout_time, is_current入住/住宿记录表核心表t_repairid, student_id, dorm_id, content, status, create_time, finish_time报修工单status流转t_hygieneid, dorm_id, score, check_date, inspector, remark卫生检查记录t_violationid, student_id, dorm_id, type, detail, level, create_time违纪记录t_noticeid, title, content, create_time, publisher公告通知t_leave_schoolid, student_id, leave_time, reason, operator离校/退宿登记这套设计的几个要点值得单独说一下第一t_room_checkin表是整个系统的事实中心。它记录了每一次学生入住和退宿行为的起始时间查某个学生当前住哪就是is_current1并且checkout_time IS NULL这条记录查宿舍历史入住人员就按dorm_id查全部记录。MyBatis的Mapper里写这种当前住宿关联查询很简单Django版用ORM的filter也能一句拿下但如果没有这张表很多统计需求都会打折扣。第二宿舍表的性别字段。宿舍分配必须校验性别一致这是业务上绕不过去的规则。如果这套系统要支持男女宿舍楼分开管理宿舍表里加gender字段就是硬要求不然一个男生被分进女生楼层的bug会让你在演示现场非常尴尬。第三脱敏和字段冗余。学生表里保留id_card身份证号没问题但前端列表展示时通常只展示后四位或完全不展示。这种细节答辩时主动提出来评委的印象分会明显不一样——这代表你考虑过真实系统的合规问题不是停留在表能建出来就行的水平。2.4 床位统计的双写一致性单独把剩余床位拎出来说是因为这是宿舍管理系统里最容易被追问深挖的点。假设t_dormitory.remaining_bed在入住时-1、退宿时1同时t_room_checkin插入或更新记录。如果这两步没有放在同一个数据库事务里出现异常时床位数和实际入住记录就对不上。SSM版本里在Service层方法上加Transactional并把两个Mapper操作包进去Django版本里用transaction.atomic装饰器包裹整个逻辑块。代码上都只有一层但答辩时能讲清楚为什么要保证事务一致性比背一百个八股文都管用。另外有个实践技巧不要只在界面上显示剩余床位数字而要提供一个床位概要页按楼栋、楼层、宿舍类型做分组统计。用一条GROUP BY语句就能从数据库直接算出全校宿舍利用率这是答辩现场最高性价比的功能展示点之一。3. SSM版核心链路从实体类到前端页面的完整流转3.1 SSM项目骨架与关键配置SSM即Spring SpringMVC MyBatis技术栈是Java Web课程设计里的常青树。你拿到源码后第一件事不是看Controller而是看配置文件骨架对了后面全顺。标准的SSM项目目录结构按Maven约定展开src/main/java ├── com.xxx.controller // 控制层 ├── com.xxx.service // 业务接口 ├── com.xxx.service.impl // 业务实现 ├── com.xxx.mapper // MyBatis Mapper接口 ├── com.xxx.pojo // 实体类 └── com.xxx.utils // 工具类 src/main/resources ├── applicationContext.xml // Spring核心配置 ├── spring-mvc.xml // SpringMVC配置 ├── mybatis-config.xml // MyBatis配置 ├── jdbc.properties // 数据库连接 └── mapper // XML映射文件目录 src/main/webapp ├── WEB-INF/web.xml ├── static/js └── jsp 或 templates三个配置文件的分工我用最直白的方式解释applicationContext.xml负责管对象把Service、Mapper、数据源全部注册成Spring Beanspring-mvc.xml负责管请求告诉DispatcherServlet哪里去找Controller、静态资源放哪里、用了什么视图解析器mybatis-config.xml负责管SQL配置驼峰映射、日志等。很多同学debug半天登不进去查到最后是数据库连接配置写错或Mapper没扫描到都是基础配置不熟。核心配置段我直接贴出来!-- applicationContext.xml 中数据源与SqlSessionFactory -- bean iddataSource classcom.alibaba.druid.pool.DruidDataSource destroy-methodclose property namedriverClassName valuecom.mysql.cj.jdbc.Driver/ property nameurl valuejdbc:mysql://localhost:3306/dormitory?useUnicodetrueamp;characterEncodingutf8amp;serverTimezoneAsia/Shanghai/ property nameusername valueroot/ property namepassword value123456/ /bean bean idsqlSessionFactory classorg.mybatis.spring.SqlSessionFactoryBean property nameconfigLocation valueclasspath:mybatis-config.xml/ property namedataSource refdataSource/ property namemapperLocations valueclasspath:mapper/**/*.xml/ /bean bean classorg.mybatis.spring.mapper.MapperScannerConfigurer property namebasePackage valuecom.xxx.mapper/ /bean两个易错细节数据库URL里的characterEncodingutf8必须写成utf8少一个连字符在部分MySQL版本下会导致乱码serverTimezone必须显式指定MySQL 8.0默认时区跟中国差8小时很多时间错了8小时的bug就是这样来的。3.2 核心业务实现的代码逻辑入住登记SSM版的核心业务体现为Controller收到请求后Service层组织多个Mapper操作完成业务。以学生入住登记为例明确流程校验学生存在且未在住 - 校验目标宿舍性别匹配且有空床位 - 插入入住记录 - 宿舍剩余床位减一 - 学生状态改为在住。Service接口方法签名一般长这样public interface DormitoryService { // 学生入住 boolean assignDormitory(Integer studentId, Integer dormId); // 退宿/离校 boolean checkout(Integer studentId); // 调宿 boolean changeDorm(Integer studentId, Integer newDormId); // 统计宿舍入住率 MapString, Object countDormOccupancy(); }实现类里的核心逻辑我用伪代码帮大家理清Override Transactional(rollbackFor Exception.class) public boolean assignDormitory(Integer studentId, Integer dormId) { Student student studentMapper.selectById(studentId); if (student null) { throw new BusinessException(学生不存在); } // 已经是入住状态则拒绝 RoomCheckin current roomCheckinMapper.selectCurrentByStudentId(studentId); if (current ! null) { throw new BusinessException(该学生已在住请先办理退宿); } // 宿舍校验 Dormitory dorm dormitoryMapper.selectById(dormId); if (!dorm.getGender().equals(student.getGender())) { throw new BusinessException(性别与宿舍类型不匹配); } if (dorm.getRemainingBed() 0) { throw new BusinessException(该宿舍已满员); } // 写入住记录 RoomCheckin checkin new RoomCheckin(); checkin.setStudentId(studentId); checkin.setDormId(dormId); checkin.setCheckinTime(new Date()); roomCheckinMapper.insert(checkin); // 扣减冗余剩余床位字段 dormitoryMapper.decreaseRemainingBed(dormId); // 更新学生状态 studentMapper.updateStatus(studentId, 在住); return true; }这段逻辑是体现业务规则的关键。很多课程设计版本只做跳个页面、增删改查就能交差没有这些前置校验。但我说实话上面这几个if判断才是答辩时能讲出东西的地方。评委问你怎么保证宿舍不超员你指着这段代码说每一步都有校验并且在同一个事务里整份项目的含金量立刻不一样。controller层则是典型的路由分发Controller RequestMapping(/dorm) public class DormitoryController { Autowired private DormitoryService dormitoryService; RequestMapping(/assign) ResponseBody public Result assign(RequestParam Integer studentId, RequestParam Integer dormId) { try { dormitoryService.assignDormitory(studentId, dormId); return Result.success(分配成功); } catch (BusinessException e) { return Result.fail(e.getMessage()); } } }用ResponseBody返回JSON前端AJAX直接弹提示。这种前后端通过JSON交互的方式比传统JSP表单提交更现代也是很多课设项目里容易被忽略的细节——如果全程靠页面跳转传惨演示效果会显得非常老旧。3.3 MyBatis的动态SQL与多表关联SSM版里查询宿舍列表经常带多条件组合按楼栋、按楼层、按宿舍类型、按剩余床位是否大于0。如果用拼接SQL字符串的方式注入风险且烦琐。MyBatis的 和 标签就是为这个场景准备的select idselectDormList resultTypecom.xxx.pojo.Dormitory select * from t_dormitory where if testbuildingNo ! null and buildingNo ! and building_no #{buildingNo} /if if testfloor ! null and floor #{floor} /if if testtype ! null and type ! and type #{type} /if if testgender ! null and gender ! and gender #{gender} /if if testonlyAvailable ! null and onlyAvailable true and remaining_bed gt; 0 /if /where order by building_no, room_no /select注意XML里小于号必须转义成肥肠典型的低级报错点。另外resultType如果直接映射成pojo需要在mybatis-config.xml里开启驼峰映射settings setting namemapUnderscoreToCamelCase valuetrue/ /settings这样数据库字段dorm_id才能自动映射到Java属性dormId否则查出来全是null。前端页面建议采用JSP AJAX的方式。列表页用表格展示操作按钮绑click事件调$.ajax到Controller接口刷新局部数据。这样比传统表单提交体验好很多也是调试文档里容易一笔带过但实际很影响使用感受的部分。4. Django版另开一条线模型、视图与模板的对应关系4.1 Django项目的组织方式与SSM的差异如果同一个业务需求用Django重新实现项目的组织方式差异很大。SSM是按技术层次分包——controller、service、mapper各一层Django是按业务模块分app——一个app对应一个功能域。所以在Django版里目录会是这样dormitory_project/ ├── manage.py ├── dormitory/ # 项目配置目录 │ ├── settings.py │ ├── urls.py └── apps/ ├── student/ # 学生管理app ├── dorm/ # 宿舍管理app ├── repair/ # 报修app └── system/ # 公告与用户认证app └── templates/ # 模板目录 ├── student/ └── dorm/ └── static/ # 静态资源 ├── css/ ├── js/ └── images/Django的核心思想是MTVModel模型、Template模板、View视图。对照SSM可以粗略理解为Model约等于pojo加MapperView函数约等于ControllerTemplate约等于JSP页面URL配置约等于SpringMVC里的RequestMapping。4.2 models.py中的核心模型定义Django版不需要手写XML映射文件模型直接在models.py里定义由ORM自动生成建表语句和SQL。但要注意Django默认表名是app名_模型名如果想让表名跟SSM版一致方便文档对比可以在Meta类里用db_table指定from django.db import models class Student(models.Model): student_no models.CharField(max_length20, uniqueTrue, verbose_name学号) name models.CharField(max_length50, verbose_name姓名) gender models.CharField(max_length4, choices[(男, 男), (女, 女)], verbose_name性别) class_name models.CharField(max_length50, nullTrue, blankTrue, verbose_name班级) phone models.CharField(max_length11, nullTrue, blankTrue, verbose_name电话) id_card models.CharField(max_length18, nullTrue, blankTrue, verbose_name身份证号) status models.CharField(max_length10, default离校, verbose_name状态) create_time models.DateTimeField(auto_now_addTrue, verbose_name创建时间) class Meta: db_table t_student verbose_name 学生信息 ordering [id] def __str__(self): return f{self.student_no} - {self.name}这里有个实际开发中常见的坑Django默认每个模型都会有一个自增id主键你要么直接用这个id做关联要么明确设置primary_key。如果沿用SSM版里的逻辑主键设计最好在所有关系字段上明确指定to_field和on_delete规则。宿舍表同样在Meta里指定db_tablet_dormitory字段和SSM版保持一致。入住记录表是关联两张表的中间表用ForeignKey关联class RoomCheckin(models.Model): student models.ForeignKey(Student, on_deletemodels.CASCADE, verbose_name学生) dorm models.ForeignKey(Dormitory, on_deletemodels.CASCADE, verbose_name宿舍) checkin_time models.DateTimeField(auto_now_addTrue, verbose_name入住时间) checkout_time models.DateTimeField(nullTrue, blankTrue, verbose_name退宿时间) is_current models.BooleanField(defaultTrue, verbose_name是否当前有效) class Meta: db_table t_room_checkinon_delete取值建议业务上学生退宿后我们希望保留历史记录而不是把入住流水一起删掉所以ForeignKey关联用models.CASCADE还是models.PROTECT要结合业务考虑。如果退宿动作是同时删除学生信息和入住记录那CASCADE没问题但如果学生信息归档保留而入住记录想保留那么用PROTECT更安全退宿时手动更新checkout_time和is_current而不是删除记录。4.3 URL路由、视图函数与模板渲染链路Django版的页面请求链路是浏览器输入URL - urls.py路由匹配 - 视图函数处理 - 返回HttpResponse或渲染模板。在views.py里写一个查询所有在住学生及宿舍信息的视图from django.shortcuts import render from apps.student.models import Student from apps.dorm.models import RoomCheckin def student_dorm_list(request): # 查询当前正在住宿的学生关联宿舍和楼栋信息 checkins RoomCheckin.objects.filter( is_currentTrue, checkout_time__isnullTrue ).select_related(student, dorm).all() context { checkins: checkins, total_count: checkins.count(), } return render(request, dorm/student_dorm_list.html, context)select_related是个值得讲的优化点。因为RoomCheckin通过ForeignKey关联Student和Dormitory如果不用select_related循环模板里每访问一次checkin.student.name都会额外发一条SQL数据量大时就是N1查询问题。课程设计的数据量小可能看不出来但答辩时主动提一句用select_related优化关联查询避免N1这个细节绝对是加分项。URL路由配置在app的urls.py中from django.urls import path from . import views urlpatterns [ path(dorm/list/, views.student_dorm_list, namedorm_list), path(dorm/assign/, views.assign_dorm, nameassign_dorm), path(dorm/checkout/, views.checkout, namecheckout), path(repair/submit/, views.submit_repair, namesubmit_repair), ]模板渲染用Django模板语言DTL继承基础模板后重写content块{% extends base.html %} {% block content %} table classtable table-bordered thead tr th学号/th th姓名/th th宿舍楼/th th房间号/th th入住时间/th th操作/th /tr /thead tbody {% for item in checkins %} tr td{{ item.student.student_no }}/td td{{ item.student.name }}/td td{{ item.dorm.building_no }}/td td{{ item.dorm.room_no }}/td td{{ item.checkin_time|date:Y-m-d H:i }}/td td button classbtn btn-danger btn-sm onclickcheckout({{ item.id }})退宿/button /td /tr {% empty %} trtd colspan6暂无数据/td/tr {% endfor %} /tbody /table {% endblock %}4.4 Django静态文件与部署差异Java课设里静态资源放webapp/static下spring-mvc.xml配置静态资源映射就完事。Django略有不同开发阶段settings.py里要配置STATIC_URL和STATICFILES_DIRS项目上线收集静态资源时才用collectstatic命令STATIC_URL /static/ STATICFILES_DIRS [ BASE_DIR / static, ]这里有个经典坑明明静态文件放好了路径也对页面就是加载不了CSS和JS。大概率原因有三个——第一模板里写的是/static/css/style.css但STATIC_URL没设置成/static/第二settings.py里没把自己项目根目录下的static目录加进STATICFILES_DIRS第三访问路径和实际文件名大小写不匹配。Linux环境下大小写敏感CSS写成css乱之一只会让你对着浏览器F12发呆。数据库配置这部分Django默认用SQLite对课设来说够用。但如果要跟SSM版共用一份MySQL数据settings.py里可以这样配置DATABASES { default: { ENGINE: django.db.backends.mysql, NAME: dormitory_db, USER: root, PASSWORD: 123456, HOST: 127.0.0.1, PORT: 3306, OPTIONS: { charset: utf8mb4, }, } }注意如果直接用SSM版建好的MySQL库Django的ORM对表结构有预期约束。最省事的方法是把Django每个models的Meta.db_table对应好并且用manage.py migrate只生成系统表业务表自己通过SQL脚本建好再反向写模型字段速度会快很多。5. 调试文档里真正值钱的排错经验5.1 SSM项目最容易翻车的三个配置点拿到调试文档后你会发现里面最有价值的部分不是我上面写的架构分析而是排错记录。根据我带过的项目SSM宿舍管理系统出问题的点位高度集中在三个地方。第一MyBatis的Invalid bound statement (not found)报错。Mapper接口和对应的XML文件没有建立映射。绝大多数情况是XML文件没被扫描到。java目录下的mapper接口和resources/mapper目录里的mapper XML开发阶段XML文件必须被构建到target/classes里如果你改了XML但没重新build或者MapperScannerConfigurer的basePackage写错了包名就会报这个错。排查方式很简单先看target/classes/mapper下面有没有对应XML。第二JSP页面上的中文乱码。配置了Spring的CharacterEncodingFilter还乱码就去查数据库连接串里有没有characterEncodingutf8同时检查MySQL数据库自身字符集。再不行看JSP页面头部pageEncoding有没有写对。三个地方必须全部统一成utf8体系缺一不可。有一回我排查了一晚上最后发现是MySQL建立连接时没加useUnicodetrue导致提交到数据库之前就已经坏了。第三启动Tomcat报ClassNotFoundException。常见场景是Maven项目里某个依赖下载不完整或者根本没引入。SSM项目建议一开始就把依赖版本锁死Spring 5.2.x配MyBatis 3.5.x是比较稳定的组合别一上来就追最新版。最新的Spring 6要求Jakarta命名空间跟传统javax包不兼容很多老教程代码直接跑不起来。5.2 Django项目的高频报错清单Django版的调试文档我也翻烂过对应的高频问题整理成一张表异常原因处理ImproperlyConfiguredsettings.py中DATABASES或INSTALLED_APPS配置有问题检查app名是否注册在INSTALLED_APPS中TemplateDoesNotExist模板路径配置错误或templates目录位置不对确认settings中DIRS路径和实际目录结构Field id expected a number but got ...传参类型不对主键传了非数字字符串在视图层做类型转换或前端校验NoReverseMatchurls.py中name没配好模板里的url标签找不到路由统一所有路由name用name反向解析django.db.utils.OperationalError: no such table忘记执行migrate或模型改动后未生成迁移python manage.py makemigrations python manage.py migrate其中模板加载问题最常见。Django的模板查找顺序受settings里TEMPLATES设置的DIRS和app内部templates目录影响如果你手动建了templates目录却忘了把它加进DIRS那项目永远找不到页面。开发环境建议在settings.py中这样配置TEMPLATES [ { BACKEND: django.template.backends.django.DjangoTemplates, DIRS: [BASE_DIR / templates], APP_DIRS: True, ... } ]5.3 演示数据与种子脚本这一节我要单独强调因为绝大多数拿到项目的人忽略它的价值。宿舍管理系统演示效果好不好几乎完全取决于数据库里有没有像样的演示数据。空表跑起来页面一片空白什么功能都看不出来答辩时很难撑场面。我的建议是准备一份seed.sql脚本预先造好一批逻辑自洽的数据5栋宿舍楼每栋6层每层10个房间每间4个床位模拟480个床位中已入住300人、剩余180人的状态学生信息覆盖不同年级姓名避免全叫张三李四报修工单至少3条正常流转状态待处理/处理中/已完成卫生检查记录覆盖最近4周每栋楼每周一条。造数的时候最怕逻辑冲突。比如某学生已经入住A宿舍又被插了一条入住B宿舍记录或者某宿舍剩余床位写着2但入住记录里已经住了4个人。这些数据不一致在演示页面上瞬间穿帮。建议用SQL脚本生成而不是手插脚本里先清空再按事务逐张表插入保持外键关系顺序先宿舍、再学生、最后入住流水。6. 答辩、演示与二次开发的加分建议6.1 三十五分钟演示流程设计不管你是自己做了这个项目还是准备拿这套源码做演示流程编排很关键。我发现很多同学演示时是从登录页开始输入账号密码进首页看看图表然后点开几个菜单这个能查学生、这个能查宿舍就结束了。评委全程面无表情因为你只是展示了CRUD没有展示业务闭环。建议的演示顺序是第一步用管理员账号登录先展示首页统计看板说明宿舍总数、学生总数、入住率、报修待处理数用数据说明系统全局视图。第二步切换到学生管理页演示组合条件查询——按班级、性别、状态筛选展示多条件SQL的能力。第三步核心重头戏——演示入住分配完整流程先查询某个宿舍的剩余床位再选择一名未入住学生执行分配然后回到宿舍列表页确认床位已减一再去学生信息页确认状态已变为在住。这一步是完整业务闭环的演示比任何口头说明都有力。第四步演示退宿流程床位释放、历史记录保留。第五步演示报修工单从学生提交到管理员处理完成的状态流转。最后回到统计页展示入住率数据变化。时间控制在8到12分钟剩余时间留给评委提问。演示之前把环境跑一遍浏览器缓存清干净数据库重启一次这是最基本的。6.2 答辩被问最多的六个问题根据这些年的答辩观察宿舍管理系统被问的问题高度集中。我把高频问题列出来并给出回答建议。问一系统有哪些角色权限如何控制答三类角色管理员、楼管员、学生。实现上通过t_admin表和role字段区分管理员与楼管员权限不同账号登录后菜单可见性不同路由级控制关键操作如删除学生只对超级管理员开放。如果做的是简化版只有管理员单角色千万不要嘴硬说我实现了RBAC承认设计取舍并说明未来可扩展反而是成熟的表现。问二如何防止宿舍超员分配答两种手段结合。前置校验分配前查询目标宿舍当前有效入住人数是否等于床位总数事务保障插入入住记录和扣减冗余床位字段在同一个事务中执行异常时回滚。这句话说完基本就过关了。问三某个学生换宿舍后历史入住记录怎么处理答换宿舍不是删除旧记录而是将旧记录的is_current置为false并写入checkout_time然后新增一条is_currenttrue的新记录。保留完整轨迹可以追溯每个学生住过哪些宿舍、时间段是什么。问四这张统计报表的数据是怎么算出来的答按楼栋与宿舍类型维度做GROUP BY聚合LEFT JOIN入住记录表统计实际人数和剩余床位在SQL层完成避免把数据捞到内存里算。问五SSM和Django两个版本哪个性能好答业务场景简单时两者无明显差距。SSM结合MyBatis对SQL可控性强适合复杂查询Django开发效率高内置admin和ORM适合快速交付。性能瓶颈更多在数据库结构和索引设计不在框架本身。问六数据库索引是怎么设计的答入住记录表的student_id和dorm_id建联合索引或分别建索引报修表按status建索引统计报表查询涉及的building_no和remaining_bed也建议建索引。这个回答能体现你考虑过数据量增长后的查询性能。6.3 从课设项目到线上系统的扩展方向如果学完这套项目还想继续深挖有几个高性价比的扩展点。第一个是前后端分离改造。后端只提供JSON API前端用Vue或React独立部署SSM版可以不改核心Service层只把Controller的返回结果统一成JSON结构Django版可以用Django REST Framework快速生成API。第二个是引入Redis做缓存。登录会话、楼层统计、公告列表这种读多写少的数据缓存到Redis可以显著减少数据库压力。答辩时提用Redis缓存热点数据设置过期时间保证一致性这已经是进阶水平的回答了。第三个是接入微信公众号或企业微信通知。宿舍报修处理完成、晚归违纪记录生成通过消息模板推送给学生这在真实宿舍管理中很有需求。我自己实际操作下来的体会是这类管理系统类的毕设项目真正拉开差距的地方从来不是技术栈多新而是业务规则是否闭环、数据设计是否经得起追问、演示是否有故事线。宿舍管理系统看起来平平无奇但把入住、调宿、退宿、报修、卫生检查这几条业务线走通把事务、关联查询、权限控制这几个技术点讲清楚它就是一个非常扎实的练手项目。拿这套源码做二次开发时强烈建议先把表结构吃透再动代码——凭我这几年折腾课设项目的经验十个人里头有八个在改功能时被数据表设计拖了后腿。最后再分享一个小技巧项目跑通之后给自己录十分钟的演示视频边操作边讲解。录的时候会发现很多我以为很熟的操作其实会卡壳比如某个查询条件忘了怎么触发、某个按钮点击后数据没刷新。把这些卡壳点记录下来就是一份特别好用的个人调试笔记。课程设计如此工作后做项目也如此。