Java+SpringBoot+Vue宿舍报修管理系统：需求分析与数据库设计

简介这份资源面向计算机专业学生与Java Web初学者提供一套基于Java的宿舍报修管理系统完整毕业设计资料包含论文与源码可用于课程设计、毕业设计参考或校园后勤维修管理场景的技术学习。压缩包共1个docx文件约4.78MB内容为系统设计与实现的完整论文文档涵盖摘要、绪论、相关理论与技术、系统分析等章节后端采用Java语言与SpringBoot框架前端使用Vue数据库为MySQL并借助Navicat与IDEA、Tomcat完成开发部署。系统功能覆盖用户管理、维修员管理、宿舍类型与信息管理、配件分类与设备管理、维修类型管理、宿舍分配、报修信息与接单管理、配件申请及维修进度管理等模块论文对可行性分析、需求与设计思路均有展开。目前已有433人学习适合需要理解SpringBootVue前后端分离项目结构、撰写同类论文或搭建报修管理系统的读者参考借鉴。1. 从一张手写报修单说起这套系统到底要解决什么宿舍楼管桌上那本翻烂的报修登记簿大概是很多后勤管理者最熟悉的“黑匣子”——学生写一句“灯不亮”宿管抄一遍维修师傅来了再问一遍是哪个房间修完了没人记录换了什么配件。信息在三个角色之间反复传递每一次传递都在丢东西。这套基于 Java SpringBoot Vue MySQL 的宿舍报修管理系统要解决的就是这条链路上的信息断层让学生在线下单、维修员在线接单、管理员在线调度配件和进度把“口头报修、纸面登记”换成一条可追溯的数据流。它适合正在做 Java Web 方向毕设或课程设计的同学直接参考整体结构也适合需要给小型园区、公寓楼做一套轻量报修流程的开发者拿来改。下面按需求、设计、实现、避坑、验收的顺序把这份方案拆开讲透。2. 需求与角色分析三类用户、十二条功能线怎么划2.1 先定角色再谈功能很多同学一上来就画功能模块图结果画到一半发现“谁能删这条报修单”说不清楚。这套系统的角色划分很干脆管理员、用户学生/住宿者、维修员。三个角色对应三条完全不同的操作路径功能清单必须挂在角色下面才有意义。用户侧的核心动作只有五个注册登录、查宿舍信息、提交报修、查自己的报修记录、看维修进度。注意“查宿舍信息”不是可有可无的报修单里的宿舍名称、房间号、床位号都依赖宿舍分配数据用户得先能看到自己住哪报修时才能选对位置。维修员侧是登录注册、查配件、申请配件、接单、查报修、更新维修进度。这里有个容易被忽略的点——维修员不是直接改配件库存而是“申请”由管理员审批。这个设计把库存变更的权限收口到管理员手里避免维修员各自为政把库存改乱。管理员侧最重十二条管理线里有九条归他用户管理、维修员管理、宿舍类型管理、宿舍信息管理、配件分类管理、配件设备管理、维修类型管理、宿舍分配管理、报修信息管理、报修接单管理、配件申请管理、维修进度管理。看着多其实可以归成四组基础数据宿舍类型/宿舍信息/配件分类/配件设备/维修类型、人员用户/维修员、业务流转报修信息/报修接单/配件申请/维修进度、分配宿舍分配。2.2 功能需求落到用例上把上面的清单转成用例用户用例是“宿舍信息查询、报修信息查询、接单信息查询、维修进度查询、登录、注册、宿舍报修”维修员用例是“配件查询、配件申请、任务接单、报修查询、维修进度查询、登录、注册”管理员用例覆盖全部十二条管理线。写论文或方案文档时这三张用例图是系统分析章节的骨架别省。2.3 非功能需求别写成套话原文提了可靠性、稳定性、可扩展性、易于维护性四条。这四条要落到可检验的表述上才有价值可靠性指登录和报修数据录入在并发提交时不丢单稳定性指连续操作两小时不出现白屏或接口 500可扩展性指新增一种维修类型不需要改代码只在维修类型管理里加一条记录易于维护性指接口异常时有统一返回结构和日志可查。写方案时把这四条翻译成这样的句子答辩时老师追问“你怎么保证稳定性”你才有话答。提示需求分析阶段就把“配件申请需要管理员审批”这条写进流程图后面数据库设计和接口设计都会顺很多否则做到一半才发现库存表没有审批状态字段返工成本很高。3. 总体架构与技术选型前后端分离下的四层结构3.1 为什么是 SpringBoot Vue 这套组合后端 Java SpringBoot前端 Vue数据库 MySQL开发工具 IDEA Navicat服务器 Tomcat。这套组合在高校毕设里出现频率极高原因不玄学SpringBoot 把 XML 配置砍掉大半起步快Vue 的组件化让列表页、表单页可以复用MySQL 免费、资料多、Navicat 可视化建表省事。对一个人要独立完成前后端加论文的项目来说选型的首要标准不是“先进”而是“每一层你都能自己调通”。需要说清楚的是 Tomcat 的位置SpringBoot 内嵌了 Tomcat打成 jar 直接跑不需要单独部署一个外部 Tomcat。原文写“IDEA 服务器的搭建使用 Tomcat 来完成”实际落地时通常是 IDEA 里直接启动 SpringBoot 主类内嵌容器就是 Tomcat。方案文档里可以这么表述但代码层面别去配外部 Tomcat多一层就多一个翻车点。3.2 四层结构怎么分整体按前后端分离组织逻辑上分四层表现层Vue 单页应用按角色渲染不同菜单登录后把 token 存本地每次请求带上。接口层SpringBoot 的 Controller按业务域拆成用户、宿舍、报修、配件、进度等控制器统一返回结构。业务层Service处理“接单后状态怎么变”“配件申请通过后库存怎么扣”这类规则。数据层MyBatis 或 JPA 映射到 MySQL表结构对应前面列的实体。前端通过 axios 调后端 REST 接口跨域在开发期用代理解决生产期同源部署。这个结构的好处是每一层职责清晰答辩时被问“你的业务逻辑写在哪”能明确指到 Service 层而不是全堆在 Controller 里。3.3 统一返回结构先定下来接口返回格式要在写第一个接口前定死不然后面十几个控制器各写各的前端处理起来很痛苦。通常的做法是定义一个通用结果类// 统一接口返回结构code200 表示成功其余为业务错误码 public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT r new Result(); r.code 200; r.message 操作成功; r.data data; return r; } public static T ResultT fail(Integer code, String message) { ResultT r new Result(); r.code code; r.message message; return r; } }code用 200 表示成功401 表示未登录或 token 失效500 表示服务端异常业务错误比如“该报修单已被接单”用 4xx 段自定义码。data泛型承载列表或对象。前端拦截器统一判断code非 200 弹提示401 跳登录页。这个约定一旦定下后面所有接口都照此返回联调时能省掉大量“这个接口返回的字段名怎么又不一样”的扯皮。4. 数据库设计从 E-R 到十二张表的落地4.1 实体与关系先理清系统里的核心实体有六个管理员、用户、维修员、宿舍、配件、报修单。关系上一个用户对应一条或多条宿舍分配记录换宿舍的情况一条报修单属于一个用户、关联一个宿舍、可被一个维修员接单、产生若干条配件申请和进度记录。E-R 图里把“报修单”放在中心它连接用户、维修员、宿舍、配件四个实体这个中心位置决定了后面表设计的关联字段往哪放。4.2 关键表结构原文给了管理员表、token 表、宿舍信息表、用户表、宿舍类型表、宿舍分配表的结构。挑几张关键的说明设计意图。管理员表users字段是 id、username、password、role、addtime。role字段区分角色虽然叫管理员表实际可以承载多角色账号登录时按 role 分流到不同首页。密码字段长度 10 偏短实际落地建议放宽到 64 并存加密后的值原文没写加密但这是合格负责人的常规做法。token 表是这套系统的一个实用设计id、userid、username、tablename、role、token、addtime、expiratedtime。tablename记录这个 token 属于哪张用户表用户表还是维修员表因为不同角色存在不同表里登录校验时要靠它定位。expiratedtime做过期控制前端每次请求带 token后端查这张表判断有效性。这比纯 JWT 多一次查库但实现简单、能主动踢人下线对毕设场景够用。宿舍信息表sushexinxi字段较多宿舍名称、宿舍类型、宿舍分类、宿舍楼、房间号、可住人数、已住人数、有床位、更新时间、宿舍详情。这里“可住人数/已住人数/有床位”三个字段是冗余设计理论上可由宿舍分配表统计得出但列表页要频繁展示冗余存一份能避免每次聚合查询属于用空间换查询效率的常见取舍。代价是分配或退宿时要同步更新这三个字段这个同步逻辑必须写在 Service 里不能靠手动改。宿舍分配表sushefenpei记录宿舍名称、类型、分类、楼、房间号、用户账号、用户姓名、床位号、分配日期、备注。它和宿舍信息表有字段重叠这是反范式的结果——分配记录要保留当时的快照即使宿舍信息后来改了历史分配记录也不该跟着变。4.3 建表时的两个约定一是所有表统一带id主键bigint 自增和addtimetimestamp 默认 CURRENT_TIMESTAMP排序和排查问题时直接按时间倒序不用额外加字段。二是状态类字段用整型或短字符串枚举比如报修单状态用 0 待接单、1 已接单、2 维修中、3 已完成、4 已取消别用中文直接存前端映射显示文案后期加状态不用改表结构。-- 报修信息表核心字段示例状态用整型枚举便于流转控制 CREATE TABLE baoxiuxinxi ( id BIGINT PRIMARY KEY AUTO_INCREMENT, addtime TIMESTAMP DEFAULT CURRENT_TIMESTAMP, baoxiubianhao VARCHAR(32) NOT NULL, -- 报修单号业务唯一 yonghuzhanghao VARCHAR(20) NOT NULL, -- 报修人账号 sushemingcheng VARCHAR(20), -- 宿舍名称 fangjianhao VARCHAR(20), -- 房间号 weixiuleixing VARCHAR(20), -- 维修类型 baoxiuneirong TEXT, -- 故障描述 zhuangtai INT DEFAULT 0, -- 0待接单 1已接单 2维修中 3已完成 4已取消 weixiuyuanzhanghao VARCHAR(20), -- 接单维修员账号未接单为空 INDEX idx_yonghu (yonghuzhanghao), INDEX idx_zhuangtai (zhuangtai) );baoxiubianhao单独做业务单号方便用户口头报单号查询zhuangtai加索引因为管理员列表页最常按状态筛选weixiuyuanzhanghao为空表示未接单接单时写入这个字段同时承担“是否已被接单”的判断职责不用再加布尔字段。5. 核心模块实现登录、报修流转与配件申请5.1 登录与 token 校验登录接口接收账号密码按角色查对应表校验通过后生成 token 写入 token 表返回给前端。前端存本地后续请求在请求头带 token。后端用一个拦截器统一校验// 登录拦截器放行登录注册接口其余请求校验 token 有效性 public class AuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String uri request.getRequestURI(); if (uri.contains(/login) || uri.contains(/register)) { return true; // 登录注册直接放行 } String token request.getHeader(token); if (token null || token.isEmpty()) { writeFail(response, 401, 未登录); return false; } // 查 token 表判断是否存在且未过期 TokenEntity t tokenService.getByToken(token); if (t null || t.getExpiratedtime().before(new Date())) { writeFail(response, 401, 登录已失效请重新登录); return false; } return true; } }拦截器注册时排除登录、注册和静态资源路径。writeFail往 response 写统一 JSON前端拦截器收到 401 清本地 token 并跳登录页。这里的关键是 token 表要记录tablename校验通过后把当前用户信息放进 request 上下文后续 Controller 取当前登录人时直接用不用前端再传一遍账号——前端传的账号不可信这是权限控制的基本盘。5.2 报修单的状态流转报修单是整个系统的业务主线状态流转必须收口在一个 Service 方法里不能各个 Controller 随手改zhuangtai。流转规则是用户提交生成待接单0维修员接单变已接单1并写入维修员账号维修员开始维修变维修中2维修完成变已完成3用户或管理员可取消未接单的单4。每次流转写一条维修进度记录进度表存报修单号、状态、操作人、操作时间、说明。// 接单操作校验状态后更新防止两个维修员同时接同一单 Transactional public ResultString acceptOrder(String baoxiubianhao, String weixiuyuanzhanghao) { BaoxiuEntity order baoxiuMapper.selectByBianhao(baoxiubianhao); if (order null) { return Result.fail(404, 报修单不存在); } if (order.getZhuangtai() ! 0) { return Result.fail(400, 该单已被接单或已取消); } // 带状态条件的更新影响行数为 0 说明被并发抢先 int rows baoxiuMapper.acceptIfPending(baoxiubianhao, weixiuyuanzhanghao); if (rows 0) { return Result.fail(409, 手慢了该单已被其他维修员接走); } progressService.add(baoxiubianhao, 1, weixiuyuanzhanghao, 维修员接单); return Result.success(接单成功); }acceptIfPending对应的 SQL 是UPDATE baoxiuxinxi SET zhuangtai1, weixiuyuanzhanghao? WHERE baoxiubianhao? AND zhuangtai0。先查再改在并发下会翻车两个维修员同时查到状态 0都判断可接然后都更新成功一单被两人接。带AND zhuangtai0的条件更新让数据库来保证原子性影响行数为 0 就说明被别人抢先了。这个细节答辩时讲出来比背十页理论都管用。5.3 配件申请与库存扣减维修员修东西要换配件流程是维修员提交配件申请报修单号、配件、数量管理员审批通过后扣减配件库存并记录。库存扣减同样要防超卖// 审批通过先条件扣库存再改申请状态同一事务 Transactional public ResultString approve(Long shenqingId) { ShenqingEntity sq shenqingMapper.selectById(shenqingId); if (sq null || sq.getZhuangtai() ! 0) { return Result.fail(400, 申请不存在或已处理); } // 库存充足才扣影响行数为 0 表示库存不足 int rows peijianMapper.reduceStock(sq.getPeijianId(), sq.getShuliang()); if (rows 0) { return Result.fail(400, 配件库存不足无法通过); } shenqingMapper.updateZhuangtai(shenqingId, 1); // 1 表示已通过 return Result.success(审批通过); }reduceStock的 SQL 是UPDATE peijian SET kucun kucun - ? WHERE id ? AND kucun ?。把“库存够不够”的判断交给 WHERE 条件而不是先查再减避免并发下扣成负数。审批和扣库存放在同一个Transactional里任何一步失败整体回滚不会出现“申请通过了但库存没扣”的脏数据。5.4 宿舍分配与人数同步宿舍分配新增一条记录时要同步更新宿舍信息表的已住人数和有床位字段。这个同步写在分配 Service 的同一个事务里插入分配记录后按宿舍名称统计当前分配人数回写宿舍信息表。退宿或换宿舍时反向操作。之所以用统计回写而不是简单加一减一是因为换宿舍、删记录等操作容易让计数漂移每次按实际记录数重算虽然多一次查询但数据永远对得上这是用一点性能换数据一致性在宿舍规模不大的场景完全划算。6. 避坑与排查五个最容易翻车的点6.1 跨域配置写了但预检请求还是 403现象是前端调接口浏览器报 CORS 错误后端日志看不到请求。原因通常是只配了addCorsMappings允许来源但拦截器把 OPTIONS 预检请求也拦了预检没通过真实请求根本发不出去。解决是在拦截器preHandle里对OPTIONS方法直接返回 true或者用过滤器在拦截器之前处理跨域。开发期也可以用前端代理绕开但生产同源部署时这条配置仍要写对。6.2 token 过期后前端一直弹登录框现象是 token 过期用户点任何操作都弹“请重新登录”关掉又弹。原因是前端拦截器对 401 的处理没有去重一个页面同时发三个请求三个都返回 401弹三次。解决是在拦截器里加一个标志位第一次 401 时清 token 跳登录页后续 401 直接丢弃或者用 Promise 队列让并发请求等登录完成后再重放。这个坑不致命但体验极差答辩演示时很容易被撞上。6.3 报修单列表按状态筛选查不到数据现象是管理员选“已接单”筛选列表为空但数据库里明明有状态 1 的记录。原因多半是前端传的是字符串1后端实体字段是 IntegerMyBatis 拼接时类型不匹配或者状态枚举前后端定义不一致前端 1 代表待接单后端 1 代表已接单。解决是把状态枚举统一定义在一处前后端都引用同一份约定接口参数用整型接收并在文档里写清每个值的含义。这类问题排查时先看后端收到的参数值再看 SQL 日志两步就能定位。6.4 配件库存扣成负数现象是并发审批时库存出现负数。原因就是前面说的先查再减。解决是改成条件更新WHERE kucun ?判断影响行数。已经出现负数的写一个修复脚本按实际出入库记录重算库存回写。这个坑在演示时不一定触发但代码评审或答辩追问时是高频问题提前改掉能加分。6.5 删除宿舍类型导致宿舍信息页报错现象是管理员删了一个宿舍类型宿舍信息列表页加载失败或类型显示空白。原因是宿舍信息表里存的是类型名称字符串删类型不影响已有数据但前端下拉框取不到该选项或者后端关联查询时按类型名匹配不到。解决有两个方向一是删除前校验是否被引用被引用则禁止删除并提示二是关联字段改存类型 id 而不是名称。毕设场景推荐第一种改动小、逻辑直观在删除接口里加一次引用计数查询即可。注意上面五个点里6.2 和 6.4 是演示环节最容易暴露的建议在联调阶段就专门造数据压一遍别等到答辩前一天才发现。7. 验收与答辩怎么证明这套系统真的能跑验收不是把功能点挨个点一遍就完事要有能拿出手的证据链。我一般按三步走。第一步功能验收对照需求清单逐条打勾但每条要配一个具体操作路径和数据。比如“报修接单管理”这条验收动作是用户 A 提交报修单维修员 B 登录看到待接单列表接单后状态变已接单用户 A 的进度页出现“已接单”记录管理员列表按状态筛选能查到。一条链路串起三个角色比单独点三个页面有说服力。测试用例表可以这么组织用例编号测试功能前置条件操作步骤预期结果TC-01用户登录账号已注册输入正确账号密码点登录跳转用户首页token 写入本地TC-02登录失败账号已注册输入错误密码提示密码错误不跳转TC-03提交报修用户已登录且有宿舍分配选宿舍、填故障描述提交生成待接单报修单列表可见TC-04维修员接单存在待接单报修单维修员点接单状态变已接单其他维修员不可再接TC-05配件审批扣库存存在待审批申请且库存充足管理员点通过申请状态变已通过库存减对应数量TC-06配件审批库存不足申请数量大于库存管理员点通过提示库存不足申请状态不变第二步异常路径验收。正常流程谁都能跑通答辩老师更爱问异常重复接单会怎样、库存不足会怎样、token 过期会怎样、删除被引用的类型会怎样。把 6.1 到 6.5 那几个坑对应的场景各测一遍记录实际返回这比只演示成功路径更能说明系统健壮。第三步答辩陈述控制在五分钟内结构是一句话说清解决什么问题一张架构图说清技术分层一条报修全流程串起三个角色最后主动讲一个你踩过的坑和怎么解决的。最后这点特别重要——主动暴露一个已解决的问题比被问出来强得多。比如讲接单并发那个条件更新既展示了思考深度又堵住了“两个人同时接单怎么办”的追问。从那以后我每次带人做这类系统都强制在联调前把状态流转和库存扣减的并发场景先写测试跑一遍再开始堆页面。页面做得再花一条数据对不上就全盘失信。希望这套结构和验收思路能帮到你把方案落到自己的项目里时按你的实际表结构和角色再对一遍别照抄字段名。本文还有配套的精品资源点击获取