SSM+Flask双技术栈，打造高校宿舍管理系统全栈实战

一说宿舍管理系统，每年毕业设计季它都是“流量担当”。你搜一下“Java+SSM+高校宿舍管理系统”，能出来一大批带源码、带论文（也就是标题里那个LW）、带调试文档和讲解视频的完整项目。作为一个把这些年帮人调过各种烂代码、也带过不少新人做完整个系统的老开发，我可以明确告诉你：SSM+Flask这种“双技术栈”组合在毕设和实训项目里非常讨巧。SSM负责学生管理、宿舍分配、报修、查寝这些核心业务，Flask则专门干统计报表、数据可视化、定时消息推送这种“杂活”，各用各的强项。

这篇博文我会按照“真实做了一遍这个系统”的口径，从技术选型、功能拆解、数据库设计、SSM核心实现、Flask辅助服务、部署调试这条完整链路来复盘。不管你是准备拿它当毕设、课设，还是纯粹想练手SSM+Flask混合开发，跟着走一遍，收获绝对比你自己瞎摸三天大得多。

1. 项目全貌与技术选型：为什么是SSM夹带Flask

1.1 SSM主链路的价值与定位

SSM就是Spring+SpringMVC+MyBatis这三个框架的组合。现在很多新人一上来就学Spring Boot，反而对SSM这种“手动组装”的方式没什么概念。但SSM在高校宿舍管理这种偏传统的管理信息系统项目里，优势非常明确：它结构清晰，分层的约束感极强。

Controller接收请求、Service写业务逻辑、Mapper管数据库操作，这种三层结构在代码量不大但功能点很散的管理系统里特别合适。比如“学生入住宿舍”这个动作，Controller里接收学生ID和房间ID，Service里要校验房间是否满员、学生是否已入住、是否处于退宿状态，最后通过Mapper更新房间已住人数。每一步都落在具体的层里，新人写完不容易乱。而且SSM里的MyBatis比Spring Data JPA更直观，SQL你完全自己掌控，尤其是多表关联查询、动态拼接条件这种场景，写起来非常顺手。

这类系统之所以常年被选为毕业设计，是因为它“麻雀虽小五脏俱全”。对外它是给学校宿舍管理用的一套信息化工具，对内它把Java Web开发的核心知识点全串起来了：IOC容器管理对象、SpringMVC请求流转、MyBatis映射和事务控制，哪一个单独拿出来都是Java面试的必考范围。

1.2 Flask在这个项目里到底干什么活

为什么要单独加一个Flask？很多第一次接触这种组合的人会问，我一个SSM项目不都能把业务做完吗？确实能做完，但做得“不漂亮”。宿舍管理不只是增删改查，老师必查的数据包括：各个楼栋的入住率、每个年级/学院的住宿分布、晚归未归趋势、报修高发宿舍排行。这些统计如果全部用SSM手写SQL再做页面，代码量上去了，页面还不一定好看。

Flask的角色是“数据加工与可视化服务”。它和SSM共用同一个MySQL数据库，SSM管数据录入和修改，Flask管只读统计和图表展示。你可能在系统里看到“可视化大屏”菜单，一点进去是ECharts柱状图、饼图、趋势图，这些图表的数据接口就是Flask吐出来的JSON。为什么不用FastAPI替代Flask？不是不行，但毕设场景下Flask的资料更多、部署教程更全、和老代码的兼容性也更好，FastAPI的异步特性在这个场景下完全用不出来，反而因为Pydantic、ASGI这些额外概念给联调添堵。稳妥压倒一切，这就是选型逻辑。

1.3 整体架构与数据流向

整个系统的运行形态是这样的：Tomcat跑SSM主应用，Flask独立进程跑在另一个端口。浏览器访问系统时，SSM应用负责页面跳转、业务表单、登录鉴权；遇到需要展示统计图表、报表下载的地方，前端直接向Flask发起Ajax请求。两边都连接同一个MySQL实例，只是Flask这边只做查询、不做写入。

数据流向可以概括成三句话：宿管员和学生通过SSM页面录入业务数据，数据落库；Flask定时或实时读取业务表，计算统计指标后生成JSON接口；前端图表组件获取JSON渲染可视化。这样做的好处是互不干扰，Flask进程挂了，核心业务照常跑；SSM重启维护时，也已经生成好的统计缓存数据还在，不会全面瘫痪。架构上不复杂，却能清清楚楚解释清楚“多服务协作”这件事，答辩时这是加分项。

2. 业务需求与功能模块拆解

2.1 角色权限是管理系统的地基

