SpringBoot+Vue校园设备维护报修系统：从状态机到业务闭环

不知道你有没有这种经历：在学校里待久了，最怕的就是教室的多媒体设备突然罢工、宿舍空调漏水、实验室电脑蓝屏，然后你拿着一张小纸条满楼找后勤，找到之后还不一定有人理你。报修这件事，看起来流程简单，真跑起来全是信息差。

所以当我决定自己动手做一套完整的校园设备维护报修系统时，要做的不只是把“报修单”从纸质挪到网页上，而是把整条业务流程重新捋一遍：谁报修、谁接单、谁派单、修完怎么验收、一个学期下来哪个设备最脆弱、哪个维修师傅最辛苦。这套基于SpringBoot+Vue的实现方案，不是单纯为了交作业，而是真正从使用痛点出发，把校园后勤维修管理的信息化链路跑通。

文章后面我会把整个系统的核心设计思路、关键表结构、后端接口实现、前端页面交互，以及我在实际开发中踩过的坑全部摊开来讲。如果你正打算做类似项目，或者想把自己的毕设做得更有说服力，那这篇文章应该能帮你省下不少走弯路的时间。

1. 校园设备报修的业务地图：从“一张纸条”到“完整闭环”

很多同学拿到这个题目后的第一反应是：不就是做个增删改查吗？报修人填个表单，维修工看到单子去修，管理员再汇总一下，完事。真这么想就低估校园场景的复杂性了。

1.1 三类核心角色的真实诉求

校园设备维护报修系统至少牵扯三个角色，而且每个角色对系统功能的期望完全不同。

报修人（通常是学生、任课老师、实验室管理员）要的是“容易报、看得见”。他们希望提交报修单就像发一条微信消息一样简单，不需要记一堆工号密码，也不要填十几个字段。填完之后还能随时看一下：我的单子现在到哪一步了？是没人接还是正在修？如果长期没有处理，最好还能有个催办入口。

维修人员要的是“任务清晰、路径明确”。他们最反感的是报修描述模糊——比如“多媒体教室设备坏了”，坏成什么样？是没画面还是没声音？屏幕整个黑掉还是只有信号源不对？信息不明直接导致维修工跑空、带错配件。另外维修工也需要知道自己今天有几单、都在哪栋楼，有没有哪些因为缺配件需要“挂起”的单子。

后勤管理员是整套系统的中枢。他们除了派单、分配任务、审核完成之外，还要面对月报统计的拷问：这个月一共多少单？报修高峰集中在哪几天？哪类设备故障率最高？哪个维修工平均处理时长最长？如果你只实现了一个简单的“报修列表”，管理员根本没法回答领导这些问题。

1.2 报修流程的六个关键节点

我梳理这套系统时，把完整报修生命周期拆成了六个节点：提交报修、管理员派单、维修工接单、维修处理（处理中或挂起）、完工提交、确认验收。对应到数据库里，就是一个用状态字段驱动的流转模型。

这里特别想提醒一句：很多参考代码把状态数量定得太多，结果前端页面的按钮逻辑写得乱七八糟，用户点来点去都绕晕了。我最后采用的是六态模型，方案如下：

为什么要在中间加“挂起”这个状态？因为在校园场景里，有些设备维修确实需要等配件，比如某个型号的投影仪灯泡、特定批次的主板电源电容。如果不设挂起态，维修工只能一直压着单子不处理，报修人看到系统毫无变化就会反复催单，反而增加沟通成本。挂起是给状态机一个合法暂停的口子，等配件到了再恢复成维修中。

1.3 设备台账：容易被忽略的底层数据

我见过很多版本的报修系统，都会把“设备”做成一个可有可无的下拉框选项，甚至直接让用户手填设备名称。这是个大坑。一旦设备名称不统一，后面所有的故障率统计、维修记录追溯、耗材预算核算都会变成一团乱麻。

