Java全栈宿舍报修系统：SpringBoot+Vue实现业务闭环与状态流转

简介这份资源面向计算机专业学生与Java Web初学者提供一套基于Java的宿舍报修管理系统完整毕业设计资料包含论文与源码可用于课程设计、毕业设计参考或校园后勤维修管理场景的技术学习。系统后端采用Java语言与SpringBoot框架前端使用Vue数据存储依托MySQL开发工具涉及IDEA、Navicat与Tomcat功能覆盖用户管理、维修员管理、宿舍类型与信息管理、配件分类与设备管理、维修类型管理、宿舍分配、报修信息与接单管理、配件申请及维修进度管理等模块业务链条较为完整。压缩包共1个文件为docx文档大小约4.78MB内容以论文正文为主涵盖摘要、绪论、相关理论与技术、系统分析等章节便于读者理解选题背景、技术选型与整体设计思路。目前已有433人学习适合需要参考同类系统架构、梳理论文写作框架或进行功能扩展练习的读者。1. 一套能跑通“报修—接单—配件—进度”闭环的 Java 全栈毕设资源宿舍报修这件事真正难的不是写一个提交表单而是把“学生报修、维修员接单、配件申请、进度回写”这条链路串成闭环。很多同学拿到一份 Java 源码包打开发现只有登录和增删改查业务流是断的答辩时被问一句“维修员申请了配件库存怎么扣”就卡住。这份基于 Java SpringBoot Vue MySQL 的宿舍报修管理系统把用户、维修员、管理员三类角色和十二个管理模块都铺开了报修信息、报修接单、配件申请、维修进度四张表之间是有状态流转的。它适合正在做 Java 全栈课程设计、需要一份能讲清业务闭环的参考实现的人也适合想拿它当 SpringBoot 分层写法模板的初学者。下面按“资源是什么—怎么跑起来—坑在哪”的顺序拆。2. 技术栈选型与三角色权限模型为什么是 SpringBoot Vue 而不是 JSP这套资源的技术组合是后端 Java SpringBoot、前端 Vue、数据库 MySQL、连接工具 Navicat、开发工具 IDEA、容器 Tomcat。乍看是常见的毕设套餐但选型背后有它自己的逻辑先把这层讲清楚后面读代码才不会觉得是堆砌。2.1 后端为什么用 SpringBoot 而不是原生 Servlet 或 SSM原生 Servlet 写一个报修列表要手写 request 解析、JDBC 连接、结果集映射代码量翻三倍SSM 虽然分层清晰但 XML 配置多一个数据源、一个事务管理器、一个 Mapper 扫描都要单独配初学者很容易在“配置文件写错一个标签”上耗掉两天。SpringBoot 的自动装配把数据源、事务、Web 容器都收进 starter 里启动类上一个注解就能跑这对课程设计这种周期短、要快速看到页面的场景是刚需。从这份资源的目录结构看后端是标准的 controller / service / mapper / entity 四层。controller 只做参数接收和返回封装service 放业务判断比如接单时校验报修单状态是不是“待接单”mapper 对应 MyBatis 的接口entity 和数据库表一一对应。这种分层的好处是答辩时能指着代码说“业务逻辑不在 controller 里”这是加分项。常见做法是把统一返回体封装成一个 Result 类code msg data 三段式前端 axios 拦截器统一处理这份资源里也是这个路子。2.2 前端为什么选 Vue 而不是 Thymeleaf 模板Thymeleaf 是服务端渲染页面和数据绑死在后端改一个表格列要重启整个应用。Vue 是前后端分离前端跑在 8080后端跑在另一个端口通过 axios 调接口改页面只刷新浏览器。对报修系统这种“列表页多、表单多”的管理后台Vue 的组件复用能省很多事一个表格组件配不同的列定义就能复用到宿舍信息、配件设备、报修信息十几个页面。这里有个容易被忽略的点前后端分离意味着要处理跨域。开发阶段前端用 devServer 的 proxy 把 /api 转发到后端端口生产阶段用 Nginx 反向代理或者把前端打包产物丢进 SpringBoot 的 static 目录。这份资源如果是直接双击 index.html 打开大概率接口全 404原因就是没走代理。后面排错章节会专门讲这个。2.3 三类角色的权限边界怎么划系统里角色分管理员、用户学生、维修员。权限不是简单的“登录了就能看所有菜单”而是按角色过滤角色可见菜单核心动作管理员全部十二个管理模块增删改查基础数据、审核配件申请、查看全部报修用户宿舍信息、报修信息、接单信息、维修进度提交报修、查看自己报修单的进度维修员配件查询、配件申请、任务接单、报修查询、维修进度接单、申请配件、回写维修进度实现上登录成功后后端返回 token同时把角色写进 token 表资源里有一张 token 表字段含 userid、username、tablename、role、token、expiratedtime。前端把 token 存 localStorage每次请求带在 header 里后端拦截器解析 token 拿到 role再决定这个接口能不能调。这里的关键是“数据级权限”而不只是“菜单级权限”用户查报修列表时SQL 里必须带where yonghuzhanghao 当前登录账号否则学生能看到全楼的报修单这是这类系统最常见的越权漏洞答辩老师一问一个准。提示token 表里存了 expiratedtime 过期时间但很多同类实现只存不校验token 永不过期。拿到资源后先搜一下拦截器里有没有比对过期时间没有的话自己补一行判断这是能写进论文“系统安全性”小节的实际改动。3. 从建库到跑通第一个接口数据库表结构与启动顺序这一章是动手部分。资源里给了论文和源码但论文的数据库章节是表格描述真正建库要靠源码里的 SQL 文件或者照着表结构手写。下面按“建库—配连接—起后端—起前端—验证接口”的顺序走每步给出可抄的命令和配置。3.1 十二张核心表的关系与建库要点从论文的物理设计看核心表包括 users管理员、token、sushexinxi宿舍信息、yonghu用户、susheleixing宿舍类型、sushefenpei宿舍分配再加上报修信息、报修接单、配件分类、配件设备、配件申请、维修进度合计十二张左右。字段命名是拼音和英文混用比如 sushemingcheng、fangjianhao、yonghuzhanghao这是这类资源的典型风格读代码时别被拼音劝退对照论文表 4.3 到 4.6 的字段说明就能对上。建库时注意三个细节。第一主键统一用 bigint 自增外键关联靠业务字段比如报修单里存 yonghuzhanghao 而不是 user_id这意味着没有数据库级外键约束数据一致性要靠 service 层保证删用户前要先查有没有未完成的报修单。第二时间字段用 timestamp 且默认 CURRENT_TIMESTAMP插入时不用手动赋值。第三长文本字段宿舍详情、备注、头像用 longtext头像存的是 base64 或路径如果是 base64字段长度要给够否则插入报错。-- 建库字符集必须 utf8mb4否则中文宿舍名和备注会乱码 CREATE DATABASE dorm_repair DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; -- 用户表核心字段对照论文表 4.4补了主键和默认时间 CREATE TABLE yonghu ( id BIGINT PRIMARY KEY AUTO_INCREMENT, addtime TIMESTAMP DEFAULT CURRENT_TIMESTAMP, yonghuzhanghao VARCHAR(20) NOT NULL COMMENT 用户账号登录名, mima VARCHAR(20) NOT NULL COMMENT 密码明文存储见避坑章节, yonghuxingming VARCHAR(20) COMMENT 用户姓名, xingbie VARCHAR(20) COMMENT 性别, lianxifangshi VARCHAR(20) COMMENT 联系方式, touxiang LONGTEXT COMMENT 头像base64 或路径 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;上面只给了用户表做示范其余表照论文表结构逐字段抄即可。逻辑说明账号字段设 NOT NULL 是因为它是登录凭据和业务关联键密码字段长度 20 够存明文但如果要改成加密存储推荐 BCrypt长度要放到 60 以上改表时记得同步改登录逻辑。参数说明utf8mb4 而不是 utf8是因为 utf8 在 MySQL 里只支持三字节存 emoji 或部分生僻字会截断报错宿舍备注里学生写个表情就翻车。3.2 application.yml 数据源配置与端口规划后端启动前要配数据库连接。SpringBoot 的配置文件在 src/main/resources 下常见是 application.yml 或 application.properties。这份资源用 MySQL连接串里要带时区和编码参数否则插入时间差 8 小时、中文变问号。server: port: 8081 # 后端端口避开前端 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/dorm_repair?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse username: root password: 你的数据库密码 mybatis: mapper-locations: classpath:mapper/*.xml # XML 映射文件位置 type-aliases-package: com.example.entity # 实体包名按实际改逻辑说明serverTimezoneAsia/Shanghai解决时间偏移useSSLfalse避免本地连接时的证书告警characterEncodingutf8配合库的 utf8mb4 保证中文正常。参数说明端口设 8081 是为了不和 Vue 默认的 8080 撞车如果后端也用 8080前端起不来会报端口占用。mapper-locations 的路径必须和实际目录一致MyBatis 找不到 XML 时启动不报错、调接口才报“Invalid bound statement”这是新手最常卡的一步。3.3 启动顺序与第一个接口验证正确顺序是先确认 MySQL 服务在跑、库和表已建好再起后端最后起前端。后端用 IDEA 打开等 Maven 依赖下载完找到带 SpringBootApplication 的启动类右键运行控制台出现 Tomcat started on port 8081 就算成功。前端进目录执行安装和启动# 前端目录下先装依赖再起开发服务器 npm install # 或 yarn install看资源里有没有 lock 文件 npm run serve # Vue CLI 项目如果是 Vite 则 npm run dev启动后浏览器开前端地址用管理员账号登录。如果登录转圈然后报网络错误先别改代码打开浏览器 F12 的 Network 面板看请求地址如果请求打到了前端端口而不是 8081说明 proxy 没配或没生效。验证后端是否独立可用可以直接用 curl 打登录接口# 直接验证后端登录接口排除前端干扰 curl -X POST http://localhost:8081/yonghu/login \ -H Content-Type: application/json \ -d {yonghuzhanghao:admin,mima:123456}返回体里如果有 token 字段说明后端链路通了问题只在前端代理。这一步的价值是把“前后端都可能有错”拆成“先证明后端对”排错效率差好几倍。4. 报修业务闭环的实现细节状态流转、接单与配件申请登录能进只是门槛这套资源真正值得看的是报修单从提交到完结的状态机。很多同类源码在这里是断的报修表只有一个“状态”字段维修员点接单直接改成“已接单”配件申请和维修进度各玩各的数据对不上。下面按业务顺序拆实现。4.1 报修单状态机五个状态与合法迁移一个能自洽的报修流程至少要有五个状态待接单、已接单、维修中、待配件、已完成。迁移规则是用户提交后为待接单维修员接单变已接单开始维修变维修中发现缺配件发起申请变待配件配件到齐继续维修最终变已完成。非法迁移要拦住比如已完成的单不能再接单待接单的单不能直接跳已完成。实现上service 层接单方法里先查当前状态不匹配就抛业务异常// 维修员接单核心是状态校验防止重复接单和跨状态操作 public Result acceptOrder(Long repairId, String weixiuyuanzhanghao) { Baoxiuxinxi order baoxiuMapper.selectById(repairId); if (order null) { return Result.error(报修单不存在); } // 只有待接单状态才能接已接单/已完成都拒绝 if (!待接单.equals(order.getZhuangtai())) { return Result.error(该报修单当前状态为 order.getZhuangtai() 无法接单); } order.setZhuangtai(已接单); order.setWeixiuyuanzhanghao(weixiuyuanzhanghao); order.setJiedanshijian(new Date()); baoxiuMapper.updateById(order); return Result.success(); }逻辑说明先查后判再改三步都在同一个 service 方法里配合方法上的 Transactional 保证原子性。参数说明repairId 是报修单主键weixiuyuanzhanghao 从 token 里解析出来而不是前端传防止维修员 A 替维修员 B 接单。这里用!equals判断状态而不是因为状态是字符串用 比较的是引用地址这是 Java 初学者高频翻车点。4.2 配件申请与库存扣减的联动维修员发现要换配件发起配件申请管理员审核通过后配件库存要减。资源里有配件分类、配件设备、配件申请三张表配件设备表里应该有库存数量字段论文表结构里没细列按业务常识补。联动逻辑是申请单审核通过时查配件设备库存够就扣减并改申请单状态为已通过不够就提示库存不足。// 管理员审核配件申请通过则扣库存拒绝则只改状态 Transactional public Result auditPeijian(Long shenqingId, String jieguo) { Peijianshenqing sq shenqingMapper.selectById(shenqingId); if (sq null || !待审核.equals(sq.getZhuangtai())) { return Result.error(申请单不存在或已处理); } if (通过.equals(jieguo)) { Peijianshebei sb shebeiMapper.selectById(sq.getShebeiId()); int kucun Integer.parseInt(sb.getKucun()); int qingqiu Integer.parseInt(sq.getShuliang()); if (kucun qingqiu) { return Result.error(库存不足当前库存 kucun); } sb.setKucun(String.valueOf(kucun - qingqiu)); shebeiMapper.updateById(sb); sq.setZhuangtai(已通过); } else { sq.setZhuangtai(已拒绝); } shenqingMapper.updateById(sq); return Result.success(); }逻辑说明Transactional 保证“扣库存”和“改申请状态”要么都成要么都败否则会出现库存扣了但申请单还是待审核的脏数据。参数说明库存和数量在表里是 varchar 存的这类资源常见所以要先 parseInt 再比较直接字符串比较 “9” “10” 会得到 true这是隐蔽 bug。如果资源里库存字段是 int去掉转换即可。4.3 维修进度回写与用户端可见性维修进度表记录每次进度更新用户端查进度时按报修单 id 查列表按时间倒序展示。实现上要注意两点进度记录要带操作人和时间方便追责用户只能查自己报修单的进度SQL 里必须带账号过滤。前端展示用时间线组件每条记录显示“时间 状态 说明”这是答辩演示时最直观的一屏。注意进度回写和报修单主状态要同步。维修员点“完成维修”时除了插一条进度记录还要把报修单状态改成已完成两个操作放同一个事务里。只改进度不改主状态用户列表里单子永远显示“维修中”这是演示时最容易被抓的破绽。5. 避坑与排查这份资源跑不起来时先看这五条资源类文章最有价值的部分在这里。下面五条是按“现象—原因—解决”整理的实测高频问题覆盖环境、配置、数据、权限、部署五个层面。5.1 启动报 Invalid bound statement (not found)现象后端能启动一调接口就报 MyBatis 的 Invalid bound statement控制台堆栈指向 mapper 方法。原因XML 映射文件没被扫描到或者 XML 里的 namespace 和接口全限定名不一致或者方法名和 XML 里的 id 对不上。解决先看 application.yml 的 mapper-locations 路径是否和实际目录一致常见是写成 classpath:mapper/*.xml 但文件在 resources/mapping 下再打开对应 XML核对 namespace 是不是接口的完整包名id 是不是方法名。三者缺一不可改完重启。5.2 登录成功但所有列表接口 401 或返回空现象登录接口返回了 token但进首页后列表全是空Network 里请求头没有 token 或 token 是 undefined。原因前端 axios 拦截器没把 token 塞进 header或者后端拦截器放行的路径配置把列表接口也拦了。解决打开前端 request.js 一类的封装文件确认请求拦截器里有config.headers[token] localStorage.getItem(token)再查后端拦截器登录、注册、静态资源要放行其余接口校验 token校验失败返回明确错误码而不是空数据否则前端以为查无数据。5.3 中文乱码宿舍名变问号、备注变方块现象页面输入中文存进库变成 ???或者查出来是乱码。原因三层编码不一致——数据库/表不是 utf8mb4、连接串没带 characterEncoding、前端页面或接口响应头编码不对。解决按顺序查先SHOW CREATE TABLE yonghu看表字符集不是 utf8mb4 就 ALTER 改再看连接串有没有 characterEncodingutf8最后看后端返回的 Content-Type 是否带 charsetUTF-8。三层都对齐乱码必消。5.4 前端起不来或接口全 404现象npm run serve 报错或者页面能开但所有请求 404。原因依赖没装全node_modules 缺失或版本冲突、proxy 没配、后端没起。解决删掉 node_modules 和 lock 文件重装检查 vue.config.js 里 devServer.proxy 的 target 是否指向后端实际端口8081 而不是 8080用 curl 直接打后端接口确认后端活着。顺序是“先证后端、再查代理、最后看依赖”别一上来就重装环境。5.5 密码明文存储与越权查询现象数据库里密码一眼可见用学生 A 的账号能查到学生 B 的报修单。原因登录逻辑直接明文比对列表查询 SQL 没带当前账号过滤。解决密码改 BCrypt 加密登录时用 matches 比对改表字段长度到 60所有“我的”类查询在 service 层强制拼当前登录账号不信任前端传的账号参数。这两条改动能直接写进论文的安全设计小节比空谈“系统安全”有说服力。6. 二次开发与答辩演示把资源改成自己的东西拿到这份资源直接交上去风险在于“和网上另一份长得一样”。真正稳妥的做法是做三处可控改动既保留业务闭环又能讲出自己的设计。第一处是加一个统计看板管理员首页放四个数字——本月报修总数、待接单数、平均维修时长、配件消耗 Top3用一条 group by 的 SQL 就能出演示时比列表页有记忆点。第二处是把状态字段从字符串改成枚举或常量类顺手在论文里写“避免魔法值”这是代码规范层面的加分。第三处是给报修单加一个“催单”按钮用户点一次给维修员发一条站内提醒实现上就是插一条消息记录工作量小但业务感强。验证改动是否成功别只看页面走一遍完整链路学生提交报修 → 维修员接单 → 发起配件申请 → 管理员审核扣库存 → 维修员回写进度 → 学生看到已完成。每一步都去数据库里对一眼状态字段和库存字段数据对得上才算真跑通。我自己的习惯是每次改完 service 层逻辑先在 Navicat 里手动改一条数据造异常状态比如把已完成的单改成待接单再点接单按钮看拦截是否生效——这种“故意造脏数据”的测法比正常流程更能暴露状态校验的漏洞。从那以后我每次交付这类管理系统都强制走一遍“造异常—看拦截—对数据”的流程省得演示当天被一个越权查询问住。希望帮到你。本文还有配套的精品资源点击获取