宿舍管理系统不像电商系统那样有复杂的用户成长体系，角色只有三种：学生、宿管员、系统管理员。但权限设计不能因为角色少就糊弄。我见过不少毕设代码，前端隐藏一下按钮就算权限控制了，后端接口裸奔，谁都能调，这是最大的安全败笔。

合理的做法是后端用拦截器加注解双重控制。系统管理员能管理楼栋、房间、用户账号，能把某个学生从A栋调到B栋；宿管员负责录入查寝记录、登记晚归学生、处理宿舍报修单；学生只能看自己的住宿信息、提交报修、查看公告。登录成功后把用户角色写入Session，写一个权限拦截器，放行登录接口、静态资源，其余接口都要校验Session和角色注解。表设计上不需要单独的权限表，一张学生表里加个角色字段就够了，因为三种角色正好是三种不同的人员身份，反而是“管理员账号”要不要单独建表要看具体需求。

2.2 一个宿舍管理系统不能只做“登记入住”

很多初做这个题目的人把系统简化成了学生信息管理加房间分配，这是不对的。高校宿舍管理的核心痛点在于“日常事务流”，至少这六块要做扎实：

• 楼栋与房间管理：宿舍楼基本信息、房间类型（四人间/六人间）、床位数量、已住人数、房间状态（空闲/部分入住/已满员/维修中）。这是整个系统的基础数据，所有业务都围绕房间展开。
• 入住与调宿流程：新生入住、在校生调宿、毕业退宿。重点是流程校验：目标房间没有空床位、学生当前没有未迁出的住宿记录。
• 报修管理：学生提交报修单（宿舍号、故障描述、图片选填），宿管员接单、派工、填写维修结果，学生确认完成。报修单要有状态机流转，否则就会变成“报修了但没有下文”。
• 查寝与晚归登记：宿管员按日期登记查寝结果、晚归学生名单，迟到早退的去向说明。这部分最喜欢考连表查询，按日期查、按楼栋查、按学生查，SQL写得好不好一眼可见。
• 水电表管理：每月抄表录入，生成宿舍用水用电明细，对异常用量标红提醒。
• 公告与通知：宿管发布停水停电通知、安全检查通知等。公告要有置顶、按楼栋可见范围过滤。

每一条都不是独立存在的。比如调宿要先看有没有未完成的报修，退宿时要结清水电费余额，查寝异常记录会联动推送晚归名单。真正把这些流程串起来，系统才算“活”了。

2.3 容易被忽视的边界场景

边界场景是拉分项。普通毕设做的是“正常流程能跑通”，高分毕设还会处理这些场景：批量退宿（一个宿舍毕业全退）、批量入住（新生入学导入Excel）、宿舍合并（两个低入住率宿舍合并清理一间）、违规电器登记、离校清点资产。这些场景不复杂，核心就是循环调Service方法和事务边界的把控。批量导入时几千条数据一次性插入，MyBatis用批量insert的foreach批量处理，效率和异常回滚都要考虑。

答辩时老师经常问的一句话是“你考虑过哪些特殊情况”。你如果能把上面这些场景讲清楚，说明你确实做了需求分析，而不是把网上的代码抄了一遍。

3. 数据库设计：这十张表撑起整个系统

3.1 核心表结构设计思路

数据库是管理系统的灵魂。我在设计这类项目时，基础表至少包括十张：宿舍楼表（dorm_building）、房间表（dorm_room）、学生表（student）、住宿关系表（student_dorm）、报修单表（repair_order）、查寝记录表（check_record）、晚归登记表（late_record）、水电读数表（utility_record）、公告表（announcement）、访客登记表（visitor_record）。有精力还可以加违规登记表、调宿申请表。

先挑重点说字段设计。宿舍楼表很简单：楼号、名称、楼层数、管理员ID。房间表是关键：所属楼栋ID、房号、房间类型、床位容量、已住人数、房间状态，注意这里要建一个楼栋ID和房号联合索引，因为日常查询全是“某栋楼有哪些房间”。学生表围绕校园场景展开：学号、姓名、性别、学院、专业、年级、手机号、角色、登录密码（BCrypt加密）、状态（在校/离校）。住宿关系表管理“谁住哪”这一动态事实：学生ID、楼栋ID、房间ID、入住时间、迁出时间、状态。为什么要单独建这张表，而不是直接在student表里加个room_id字段？因为学生换宿舍是历史事实，直接覆盖字段就把历史丢了，后面统计“这栋楼住过多少人”就做不出来。

3.2 关联关系与约束设计