正确做法是提前维护一份设备台账。每一台设备在入库时就录入系统，带一个唯一的设备编号，关联所属建筑、房间号、设备类型、购置日期、质保截止日期。报修人发起保修时，直接选择设备编号，系统自动带出位置信息，无需重复填写。这样做的好处有三个：

• 报修单上的位置信息准确率接近100%，维修工不用打电话反查“你说的302到底是一号楼还是三号楼？”之一。
• 故障数据能精确落到设备维度，后续可以统计出“哪台设备已经修了三次，建议直接报废换新”。
• 管理员做资产盘点时，台账和历史维修记录能相互印证，减少设备“失踪”的扯皮。

2. 技术选型背后的原因：为什么是SpringBoot+Vue而不是别的

关于技术栈，我不打算堆满一页“全家桶”。核心原则是：尽量主流，但每一层选择都要有明确的理由。

2.1 后端：SpringBoot + MyBatis-Plus

SpringBoot在这个项目里几乎是没得选的标准答案。它对内嵌Tomcat、自动配置、依赖管理做得太顺手了，你不需要自己去配一堆XML文件，写几个@RestController就能把接口暴露出去。

ORM层我用了MyBatis-Plus而不是纯MyBatis或者JPA。原因很实际：简单查询用LambdaQueryWrapper就能搞定，不用写XML映射；复杂统计比如多表关联查维修工月度完工数量，也可以直接在Mapper里面用注解SQL实现。MyBatis-Plus最实用的功能其实是分页插件，校园设备报修系统里的报修单列表几乎都要分页，写起来非常省力。

2.2 前端：Vue 2或Vue 3 + Element UI / Element Plus

前端选Vue是因为它足够轻，而且生态成熟。如果是从零开始学，建议直接上手Vue 3 + Element Plus。不过我自己的项目用的是Vue 2 + Element UI，原因是我参考的一些组件库和模板在那个时间点对Vue 3的支持还不是特别稳定。如果你现在要做，直接Vue 3就行，Element Plus已经非常成熟了。

为什么不选React？不是React不好，而是对于这类以表单、列表、弹窗为基础的管理系统，Vue加Element的上手速度和无脑组件化开发体验有优势。招聘市场上React岗位确实更多，但如果是个人项目或者毕设，我更看重的是“一个人也能快速完成前后端联调”的效率。

2.3 辅助组件：Redis、WebSocket、ECharts

这三个组件不是必须的，但加上之后整个系统的完成度会明显上一个台阶。

Redis用来做验证码存储、登录状态缓存或接口防重复提交。尤其在高并发场景下，若同一用户连续点击“保存”按钮，后端可以基于Redis的原子性操作拦截重复请求。校园报修系统的并发量虽然不高，但接口防重这层意识是好的。

WebSocket用来做新单提醒。报修人提交单子后，管理员的页面上可以实时弹出一个“新报修单待处理”的小红点。如果只靠前端轮询，每几秒请求一次不仅浪费资源，而且体验也不够即时。

ECharts用来做数据可视化面板。管理员首页放几个图表，比如近7天报修趋势、各类型设备故障占比、维修工完工数量排名，瞬间比一堆干巴巴的统计数字来得直观。

3. 数据库设计的关键决策：五张表如何撑起整个系统

表结构设计是整个项目的灵魂。我见过很多方案里表设计得太碎，一张报修单硬生生拆成五六个子表，增删改查麻烦透顶；也有设计得太粗，所有信息塞一张大表里，字段冗余到难以维护。我的做法是以“最小业务闭环”作为设计标准，把核心表控制在五张以内。

3.1 用户表与角色设计

用户表是基础中的基础。字段包含用户ID、用户名、密码（BCrypt加密存储）、真实姓名、联系电话、所属部门或学院、角色标识。角色我这里做了三种：报修人（普通用户）、维修工、管理员。没有用独立的角色表，而是在用户表里加一个role字段，用0、1、2区分。

