企业官网建设流程全解析

宿舍报修这个题目，几乎是每届计算机毕业设计里都会出现的“常青树”。我见过太多人把它做成一个简单的增删改查，答辩时被老师问两句“并发高了怎么办”“状态乱了怎么处理”就答不上来。但其实，只要把业务逻辑捋清楚、技术选型有讲究，这个题目完全可以做成一份漂亮的作品，既能体现工程能力，又能展示你对智慧校园场景的理解。

这篇文章我会完整拆解一个基于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 Map<Integer, List<Integer>> 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) { List<Integer> 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的要点有两个。一个是初始化Client：

@Configuration 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传过来，后端用ConcurrentHashMap<Long, 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.campus，Artifact填dorm-repair，JDK选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?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/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 --from=build /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 高频坑点与排查实录

我把实际开发中遇到并且解决过的问题整理成一张速查表，这些都是常规文章里不会写的：

其中ThreadLocal那次问题最隐蔽。当时是前端的同学发现，多开两个浏览器标签页，登录A账号后B标签页也变成了A账号的权限。我查了半天代码才意识到，拦截器里put进去的用户信息在请求结束后没清理。这个坑很值得记下来，因为ThreadLocal在Tomcat线程复用机制下，如果不清理，数据会被同一个线程的下一次请求读到。

4.4 答辩时的加分点展示建议

这个系统做完了，答辩的时候建议按下面的顺序展示，每一条都对应一个“你真正动了脑子”的证据：

第一，先演示工单状态流转的完整链路，并且故意触发一个非法操作（比如试试能不能把“待接单”直接改成“已完成”），然后给老师看系统的校验拦截效果。这个演示能说明你的业务逻辑是有防御性的。

第二，打开数据库，展示repair_order_log表，说明你做了操作留痕，所有状态变更都有迹可循。然后说“这是我们后面做学生信用分体系的基础数据”，瞬间拔高你的项目高度。

第三，打开统计看板，展示ECharts图表，说明你做的不是一个孤立的报修工具，而是智慧校园数据分析平台的一个组成部分。这里可以说“未来可以接入水表电表数据，做设备预测性维护”。这种话术是在描述真实规划，而不是空泛展望。

第四，展示你的Docker部署脚本。老师问“你的项目怎么让别人跑起来”，你直接说“docker-compose up”，然后在笔记本上现场执行一遍，这种说服力比任何PPT都强。

5. 这个项目的后续进化空间

如果你做完这套系统以后还有时间，或者想在答辩里更进一步，我给两个可以实际落地的扩展方向。

第一个方向是引入消息队列。目前WebSocket推送是实时的，但如果报修单量很大，比如开学季集中报修高峰期，WebSocket的长连接数量和推送消息的瞬时吞吐会成为瓶颈。可以引入RabbitMQ做异步削峰：状态变更事件先发到消息队列，推送服务消费后再发送给前端。这个改动本身不大，但架构上就从“同步调用”升级成了“事件驱动”，写进论文里是一个很亮眼的架构演进章节。

第二个方向是做维修工单的智能调度。宿舍管理员目前是手工分配工单，你可以把分配规则做成一个简单的推荐算法：根据维修工的技能标签（水、电、木工）、当前待处理工单数、最近完成的平均时长，计算一个“空闲度分数”和“适配度分数”，宿管员分配的时候系统默认按综合分数排序推荐维修工。这个不需要复杂的机器学习，就是一个加权打分公式，但做成之后你可以在答辩上说“这是未来朝智能化运维平台演进的第一步”。

我个人在实际开发中还做过一个很小的细节优化，就是这个系统上线后，维修工经常说“不知道学生宿舍怎么走”。后来我在系统里给每栋宿舍楼加了一个定位小程序——楼栋管理员可以上传楼栋的平面图和房间索引信息，维修工在工单详情里能直接看图找到房间。那一个小改动，维修效率提升得非常明显，而且是我最喜欢跟人聊的一个功能点。

宿舍报修系统这种题目，上限和下限的差距可以非常大。往简单做，就是一个CRUD；往扎实做，它是智慧校园运维体系里一个完整的业务闭环。核心就看你在状态机、权限模型、消息推送、部署交付这些关键节点上有没有想透。把这篇里的每个点落地，你的项目就已经超过绝大多数同类毕业设计了。真遇到不确定的细节，多看官方文档、多跑测试，比到处问人要现成代码靠谱得多。