关联关系的核心约束是“一个学生同一时间只能有一个有效住宿记录”。这个约束靠业务校验，不能只靠数据库唯一索引，因为唯一索引没法保证“同一时间有效”。正确做法是插入住宿记录前，先查该学生有没有状态为“在住”的记录，没有才允许插入，并且这两个操作要放在同一个事务里。

报修单表字段除了常规问题描述、报修人、宿舍地址、联系电话，还要有状态字段：待接单、维修中、已完成、已确认、已取消。每次状态变更都记录更新时间，最后可以统计“平均维修时长”。水电读数表做一个联合唯一约束：房间ID加月份，防止同一个月重复录入，这是数据库层面兜底的好设计。

3.3 几个容易踩坑的字段设计细节

嵌套坑一：房间表的“已住人数”字段。它是冗余字段，因为正常的统计可以由住宿关系表count来得到。但查询房间列表时每次都count，性能不好。做法是维护冗余字段，但所有增删住宿记录的地方都要同时更新它。这一步特别容易漏，漏了就会发现房间列表和实际住宿人数对不上。解决方案是数据库层面不要逻辑散落，而是在Service层封装统一方法，学生入住的唯一入口方法里同时完成住宿记录新增和已住人数自增。

嵌套坑二：逻辑删除。学生退宿、取消报修都不要物理删除记录，加一个is_deleted字段，默认0，删除时置为1。查询语句默认加上is_deleted=0条件。物理删除一时爽，后面对账火葬场。

嵌套坑三：日期字段统一用datetime，不要用varchar存时间。因为后面你要做按月份统计水电、按日期排查晚归，字符串时间用不了时间函数，还得先转换，徒增麻烦。

4. SSM核心实现与关键代码片段

4.1 分层结构说明书

项目结构尽量按照规范建包：controller、service、mapper、pojo、interceptor、config、util。pojo里放实体类、VO（视图对象）、DTO（传输对象），比如后端返回给前端的时间格式统一包装成ResultVO，里面放code、message、data三个字段。前端拿到code为200才渲染数据，错误统一在errorhandler里处理，不要在Controller里到处try-catch返回奇怪结构。

Service层接口和实现分离是SSM项目的习惯写法。虽然代码量上去了，但面试和答辩时这个点很有讨论价值：面向接口编程带来的好处就是方便替换实现、方便测试mock。Controller层一定要薄，只做参数接收和结果返回，业务判断全部下沉到Service，不然代码烂起来非常快。

4.2 MyBatis动态SQL解决多条件组合查询

宿舍管理系统里最典型的场景就是多条件查询：学生管理页要按学号、姓名、学院、年级、宿舍楼栋任意组合筛选。用MyBatis的 和 标签可以零散拼接SQL，干净优雅。下面是我常用的写法：

