SpringBoot校园设备维护报修系统：从需求到部署的完整实战

自己开发完整的项目，和跟着教程做项目，体验完全不一样。做校园设备维护报修系统这套项目，最开始是为了解决某高校后勤处一个特别现实的麻烦：维修申请靠纸质单子、设备台账靠Excel表格、报修进度全靠打电话问。后来我把整套方案整理成一套基于SpringBoot的校园设备维护报修系统，从需求分析、数据库设计、前后端编码，到部署上线，一条线全部跑通，还顺手把毕业论文也写完了。这篇文章就是把整个项目的完整经历和实操方法做个总结，想动手做类似系统，或者正在为毕业设计发愁的同学，可以参考一下。

这套项目表面上看是一个“报修管理网站”，但拆开来看，里面包含了用户认证、权限控制、业务流状态机、文件上传、数据统计、前后端交互等一套Web系统最常见的功能模块，非常适合用来练手和学习完整的开发流程。做一遍这套系统，你对SpringBoot的理解会和只看教程完全不一样。

1. 项目定位与核心需求拆解

1.1 先搞清这个系统到底解决什么问题

很多同学拿到类似题目，第一反应就是上网搜“报修系统源码”，下载下来一看，只有几个页面和一堆简单的增删改查，然后就开始犯愁：这种东西怎么才能写成论文？怎么才能过答辩？

我建议你先别急着找代码，而是回到业务本身去思考问题。校园报修这件事，主要集中在三类场景：教室的多媒体设备坏了、宿舍的水电设施出问题、办公室的电脑和打印机故障。那么系统至少要管好这几件事：学生或老师能方便地发起报修、后勤维修人员能接到工单并反馈进度、管理员能一目了然地看到所有设备状态和维修统计。

围绕这三个场景，系统核心功能其实可以拆成下面几块：

• 用户管理：学生的注册登录、维修工的账号分配、管理员的权限管理。
• 设备管理：建立设备台账，记录设备信息、所在位置、使用状态。
• 报修管理：提交报修工单、维修工接单、维修进度更新、完工确认。
• 统计报表：按状态统计工单数量、按类别统计设备故障次数、按维修工统计工作量。

这个拆解过程本身就很有价值，因为它把“做系统”变成了“解决业务问题”。在和别人讲项目的时候，你只要把这条主线讲清楚，别人一下子就能明白你的系统是干嘛的。

1.2 业务角色与报修流程梳理

一个完整的校园报修流程，涉及三类角色，他们的关注点完全不同：

在设计数据库和接口的时候，始终要围绕这三条线走，才不会把系统做成一个“花架子”。比如报修人关心的是“我现在能不能方便地上报一个故障”，维修工关心的是“今天到底有哪些活要干嘛、哪些干完了”，管理员关心的是“哪一类设备故障率最高、哪个维修工最忙”。

流程上我是这么设计的：报修人提交工单 -> 管理员审核并派单给维修工 -> 维修工接单开始维修 -> 维修工更新状态或申请备件 -> 维修完工，报修人确认 -> 管理员归档并记录评价。这个流程是标准的工单状态机，后面会详细说状态该怎么设计。

1.3 为什么选SpringBoot而不是其他框架

现在的Web系统开发，老实说已经不太需要去纠结 SSH（SpringMVC+Spring+Hibernate）那套老古董了。SpringBoot 的生态成熟、上手快、社区资料多，而且很多企业在实际项目中确实在用，选了它，无论是做毕业设计还是找工作面试，都说得上话。

用SpringBoot还有一个特别现实的原因：它省去了大量繁琐的XML配置。早些年做SSH框架项目，光配置文件就能写一厚叠，新手很容易被配置劝退。SpringBoot把这些都自动装配好了，你可以把有限的精力放在业务逻辑上，而不是和配置文件死磕。

当然，选择SpringBoot不代表什么都不用管。你要理解它的自动配置原理，比如内置的Tomcat是怎么启动的、参数怎么改、怎么打成可执行的JAR包。这些内容虽然不会写在系统里，但面试官很喜欢问。

2. 技术选型与整体架构设计