为什么不做RBAC权限模型？因为这类系统的角色权限边界非常清晰，不存在“某个维修工同时又是管理员”这种交叉需求。提前上RBAC反而会让查询变得绕路——你每次判断当前用户能不能接单，都要去关联查询角色权限表。用一个role字段加几个自定义注解做接口权限拦截，已经是这个场景下性价比最高的方案了。

3.2 报修单表：状态机落地的关键

报修单表是整个系统的主表，字段设计上必须覆盖业务信息和状态流转信息：

• repair_id：主键
• device_id：关联设备台账表，确定报修对象
• reporter_id：报修人用户ID
• assignee_id：维修工用户ID，派单后才写入
• fault_desc：故障描述，由报修人手写或语音转文字
• fault_type：故障类型（硬件故障/软件故障/网络故障/其他），方便后续统计
• priority：优先级（普通/紧急），紧急单可以特殊标识
• status：当前状态，对应前面提的六态
• appoint_time、accept_time、finish_time：记录时间节点
• handle_content：维修处理说明
• evaluate_content、evaluate_score：维修完成后的评价信息

这中间最容易被忽略的字段是时间是流程记录。你可以用一张“流程日志表”去记录每一步的操作人和时间，但如果只是校内规模使用，直接在这些时间字段里存关键节点就够了。想要审计追溯时再查日志，日常就靠最后一列字段来展示进度。

3.3 设备台账与单表关联

设备台账表字段包括设备编号、设备名称、设备类型、所属建筑、房间号、采购时间、质保截止时间、设备状态（正常/维修中/已报废）。设备表和报修单表是一对多的关系——一台设备可以产生多次报修记录。

建议记录maintenance_count字段（维修次数），每次完工后由后台自动累加。这个字段的价值在于：当维修次数超过一定阈值，管理员可以在列表里快速筛选出“高维修频次设备”，为设备报废更新提供数据支撑。否则你要靠一条统计SQL实时去count，单子多了之后会很吃力。

3.4 评论模块是否要建表？

我之前尝试过把“评价”做成独立表，后来发现绝大多数报修单的评论都是一句“修好了，满意”或者“速度有点慢，但态度很好”，内容很轻量，根本不需要单独成表。不如直接在报修单表上扩展出evaluate_content和evaluate_score两个字段更实用。

4. 后端核心接口实现：权限校验、动态路由与状态流转

后端不是把CRUD写完就了事了。接口设计里最值得讲清楚的有三块：权限拦截方案、报修单状态流转的一致性保证、以及修复进度与WebSocket通知的联动。

4.1 用自定义注解实现接口权限拦截

