杨良枝1. 项目概述：这个宿舍报修系统到底做了什么
先说结论：这是一个基于Spring Boot的宿舍报修维护系统，面向高校宿舍管理场景，核心解决学生报修、维修派单、进度跟踪、评价反馈这一整条业务链路。开发技术栈以Spring Boot + MyBatis Plus + MySQL为主，前端可以用Vue或Thymeleaf模板引擎，权限上使用Spring Security或Sa-Token做角色隔离。
我在帮学生做毕设辅导的过程中，接触过大量类似的选题，宿舍报修系统属于典型的“业务清晰、边界明确、工作量适中”的管理类项目，非常适合作为Java毕设。它不涉及复杂的算法，不需要高并发的架构设计，核心考察的是对业务需求的理解、数据库设计能力和CRUD功能的熟练度，以及Spring Boot核心机制（自动装配、AOP、事务管理等）的掌握程度。
这个系统适合三类人来参考：第一类是正在准备Java毕业设计、想找一个稳妥且容易过审选题的学生；第二类是自学Spring Boot、想通过完整项目练手巩固知识的开发者；第三类是高校后勤管理部门的信息化需求参考者，当然这个角度更多是业务层面的借鉴意义。
我在下面的内容里会从功能设计、数据库建模、核心代码实现、调试运行、常见问题、定制扩展、答辩准备这几个维度逐层拆解，把你写论文、做系统、过答辩这条路走通。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 功能模块拆解：三端业务闭环怎么设计
2.1 角色划分与权限边界
宿舍报修系统第一个要解决的，是角色权限问题。一个完整的业务闭环里至少有三类角色：学生、维修工、管理员。如果系统扩到楼栋维度，还可以加一层宿管角色，但毕设规模控制在三类角色比较合适，不然权限和页面量会膨胀得很厉害。
学生端能做的操作很清晰：提交报修单、查看自己报修单的处理进度、取消未接单的报修单、对已完成的维修进行评价。维修工端负责接单、填写维修结果、查看自己的历史任务和评价。管理员的权限则是全量的，包括用户管理、楼栋管理、报修单审核与派单、统计报表、评价管理。
这三个角色的权限边界必须用代码控制，而不是只靠前端隐藏按钮来实现。我在给学生指导时反复强调一个原则：后端接口才是权限控制的真正防线，前端隐藏入口只是用户体验优化。你想想，如果学生在前端发现一个接口可以直接调维修工的接口，那系统基本就没法看了，答辩时老师一旦攻击这个点，很难解释。
2.2 报修单状态机的设计
报修单是整个系统的核心实体，它的状态流转决定了整个业务流程的骨架。我建议把状态设计成六个：待审核、待派单、待维修、维修中、待评价、已完成。
流程大致是这样：学生提交报修单后，状态为待审核；管理员审核通过后，状态变为待派单，如果不通过则直接驳回并填写驳回原因；管理员手动或系统自动指派给某个维修工后，状态为待维修；维修工接单，变为维修中；维修工填写维修结果后，状态为待评价；学生在七天内评价完毕，状态变为已完成。
这个状态机设计有三个好处：第一，每个状态都有明确的操作主体，权限划分自然清晰；第二，页面上的操作按钮可以直接依据状态来判断是否显示，前端逻辑变得很简洁；第三，状态表加一个时间字段，就能统计响应时长和维修时长，为后续报表功能提供数据支撑。
我见过不少学生的代码里没有状态机概念，报修单状态直接用字符串存，然后到处if判断，代码散得到处都是。比较好的做法是用枚举类定义状态常量，并且把状态流转校验集中到一个服务方法里。这样既保证了健壮性，也方便答辩时向老师展示你的工程化意识。
2.3 数据库表结构设计要点
数据库设计是这个项目的核心工作量之一，也是写论文时最好展开写的部分。我建议最少设计这八张表：用户表、角色表、用户角色关联表、楼栋表、宿舍表、报修单表、报修评价表、公告表。如果要做操作日志和流程追踪，可以再加一张日志表，但这不是必须的。
报修单表建议至少包含这些字段：报修单号、报修人ID、宿舍楼ID、宿舍ID（或房间号）、报修类型、报修描述、报修图片URL、紧急程度、状态、指派维修工ID、审核人ID、审核时间、接单时间、维修完成时间、评价期限、是否超时、备注。
这里有一个容易被忽略的点：报修图片。学生提交报修时拍照上传图片，在真实场景里几乎是刚需功能，因为管理员需要依据照片判断问题的严重程度和维修难度。这个功能实现上用什么方案？最简单的方案是本地磁盘存储，配置一个虚拟路径映射；好一点的方案是用OSS对象存储。对毕设来说，本地存储就够了，答辩时能讲清楚图片上传的流程和文件存储路径的设计思路即可。
宿舍表建议和楼栋表分开，不要只用一