2.1 后端技术栈的选择理由

这个项目的后端，我的选择是 SpringBoot 2.x 搭配 MyBatis-Plus。为什么用 MyBatis-Plus？因为它既保留了 MyBatis 手写SQL的灵活性，又内置了通用的单表增删改查方法，写代码效率能提升不少。

持久层框架选型上，有人可能会用 Spring Data JPA，它确实省事，但写复杂查询的时候会头疼；有人用原生MyBatis，每张表都要手写XML映射文件，工作量偏大。MyBatis-Plus算是折中选择，简单查询直接调用封装好的方法，复杂统计可以写自定义SQL，两边都不耽误。

数据库用MySQL，这是目前最主流的选择，部署文档多、问题排查容易。后来我意识到一个问题：开发阶段用MySQL没问题，但写论文的时候不要只写“用了MySQL”，而要讲清楚为什么是它——数据量不大、环境成熟、社区资料多、和SpringBoot整合方便，这些都是充足理由。论文写的是思考过程，不是单纯的工具罗列。

2.2 前端方案：管理系统到底该用什么做

管理系统类项目，前端方案我试过好几种。第一种是纯HTML页面配合Thymeleaf模板引擎，直接在Java服务端渲染，优点是结构简单、部署容易，缺点是前后端混在一起，维护起来比较痛苦。第二种用Vue写成前后端分离，功能上没问题，但需要额外搭一套前端环境，还要处理跨域问题，对新手来说成本偏高。

最后我选了一个折中方案：后端提供RESTful接口，前端用Vue或者Layui这类轻量级框架配合模板渲染。具体到这套系统，列表页用Layui的表格组件，表单页用普通HTML+Ajax提交。这种方式的优势在于一看就懂、容易改、也不影响接口的独立性。

如果你是在做毕业设计，我不太建议在技术选型上过度追求“高大全”，比如非要上微服务、非要上分布式缓存。一个校园报修系统的业务复杂度就在这里，你先把单体的代码质量做好、业务逻辑理清，远比堆技术栈更能体现工程能力。

2.3 分层架构与包结构规划

系统整体采用经典的三层架构，我按照这个包结构来组织代码：

code复制com.campus.repair
├── controller        # 接口层，接收前端请求
├── service           # 业务层，处理业务逻辑
├── mapper            # 数据访问层，封装SQL操作
├── entity            # 实体类，与数据库表对应
├── dto               # 数据传输对象，用于接口参数
├── vo                # 前端展示对象
├── config            # 配置类，拦截器、跨域处理等
├── common            # 公共类，统一返回结果、异常处理
└── utils             # 工具类

分层这件事，看起来只是一个目录结构，实则是代码逻辑的物理边界。controller层只负责接收参数和返回结果，不写业务逻辑；service层做业务判断和流程编排；mapper层只做数据访问。这样做有个特别明显的好处：以后要加个报表功能，不影响原有代码；出了Bug，也大致知道往哪个层去找问题。

3. 核心功能模块与数据库设计详解

3.1 用户角色与权限模型

权限设计是这类系统的灵魂。如果一开始就把权限做复杂了，后面每一步都会很难受。我的方案是三张表：用户表、角色表和用户角色关联表。不过在实际操作中，我发现校园报修系统的角色很固定，没有必要引入Spring Security那种重量级的权限框架，自己写一个拦截器就可以了。

