杨良枝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对象存储。对毕设来说，本地存储就够了，答辩时能讲清楚图片上传的流程和文件存储路径的设计思路即可。
宿舍表建议和楼栋表分开，不要只用一个宿舍名称字段。很多学生图省事，把宿舍表做成一维的，所有宿舍直接挂在一张表下，字段就是楼栋、房间号。这样做的问题在于，后续要按楼栋统计报修数量时，SQL写起来很别扭。建议楼栋表和宿舍表做主外键关联，宿舍表存楼栋ID，这样统计和筛选都会顺手很多。
3. 核心代码实现：这几块是最容易拉开差距的地方
3.1 Spring Boot项目结构和分层设计
项目结构决定了代码的可维护性，也是老师第一眼会看的东西。我建议采用标准的四层结构：controller、service、mapper、entity，再加上config、common、dto、vo这几个辅助包。
很多初学者分不清VO、DTO、Entity的区别，把返回给前端的JSON直接拿实体类来用。这样做在毕设阶段问题不大，但如果被答辩老师追问，很容易露怯。我的建议是：查询列表和详情时，封装一个VO类，把需要的字段合并出来，比如报修单详情需要同时展示报修人姓名、宿舍楼名称、维修工姓名，这些字段分散在各张表里，用VO来接收多表查询的结果会比直接用实体类更规范。
业务逻辑尽量写在Service层，Controller只做参数接收和结果封装返回，这样层次清晰，也便于后期编写单元测试时Mock掉Service层。如果你在代码里看到Controller里写了一大堆业务代码，那基本就是代码规范没过关的信号，答辩老师可能不需要太深的技术提问就能看出问题。
3.2 报修单提交与派单的代码逻辑
学生提交报修单是一个典型的写多表操作。用户在前端选择报修类型、填写描述、上传图片、选紧急程度后，后端要做的是：将报修单主表数据insert进去，同时可能写入图片表的关联数据。一个报修单对应多张图片，这就要考虑事务问题：主表和图片表必须同时写入成功，或者同时失败。
在Spring Boot中，处理方式很简单，在Service方法上标注@Transactional注解即可。我在给学生看代码时反复强调：涉及多表写入的操作，事务注解必须加，这是最基本的正确性保障。如果你不加，一旦第二步图片表写入失败，报修单主表已经落库，数据就出现了孤儿记录。
派单逻辑上，维修工的分配有两种常见方案：管理员手动指派，或者按维修工当前任务数和最近接单时间自动派单。手动指派适合毕设展示，因为交互过程更清晰；自动派单适合扩展加分，可以按“当前待维修任务数最少的维修工优先分配”这个策略来写，代码量不大但在功能和答辩层面都能加分。
3.3 状态流转校验的优雅写法
状态流转校验如果写不好，代码会非常臃肿。假设你有六个状态，如果每两个状态之间是否允许流转都用if else判断，组合数会很多。比较好的做法是用状态机思想：每个状态定义允许流转到哪些后续状态，然后统一校验。
用Map或者枚举实现这个映射关系，代码量很少。比如定义一个枚举状态，里面维护一个nextState集合，流转时判断目标状态是否在nextState里。这样核心校验逻辑只有十几行，并且当状态增加时只需要修改枚举定义，不会影响其他代码。这种写法在答辩时是很大的加分项，它展示了你不是在写流水账CRUD，而是有一定的抽象设计能力。
3.4 前端页面和接口联调注意事项
如果你选的是前后端分离方案，Vue + Element UI是比较主流的组合。页面数量不多，核心页面就是登录注册页、报修单提交页、报修列表页、报修详情页、数据统计页，按角色拆分后大约是六到八个页面。
前后端分离下有一个细节容易踩坑：跨域配置。Spring Boot后端默认端口是8080，Vue前端开发服务器端口是5173或者8081，两者之间必然存在跨域问题。解决方式是在后端配置一个CorsFilter，或是在Controller上使用@CrossOrigin注解。再有一种方式是通过Vue的vite proxy代理转发，把/api开头的请求转发到后端。个人更推荐vite proxy方案，因为它在生产环境下不需要额外处理，且配置更集中。
另外一个常见的坑是时间字段格式问题。后端返回LocalDateTime类型时，默认序列化格式是带T的ISO格式，比如2025-06-25T10:30:00，前端展示起来不好看。解决办法是在application.yml里配置Jackson的日期格式，全局统一成yyyy-MM-dd HH:mm:ss。这种细节虽然小，但很影响产品质感，答辩现场的演示效果也会好很多。
4. 调试运行全流程：从零到能跑通的每一个步骤
4.1 环境准备与版本搭配
环境这一块是很多学生卡壳的重灾区，主要问题集中在JDK版本和Spring Boot版本不匹配上。我建议直接用下面这套组合，兼容性和稳定性都有保障：
- JDK 1.8（对应Spring Boot 2.x）。
- Spring Boot 2.7.x（目前2.x的最新维护版本，稳定且资料多）。
- MySQL 5.7或8.0（如果安装的是8.0，记得加驱动配置，驱动类名是com.mysql.cj.jdbc.Driver）。
- Maven 3.6.x以上。
- IDEA（用社区版也行，但旗舰版对Spring Boot的集成支持更好）。
网上现在能搜到很多Spring Boot 3.x的教程，但对毕设项目来说，如果你对Spring Boot的底层原理不够熟悉，我不建议一上来就追新版本。Spring Boot 3要求JDK 17，这就带来了很多连锁问题：JDK 17的模块化限制、某些第三方库的不兼容、IDEA版本要求更高等。很多学生在配置环境时花了大量时间调试版本兼容，最终项目还没开始写代码就失去了信心。如果你的毕设选题没有特殊要求，Spring Boot 2.7 + JDK 8是最省心的选择。
4.2 项目初始化的两种方式
创建Spring Boot项目的方式有两种，我都做过实际测试，各有优缺点。
第一种是使用IDEA的Spring Initializr。IDEA新建项目时选择Spring Initializr，需要选择Spring Boot版本和依赖，这个过程是可视化操作，比较适合新手。需要注意的是，如果你的网络环境访问start.spring.io比较慢，可以在初始化的时候配置阿里的镜像地址。依赖选择上，Web、MyBatis、MySQL Driver、Lombok这几个是必选的。
第二种是直接访问start.spring.io网站下载压缩包，再导入IDEA。这种方式和第一种本质一样，区别只是操作路径。
导入项目后，建议先执行一次Maven的clean和compile命令。第一次下载依赖会比较慢，如果卡住，需要在Maven的settings.xml里配置阿里云镜像仓库。这个步骤很关键，别等到运行报错再去排查。我在帮一些学生远程调试时发现，很多启动报错其实都是依赖下载不完整导致的。
4.3 数据库脚本的创建与初始数据
数据库设计我前面讲到了表结构，这里再着重说下SQL脚本的细节。建表SQL建议按顺序执行：先建用户表，再建角色表和用户角色关联表，然后是楼栋表、宿舍表、报修单表、评价表。因为表之间有关联关系，顺序反了会报外键约束的错误。
初始数据至少要包含：管理员账号（admin）、两名维修工账号、几名测试学生账号、几栋宿舍楼和对应的宿舍号。数据库脚本里还要包含一个初始化密码，建议统一用MD5加密后的默认密码，这样代码里就可以用固定的加密工具类做比对。如果你用的加密方式是BCrypt，密码字段是60位字符串，注意长度不要定得太短。
我遇到过不少学生在数据库导入阶段踩坑：MySQL的时区设置问题会导致连接报错的错乱现象。在jdbc连接串里加上serverTimezone=Asia/Shanghai，可以规避这类问题。另外数据库名称和application.yml里的配置一定要保持一致，大小写敏感问题在Windows下不明显，在Linux下就会暴露。
4.4 启动过程的常见报错与排查
项目能正常启动，是前期所有准备工作是否正确的综合验证。启动过程最常遇到的报错是端口被占用，Spring Boot默认的Tomcat端口是8080，如果本机已经运行了另一个服务，启动日志里会直接报Address already in use。这种情况下，要么关掉占用进程，要么在application.yml里把server.port改成8081或其他端口。
另一个非常常见的报错是MyBatis绑定异常，报的是Invalid bound statement not found。这个错误几乎都是mapper接口和mapper XML文件在路径或命名上没有对上导致的。检查两个地方：第一，mapper接口和mapper XML文件是否在同一个包路径下，或者是否通过mybatis-plus配置中的mapper-locations指定了XML路径；第二，XML文件里的namespace是否和接口全限定名一致。
还有一类问题出现在Lombok上。如果IDEA提示找不到getter和setter方法，或者编译报错说找不到符号，多半是Lombok的插件没有安装，或者注解处理器没有开启。IDEA需要安装Lombok插件，并且在Settings中启用Annotation Processing。JDK 17和Lombok版本不兼容也会出现类似问题，这就是为什么我前面建议用JDK 8的原因之一。
5. 常见问题与排查技巧实录
5.1 问题速查表
我整理了最近一年帮学生调试过程中出现频率最高的几个问题，做成表格，可以收进自己的调试笔记里以备查阅。
| 问题现象 | 可能原因 | 解决办法 |
|---|---|---|
| 启动时报Address already in use | 8080端口被占用 | 更换端口或关闭占用进程 |
| 启动后访问页面报Whitelabel Error Page | Controller路由未匹配或静态资源路径错误 | 检查Controller上的RequestMapping注解 |
| 数据库连接失败 | 数据库名称、账号密码配置错误 | 核对application.yml和数据库实际情况 |
| Invalid bound statement not found | Mapper接口和XML不匹配 | 检查XML的namespace和接口路径 |
| 中文乱码 | 数据库编码不是utf8mb4 | 在连接串加characterEncoding=utf8，数据库表默认编码改为utf8mb4 |
| 时间相差8小时 | 时区问题 | 连接串添加serverTimezone=Asia/Shanghai |
| 图片上传后访问404 | 静态资源映射未配置 | 添加资源映射目录配置类 |
| 前端接口跨域报错 | 未配置跨域 | 使用CorsFilter或vite proxy代理 |
5.2 关于报修图片上传的经典Bug
图片上传功能，几乎每一个做这个选题的学生都会遇到一个问题：本地开发时图片能上传到服务器磁盘，刷新页面后图片也能正常显示，但是换成别人电脑访问时就看不到图了。这个问题根源在于：你存储图片的路径是服务器本地磁盘路径，但浏览器访问时只能通过URL访问。
解决方式是在配置类里添加静态资源映射，把磁盘路径映射成URL路径。代码大致是这样：addResourceHandlers中，将/image/**路径映射到file:图片存储目录。这样图片上传后返回URL，浏览器通过这个URL就能访问到文件。这个点虽然不难，但属于那种不实际踩坑就不会注意到的细节。
5.3 Spring Boot版本过高引发的连带问题
很多学生直接使用IDEA里默认的最新版本Spring Boot创建项目，结果发现一堆问题。Spring Boot 3.x配合JDK 17，如果IDE版本不够新，代码提示都是缺失的；如果你看网上2.x的教程写MyBatis整合配置，会发现完全对不上；部分老版本的第三方jar包在JDK 17下会启动失败。这种情况我见得太多了。
对于毕设项目，我个人的看法是可以展示对新技术趋势的了解，但这不意味着必须用最新版本去承担风险。你在论文里写“为什么选Spring Boot 2.7.x而不是3.x”，理由可以写生态成熟、资料丰富、与当前主流企业实践一致。这反而是个能自圆其说的答辩点。
6. 定制扩展方向：想让项目更出彩的几个加分项
6.1 从固定派单到自动派单
如果觉得系统功能太简单，把管理员手动派单升级为“基于负载均衡的自动派单”是性价比最高的改进。策略是：当报修单审核通过后，系统自动在所有维修工中，找到当前待维修任务数最少的那一位，将其指派给他。
实现思路不复杂：查询所有维修工，对每个维修工统计其待维修状态的报修单数量，取出任务数最少的，更新报修单的维修工ID。SQL一条group by就能查出来。但这个功能点的价值在于：它把原本纯CRUD的系统，提升到了一个带有简单业务策略的层次。答辩时你可以说，业务层面参考了负载均衡的最小连接数算法思想。这个拔高后的视野，会非常有说服力。
6.2 增加数据可视化大屏
宿舍报修系统的数据量不大，做复杂的数据分析并不现实，但做一个简单的统计看板却恰到好处。按楼栋统计报修数量、按类型统计报修占比、统计本月维修完成率，这些用ECharts画一个饼图和柱状图，再加几个统计卡片，视觉效果立刻就不一样了。
技术实现上，Vue前端加一个echarts依赖，后端写几个统计接口，返回的数据结构定义好，前端直接调用渲染即可。代码量不大，但视觉提升非常明显。很多学生的毕设项目在功能上挑不出大毛病，但演示时页面简陋、没有什么数据可视化元素，整体气质就掉了一档。
6.3 增加消息通知
消息通知属于可选的加分项，可以在报修单状态变更时，向对应用户发送系统通知。实现方式有两种：简单的做法是增加一个通知表，状态变更时插入记录，学生登录后在通知中心查看；复杂的做法是接入WebSocket做实时推送。如果时间充裕，WebSocket实时推送是一个好功能，能让答辩演示产生立刻的互动反馈，学生端页面收到新通知时弹出提示，这个体验在给老师演示时非常加分。
6.4 二维码扫码报修
如果想让系统有更多实战味道，可以考虑在每间宿舍门口贴一个二维码，扫码后直接跳转到报修页面，并在URL参数中带上宿舍ID。实现上就是生成二维码图片，二维码内容为系统报修页的URL加宿舍ID，扫码后前端解析参数，自动填充楼栋和宿舍信息。
手写一个二维码生成器需要依赖工具包，常见的方案是用Google的ZXing库。项目里加一个工具类，生成二维码图片输出到前端页面中。这个功能在演示环节会非常吸引注意力，因为它给人的感觉是这个系统不只是个课程设计，而是真的考虑了实际使用场景。
7. 文档撰写与答辩准备的关键思路
7.1 论文结构怎么安排
毕业设计的论文结构虽然各校要求不同，但大体上有一个标准模板。我个人建议的章节安排是：绪论、相关技术介绍、系统需求分析、系统设计、系统实现、系统测试、总结与展望。很多学生把写论文当成最后凑字数的工作，这是误区。答辩老师一般不会深抠代码细节，他会通过论文来了解你对你项目的理解程度。
论文里最值得花精力写的是第三章和第四章。第三章要写清楚功能需求和非功能需求，画出用例图、业务流程图；第四章要写系统架构图和数据库ER图、核心表结构设计。这些图和流程是论文的骨架，也是答辩时最容易提问的区域。图一定要画规范，IDEA的数据库可视化工具可以自动导出ER图，整理后直接用就行，不需要手绘。
7.2 答辩前需要突击准备的问题
答辩现场的时间通常有限，老师最可能问的问题集中在这几个方向：为什么选择Spring Boot而不是SSM？数据库有哪些表，表之间的关联关系是什么？报修单的状态是怎么流转的？权限是怎么控制的？如果报修单量特别大，系统会怎么优化？
这几个问题建议提前准备答案。比如Spring Boot相比SSM的优势，核心回答自动配置和起步依赖两点就够了，再补充说Spring Boot本质上还是Spring家族的封装，降低配置成本。数据量大时的优化可以说加索引、分页查询、缓存热点数据。能不能答上来是次要的，关键是展现你的思路是清晰的。
8. 我踩过的一些坑，现在分享给你
做这类毕设项目一年又一年，我发现学生的常见问题其实很集中：不是技术上多难，而是在环境配置、细节取舍和时间分配上反复犯低级错误。
第一个坑是时间安排。不少学生前期花大量时间折腾环境、纠结用不用Vue，迟迟不动手写代码，结果到中期检查前才慌慌张张开始赶工。我的建议是环境准备最多花两天，第三天必须把项目骨架跑起来，哪怕只是一个Hello World级别的页面。先跑通再填充功能，这是所有项目的铁律。
第二个坑是过度追求炫技。有的学生看了几篇博客就想着把Redis、消息队列、微服务都集成进系统。毕设的重点是完整性和逻辑自洽，而不是技术栈的堆砌。一个宿舍报修系统强行用微服务架构，反而会暴露出你对其原理的不熟。踏踏实实把Spring Boot的核心功能用好，胜过一堆花架子。
第三个坑是不重视数据初始化。演示时系统里没有数据，每页列表都是空荡荡的，这样的演示效果非常差。我建议第一次启动前就把测试数据准备好：学生账号、维修工账号、不同状态的报修单各几条。这样打开页面就能直接演示各种流程，老师看到的是一个有内容的产品，而不是一个空壳。
第四个坑是备份意识缺失。源码被误删、数据库被改坏、论文没保存，这种事每年都有发生。建议代码至少同步到码云或GitHub的私有仓库，数据库脚本单独保存，论文打开自动保存功能之外再隔段时间手动备份一次。
这个项目最让我喜欢的点在于它的业务逻辑非常自洽：从学生提交报修，到管理员审核派单，再到维修工维修反馈，最后学生评价，整条链路完整且贴合真实场景。做的时候只要把这条链路每一步都走通，就已经是一个合格的毕业设计了。最后再送大家一个小技巧：把系统跑起来之后，录一段两三分钟的操作演示视频存在手机里。答辩前拿出来回看一遍，比临时翻代码回忆功能要高效得多，而且万一现场环境出问题，这段视频还能救场。