简介：这份资源面向计算机专业学生与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 或路径' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

上面只给了用户表做示范，其余表照论文表结构逐字段抄即可。逻辑说明：账号字段设 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?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false username: root password: 你的数据库密码 mybatis: mapper-locations: classpath:mapper/*.xml # XML 映射文件位置 type-aliases-package: com.example.entity # 实体包名，按实际改

逻辑说明：serverTimezone=Asia/Shanghai解决时间偏移，useSSL=false避免本地连接时的证书告警，characterEncoding=utf8配合库的 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 改；再看连接串有没有 characterEncoding=utf8；最后看后端返回的 Content-Type 是否带 charset=UTF-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 里手动改一条数据造异常状态（比如把已完成的单改成待接单），再点接单按钮，看拦截是否生效——这种“故意造脏数据”的测法比正常流程更能暴露状态校验的漏洞。从那以后我每次交付这类管理系统，都强制走一遍“造异常—看拦截—对数据”的流程，省得演示当天被一个越权查询问住。希望帮到你。

本文还有配套的精品资源，点击获取