在SpringBoot里做接口权限拦截，通常有两种方式：靠拦截器判断请求路径，或者靠自定义注解加AOP切面。路径判断简单但容易漏，比如某个接口前缀是/api/repair/**，你可能其中一部分允许学生访问，另一部分只允许管理员访问，靠前缀划分迟早会混乱。

我采用的是自定义注解加拦截器的方案：

@Target({ElementType.METHOD, ElementType.TYPE}) @Retention(RetentionPolicy.RUNTIME) public @interface RequireRole { String value() default "admin"; }

然后在控制器方法上标注：

@RequireRole("admin") @PostMapping("/assign") public Result assignRepair(@RequestBody AssignDTO dto) { // 管理员派单接口 }

接着写一个拦截器，在preHandle里解析JWT或Session，获取当前用户角色，与注解要求的角色比对。不匹配直接返回401或403，前端统一弹提示。

这比在每个方法里手写if (!currentUser.getRole().equals("admin"))要优雅得多，改动权限也只需要动注解。

4.2 状态流转如何避免并发问题

报修单的状态是不断变化的，最害怕的是两个人同时操作同一张单子。比如维修工A刚点了“接单”，结果管理员也恰好在这时点了“重新指派”，两个请求同时到达后端，导致状态覆盖错乱。

解决方案有两个层面。

第一层，接口幂等：在更新状态的SQL语句里加上条件判断：

boolean updated = repairMapper.updateStatus(repairId, oldStatus, newStatus) > 0;

SQL上写成：UPDATE repair SET status = newStatus WHERE repair_id = ? AND status = oldStatus。MySQL的行锁会自动保证同一时间只有一个事务能成功修改这一行。如果updated为false，说明当前状态已经不是预期的oldStatus，直接返回“操作冲突，请刷新页面”。

第二层，前端按钮做提交锁：状态流转的操作在点击后立即禁用按钮，并附带loading效果。虽然前后端都要防，但最终的安全性要依托后端的条件更新。

4.3 WebSocket通知链路的搭建

新单提交流程上，需要给管理员一个实时提醒。实现方案是后端维护一个WebSocket的Session集合，当新报修单插入成功之后，向管理员用户对应的Session推送一条消息，前端收到后弹出Notification。

推送前一定要判断Session是否有效、用户是否在线。维护一个ConcurrentHashMap，key是sessionId，value是userId。用户登录成功之后，前端发起WebSocket连接，再把userId通过消息体传给后端进行绑定。这样后端就知道用户A在线，推送时直接定向发送。

WebSocket连不上时的兜底方案也不能少：每次页面刷新时调一次“拉取待处理单数量”的普通接口。这样即使浏览器的实时连接掉了，用户刷新后也能看到数据变化。

5. 前端页面与交互细节：宁可做少一点，也要做流畅一点

前端部分如果你用过Element UI，大部分组件的使用都是套路：表单用el-form、列表用el-table、弹窗用el-dialog、提示用el-message。真正拉开体验差距的，是下面这几种交互设计。

5.1 报修表单的“极简输入”原则

报修人最讨厌填表单，所以报修页面的字段要克制。我最终只保留四个核心输入项：选择设备、故障类型、故障描述、上传图片（选填）。

选择设备这里用的是级联选择器，先选建筑楼，再选房间号，此时系统自动过滤出该楼栋房间下的设备列表，用户只要点选即可。故障描述用多行文本框，并且给一个字数下限（比如不少于10个字），避免用户只写“坏了”两个字，维修工无从下手。

上传图片建议接入对象存储或者本地上传到后端的/upload接口。图片字段存的是URL字符串，多个图片用逗号拼接。考虑到图大小，前端在提交前用canvas压缩到宽度不超过1280px，单张控制在500KB以内，避免给服务器存储造成压力。

5.2 列表页的状态标签和操作按钮

列表页（包括各自的报修记录、待分配列表、维修任务列表）最核心的处理是：不同状态显示不同操作按钮。这个直接用v-if做判断就行，不必追求动态配置。重点是状态标签的颜色要统一：待派单用灰色、待接单用橙色、维修中用蓝色、挂起用红色、待验收用紫色、已完成用绿色。视觉上一眼扫过去就能知道还有多少单“挂红灯”。

这种细节学校里的体验很重要。维修工每天来回跑，不太可能逐行仔细读状态文本，颜色一眼能看出的东西不多。

5.3 维修工移动适配：用卡片代替表格

维修工经常在校园里走动，不太可能一直坐在电脑面前。如果给维修工设计的任务列表还按照管理端的el-table来做，手机上显示会很拥挤。

针对维修工角色，我做了一个移动端适配的任务卡片流：一张卡片是一单报修，包含设备名称、楼栋房间、故障描述摘要、优先级标签、当前状态。卡片上只有两个按钮：接单/开始维修，提交完工/申请挂起。这样维修工掏出手机就能操作，不需要缩放页面。

通用处理方式是加一个isMobile状态，通过媒体查询或者window.innerWidth判断，然后切换列表渲染模板。不必单独开发一套移动端，Vue组件化可以复用大部分逻辑。

5.4 数据看板：让图表告诉你“该修什么”

管理员的首页我只放了四个图表：最近7天报修趋势折线图、设备类型故障占比饼图、维修工完工数量柱状图、平均完工时长排行表格。

折线图的横轴日期、纵轴报修数量，非常直观地可以看出每周周几是报修高峰；饼图能看到多媒体设备还是网络设备最容易出问题，预算要是有限就能优先备库相关配件；柱状图和表格用于考核维修工绩效，简单不加戏。

ECharts在Vue里的使用要注意一点: 图表容器必须有固定高度，否则默认宽度为0，图表就没法渲染。我在开发时吃过这个亏，项目里统一给图表外层套了一个classchart-box，默认高度400px。

6. 我踩过的几个坑和最终效果复盘

最后这部分不按“操作指南”来写，更像是我做这个项目时真实的调试记录。代码层面能避的坑，这里给大家都划出来。

6.1 MyBatis-Plus时间字段自动填充失效

如果实体类里的create_time、update_time用了@TableField(fill = FieldFill.INSERT)，一定要检查有没有配置MetaObjectHandler。很多同学只加了注解忘了实现接口，结果数据插入时时间字段全是null，前端列表渲染直接报错。我当时加了一个MyMetaObjectHandler（需要 implements MetaObjectHandler），在insertFill和updateFill方法里分别设置LocalDateTime.now()，问题就解决了。

6.2 事务失效场景

派单操作可能包含两个动作：更新报修单状态、给维修工写入一条待办通知。这两个动作应该是一个事务整体成功或整体失败。我一开始直接在一个方法里写了两条Mapper操作，忘了加@Transactional，结果有一次更新了状态、通知写入却失败，数据对不上了。

排查思路：先看报修单状态有没有变化，再看通知表里有没有记录。定位到问题后，在方法上加@Transactional(rollbackFor = Exception.class)，问题就解决了。记住，SpringBoot里事务默认只回滚运行时异常，如果你代码里手动捕获了异常又吃掉，事务是不生效的。

6.3 文件上传大小限制

Spring Boot默认单文件上传上限是1MB，测试时如果传大图，请求会直接报错，提示“未找到多部分文件上传”。新手很容易怀疑是前端的问题，其实改后端配置就能解决：

spring: servlet: multipart: max-file-size: 10MB max-request-size: 20MB

不过也别无脑调大。校园里上千号人同时用，存储空间是会被撑爆的，前端压缩加限制大小两手都要硬。

6.4 前端路由越权的隐患

一开始我的前端路由只是根据角色生成了菜单，但并没有真正控制页面访问权限。懂点浏览器知识的人可以绕过菜单，直接改URL访问管理页面。虽然数据量不大，真发生了就尴尬。

后来我在前端路由的meta里加了roles: ['admin', 'worker', 'user']，并且在beforeEach路由守卫里检查当前用户角色。后端接口也做了同样的权限拦截，双层防护之后才放心。

6.5 实际交付效果参考

系统真实跑起来之后，我拿学校某二级单位的后勤办公室做了小范围模拟试用。将近两周时间里登记了60多单报修，整个流程跑下来，有这几点直观感受：

• 报修人普遍欢迎“扫码报修”入口，不用抱着电脑登后台，手机浏览器打开就能填。
• 派单环节的管理员压力明显减少，因为系统会自动按楼栋分组展示待派单，且标注紧急程度，管理员不用再翻聊天记录。
• 维修工表示“接单后能看到历史维修记录”很实用，能提前预判这个设备是不是老毛病，直接带对应配件上门。
• 报表模块帮管理员发现了某个实验室的投影仪一个月内报修了5次，果断联系更换新设备，省掉了反复维修的成本。

其实如果后续要继续扩展，还可以增加配件库存管理模块，维修工在“挂起”单据时自动扣减配件数量；或者增加短信通知（需要申请短信服务签名），走到待接单、待验收状态时给相关人员发一条短信，体验会更完整。

做这套系统的过程，也是一次很好的业务梳理机会。比起堆叠花哨技术，我更推荐你先把“报修单生命周期”想明白，再动手开发。后端接口写得再漂亮，如果业务节点的状态流转都是乱的，那也只是在做一个不好用的系统而已。