1. 选题背景：为什么学生公寓管理APP能成为毕业设计的“万能解”
先聊点实在的。每年毕业季，我都能看到大量同学在选题上反复纠结：既要技术栈主流、工作量适中，又要业务逻辑好讲、演示效果好，还得能顺利通过答辩。说实话，能同时满足这四个条件的题目并不多，但“基于Spring Boot的学生公寓管理APP”恰恰是一个经典中的经典——它不挑基础、不挑学校、不挑导师喜好，甚至不管你是计算机专业还是信息管理相关方向，都能找到合适的切入点。
我见过不少同学做电商系统、点餐系统或者博客系统，不是说这些题目不行，而是它们的业务复杂度要么太低容易撞车，要么太高容易失控。学生公寓管理这个场景恰好卡在一个非常舒服的位置：用户角色天然是多端的，业务链条是完整闭环的（从入住、报修、缴费到退宿），数据模型清晰但不简单，而且每届都有真实的宿舍管理需求做参照。尤其对Spring Boot这套技术栈来说，它几乎能覆盖你学到的大多数核心知识点：Spring MVC、MyBatis或JPA、Spring Security、文件上传、定时任务、WebSocket消息推送，全都能在同一个项目里找到用武之地。
更要紧的是，这个题目自带“演示优势”。答辩现场你让评委掏出手机扫码体验一个真实可操作的公寓管理APP，比你对着PPT念十分钟架构图有说服力得多。管理员端、学生端、楼栋数据、报修流程、宿舍分配，这些都能做成看得见摸得着的界面流转，评委的注意力自然会被带进你的演示节奏里。
写这篇文章，就是希望能帮你把整个项目的前因后果、技术选型、模块拆分、数据库设计、核心代码实现、常见坑点全部讲透，让你既能真正理解这个项目的本质，也能在答辩时做到心中有数。
2. 技术选型解析：Spring Boot为什么是毕业设计的最优解
2.1 后端为什么选Spring Boot而不是其他框架
很多同学在选题后会纠结：要不要用Spring Boot，还是用更轻量的框架？或者干脆用Python的Django/Flask？我的观点很明确：如果你以“稳妥过关+三年后还能看懂自己的代码”为目标，Spring Boot几乎是唯一不需要犹豫的选择。
原因有以下几点。第一，Spring Boot的生态成熟度在高校教学体系里是“统治级”的，你的导师大概率熟悉它，遇到问题时他能接住你。第二，Spring Boot的自动配置让开发效率极高，不用像传统SSH项目那样写一大堆XML配置，一个注解就能把数据库连接池、事务管理、参数校验全部搞定。第三，它的分层架构天然适合写文档和画架构图——Controller层、Service层、Mapper层，每层职责单一，答辩时你能很清楚地讲出请求从进入控制器到返回结果的全过程。
但这不代表选择Spring Boot就万事大吉了。我见过太多同学把Spring Boot当“黑盒”用：接口能调通就完事，问起原理一问三不知。答辩时一旦被追问“你的事务是怎么控制的”“你的索引为什么这么建”，立马露馅。所以，在用Spring Boot搭建之前，建议你先搞清楚三个最基础的问题：IoC容器到底帮你管理了什么、Spring MVC的请求映射是怎么匹配的、MyBatis的代理Mapper是如何生成的。不需要背源码，但得能用自己的话讲明白。
2.2 前端与移动端方案：怎么做才算“APP”
“学生公寓管理APP”这个题目有个隐蔽难点：APP到底指什么？是原生安卓开发？是微信小程序？还是H5套壳？这是我在指导模拟项目X时经常和学生确认的第一个问题——技术方案如果不先定死，后面返工的成本极高。
主流的做法有三种，各有利弊。第一种是安卓原生+Spring Boot，技术上最“正统”，但开发周期长，而且你面临的是一个完整APP的界面适配、生命周期管理、网络请求封装等工作量，一个人做容易心力交瘁；第二种是微信小程序+Spring Boot，国内高校答辩接受度极高，因为小程序本身就有“APP”的外壳形态，而且开发者工具上手比Android Studio快得多；第三种是H5移动端网页，也就是用Vue或React做一个适配手机的Web端，打包进WebView当成APP用。
我的建议：如果时间充裕（三个月以上），选安卓原生；如果时间紧张（一到两个月），选小程序；如果你基础一般，想稳扎稳打，选H5响应式页面。无论选哪种，后端的接口设计方式都是一样的——先定义好RESTful接口，再让前端按接口对接。这样有一个巨大好处：即使你中途要换前端技术栈，后端代码一行都不用改。
2.3 数据库选型：MySQL够不够用
学生公寓管理系统这个体量，MySQL完全够用，甚至有点大材小用。不要为了显得厉害去引入PostgreSQL或者Oracle，也不要一开始就上Redis缓存——等你在演示时暴露了“缓存和数据库不一致”的问题，反而给自己挖坑。
MySQL在毕业设计里最友好的点是：你不需要额外安装软件，IDEA里装个插件就能看表结构；网上关于MySQL的教程多到看不完；你导师随便打开Navicat也能帮你排查问题。数据库表设计留到后面的章节细讲，这里只强调一个原则：学生公寓数据量级最多是几千学生、几万条记录，完全不需要分库分表，你只需要把索引建对、把外键逻辑理清、把冗余字段控制在合理范围内，就已经超越70%的同题作品了。
2.4 开发工具链与版本控制
无论后端用IDEA还是Eclipse，前端用什么框架，最后项目交付时你都得面对一个问题——怎么把代码整洁地交给导师看。我特别建议从第一天开始就用Git管理代码，不用GitHub也没关系，哪怕本地仓库也行。很多同学喜欢一次性写完代码再初始化版本库，结果项目崩了想回滚都回不了，只能对着满屏报错发呆。
另外，Java版本尽量统一，不要用Java 8写代码却给导师的电脑配上Java 17的环境。Spring Boot 2.x配Java 8/11最稳妥，如果你非要用Spring Boot 3.x，就要注意javax包名全部变成jakarta，这个坑每年都有一波人踩。
3. 业务架构与模块拆分：从需求文档到功能的思维转换
3.1 角色定义：谁在用这个系统
学生公寓管理系统的核心是“多角色协同”。我见过一些同学上来就画ER图，结果画到最后自己都分不清哪些数据属于谁，这其实是因为角色没有先定明白。按最常见的情况，系统至少要有三种角色：超级管理员（通常指宿管中心负责人）、楼栋管理员（每栋楼一个）、学生用户。
超级管理员管全局：能看到所有楼栋、所有宿舍、所有报修工单，具备最高的数据权限；楼栋管理员只管自己那栋楼：负责房间分配、查寝记录、报修派单；学生用户则是系统的“高频使用者”：查看宿舍信息、提交报修、查询水电费、申请调宿。
这个角色拆分同时也决定了权限模型的设计。我建议直接用Spring Boot生态里成熟的权限框架，不要自己写一套session判断的逻辑。用一个基于角色的访问控制模型就能覆盖：给每个用户分配一个角色代码，后端接口通过注解或者自定义拦截器校验角色是否匹配。答辩时你可以说这是RBAC模型的落地，能提升不少技术分。
3.2 核心模块清单
在业务功能上，我梳理了一个适合大多数毕业生参考的模块清单。不要贪多，把每个模块做扎实比堆砌一堆半成品功能强得多。
第一个模块是用户认证与个人信息管理，包括登录、退出、忘记密码（通过邮箱或手机验证码）和基础资料修改。第二个模块是宿舍信息管理，包括楼栋列表、楼层房间数、宿舍当前床位状态、宿舍成员列表。第三个模块是入住与退宿管理，包括学生入住登记、分配宿舍、退宿操作、换寝申请。第四个模块是报修管理，这是全系统最能体现状态流转的业务：学生提交报修单，楼栋管理员接单，维修人员上门处理，学生确认完成。第五个模块是水电费管理，包括每月抄表录入、费用计算、账单推送、线上缴费记录。第六个模块是数据统计，包括楼栋入住率、报修响应时长、月度水电费趋势。
如果你希望再增加一个亮点能力，可以考虑加入“访客登记”和“消息通知模块”。访客登记很简单，就是进楼登记、离楼签出；消息通知可以考虑使用Spring的事件机制配合WebSocket推送，让学生端能实时收到报修进度或账单提醒。
3.3 数据库设计：核心表结构如何落
数据库是整个项目的“地基”，地基不稳后面必然出幺蛾子。这里我给出一个经过多次验证的建表方案，你可以根据自己的业务做裁剪。
用户表：字段有用户ID、姓名、学号、手机号、密码哈希、角色编号（1超级管理员、2楼栋管理员、3学生）、头像URL、创建时间、状态（正常/禁用）。
楼栋表：楼栋ID、楼栋名称、楼层数量、每层房间数、楼栋管理员ID（外键关联用户表）、备注。
宿舍表：宿舍ID、楼栋ID（外键）、房间编号、房间类型（4人间/6人间）、当前人数、容纳人数、宿舍状态（空闲/部分入住/已满）。
入住记录表：记录ID、学生ID（外键）、宿舍ID（外键）、入住日期、退宿日期、状态（在住/已退宿）。
报修单表：工单ID、报修学生ID（外键）、宿舍ID（外键）、报修类型（水/电/家具/门窗等）、报修描述、紧急程度（普通/紧急）、状态（待接单/维修中/已完成/已评价）、接单管理员ID、维修人员姓名、完成时间、评价内容。
水电费账单表：账单ID、宿舍ID（外键）、月份、用电量、用水量、电费单价、水费单价、总费用、缴费状态（未缴/已缴）、缴费时间。
在设计时，你要特别注意两个细节。第一，学生与宿舍的关系不要直接挂在用户表上，而应该通过入住记录表来表达，这样换寝、退宿这些操作才有数据支撑，不会把历史记录弄丢。第二，凡是涉及金额的字段，数据库里尽量用decimal类型，不要用float或double，否则会出现0.1加0.2不等于0.3的尴尬。答辩时一旦被问到“为什么金额用decimal”，这就是你的加分点。
3.4 接口风格：RESTful API设计规范
后端接口设计要做到“看一眼URL就知道是干嘛的”。我通常给学生的规范是：资源用名词复数，操作用HTTP方法。例如GET /api/dormitories表示获取宿舍列表，POST /api/dormitories表示新增宿舍，PUT /api/dormitories/{id}表示更新宿舍信息，DELETE /api/dormitories/{id}表示删除宿舍。
这里有一个隐藏加分项：统一响应体。不要每个接口返回的JSON结构都不一样，应该定义一个全局响应类，像Result.success(data)和Result.error(code, msg)这样。这样前端解析数据会非常轻松，你也能在后端拦截器里统一处理异常，答辩时讲“我做了统一异常处理和统一响应格式”，效果比单纯说“我做了一个项目”强得多。
4. 核心代码实现：关键模块从零到一
4.1 项目初始化与工程结构
初始化一个Spring Boot项目很简单，打开Spring Initializr，选择Java版本和Spring Boot版本，勾上Spring Web、Spring Security、MyBatis Framework、MySQL Driver、Validation、Lombok这几个依赖即可。
工程结构建议按这样的分包方式：
com.example.apartment ├── controller // 控制器层，只做参数接收和结果返回 ├── service // 业务层，写核心逻辑 │ └── impl ├── mapper // 数据访问层，继承BaseMapper ├── entity // 数据库实体类 ├── dto // 前端请求参数对象 ├── vo // 返回给前端的视图对象 ├── config // 配置类，如CORS、拦截器、加密配置 ├── common // 全局响应体、异常处理、工具类 ├── security // JWT认证与过滤器 └── task // 定时任务，如月度账单生成别小看分包这件事，很多人的代码写的像“一坨”，就是因为所有类都丢在一个包下面。分好包，不仅你自己开发时找文件快，导师和评委看代码时也会觉得你内心有章法。
4.2 登录鉴权：JWT令牌如何接入
学生公寓管理APP涉及多端访问，传统的Session登录不够友好，移动端每次请求都带Session ID容易被跨域问题困扰。更规范的做法是使用JWT（JSON Web Token）来做无状态认证。
用户登录时，后端校验账号密码，成功后签发一个包含用户ID、角色、过期时间的JWT令牌返回给前端。前端后续请求在请求头里携带Authorization: Bearer <token>，后端通过过滤器解析令牌、校验合法性，然后把当前用户信息放入请求上下文。这里给出一个核心过滤器的大致逻辑：
public class JwtAuthenticationFilter extends OncePerRequestFilter { @Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws ServletException, IOException { String token = request.getHeader("Authorization"); if (token != null && token.startsWith("Bearer ")) { token = token.substring(7); try { Claims claims = JwtUtil.parseToken(token); request.setAttribute("userId", claims.get("userId")); request.setAttribute("role", claims.get("role")); } catch (Exception e) { response.setStatus(401); response.setContentType("application/json;charset=UTF-8"); response.getWriter().write("{\"code\":401,\"msg\":\"登录状态已过期\"}"); return; } } else { response.setStatus(401); response.getWriter().write("{\"code\":401,\"msg\":\"未提供登录凭证\"}"); return; } chain.doFilter(request, response); } }你不要觉得这个代码复杂，其实核心就三件事：取Header里的Token、解析Token、放行或者拦截。有了这个过滤器，你就能在任何Controller方法里直接通过request.getAttribute("role")判断当前操作者的身份了。
不过要提醒的是，JWT很容易被一些教程讲得神乎其神，但你自己心里要明白，JWT并不能解决所有安全问题。它防不了XSS和CSRF，也防不了客户端把令牌泄露出去。毕业设计阶段做到“登录有令牌保护、接口有角色控制”已经足够，不要在方案上过度设计。
4.3 宿舍分配与调宿：事务与并发控制的经典场景
宿舍管理最体现后端功底的业务是“分配宿舍”。这个功能背后有一个隐患：并发问题。想象一下两个学生同时申请同一个四人间的最后一个床位，系统如果不做控制，就会超卖，最后一个人也没有住进去。
解决思路是：在数据库层面加锁，或者在Java代码里用事务配合分布式锁（当然这个体量不需要分布式锁）。最简单实用的方案是使用数据库的乐观锁或者悲观锁，这里演示悲观锁的一种写法：
@Transactional public void assignDormitory(Long studentId, Long dormitoryId) { // 强制走主键查询并锁定该宿舍行 Dormitory dormitory = dormitoryMapper.selectByIdForUpdate(dormitoryId); if (dormitory.getCurrentCount() >= dormitory.getCapacity()) { throw new BusinessException("该宿舍已满员"); } // 更新入住人数 dormitoryMapper.increaseCurrentCount(dormitoryId); // 创建入住记录 checkInRecordMapper.insert(new CheckInRecord(studentId, dormitoryId)); }selectByIdForUpdate对应的SQL需要写成这样：
SELECT * FROM dormitory WHERE id = #{id} FOR UPDATEFOR UPDATE的意思是，事务在提交之前，其他事务想修改这一行都会阻塞等待。这样两个同学同时申请时，只有一个能成功更新人数，另一个会看到已满员的提示。
答辩时这个逻辑非常值得讲，因为它展示了你对“事务、并发、超卖”这些后端核心问题的理解。哪怕你只是用了最基础的悲观锁，也比那些只能在数据库里做增删改查的项目高出一个档次。
4.4 报修工单模块：状态机驱动的业务流转
报修管理是学生公寓系统的灵魂模块，因为它的状态流转最清晰，最适合做展示。在设计时，不要把所有状态逻辑散落地写在Service里到处if/else，建议定义一个枚举来管理状态：
public enum RepairStatus { PENDING(0, "待接单"), PROCESSING(1, "维修中"), COMPLETED(2, "已完成"), CONFIRMED(3, "已确认"); private final int code; private final String desc; }然后约定状态转换的规则：待接单可以转为维修中，维修中可以转为已完成，已完成可以转为已确认，已确认是终态。凡是状态不符合规则的流转，后端就直接抛异常拒绝。
这样做的好处一是代码清晰易读，二是你可以在前端把不同状态渲染成不同颜色的标签，用户一目了然。三是答辩时可以讲“状态机”，这个术语在很多评委那里印象分很高。
报修模块还有一个细节值得做：超时提醒。比如楼栋管理员接单后24小时未处理，系统应该自动提醒。这个用Spring的定时任务就能搞定，写一个@Scheduled(cron = "0 0 2 * * ?")每天凌晨两点扫描未处理的工单，发送通知消息。定时任务的触发逻辑不难，但做了它，你的项目就从“被动响应”变成了“主动服务”，这又是一个答辩加分项。
4.5 水电费生成：用定时任务打通月度账单
水电费模块看起来简单，但实现起来比想象中容易踩坑。核心流程是：每月月初，系统遍历所有在住宿舍，读取上月抄表数、本月抄表数，计算出用量，乘以单价，生成账单。
这里最常见的问题是用“套餐”把敲代码变成复制粘贴。我的建议是用一个定时任务把这些串联起来：
@Scheduled(cron = "0 0 1 1 * ?") // 每月1日凌晨1点执行 public void generateMonthlyBills() { List<Dormitory> dormitories = dormitoryMapper.selectAll(); for (Dormitory dormitory : dormitories) { // 读取上月临时表中的数值 BigDecimal lastMonthWater = meterRecordMapper.getLastRecord(dormitory.getId(), "water"); BigDecimal thisMonthWater = meterRecordMapper.getThisRecord(dormitory.getId(), "water"); BigDecimal amount = thisMonthWater.subtract(lastMonthWater) .multiply(waterPriceConfig.getPrice()); // 生成账单并触发消息推送 billMapper.insert(new Bill(dormitory.getId(), amount)); messagePushService.pushToDormitory(dormitory.getId(), "您本月的宿舍水电账单已生成"); } }这里我要专门提醒一个细节：所有涉及金额计算的字段，在Java中请使用BigDecimal，并且在数据库中使用decimal(10,2)类型。不要用double做金额运算，否则累计误差在多次计算后会变得非常明显。这也是为什么我在前面的数据库设计中反复强调decimal的原因。
5. 实战全流程：从空项目到可演示系统
5.1 开发节奏规划：三周完成核心功能
很多同学做毕设最大的问题不是技术难度，而是拖延症。面对整个项目不知道从哪里下手，最后一两周赶工质量惨不忍睹。我把一个合理的开发节奏整理出来，你可以直接用：
第一周做基础框架：搭好Spring Boot项目、连上MySQL、跑通登录接口、完成全局响应体与异常处理、把JWT过滤器接入。这一周的目标不是实现业务，而是“把锅架起来”。
第二周做核心业务：按优先级搞定宿舍信息、报修工单、入住退宿、水电费这四个模块的后端CRUD和状态流转。如果时间不够，水电费模块可以先只做查询，账单生成逻辑放到第三周。
第三周做前端联调和整体打磨：把前端页面接上后端接口、调到能跑通“学生登录-提交报修-管理员接单-完成报修”这条主链路，然后处理设备上出现的跨域、日期格式、图片上传等问题。
永远记住一个原则：先跑通主链路，再优化细节。很多人喜欢先折腾首页轮播图、动画效果，结果主流程没跑通，最后只能在答辩时看着404页面发呆。
5.2 联调阶段最容易翻车的地方
前后端联调是毕业设计项目最痛苦的时期，如果你提前知道下面这几个“翻车点”，一定能少熬好几个通宵。
第一个是跨域问题。前端项目跑在http://localhost:5173，后端跑在http://localhost:8080，端口不同就会产生跨域。解决方法是在后端写一个跨域配置类，添加@CrossOrigin或者实现WebMvcConfigurer统一允许对应域名通过。
第二个是日期格式。后端返回的LocalDateTime默认会被序列化成类似2024-05-01T12:30:00的格式，前端如果不会解析就会显示成一段英文加数字的字符串。你需要在全局配置里统一日期格式，或者在前端用工具类做格式化。
第三个是文件上传路径问题。前端传头像图片，后端接收时用的是绝对路径还是相对路径？如果写死成你自己的C:/Users/xxx/，换一台电脑跑项目就崩了。建议用配置文件管理上传路径，并且用System.getProperty("user.dir")动态获取路径。
第四个大坑是数据库初始化。很多同学把建表SQL写在某个目录下，到答辩场地要重新建库时才发现没有整理好初始化脚本，现场一个表一个表手动建，场面极其狼狈。强烈建议你提前把建表SQL、基础数据、以及application.yml配置打包放好，保证在任何一台电脑上导入SQL文件后项目能直接跑起来。
5.3 前后端分离的部署与演示准备
答辩现场的演示环境和开发环境往往不同。有一个核心建议：不要指望现场联网。你必须在答辩前把后端打包成可运行的Jar包，前端要么打包成静态文件放行进Jar包，要么至少备好一份离线版本。
部署方式的演示示例：如果你用Maven构建，在项目根目录执行mvn clean package -DskipTests，就能在target/目录下得到一个可运行的Jar包。然后执行java -jar xxx.jar，只要数据库连接配置没问题，系统就能跑起来。
现场演示时，至少准备三条业务主链路：学生登录并查看宿舍信息、提交一条报修单；管理员登录并接单处理；查看数据统计页面。把这三条路径练熟，其他功能即使没有完全做完，也不会影响整体答辩效果。另外，准备一份简单的README文档，里面写清楚项目启动方式、默认账号密码、核心接口列表，能让你在答辩现场省下大量解释成本。
6. 高频问题的排查思路与避坑经验
6.1 数据库连接失败相关报错
“Access denied for user”是最常见的一个报错，一般是因为application.yml里的密码和实际数据库密码不一致。还有一个容易忽略的点：MySQL 8.x的驱动类名是com.mysql.cj.jdbc.Driver，8.0以前是com.mysql.jdbc.Driver。如果你从老教程里把配置复制过来，很可能在启动时定位到驱动类加载失败。
另外，我特别建议你在开发时给application.yml配上spring.jpa.show-sql=true或者MyBatis的日志输出，这样你能在控制台直接看到每一次SQL语句。很多人排查问题找不到原因，就是因为SQL和业务代码之间是割裂的，看不到底层到底执行了什么。
6.2 事务不生效的隐蔽原因
@Transactional注解是Spring Boot最经典的坑之一。明明加了注解，但数据还是写入了没有回滚，原因不外乎几个：注解加在了非public方法上；方法被同类内部调用（例如save调用了同类中的insert方法）；数据库表使用了不支持事务的MyISAM引擎；异常被捕获后没有重新抛出。
这里我要专门说下同类方法调用的问题。当你调用this.insert()时，调用的是当前类的原始方法，没有经过Spring代理，所以@Transactional是不生效的。正确做法是拆分Service类，让事务方法通过注入的另一个Service调用，或者使用@Autowired注入自身代理对象。
排查这类问题有一个快捷方式：在配置里开启debug日志，观察控制台是否打印了事务管理器的创建和提交记录。如果连事务管理器的日志都没有，就不要纠结回滚逻辑了，先解决代理不生效的问题。
6.3 前端页面加载慢与数据量问题
如果宿舍数据量只有几千条，接口响应却在几百毫秒以上，多半不是数据库问题，而是查询了不需要的字段或者做了N+1查询。MyBatis-Plus提供的selectList默认会查询整行所有字段，你在展示宿舍列表时根本不需要把“备注”这类大字段也查出来，所以能用select指定字段就指定字段。
对于列表页的多表关联查询，不要在Java代码里一层一层循环查询数据库。要么写多表联查的SQL，要么用MyBatis-Plus的@TableField(exist = false)配合一个VO类承载查询结果。简单来说：能用一条SQL解决的，绝不用N条SQL。
6.4 打包部署后访问不到前端页面
这是一个很常见的“最后一公里”问题：本地开发时前端页面正常，把前端静态资源放进Spring Boot的static目录后，访问http://localhost:8080/却白屏或404。
解决方法：检查前端打包后的index.html里引用的JS和CSS路径是否使用了绝对路径（例如/assets/index.js），如果前端路由用的是history模式，而Spring Boot没有做重定向配置，刷新页面就会404。最简单的兜底方案是加一个资源路由配置，把所有非api开头的请求都转发到index.html。虽然这是治标不治本，但对于答辩演示来说，稳定跑通比优雅更重要。
7. 项目答辩展示与后续进阶方向
7.1 让答辩功能展示更有层次感
答辩时，展示千万不要只按页面顺序从头点到尾。评委一天听几十组答辩，注意力极其有限。你要做的是两到三分钟内讲出“系统亮点”：先点出这是个多角色权限系统，然后演示一条学生报修的完整闭环，再用数据统计页展示系统的全局能力。
在此基础之上，提前准备好三个问题的高质量回答：一是“为什么使用JWT做认证？”你可以回答无状态、支持跨域、适合多端APP场景。二是“宿舍分配并发问题怎么考虑？”你可以提到数据库行锁和事务隔离级别。三是“项目还有哪些不足和可扩展点？”这个问题千万不要说“没有不足”，你可以大方地承认消息推送目前只做到站内通知，未来可以接入短信或邮件渠道，这样既显得你诚实，又展示了你的思考深度。
7.2 项目后续进阶：从毕业设计变成工程能力
做完这个项目，它不应该只是一个“交差”的作品。如果你时间还有富余，完全可以在毕业之后接着往上堆能力。方向一：把原来的单体模块拆分成独立的子服务，体验一下微服务的拆分思路；方向二：把数据库读写分离，加一层Redis缓存热点宿舍数据；方向三：把前端迁移到H5多端框架，实现一个同时覆盖Web端、小程序端的版本。
一旦你把整个项目从“能用”做到“可扩展”，你对后端开发的理解就不再局限于增删改查，而是真正建立起了从需求到解决方案的工程思维。这也是毕业设计除了学分之外，最有价值的部分。
最后分享一个个人经验：我做模拟项目X时，一开始给设计的“宿舍分配”功能写了很多华丽的前端效果，后来发现整个系统的真正骨架是后端状态流转的正确性。你花三天调好的一个轮播图动画，在评委眼里远不如一条严谨的报修状态推进记录有说服力。所以，把核心业务逻辑做扎实，让每条数据流转有据可查，这个毕业设计才算真正立住了。
优化详解)