尧图网页设计 
宿舍报修这个题目几乎是每届计算机毕业设计里都会出现的“常青树”。我见过太多人把它做成一个简单的增删改查答辩时被老师问两句“并发高了怎么办”“状态乱了怎么处理”就答不上来。但其实只要把业务逻辑捋清楚、技术选型有讲究这个题目完全可以做成一份漂亮的作品既能体现工程能力又能展示你对智慧校园场景的理解。这篇文章我会完整拆解一个基于Spring Boot的高校宿舍报修管理系统的设计与实现从技术选型、数据库设计、核心业务状态机到文件上传、消息通知、数据统计再到部署和常见坑全程用我实际开发中的思路来讲。无论你是准备拿这个题目做毕设还是想在学校里落地一套公寓运维工具都可以直接“抄作业”。1. 项目整体设计与技术选型1.1 为什么说Spring Boot是这个场景的最优解先说结论Spring Boot MyBatis-Plus MySQL Vue是这类管理信息系统的最稳妥组合没有之一。很多同学会纠结要不要用Spring Cloud、要不要上Redis缓存、要不要搞微服务。我的建议很直接——宿舍报修系统本质上是一个低并发的企业级CRUD系统核心诉求是业务清晰、开发效率高、部署简单。微服务那套东西在这个场景下属于过度设计除了给答辩增加风险没有任何实际收益。Spring Boot的优势在于它把Spring生态中最常用的组件做了自动装配。你不需要再写一堆XML配置来声明数据源、配置事务管理器、注册拦截器一个SpringBootApplication注解加上application.yml里的几行配置项目就能跑起来。这对毕设项目来说极其友好你可以把时间花在业务功能上而不是浪费在环境搭建上。我实测下来的启动速度一台普通的笔记本第一次mvn spring-boot:run大概10秒左右就能完成启动热部署插件开启后改完代码重启基本在3秒以内调试效率非常高。1.2 整体架构思路前后端分离还是服务端渲染这个题目我建议采用前后端分离架构。前端用Vue 3 Element Plus后端就Spring Boot提供RESTful API。理由有三点第一智慧校园这个背景决定了系统要跟其他的校园平台做对接。前后端分离后后端接口是纯数据服务未来如果要对接校园统一门户、企业微信、钉钉只需要按接口文档调用即可不需要动页面。第二前后端分离的项目在简历上和答辩中更好讲。你可以清晰地说出“前端负责交互渲染后端负责业务逻辑与数据持久化”这种分层思想本身就是面试官和答辩老师想听到的东西。第三Vue Element Plus做出来的界面确实好看。拿宿舍报修来说学生端需要一个简洁的报修表单提交页维修工需要一个大屏任务看板管理员要看统计图表这些用Element Plus ECharts可以很轻松地实现比Thymeleaf写出来的页面漂亮不止一个档次。1.3 数据持久层为什么选MyBatis-Plus选MyBatis-Plus而不是原生MyBatis也不是Spring Data JPA我是有明确考虑的。原生MyBatis的Mapper XML写起来烦每写一个查询都要配resultMap一个报修系统光报修单相关的查询就有十来种——按学号查、按宿舍楼查、按状态查、按时间范围查、按维修工查——用XML写这些条件拼接是纯粹的体力活。MyBatis-Plus提供了BaseMapper接口单表CRUD直接继承就有不用写一行SQL。更重要的是它的条件构造器LambdaQueryWrapper像“查询某栋楼所有状态为待分配且创建时间在最近7天的报修单”这种条件用代码直接拼出来可读性比XML好太多。JPA虽然也能做但它对复杂查询的支持相对薄弱而且国内企业用MyBatis系的比例远高于JPA毕设选型紧贴就业市场的技术栈总归是加分项。2. 核心模块拆解与业务逻辑设计2.1 角色权限模型三张表搞定RBAC高校宿舍报修系统的用户角色非常清晰就三类学生、维修工、管理员。但请注意宿舍管理员和系统管理员在实际业务中权限是不同的。宿管员负责分配工单给维修工系统管理员负责维护基础数据宿舍楼、维修类型、用户账号。所以我的设计里把角色拆成了四种STUDENT、REPAIRMAN、DORM_ADMIN、SYS_ADMIN。权限模型直接用RBAC基于角色的访问控制三张核心表用户表、角色表、用户角色关联表。如果答辩老师问“你怎么控制权限”你就说“登录后把用户的角色信息存入ThreadLocal通过拦截器判断注解上的角色标识不一致就返回403”。这个回答简洁且专业比你贴一大堆Spring Security的配置代码更能说明你真正理解了权限控制的本质。实际的实现上我在后端定义了一个RequireRole注解标注在Handler方法上。拦截器里取出当前登录用户的角色集合做匹配匹配通过放行不通过直接抛异常由全局异常处理器统一转成HTTP 403响应。这段逻辑大概50行代码就能写完但效果很直观。2.2 报修工单状态机的设计最关键的业务核心报修工单绝不是一张表加一个状态字段那么简单。如果没有约束任何角色都可以任意修改状态系统很快就会乱成一锅粥。我设计的工单状态流转是严格单向的提交报修 → 待分配 → 已接单维修中 → 待验收 → 已完成中间还有一个“已驳回”和“已取消”的分支状态。学生提交工单后宿舍管理员可以驳回填写驳回理由学生自己也可以取消未开始的工单。维修工接单后状态进入维修中维修完成提交结果后进入待验收学生确认无误后置为已完成同时可以对服务进行评价。这个状态机的核心思路是状态的每一次变更都必须有合法的“前驱状态”。我在代码里用了一个枚举类RepairStatusEnum里面记录了每个状态允许的流转目标再用一个transition方法做合法性校验。这样写的好处是你完全杜绝了“从待分配直接跳到已完成”这种非法操作业务数据非常干净。写代码的时候要注意一个点状态变更和数据操作必须放在同一个事务里。比如维修工点击“接单”时不仅要改工单状态还要把工单的维修工ID、接单时间一并更新这两个操作要么同时成功要么同时失败否则就会出现“状态显示维修中但工单上没有维修工”的脏数据。2.3 数据库设计要点字段、索引与关联关系我直接给出我实测用的数据库设计方案。核心表一共六张外加三张辅助表。报修单表repair_order是核心字段包括id、order_no工单编号用年月日流水号生成、student_id报修学生、dorm_building_id宿舍楼、dorm_room宿舍门牌号、repair_type_id维修类型枚举水、电、木工、网络、其他、description问题描述、image_url图片地址JSON数组、status状态、create_time、update_time。索引上status和dorm_building_id必须加索引因为查询场景里大概率是“某栋楼未完成的工单”联合索引(dorm_building_id, status)实测效果非常好。工单表repair_work_order跟报修单表一对一关联字段包括id、repair_order_id、repairman_id、assign_time、accept_time、finish_time、finish_note维修结果说明、complete_time。用户表、宿舍楼表、维修类型表、评价表、通知公告表按常规设计即可。需要特别说明的是在宿舍楼表里我加了一个dorm_admin_id字段表示每栋楼的宿管员。这样宿管员登录后只需要查自己负责的那栋楼的工单SQL非常简单。3. 关键功能实操实现3.1 工单状态变更的代码实现从枚举到Service下面这个枚举是我在项目里实际用的精简了注释后贴出来public enum RepairOrderStatusEnum { PENDING_ASSIGN(0, 待分配), ASSIGNED(1, 待接单), REPAIRING(2, 维修中), PENDING_ACCEPT(3, 待验收), COMPLETED(4, 已完成), REJECTED(5, 已驳回), CANCELED(6, 已取消); private final Integer code; private final String desc; private static final MapInteger, ListInteger TRANSITION_MAP new HashMap(); static { TRANSITION_MAP.put(PENDING_ASSIGN.getCode(), Arrays.asList(ASSIGNED.getCode(), REJECTED.getCode(), CANCELED.getCode())); TRANSITION_MAP.put(ASSIGNED.getCode(), Arrays.asList(REPAIRING.getCode(), CANCELED.getCode())); TRANSITION_MAP.put(REPAIRING.getCode(), Arrays.asList(PENDING_ACCEPT.getCode())); TRANSITION_MAP.put(PENDING_ACCEPT.getCode(), Arrays.asList(COMPLETED.getCode())); } public static boolean canTransition(Integer from, Integer to) { ListInteger allowed TRANSITION_MAP.get(from); return allowed ! null allowed.contains(to); } }Service层里每次变更状态先校验合法性Transactional(rollbackFor Exception.class) public void finishRepair(Long workOrderId, String finishNote) { RepairWorkOrder workOrder workOrderMapper.selectById(workOrderId); RepairOrder order repairOrderMapper.selectById(workOrder.getRepairOrderId()); if (!RepairOrderStatusEnum.canTransition(order.getStatus(), RepairOrderStatusEnum.PENDING_ACCEPT.getCode())) { throw new BizException(当前状态不允许执行此操作); } order.setStatus(RepairOrderStatusEnum.PENDING_ACCEPT.getCode()); repairOrderMapper.updateById(order); workOrder.setFinishNote(finishNote); workOrder.setFinishTime(new Date()); workOrderMapper.updateById(workOrder); }这个实现的优点在于所有状态的流转规则都集中在枚举里后续要加新的状态比如“维修失败重新分配”只需要改TRANSITION_MAP不用翻业务代码。我在实际开发中还把状态变更记录写进了一张order_log表每次变更都留下痕迹答辩的时候这张表就是你的“过程管理”亮点。3.2 图片上传本地存储还是MinIO学生报修时上传现场照片是刚需。维修工到现场也经常拍个“修好后的照片”作为凭证。我的建议是本地开发用本地磁盘存储部署上线后替换成MinIO。先解释一下为什么不太推荐用FastDFS——配置太复杂需要部署Tracker和Storage两个节点单机部署为了一个毕设项目完全不值得。MinIO就简单得多就是一个提供S3兼容接口的轻量级对象存储服务单机模式一条命令就能启动。而且MinIO有非常友好的Web控制台上传的文件可以直接看到演示的时候很方便。Spring Boot集成MinIO的要点有两个。一个是初始化ClientConfiguration public class MinioConfig { Value(${minio.endpoint}) private String endpoint; Value(${minio.access-key}) private String accessKey; Value(${minio.secret-key}) private String secretKey; Bean public MinioClient minioClient() { return MinioClient.builder() .endpoint(endpoint) .credentials(accessKey, secretKey) .build(); } }另一个是文件上传的核心逻辑。我封装了一个FileStorageService对外提供upload(MultipartFile file, String bucketName)方法。存入MinIO时文件名我用UUID.randomUUID().toString()重命名目的是防止文件名冲突和特殊字符问题同时把原始文件名记录在数据库字段里下载的时候再做映射还原。这里有个实测的坑Spring Boot默认的单次请求文件大小限制是1MB multipart配置需要改大。在application.yml里加上spring: servlet: multipart: max-file-size: 10MB max-request-size: 20MB不然学生手机拍的照片稍微大一点就会报MaxUploadSizeExceededException前端弹出一个看不懂的英文错误体验极差。3.3 WebSocket实时消息通知维修进度主动推送这个系统里有一个体验分水岭——学生能不能实时收到维修进度。单纯靠学生自己去查工单状态体验感很弱。我用WebSocket做了一个消息推送模块。具体思路是学生登录系统后前端建立WebSocket连接把用户ID传过来后端用ConcurrentHashMapLong, WebSocketSession维护在线用户映射。当工单状态变更时调用MessagePushService.pushToUser(userId, message)从Map里取出该用户的Session发送JSON消息。前端收到消息后弹出一个通知提示并刷新工单列表数据。WebSocket在Spring Boot里集成不需要额外引入第三方库直接使用spring-boot-starter-websocket。实现一个WebSocketHandler或者用ServerEndpoint注解都可以。我实测下来ServerEndpoint更轻量配合Spring管理的Service使用Autowired需要额外做一个ApplicationContext工具类从Spring容器中取Bean这个坑网上解决方案很多照着用即可。这个模块做完后整个系统的交互质感会明显提升。答辩时你演示“学生提交报修后浏览器实时弹出维修工已接单的通知”绝对比干巴巴的刷新列表有说服力。3.4 数据统计与可视化ECharts展示维修画像作为智慧校园平台的一部分数据可视化是标配。我在管理后台加了一个统计看板展示三类数据近7日报修趋势、维修类型分布占比、各宿舍楼报修量排行。数据统计在后端写一个DashboardController用SQL聚合查询。比如维修类型分布SELECT repair_type, COUNT(*) AS cnt FROM repair_order WHERE create_time DATE_SUB(NOW(), INTERVAL 30 DAY) GROUP BY repair_type前端用ECharts的PieChart渲染配置项大概二十行代码。这里有个经验聚合查询的结果集不要在前端做二次加工直接让SQL把分组、排序、求和都做掉后端返回的就是可以直接渲染的清洁数据结构。前端只负责把数据映射到图表配置里这样做既高效又不容易出错。4. 项目部署与常见问题排查4.1 从IDEA新建项目到本地跑通整个流程我按一个新的Spring Boot项目从零搭建的步骤说一遍这个流程你做完一遍之后会非常顺。第一步打开IDEA选择Spring Initializr创建项目。Group填com.campusArtifact填dorm-repairJDK选1.8或者11。注意依赖选择时勾选Spring Web、MyBatis-Plus如果Initializr里没有就创建后手动引入、MySQL Driver、Lombok、Validation。第二步手动在pom.xml里加入MyBatis-Plus依赖。这里要注意version的选择早期踩过坑——MyBatis-Plus的3.5.x版本适配Spring Boot 2.x如果你用的是Spring Boot 3.x必须用MyBatis-Plus的mybatis-plus-spring-boot3-starter这个新坐标旧坐标会导致启动报找不到SqlSessionFactory。第三步配置application.yml核心配置server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/dorm_repair?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: root mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0这里我故意加了log-impl因为在开发阶段你要能看到MyBatis-Plus实际执行的SQL不然查不到数据的时候你都不知道是自己SQL写错了还是参数传错了。第四步写一个测试用Controller启动项目访问localhost:8080返回一个JSON字符串确保环境通畅。然后再从实体类、Mapper、Service、Controller的顺序逐层完善业务代码。4.2 Docker单机部署全流程毕设答辩通常需要现场演示总不能评委老师面前开一个IDEA在那里跑项目。所以提前准备一套Docker部署方案非常有必要。我推荐一个docker-compose编排两个服务MySQL 8和Java应用。MySQL用官方镜像挂载数据卷。Java应用用多阶段构建的Dockerfile打包FROM maven:3.8-openjdk-8 AS build WORKDIR /app COPY pom.xml . RUN mvn dependency:go-offline COPY src ./src RUN mvn package -DskipTests FROM openjdk:8-jre-alpine WORKDIR /app COPY --frombuild /app/target/dorm-repair-0.0.1-SNAPSHOT.jar app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, app.jar]然后docker-compose.yml里把两个服务关联起来Java应用的环境变量里配置SPRING_DATASOURCE_URL指向MySQL服务名而不是localhost。这个细节如果忘了容器里会出现“连接数据库超时”的经典报错。部署好后一条docker-compose up -d --build就能把整个系统跑起来。我自己的经验是用Docker部署完跑一遍全流程测试学生提交报修、宿管分配、维修工接单、学生验收确保所有功能正常再准备答辩。不要到答辩前一天才部署环境问题永远是最后一刻才暴露的。4.3 高频坑点与排查实录我把实际开发中遇到并且解决过的问题整理成一张速查表这些都是常规文章里不会写的症状原因解决方案启动报Failed to configure a DataSource引入了MyBatis-Plus依赖但没有配置数据源检查application.yml里的url、username、password是否配置完整访问404但Controller代码没问题启动类扫描包路径不对确保启动类在com.campus.dormrepair包下Controller也在这个包或子包下时间字段差了8小时MySQL连接串没加serverTimezoneurl加serverTimezoneAsia/Shanghai前端请求接口就报跨域错误前后端分离但没配CORS写一个WebMvcConfigurer配置allowedOrigins(*)注意区分开发和生产环境Lombok的Data一用就编译报错IDEA没启用注解处理器Settings → Build → Compiler → Annotation Processors 勾选Enable上传图片后访问URL报403MinIO桶权限是private下载/预览走后端接口做预签名URL不要直接把桶公有化前端WebSocket连不上后端端口和前端页面端口不同后端配置setAllowedOrigins允许前端来源用Postman测试登录接口一切正常但前端就是不行并发请求导致ThreadLocal用户信息串了确认是每个请求一个线程的模型拦截器里用完后必须remove()其中ThreadLocal那次问题最隐蔽。当时是前端的同学发现多开两个浏览器标签页登录A账号后B标签页也变成了A账号的权限。我查了半天代码才意识到拦截器里put进去的用户信息在请求结束后没清理。这个坑很值得记下来因为ThreadLocal在Tomcat线程复用机制下如果不清理数据会被同一个线程的下一次请求读到。4.4 答辩时的加分点展示建议这个系统做完了答辩的时候建议按下面的顺序展示每一条都对应一个“你真正动了脑子”的证据第一先演示工单状态流转的完整链路并且故意触发一个非法操作比如试试能不能把“待接单”直接改成“已完成”然后给老师看系统的校验拦截效果。这个演示能说明你的业务逻辑是有防御性的。第二打开数据库展示repair_order_log表说明你做了操作留痕所有状态变更都有迹可循。然后说“这是我们后面做学生信用分体系的基础数据”瞬间拔高你的项目高度。第三打开统计看板展示ECharts图表说明你做的不是一个孤立的报修工具而是智慧校园数据分析平台的一个组成部分。这里可以说“未来可以接入水表电表数据做设备预测性维护”。这种话术是在描述真实规划而不是空泛展望。第四展示你的Docker部署脚本。老师问“你的项目怎么让别人跑起来”你直接说“docker-compose up”然后在笔记本上现场执行一遍这种说服力比任何PPT都强。5. 这个项目的后续进化空间如果你做完这套系统以后还有时间或者想在答辩里更进一步我给两个可以实际落地的扩展方向。第一个方向是引入消息队列。目前WebSocket推送是实时的但如果报修单量很大比如开学季集中报修高峰期WebSocket的长连接数量和推送消息的瞬时吞吐会成为瓶颈。可以引入RabbitMQ做异步削峰状态变更事件先发到消息队列推送服务消费后再发送给前端。这个改动本身不大但架构上就从“同步调用”升级成了“事件驱动”写进论文里是一个很亮眼的架构演进章节。第二个方向是做维修工单的智能调度。宿舍管理员目前是手工分配工单你可以把分配规则做成一个简单的推荐算法根据维修工的技能标签水、电、木工、当前待处理工单数、最近完成的平均时长计算一个“空闲度分数”和“适配度分数”宿管员分配的时候系统默认按综合分数排序推荐维修工。这个不需要复杂的机器学习就是一个加权打分公式但做成之后你可以在答辩上说“这是未来朝智能化运维平台演进的第一步”。我个人在实际开发中还做过一个很小的细节优化就是这个系统上线后维修工经常说“不知道学生宿舍怎么走”。后来我在系统里给每栋宿舍楼加了一个定位小程序——楼栋管理员可以上传楼栋的平面图和房间索引信息维修工在工单详情里能直接看图找到房间。那一个小改动维修效率提升得非常明显而且是我最喜欢跟人聊的一个功能点。宿舍报修系统这种题目上限和下限的差距可以非常大。往简单做就是一个CRUD往扎实做它是智慧校园运维体系里一个完整的业务闭环。核心就看你在状态机、权限模型、消息推送、部署交付这些关键节点上有没有想透。把这篇里的每个点落地你的项目就已经超过绝大多数同类毕业设计了。真遇到不确定的细节多看官方文档、多跑测试比到处问人要现成代码靠谱得多。 基于Spring Boot的高校宿舍报修管理系统设计与实现
宿舍报修这个题目几乎是每届计算机毕业设计里都会出现的“常青树”。我见过太多人把它做成一个简单的增删改查答辩时被老师问两句“并发高了怎么办”“状态乱了怎么处理”就答不上来。但其实只要把业务逻辑捋清楚、技术选型有讲究这个题目完全可以做成一份漂亮的作品既能体现工程能力又能展示你对智慧校园场景的理解。这篇文章我会完整拆解一个基于Spring Boot的高校宿舍报修管理系统的设计与实现从技术选型、数据库设计、核心业务状态机到文件上传、消息通知、数据统计再到部署和常见坑全程用我实际开发中的思路来讲。无论你是准备拿这个题目做毕设还是想在学校里落地一套公寓运维工具都可以直接“抄作业”。1. 项目整体设计与技术选型1.1 为什么说Spring Boot是这个场景的最优解先说结论Spring Boot MyBatis-Plus MySQL Vue是这类管理信息系统的最稳妥组合没有之一。很多同学会纠结要不要用Spring Cloud、要不要上Redis缓存、要不要搞微服务。我的建议很直接——宿舍报修系统本质上是一个低并发的企业级CRUD系统核心诉求是业务清晰、开发效率高、部署简单。微服务那套东西在这个场景下属于过度设计除了给答辩增加风险没有任何实际收益。Spring Boot的优势在于它把Spring生态中最常用的组件做了自动装配。你不需要再写一堆XML配置来声明数据源、配置事务管理器、注册拦截器一个SpringBootApplication注解加上application.yml里的几行配置项目就能跑起来。这对毕设项目来说极其友好你可以把时间花在业务功能上而不是浪费在环境搭建上。我实测下来的启动速度一台普通的笔记本第一次mvn spring-boot:run大概10秒左右就能完成启动热部署插件开启后改完代码重启基本在3秒以内调试效率非常高。1.2 整体架构思路前后端分离还是服务端渲染这个题目我建议采用前后端分离架构。前端用Vue 3 Element Plus后端就Spring Boot提供RESTful API。理由有三点第一智慧校园这个背景决定了系统要跟其他的校园平台做对接。前后端分离后后端接口是纯数据服务未来如果要对接校园统一门户、企业微信、钉钉只需要按接口文档调用即可不需要动页面。第二前后端分离的项目在简历上和答辩中更好讲。你可以清晰地说出“前端负责交互渲染后端负责业务逻辑与数据持久化”这种分层思想本身就是面试官和答辩老师想听到的东西。第三Vue Element Plus做出来的界面确实好看。拿宿舍报修来说学生端需要一个简洁的报修表单提交页维修工需要一个大屏任务看板管理员要看统计图表这些用Element Plus ECharts可以很轻松地实现比Thymeleaf写出来的页面漂亮不止一个档次。1.3 数据持久层为什么选MyBatis-Plus选MyBatis-Plus而不是原生MyBatis也不是Spring Data JPA我是有明确考虑的。原生MyBatis的Mapper XML写起来烦每写一个查询都要配resultMap一个报修系统光报修单相关的查询就有十来种——按学号查、按宿舍楼查、按状态查、按时间范围查、按维修工查——用XML写这些条件拼接是纯粹的体力活。MyBatis-Plus提供了BaseMapper接口单表CRUD直接继承就有不用写一行SQL。更重要的是它的条件构造器LambdaQueryWrapper像“查询某栋楼所有状态为待分配且创建时间在最近7天的报修单”这种条件用代码直接拼出来可读性比XML好太多。JPA虽然也能做但它对复杂查询的支持相对薄弱而且国内企业用MyBatis系的比例远高于JPA毕设选型紧贴就业市场的技术栈总归是加分项。2. 核心模块拆解与业务逻辑设计2.1 角色权限模型三张表搞定RBAC高校宿舍报修系统的用户角色非常清晰就三类学生、维修工、管理员。但请注意宿舍管理员和系统管理员在实际业务中权限是不同的。宿管员负责分配工单给维修工系统管理员负责维护基础数据宿舍楼、维修类型、用户账号。所以我的设计里把角色拆成了四种STUDENT、REPAIRMAN、DORM_ADMIN、SYS_ADMIN。权限模型直接用RBAC基于角色的访问控制三张核心表用户表、角色表、用户角色关联表。如果答辩老师问“你怎么控制权限”你就说“登录后把用户的角色信息存入ThreadLocal通过拦截器判断注解上的角色标识不一致就返回403”。这个回答简洁且专业比你贴一大堆Spring Security的配置代码更能说明你真正理解了权限控制的本质。实际的实现上我在后端定义了一个RequireRole注解标注在Handler方法上。拦截器里取出当前登录用户的角色集合做匹配匹配通过放行不通过直接抛异常由全局异常处理器统一转成HTTP 403响应。这段逻辑大概50行代码就能写完但效果很直观。2.2 报修工单状态机的设计最关键的业务核心报修工单绝不是一张表加一个状态字段那么简单。如果没有约束任何角色都可以任意修改状态系统很快就会乱成一锅粥。我设计的工单状态流转是严格单向的提交报修 → 待分配 → 已接单维修中 → 待验收 → 已完成中间还有一个“已驳回”和“已取消”的分支状态。学生提交工单后宿舍管理员可以驳回填写驳回理由学生自己也可以取消未开始的工单。维修工接单后状态进入维修中维修完成提交结果后进入待验收学生确认无误后置为已完成同时可以对服务进行评价。这个状态机的核心思路是状态的每一次变更都必须有合法的“前驱状态”。我在代码里用了一个枚举类RepairStatusEnum里面记录了每个状态允许的流转目标再用一个transition方法做合法性校验。这样写的好处是你完全杜绝了“从待分配直接跳到已完成”这种非法操作业务数据非常干净。写代码的时候要注意一个点状态变更和数据操作必须放在同一个事务里。比如维修工点击“接单”时不仅要改工单状态还要把工单的维修工ID、接单时间一并更新这两个操作要么同时成功要么同时失败否则就会出现“状态显示维修中但工单上没有维修工”的脏数据。2.3 数据库设计要点字段、索引与关联关系我直接给出我实测用的数据库设计方案。核心表一共六张外加三张辅助表。报修单表repair_order是核心字段包括id、order_no工单编号用年月日流水号生成、student_id报修学生、dorm_building_id宿舍楼、dorm_room宿舍门牌号、repair_type_id维修类型枚举水、电、木工、网络、其他、description问题描述、image_url图片地址JSON数组、status状态、create_time、update_time。索引上status和dorm_building_id必须加索引因为查询场景里大概率是“某栋楼未完成的工单”联合索引(dorm_building_id, status)实测效果非常好。工单表repair_work_order跟报修单表一对一关联字段包括id、repair_order_id、repairman_id、assign_time、accept_time、finish_time、finish_note维修结果说明、complete_time。用户表、宿舍楼表、维修类型表、评价表、通知公告表按常规设计即可。需要特别说明的是在宿舍楼表里我加了一个dorm_admin_id字段表示每栋楼的宿管员。这样宿管员登录后只需要查自己负责的那栋楼的工单SQL非常简单。3. 关键功能实操实现3.1 工单状态变更的代码实现从枚举到Service下面这个枚举是我在项目里实际用的精简了注释后贴出来public enum RepairOrderStatusEnum { PENDING_ASSIGN(0, 待分配), ASSIGNED(1, 待接单), REPAIRING(2, 维修中), PENDING_ACCEPT(3, 待验收), COMPLETED(4, 已完成), REJECTED(5, 已驳回), CANCELED(6, 已取消); private final Integer code; private final String desc; private static final MapInteger, ListInteger TRANSITION_MAP new HashMap(); static { TRANSITION_MAP.put(PENDING_ASSIGN.getCode(), Arrays.asList(ASSIGNED.getCode(), REJECTED.getCode(), CANCELED.getCode())); TRANSITION_MAP.put(ASSIGNED.getCode(), Arrays.asList(REPAIRING.getCode(), CANCELED.getCode())); TRANSITION_MAP.put(REPAIRING.getCode(), Arrays.asList(PENDING_ACCEPT.getCode())); TRANSITION_MAP.put(PENDING_ACCEPT.getCode(), Arrays.asList(COMPLETED.getCode())); } public static boolean canTransition(Integer from, Integer to) { ListInteger allowed TRANSITION_MAP.get(from); return allowed ! null allowed.contains(to); } }Service层里每次变更状态先校验合法性Transactional(rollbackFor Exception.class) public void finishRepair(Long workOrderId, String finishNote) { RepairWorkOrder workOrder workOrderMapper.selectById(workOrderId); RepairOrder order repairOrderMapper.selectById(workOrder.getRepairOrderId()); if (!RepairOrderStatusEnum.canTransition(order.getStatus(), RepairOrderStatusEnum.PENDING_ACCEPT.getCode())) { throw new BizException(当前状态不允许执行此操作); } order.setStatus(RepairOrderStatusEnum.PENDING_ACCEPT.getCode()); repairOrderMapper.updateById(order); workOrder.setFinishNote(finishNote); workOrder.setFinishTime(new Date()); workOrderMapper.updateById(workOrder); }这个实现的优点在于所有状态的流转规则都集中在枚举里后续要加新的状态比如“维修失败重新分配”只需要改TRANSITION_MAP不用翻业务代码。我在实际开发中还把状态变更记录写进了一张order_log表每次变更都留下痕迹答辩的时候这张表就是你的“过程管理”亮点。3.2 图片上传本地存储还是MinIO学生报修时上传现场照片是刚需。维修工到现场也经常拍个“修好后的照片”作为凭证。我的建议是本地开发用本地磁盘存储部署上线后替换成MinIO。先解释一下为什么不太推荐用FastDFS——配置太复杂需要部署Tracker和Storage两个节点单机部署为了一个毕设项目完全不值得。MinIO就简单得多就是一个提供S3兼容接口的轻量级对象存储服务单机模式一条命令就能启动。而且MinIO有非常友好的Web控制台上传的文件可以直接看到演示的时候很方便。Spring Boot集成MinIO的要点有两个。一个是初始化ClientConfiguration public class MinioConfig { Value(${minio.endpoint}) private String endpoint; Value(${minio.access-key}) private String accessKey; Value(${minio.secret-key}) private String secretKey; Bean public MinioClient minioClient() { return MinioClient.builder() .endpoint(endpoint) .credentials(accessKey, secretKey) .build(); } }另一个是文件上传的核心逻辑。我封装了一个FileStorageService对外提供upload(MultipartFile file, String bucketName)方法。存入MinIO时文件名我用UUID.randomUUID().toString()重命名目的是防止文件名冲突和特殊字符问题同时把原始文件名记录在数据库字段里下载的时候再做映射还原。这里有个实测的坑Spring Boot默认的单次请求文件大小限制是1MB multipart配置需要改大。在application.yml里加上spring: servlet: multipart: max-file-size: 10MB max-request-size: 20MB不然学生手机拍的照片稍微大一点就会报MaxUploadSizeExceededException前端弹出一个看不懂的英文错误体验极差。3.3 WebSocket实时消息通知维修进度主动推送这个系统里有一个体验分水岭——学生能不能实时收到维修进度。单纯靠学生自己去查工单状态体验感很弱。我用WebSocket做了一个消息推送模块。具体思路是学生登录系统后前端建立WebSocket连接把用户ID传过来后端用ConcurrentHashMapLong, WebSocketSession维护在线用户映射。当工单状态变更时调用MessagePushService.pushToUser(userId, message)从Map里取出该用户的Session发送JSON消息。前端收到消息后弹出一个通知提示并刷新工单列表数据。WebSocket在Spring Boot里集成不需要额外引入第三方库直接使用spring-boot-starter-websocket。实现一个WebSocketHandler或者用ServerEndpoint注解都可以。我实测下来ServerEndpoint更轻量配合Spring管理的Service使用Autowired需要额外做一个ApplicationContext工具类从Spring容器中取Bean这个坑网上解决方案很多照着用即可。这个模块做完后整个系统的交互质感会明显提升。答辩时你演示“学生提交报修后浏览器实时弹出维修工已接单的通知”绝对比干巴巴的刷新列表有说服力。3.4 数据统计与可视化ECharts展示维修画像作为智慧校园平台的一部分数据可视化是标配。我在管理后台加了一个统计看板展示三类数据近7日报修趋势、维修类型分布占比、各宿舍楼报修量排行。数据统计在后端写一个DashboardController用SQL聚合查询。比如维修类型分布SELECT repair_type, COUNT(*) AS cnt FROM repair_order WHERE create_time DATE_SUB(NOW(), INTERVAL 30 DAY) GROUP BY repair_type前端用ECharts的PieChart渲染配置项大概二十行代码。这里有个经验聚合查询的结果集不要在前端做二次加工直接让SQL把分组、排序、求和都做掉后端返回的就是可以直接渲染的清洁数据结构。前端只负责把数据映射到图表配置里这样做既高效又不容易出错。4. 项目部署与常见问题排查4.1 从IDEA新建项目到本地跑通整个流程我按一个新的Spring Boot项目从零搭建的步骤说一遍这个流程你做完一遍之后会非常顺。第一步打开IDEA选择Spring Initializr创建项目。Group填com.campusArtifact填dorm-repairJDK选1.8或者11。注意依赖选择时勾选Spring Web、MyBatis-Plus如果Initializr里没有就创建后手动引入、MySQL Driver、Lombok、Validation。第二步手动在pom.xml里加入MyBatis-Plus依赖。这里要注意version的选择早期踩过坑——MyBatis-Plus的3.5.x版本适配Spring Boot 2.x如果你用的是Spring Boot 3.x必须用MyBatis-Plus的mybatis-plus-spring-boot3-starter这个新坐标旧坐标会导致启动报找不到SqlSessionFactory。第三步配置application.yml核心配置server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/dorm_repair?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: root mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0这里我故意加了log-impl因为在开发阶段你要能看到MyBatis-Plus实际执行的SQL不然查不到数据的时候你都不知道是自己SQL写错了还是参数传错了。第四步写一个测试用Controller启动项目访问localhost:8080返回一个JSON字符串确保环境通畅。然后再从实体类、Mapper、Service、Controller的顺序逐层完善业务代码。4.2 Docker单机部署全流程毕设答辩通常需要现场演示总不能评委老师面前开一个IDEA在那里跑项目。所以提前准备一套Docker部署方案非常有必要。我推荐一个docker-compose编排两个服务MySQL 8和Java应用。MySQL用官方镜像挂载数据卷。Java应用用多阶段构建的Dockerfile打包FROM maven:3.8-openjdk-8 AS build WORKDIR /app COPY pom.xml . RUN mvn dependency:go-offline COPY src ./src RUN mvn package -DskipTests FROM openjdk:8-jre-alpine WORKDIR /app COPY --frombuild /app/target/dorm-repair-0.0.1-SNAPSHOT.jar app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, app.jar]然后docker-compose.yml里把两个服务关联起来Java应用的环境变量里配置SPRING_DATASOURCE_URL指向MySQL服务名而不是localhost。这个细节如果忘了容器里会出现“连接数据库超时”的经典报错。部署好后一条docker-compose up -d --build就能把整个系统跑起来。我自己的经验是用Docker部署完跑一遍全流程测试学生提交报修、宿管分配、维修工接单、学生验收确保所有功能正常再准备答辩。不要到答辩前一天才部署环境问题永远是最后一刻才暴露的。4.3 高频坑点与排查实录我把实际开发中遇到并且解决过的问题整理成一张速查表这些都是常规文章里不会写的症状原因解决方案启动报Failed to configure a DataSource引入了MyBatis-Plus依赖但没有配置数据源检查application.yml里的url、username、password是否配置完整访问404但Controller代码没问题启动类扫描包路径不对确保启动类在com.campus.dormrepair包下Controller也在这个包或子包下时间字段差了8小时MySQL连接串没加serverTimezoneurl加serverTimezoneAsia/Shanghai前端请求接口就报跨域错误前后端分离但没配CORS写一个WebMvcConfigurer配置allowedOrigins(*)注意区分开发和生产环境Lombok的Data一用就编译报错IDEA没启用注解处理器Settings → Build → Compiler → Annotation Processors 勾选Enable上传图片后访问URL报403MinIO桶权限是private下载/预览走后端接口做预签名URL不要直接把桶公有化前端WebSocket连不上后端端口和前端页面端口不同后端配置setAllowedOrigins允许前端来源用Postman测试登录接口一切正常但前端就是不行并发请求导致ThreadLocal用户信息串了确认是每个请求一个线程的模型拦截器里用完后必须remove()其中ThreadLocal那次问题最隐蔽。当时是前端的同学发现多开两个浏览器标签页登录A账号后B标签页也变成了A账号的权限。我查了半天代码才意识到拦截器里put进去的用户信息在请求结束后没清理。这个坑很值得记下来因为ThreadLocal在Tomcat线程复用机制下如果不清理数据会被同一个线程的下一次请求读到。4.4 答辩时的加分点展示建议这个系统做完了答辩的时候建议按下面的顺序展示每一条都对应一个“你真正动了脑子”的证据第一先演示工单状态流转的完整链路并且故意触发一个非法操作比如试试能不能把“待接单”直接改成“已完成”然后给老师看系统的校验拦截效果。这个演示能说明你的业务逻辑是有防御性的。第二打开数据库展示repair_order_log表说明你做了操作留痕所有状态变更都有迹可循。然后说“这是我们后面做学生信用分体系的基础数据”瞬间拔高你的项目高度。第三打开统计看板展示ECharts图表说明你做的不是一个孤立的报修工具而是智慧校园数据分析平台的一个组成部分。这里可以说“未来可以接入水表电表数据做设备预测性维护”。这种话术是在描述真实规划而不是空泛展望。第四展示你的Docker部署脚本。老师问“你的项目怎么让别人跑起来”你直接说“docker-compose up”然后在笔记本上现场执行一遍这种说服力比任何PPT都强。5. 这个项目的后续进化空间如果你做完这套系统以后还有时间或者想在答辩里更进一步我给两个可以实际落地的扩展方向。第一个方向是引入消息队列。目前WebSocket推送是实时的但如果报修单量很大比如开学季集中报修高峰期WebSocket的长连接数量和推送消息的瞬时吞吐会成为瓶颈。可以引入RabbitMQ做异步削峰状态变更事件先发到消息队列推送服务消费后再发送给前端。这个改动本身不大但架构上就从“同步调用”升级成了“事件驱动”写进论文里是一个很亮眼的架构演进章节。第二个方向是做维修工单的智能调度。宿舍管理员目前是手工分配工单你可以把分配规则做成一个简单的推荐算法根据维修工的技能标签水、电、木工、当前待处理工单数、最近完成的平均时长计算一个“空闲度分数”和“适配度分数”宿管员分配的时候系统默认按综合分数排序推荐维修工。这个不需要复杂的机器学习就是一个加权打分公式但做成之后你可以在答辩上说“这是未来朝智能化运维平台演进的第一步”。我个人在实际开发中还做过一个很小的细节优化就是这个系统上线后维修工经常说“不知道学生宿舍怎么走”。后来我在系统里给每栋宿舍楼加了一个定位小程序——楼栋管理员可以上传楼栋的平面图和房间索引信息维修工在工单详情里能直接看图找到房间。那一个小改动维修效率提升得非常明显而且是我最喜欢跟人聊的一个功能点。宿舍报修系统这种题目上限和下限的差距可以非常大。往简单做就是一个CRUD往扎实做它是智慧校园运维体系里一个完整的业务闭环。核心就看你在状态机、权限模型、消息推送、部署交付这些关键节点上有没有想透。把这篇里的每个点落地你的项目就已经超过绝大多数同类毕业设计了。真遇到不确定的细节多看官方文档、多跑测试比到处问人要现成代码靠谱得多。