<select id="selectStudentPage" resultType="com.example.pojo.Student"> SELECT s.*, b.name AS building_name, r.room_no AS room_no FROM student s LEFT JOIN student_dorm sd ON s.id = sd.student_id AND sd.status = '在住' LEFT JOIN dorm_room r ON sd.room_id = r.id LEFT JOIN dorm_building b ON r.building_id = b.id <where> s.is_deleted = 0 <if test="studentNo != null and studentNo != ''"> AND s.student_no LIKE CONCAT('%', #{studentNo}, '%') </if> <if test="name != null and name != ''"> AND s.name LIKE CONCAT('%', #{name}, '%') </if> <if test="college != null and college != ''"> AND s.college = #{college} </if> <if test="buildingId != null and buildingId != ''"> AND r.building_id = #{buildingId} </if> </where> ORDER BY s.create_time DESC </select>

这里有两个细节值得讲。第一，用LEFT JOIN而不是INNER JOIN，因为未分配宿舍的学生也要显示出来，方便宿管员统一安排入住。第二，参数非空判断要放在后端Controller里做好数据清洗，空字符串和null统一转为null，#{}和${}不要混用，所有外部参数一律用#{}防SQL注入。

4.3 宿舍分配与调宿的并发控制

宿舍分配是典型的高并发隐患点。想象迎新当天，上千个学生在同一时段申请入住，如果两个请求同时查到最后一间房的最后一个床位，都判断“未满员”，然后都插入住宿记录，房间超员了。这个问题的本质是经典“超卖”。

解决方案是在分配房间的SQL里加条件更新，或者使用悲观锁。我实践中更喜欢“原子更新加行级锁”方案：

@Transactional public boolean assignRoom(StudentDormDTO dto) { // 1. 原子更新，只有已住人数小于容量时才会更新成功，防止超卖 int rows = dormRoomMapper.increaseOccupiedCount(dto.getRoomId()); if (rows == 0) { throw new BusinessException("该房间已满员，分配失败"); } // 2. 插入住宿关系 StudentDorm sd = new StudentDorm(); sd.setStudentId(dto.getStudentId()); sd.setRoomId(dto.getRoomId()); sd.setStatus("在住"); sd.setCreateTime(new Date()); studentDormMapper.insert(sd); // 3. 更新学生表中的住宿状态 studentMapper.updateDormStatus(dto.getStudentId(), "已住宿"); return true; }

对应SQL里的增加已住人数操作要写成一行原子语句：

UPDATE dorm_room SET occupied_count = occupied_count + 1 WHERE id = #{roomId} AND occupied_count < capacity

这样即使并发过来，数据库行锁也会保证只有一个请求满足occupied_count < capacity条件，另一种情况直接反馈“已满员”。事务注解保证三步操作要么全成功要么全回滚。这是这个项目里最有含金量的代码之一，答辩时主动讲这段，老师一听就知道你不是只会增删改查。

4.4 Session登录态与权限拦截

登录逻辑用SpringMVC拦截器实现。写一个AuthInterceptor实现HandlerInterceptor，preHandle方法里从Session取当前用户，取不到就重定向到登录页，如果是Ajax请求就返回未登录的JSON状态码。再写一个PermissionInterceptor，检查当前用户角色是否满足接口要求的角色码。两种拦截器分别注册到不同URL路径：/admin/**需要管理员角色，/student/**需要学生角色。

跨域和Ajax的登录态要保持好，前端每次请求带上Cookie。别小看这一块，很多联调事故都出在Session配置不一致上。

5. Flask辅助服务的落地实践

5.1 与SSM共用MySQL，如何避免表结构冲突

Flask这边我建议不要用Flask-SQLAlchemy重写实体模型。原因很简单：SSM里MySQL表结构已经定死了，用ORM反而容易因为模型对应不上而出幺蛾子。干脆用PyMySQL直接连数据库执行只读SQL，简单直接。连接信息放在环境变量里，不要硬编码在代码里。

import pymysql from flask import Flask, jsonify from flask_cors import CORS app = Flask(__name__) CORS(app, supports_credentials=True) def get_conn(): return pymysql.connect( host='127.0.0.1', user='root', password='your_password', database='dorm_db', charset='utf8mb4', cursorclass=pymysql.cursors.DictCursor )

每个接口内部独立建立连接查询，查完即关。数据量不大，没必要做连接池。统计逻辑都放在SQL里，别在Python里做循环求和，能吃透SQL就吃透SQL，效率高好维护。

5.2 宿舍入住率统计与可视化API

可视化是Flask的杀手锏应用。比如入住率接口就是查出每栋楼的总床位数和已住人数：

@app.route('/api/building/occupancy') def building_occupancy(): sql = """ SELECT b.name AS building_name, SUM(r.capacity) AS total_bed, SUM(r.occupied_count) AS occupied_bed, ROUND(SUM(r.occupied_count) / SUM(r.capacity) * 100, 1) AS rate FROM dorm_building b JOIN dorm_room r ON r.building_id = b.id WHERE b.is_deleted = 0 GROUP BY b.id, b.name """ conn = get_conn() try: with conn.cursor() as cursor: cursor.execute(sql) result = cursor.fetchall() return jsonify({"code": 200, "data": result}) finally: conn.close()

前端用ECharts，拉取这个接口后把building_name做X轴，rate做Y轴，一个漂亮的入住率柱状图就出来了。我建议可视化页面至少包含：各楼栋入住率柱状图、各学院住宿人数饼图、近7天晚归人数折线图、报修类型分布图。这些图一上，整个系统的档次立马不一样。

5.3 Flask的部署、跨域与端口规划

Flask不要和SSM共用8080端口，容易冲突。我在项目中习惯让SSM跑8080，Flask跑9001。浏览器前端请求Flask接口时存在跨域，所以我上面代码写了flask_cors，allowed origins可以指定就是http://localhost:8080，不要全部放开。如果项目上线部署在服务器，更推荐用Nginx反向代理，把/api/statistics/**路径转发到127.0.0.1:9001，和SSM在同一个域名下，跨域问题自动消失。

Flask返回JSON时有一个经典坑：中文乱码。客户端看到的是Unicode转义序列，完全无法阅读。在Flask的app配置里加上两句：

app.config['JSON_AS_ASCII'] = False app.config['JSONIFY_PRETTYPRINT_REGULAR'] = True

前者解决中文转义，后者让返回的JSON有缩进，调试阶段看着舒心。

5.4 定时任务与消息推送

No. “Flask定时任务”这个功能也很有亮点。比如每天晚上11点，系统自动统计当天晚归未归登记名单，推送给宿管员。用Flask的扩展库APScheduler实现，两句话搞定定时任务。

from apscheduler.schedulers.background import BackgroundScheduler def night_check_job(): # 查当天 check_record 里 status in ('晚归', '未归') 的记录 # 然后把结果写入一张推送表，或者调用模拟消息接口 pass scheduler = BackgroundScheduler() scheduler.add_job(night_check_job, 'cron', hour=23, minute=5) scheduler.start()

有两点要提醒：第一，调试模式下Flask的debug=True会导致定时任务注册两次，因为werkzeug会重启子进程，解决方法是用环境变量控制或者使用reload=False运行Flask。第二，如果这里要推送的就是发送给宿管员微信/邮件，不要真去对接第三方API，会牵扯到复杂的注册审核流程。封装一个模拟消息发送工具类，把推送记录打印到日志，再落一张消息表即可。毕设情景下，面试时把这个东西讲出来，比对接一个跑不通的微信模板消息有用得多。

6. 部署调试与排查日记

6.1 本地联调环境清单

环境配置是第一道门槛。这个项目我推荐的组合是：JDK 1.8 + Maven 3.6 + Tomcat 8.5 + MySQL 5.7/8.0 + Python 3.8 以上。JDK别用17，很多老SSM项目在JDK9以上会出现模块访问限制报错。Maven依赖中，Spring用5.1.x，MyBatis用3.5.x，mybatis-spring用2.0.x，这个版本组合经过大量项目检验，踩坑最少。Flask这边依赖其实只需要flask、flask-cors、pymysql、apscheduler四个包就够。

启动顺序有讲究：先启动MySQL，再启动Tomcat，最后启动Flask。Flask启动晚没关系，前端页面打开可视化页面前它已经ready就行。如果顺序反了，Flask可能连不上数据库还来不及重试，界面直接一大片报错数据。

6.2 我实际调试时踩过的坑合集

这些坑全是我在真实调试同类项目时遇到过的，几乎每一个身边人都踩过，整理成表格收藏备用。

踩坑最容易发生在一个位置：把时间精力花在“这个框架怎么配”上，而不是“业务逻辑怎么完善”。新人常犯的一个错误就是配置配了一整天，结果发现是版本冲突。我的办法是永远先建一个最小Demo，能查询一条数据再开始写复杂业务。任何依赖升级前先查兼容性，不随意乱升版本。

6.3 调试利器与日志规范

日志规范要养成习惯。SSM端我用logback，输出到日志文件和控制台两份，级别设置成DEBUG。每写一个接口先打出入参日志，Service完成打业务关键操作日志，错误日志一定输出堆栈。看起来挺啰嗦的，但排查“数据为什么没插入”“条件为什么没生效”时全靠日志定位。Flask端就简单了，Flask的logger配合Python的logging模块，请求进来打一条，SQL查询结果打印几条，也够用了。

7. 关于答辩与面试的几句心得

项目做完不是终点，能把项目讲清楚才是关键。很多人光顾着写代码，到答辩时连自己项目架构都说不清，那就太亏了。我建议当你把整个系统实现完毕后，花点时间梳理这几类问题：Spring IOC和AOP在项目中具体用在哪了（IOC管理Service和Controller对象，AOP统一切事务和日志）；SpringMVC的工作流程（请求如何从DispatcherServlet流到Controller再到View）；MyBatis的#{}和${}区别（防注入用#{}，动态表名才用${}）；数据库死锁或超卖如何解决（宿舍分配那段事务加原子更新）；Flask和SSM是怎么通信的（同一个MySQL实例，各自独立进程）。

另外，Java面试中SSM相关的话题几乎是必考，拥有一个亲手完整搭建的SSM项目，能让你在“讲项目”环节有话可说。你做完这个系统，等于把Spring容器、事务管理、MyBatis映射、拦截器、Filter、Maven依赖管理、SQL调优全过了一遍，这是单纯背面试题得不到的底气。

最后再分享一条个人经验：这类全栈项目做到后期，真正拉开差距的往往不是炫酷技术，而是基础功。比如你有没有在异常处理里区分业务异常和系统异常、有没有在前端做表单校验、有没有给关键SQL加索引、有没有给敏感操作做操作日志。把这些细节补到位，项目才不是“能跑”而是“能用”。我这个系统做下来最大的感受就是：一个宿舍管理系统，处理好了并发分配、事务回滚和权限校验，你在后台系统开发领域已经具备了相当强的实战能力。这些都补完，你就可以自信地把整个项目交付给任何学校或宿管场景使用了。