角色我分了三类：学生/教职工是普通报修人员，维修工处理工单，管理员做全局管控。登录之后，系统把当前用户角色存到Session里，拦截器根据请求URL前缀判断是否放行。比如 /admin/** 开头的请求，只允许管理员访问；/worker/** 只允许维修工和访管理员访问。

这个设计在动手写代码之前花了我小半天时间考虑。因为如果用一个字段存角色，虽然简单，但是扩展性差；如果完全用框架的权限注解，写起来又啰嗦。现在这种轻量级方案，既满足业务，又特别好向别人解释。

3.2 报修工单的状态机设计

状态机是整个报修系统最核心的模型，处理得好不好，直接决定系统好不好用。我的工单状态设计如下：

状态流转的逻辑并不复杂，但容易出问题的地方在于“谁可以变更什么状态”。比如待审核工单只有管理员能看，维修中的工单只有维修工能更新进度。我实现的时候在Service层加了一个校验方法：检查当前登录用户角色和工单当前状态，匹配才能执行下一步操作。

这个校验逻辑是面试的时候很好的一个加分点，因为很多人只是做到了“能改状态”，但没做到“谁能改、什么状态下才能改”。

3.3 核心数据表结构与关键字段

数据库总共设计了六张主表，下面把其中最重要的三张表列出来。

用户表（repair_user）：

• id：主键自增
• username：登录账号，唯一索引
• password：密码，这里必须加密存储
• real_name：真实姓名
• phone：联系电话
• role_type：角色类型，1管理员、2维修工、3普通用户
• status：账号状态，1启用、0禁用
• create_time：注册时间

设备表（repair_device）：

• id：主键
• device_no：设备编号，一物一码
• device_name：设备名称
• device_type：设备类型，如多媒体、水电、办公设备
• location：所在位置，精确到楼栋和房间号
• status：设备状态，1正常、2维修中、3报废
• buy_time：购买日期
• last_repair_time：最近维修时间

报修单表（repair_order）：

• id：主键
• order_no：工单编号，建议用日期+随机数生成
• device_id：关联设备表
• report_user_id：报修人ID
• handler_id：维修工ID
• description：故障描述
• images：故障图片路径，用JSON字符串保存多张图
• priority：优先级，1一般、2紧急
• status：工单状态，对应上面的状态机
• create_time：提交时间
• finish_time：完工时间

3.4 设备台账与报修单的联动设计

设备台账和报修单之间是典型的主外键关系。每次提交报修单，必须选择一台设备或直接填写设备编号，这样统计数据的时候才能看出来“哪个楼栋故障多、哪一类设备最容易坏”。

这里有个细节很重要：报修过程中，设备状态要一起联动。当工单流转到“维修中”的时候，设备表的状态也要改成“维修中”，工单完成以后再把设备状态恢复为“正常”，并且把最近维修时间更新掉。这种做法虽然是数据库里的小联动，但业务上很合理，也是一个让系统显得“完整”的设计。

在实现联动时，提醒大家一件事：所有更新设备状态的操作，一定不要散落在各种代码里，最好封装到一个事务里面。比如维修工更新工单状态为“待验收”时，不仅要改工单表，还要改设备状态，这两个操作要么都成功，要么都失败，不然数据就乱了。

4. 关键功能实现与实战笔记

4.1 登录认证与验证码

登录逻辑是所有管理系统最基础的功能，但做得规范的人不多。我的实现方式是：用户输入账号密码后，后台先校验验证码，再查用户表，用BCrypt校验密码哈希，全部通过后把用户信息写入Session，并设置登录态。

在实现登录拦截的时候，我采用了SpringBoot的HandlerInterceptor，注册到拦截器配置类中。要注意放行登录页、静态资源，其他路径都要经过拦截。还有一个坑：如果写了拦截器但没放行注册接口，用户就永远注册不了账号，排查了大半天才反应过来是路径匹配的问题。

关于密码安全，强烈建议不要用MD5直接存密码，现在主流做法是BCrypt加密，SpringSecurity里自带这个工具，单独引入也可以。这不是让你炫技，而是答辩时老师问到密码存储方案，你答“明文存储”或“MD5”，印象分会大打折扣。

4.2 报修单的提交与进度跟踪

报修单提交页面，我重点考虑了操作体验。报修人只需要做四件事：选择设备（或填设备编号）、填写故障描述、上传照片、选择紧急程度。其他信息如报修人ID、创建时间全部由系统自动填充。

关键代码是Service层的保存逻辑。报修人提交工单时，系统要做几步处理：查询设备的当前状态，判断是否已经在维修中；如果设备不存在或状态不允许报修，直接抛出业务异常并返回给前端提示；校验通过后，插入工单数据，并且同时把设备状态标记为“维修中”。

进度跟踪对报修人来说很重要，否则他们会焦虑。我的方案是在报修单详情页展示一个简单的时间线：提交时间、审核时间、派单时间、完工时间，并显示当前状态文字。这个时间线数据不用单独建表，直接读取工单表里的几个时间戳字段，前端按固定顺序渲染即可。

4.3 派单逻辑与消息通知

派单这个功能，我一开始没想得很深，就是管理员在工单列表里选择一个维修工，然后更新工单状态。但后来发现一个问题：如果维修工不在线，这个单子就一直在那躺着，没有人处理。后来我在系统里加了一个“待接单”状态，维修工登录后能看到所有待接单的工单，根据自己能力接下对应的单子，管理员也可以指定派单，两条路都通。

说到消息通知，本来打算用WebSocket做实时提醒，后来考虑到项目周期和部署成本，用了一个折中方案：在查询工单列表的接口里增加“当前登录维修工名下有几条未处理工单”的统计，页面顶部显示一个数字角标。前端每隔10秒轮询一次，实现伪实时效果。这个方案虽然没有WebSocket那么炫，但胜在稳定、易实现、不影响论文答辩。

4.4 统计报表与图表展示

统计报表部分我做了三个维度的展示：按状态统计工单数量、按设备类型统计故障数量、按维修工统计维修完成量。前端用ECharts图表展示，后端接口直接返回统计结果。

这里涉及一个比较典型的SQL写法：按字段分组统计数量。例如统计不同状态下的工单数，SQL大概是这样：

sql复制SELECT status, COUNT(*) AS count FROM repair_order GROUP BY status;

后端组装成包含名称和值的数据结构，前端渲染饼图或柱状图。我特别提醒一下：做统计报表时，不要在Java代码里循环查数据库统计，一条SQL就能搞定的事情，写循环会导致性能差且代码难看。这个点也是答辩时老师会注意到的代码质量细节。

5. 部署安装全流程实战

5.1 开发环境准备

做这套系统，我本地的开发环境是这样准备的：JDK 1.8版本、Maven 3.6以上、MySQL 5.7或8.0、IDEA开发工具。这里有个经验：SpringBoot 2.x 配合 JDK 8 是最稳的组合，JDK版本过高反而可能出现一些意想不到的兼容问题。

开发过程中，我强烈建议在 application.yml 里分开配置开发环境和生产环境。用 spring.profiles.active 来切换环境。开发环境用本地数据库和本地文件存储路径，生产环境用服务器数据库，这样部署的时候只要改一个配置值就能切换，不用到处找配置项。

5.2 数据库初始化与配置

项目里附带的SQL脚本是完整的建库建表语句和初始数据脚本，执行方法很简单：在MySQL中创建 repair_db 数据库，设置好UTF-8编码，然后导入 repair_db.sql 文件即可。

SQL脚本中有几类初始数据必须提前准备好：管理员账号（一般是admin/admin123）、测试用的普通用户和维修工账号，以及几条设备台账数据。否则系统启动以后，你连登录都登录不了，更别提体验后续流程。

我在初始化脚本里还把默认密码统一设置成了BCrypt加密后的字符串，这样导入进去就能直接登录，这个细节会在部署文档里单独说明。如果没有这一步，新人拿到系统第一步就卡住，体验会很糟糕。

5.3 项目打包与本地启动

打包这一步，用Maven执行package命令就能生成可执行的JAR包。命令很简单：

bash复制mvn clean package -Dmaven.test.skip=true

跳过测试能节省很多打包时间。打包完成后，在target目录下会生成一个项目名的JAR文件，运行方式：

bash复制java -jar repair-system.jar --spring.profiles.active=dev

如果想改端口，可以加 --server.port=8081，这个方式非常适合在本地测试和排查问题，不用重新打包。值得一提的是，在Windows环境下启动JAR包时，如果控制台中文乱码，大概率是编码问题，需要检查IDEA和系统环境都统一成UTF-8。

5.4 服务器部署与Nginx配置

如果是部署到Linux服务器，我是这样操作的：先把JAR包上传到服务器，然后使用 nohup java -jar 后台启动并输出日志到指定文件。完整的启动命令如下：

bash复制nohup java -jar repair-system.jar --spring.profiles.active=prod > logs/run.log 2>&1 &

由于前端资源和接口是同一个服务提供的，实际上不需要复杂的反向代理配置。但如果以后想把图片等静态资源独立出来，用Nginx统一代理也是一个不错的方向。我部署的时候直接用Nginx做了两层：访问服务器的80端口，把所有请求反向代理到SpringBoot的8080端口，同时把图片上传目录单独映射到Nginx的静态目录，访问速度会好一些。

部署环节最容易忽略的是防火墙和安全组。服务器开了端口以后，一定要确认防火墙规则和云服务商的安全组规则都放行了对应端口，不然本地能启动、外部却访问不了，这个坑我踩过不止一次。

6. 常见问题与排查技巧实录

6.1 数据库连接失败

这个问题的出错概率非常高。典型的报错是 Access denied for user 或者 Communications link failure。前者是账号密码错或者权限不足，后者是数据库地址不通、端口没开。

排查的时候，我习惯先用本地的数据库客户端工具直接连接测试，如果工具能连上而程序连不上，再回头检查配置文件和依赖版本。还有一个容易忽略的点：MySQL 8.0 的驱动类名和连接URL和5.7不太一样，如果驱动版本过低会报一个奇怪的SSL错误，建议连接URL里加上 useSSL=false&serverTimezone=Asia/Shanghai，能省掉很多麻烦。

6.2 页面能打开但接口返回404

这种情况十有八九是请求路径写错了，或者Controller里没对应方法。SpringBoot的接口路径如果定义得复杂，很容易出现多一个斜杠少一个斜杠的问题。

我的排查思路是：打开浏览器的开发者工具，看网络请求返回的状态码和响应内容，然后对比Controller里的 @RequestMapping 注解路径。如果路径完全一致还是404，那就要检查是不是被拦截器拦截了，可以先把拦截器临时注释掉，再试一次，定位问题就很快。

6.3 启动时报端口被占用

这个错误我遇到好多次。用默认的8080端口启动时，提示端口被占用。最简单的处理方法是换端口启动：java -jar xxx.jar --server.port=8081。不过这只解决了启动问题，最好还是找出占用端口的进程，把它杀掉，避免后续其他项目也用这个端口的时候再冲突。

在Linux下用 lsof -i:8080 查看占用情况，Windows下用 netstat -ano | findstr 8080，看到进程ID后，任务管理器里找到对应进程结束即可，或者用 taskkill /PID 进程号 /F 强制结束。

6.4 部署后前端页面正常但图片加载不出来

图片加载不出来，大概率是上传路径和访问映射不一致。我在项目中配置了一个上传目录，并设置了静态资源映射，把 /upload/** 映射到本地磁盘的上传目录。如果你部署的时候换了目录，那访问路径就会失效。

解决方式是把上传目录做成可配置项，在配置文件中用自定义属性指定，然后用 @Value 注入到代码里。这样不管部署到哪台服务器，只要改配置文件里的路径就能保证正常访问。这个设计看起来简单，但很多项目一开始没注意，等到换服务器部署的时候才叫苦连天。

6.5 常见问题速查表

7. 项目复盘与个人经验

整套系统从设计到上线，前后花了大半个月，真正写完的那一刻，我最大的感受是：任务拆解太重要了。如果你从一开始就想着要做一个多复杂的大系统，很容易无从下手。但如果按照“用户模块->设备模块->报修模块->统计模块”这样一步一步推进，每完成一步都能看到效果，动力会持续保持。

我个人觉得这套项目的亮点不在于用了多高深的技术，而在于业务流程闭环完整、状态设计合理、部署方案可落地。特别是报修工单的状态机设计，从提交到归档每一步都有明确的角色和状态约束，这种业务抽象能力，是很多初级开发比较欠缺的地方。

如果你现在正拿着这个题目准备动手，我建议你不要只盯着源码，先自己把数据库表建一遍、把业务流程画一遍，然后再对照源码看。你会发现，真正难的不是代码怎么写，而是为什么这么设计。把这个问题想明白，无论是写论文还是面试，都轻轻松松。