1. 项目核心思路与技术选型拆解

1.1 报修管理系统的本质：一张工单的生命周期

很多人第一次看到“公寓报修管理系统”这个题目，第一反应是“这不就是个增删改查吗？”但真正动手做过的同学会明白，这类系统的核心难点不在CRUD，而在业务状态机的设计。一张报修单从被提交到最终关闭，中间要经历“待审核→待派工→维修中→待验收→已结束”等多个状态，每个状态由谁触发、什么时候允许跳转、跳转时哪些字段要跟着变，这才是系统价值的真正体现。

我习惯先画一张状态流转表再写代码（这里用文字描述，你可以照着画在纸上）：学生报修提交后生成状态为“待审核”的工单，管理员审核通过后变为“待派工”，不通过则变为“已驳回”并回填驳回原因;管理员指派维修工后进入“维修中”，维修工提交处理结果后进入“待验收”;学生验收通过后工单关闭为“已结束”，验收不通过则回到“维修中”并附带验收意见。整个闭环中，任何一个状态的非法跳转都必须被代码拦截——比如“待派工”状态直接跳到“已结束”，这在业务上是不合法的。

为什么状态机这么重要？因为答辩时评委最常问的问题不是“你这张表有多少字段”，而是“如果用户重复提交报修怎么办”“维修工没处理完管理员能不能强制关闭工单”。这些问题的答案，本质上都藏在状态流转的边界条件里。建议你在数据库设计阶段就把状态枚举值固定死（比如0待审核、1待派工、2维修中、3待验收、4已结束、5已驳回），不要用字符串随意表示，否则后面写统计SQL、写条件判断的时候会非常痛苦。

1.2 为什么是SpringBoot+Vue+MySQL这个组合

先回答一个所有毕设新手都会问的问题：为什么市面上的管理类毕设几乎都是这个技术栈？三个原因。第一，成本可控。SpringBoot自带内嵌Tomcat，装好JDK和Maven就能跑后端；Vue用Node装个脚手架就能启动前端；MySQL用官方安装包装完改个密码就能连。整个环境搭建加起来半天完成，剩下的时间全部留给业务代码。第二，学习曲线平滑。SpringMVC的注解式开发、Vue的组件化开发、MyBatis的SQL映射，每一块都有海量教程和现成模板，遇到问题搜索即有答案。第三，符合行业主流。中小型项目里Java后端+Vue前端的搭配非常常见，练完这个项目，你后续去找实习时对主流开发模式不会陌生。

这里特别想纠正一个误区：不要为了显得高级就随便引入Redis、MQ、微服务。报修管理系统的并发量、数据量远远达不到需要中间件的地步，把Redis加进来只是增加了解释成本。答辩时评委问“你的缓存和数据库一致性问题怎么解决”“消息丢失怎么办”，新手很难答得圆满。老老实实把单体应用的三层架构做扎实，把表设计的约束讲清楚，比堆砌一堆用不上的技术更能拿高分。

1.3 模块划分：先立骨架再填肉

拿到题目后别急着敲代码，先按角色和业务域把模块切清楚。我的习惯是拆成七个模块：

• 登录认证模块：处理管理员、维修工、学生三类角色的登录和权限控制
• 报修管理模块：学生提交报修、查看进度、验收工单
• 人员管理模块：管理员维护学生和维修工的基础信息
• 维修工单模块：维修工查看分派给自己的任务、回填处理结果
• 公告通知模块：系统级通知和公告的发布
• 统计分析模块：按月份、按维修类别统计报修量和完成率
• 个人中心模块：修改密码、查看个人报修记录

模块拆好之后，数据库表的设计就有依据了。报修系统的表一般不会太多，核心五张左右就够：用户表、报修表、工单表、公告表、评论/评价表。很多人容易加一堆冗余字段，比如在报修表里直接把维修工姓名写进去，这种做法短期看起来方便，后面改维修工信息时就要连带修改历史数据，而且违反第三范式。正确的做法是用工单表把报修单和维修工关联起来，通过user_id做外键查询。

2. 数据库设计与核心表结构解析

2.1 建表思路：从角色到业务流转

数据库是这类系统的地基，表结构设计得好，后面业务代码写起来顺手；设计不好，写SQL的时候处处别扭。我建议你在设计时遵循一个原则：“用户-角色”做基础，报修单做中心，工单做关联，状态字段留扩展。

用户表设计时不要把管理员、维修工、学生拆成三张表。拆成三张表看似清晰，实际上登录、权限判断会非常麻烦。更合理的方案是一张user表，加一个role字段区分角色；如果你觉得一张表字段太多、不够清晰，也可以拆成user表和user_info表，把角色信息放主表，把姓名、联系方式等个人资料放附表。不过考虑到毕设体量，一张表加角色字段已经足够，还能减少联表查询的复杂度。

报修表是整个系统的主表。除了常见的repair_id（主键）、user_id（报修人）、description（故障描述，建议用TEXT类型）、location（报修位置）、images（报修图片地址，可以用JSON数组存，也可以用逗号分隔的字符串）、create_time，核心字段还有两个：status（当前状态）和priority（紧急程度）。status字段建议用tinyint类型存枚举值，而不是直接存“已审核”“维修中”这样的中文，因为中文会占用更多存储空间，而且排序、比较都不方便。priority可以用“1普通、2紧急、3特急”，报修时如果选择特急，列表页要显示红色高亮。

维修工单表起到枢纽作用，把报修单和维修工关联起来。字段包括work_order_id、repair_id、worker_id、assign_time、finish_time、handle_result、student_evaluation。之所以不直接把维修工ID写在报修表里，是因为一张报修单可能被转派给多个维修工：第一个维修工没时间处理，管理员重新指派给第二个。如果维修工ID在报修表里，转派时就要改主表数据，而工单表可以保留历史轨迹。

2.2 索引、约束与常见截断点验证

表建好之后，有两个细节经常被忽视。第一个是索引。报修列表页通常会按创建时间倒序排列，还要按状态筛选，所以create_time和status这两个字段一定记得建索引。联合索引（status, create_time）的效果比两个单列索引更好，因为MySQL走联合索引时能同时命中状态筛选和排序。第二个是外键与级联策略。报修表里的user_id建议设置外键关联用户表，但删除策略要小心——用户删除了，报修记录不能跟着删，否则历史数据就没了。合理的做法是把外键的删除策略设为SET NULL或者干脆不建物理外键，只在逻辑层通过字段关联。这是很多毕设项目被扣分的地方：“你把用户表删了，报修单也一起没了，这合理吗？”

还有一个新手容易踩的坑：时间字段的时区问题。MySQL连接URL里最好显式写serverTimezone=Asia/Shanghai，否则插入和查询的时间会差8个小时。这个坑很小，但排查起来很烦人，而且答辩演示时被评委发现时间不对会非常尴尬。

2.3 状态枚举与SQL统计的配合

状态枚举不仅仅用于界面显示，它直接影响统计报表的写法。比如要统计“各月份报修总数”，直接对报修表按月GROUP BY即可；但要统计“本月维修完成率”，就需要在工单表里判断finish_time是否在当月且status处于“已结束”。如果你从一开始就没把状态字段规范化，这些统计SQL会写得毫无逻辑。

这里分享一个我常用的统计SQL思路：月度报修量趋势。SQL大概是这样的：

SELECT DATE_FORMAT(create_time, '%Y-%m') AS month, COUNT(*) AS total FROM repair_record WHERE create_time >= DATE_SUB(CURDATE(), INTERVAL 12 MONTH) GROUP BY DATE_FORMAT(create_time, '%Y-%m') ORDER BY month DESC;

类似地，完成率的计算思路要先定义清楚“什么是完成”——我建议以“维修工回填结果且学生确认验收”为完成标志，而不是维修工填完结果就算完。因为只有学生确认了，整个服务闭环才算真正结束。

3. 后端核心功能实现与关键代码细节

3.1 登录认证与角色权限控制

权限控制这部分在答辩里一定被问到，所以值得好好讲。最基础的方案是用JWT做登录态管理：用户登录成功后，后端根据用户ID和角色生成一个Token返回，前端把Token存到localStorage，后续每次请求都带上Authorization字段。后端用一个拦截器（HandlerInterceptor）统一校验Token，从Token里取出用户ID和角色信息后放入ThreadLocal，供当前请求后续使用。

很多同学的代码问题出在“权限判断散落各处”。比如报修单的详情接口，学生只能看自己的，管理员可以全部看，怎么实现？我的建议是在Controller层做一次统一鉴权，不要每个方法各写各的。具体做法是写一个@RequireRole注解，配合拦截器在方法执行前判断当前用户角色是否满足要求。比如：

@RequireRole({"ADMIN", "WORKER"}) @GetMapping("/repair/list/all") public Result<?> listAll(@RequestParam Integer page, @RequestParam Integer size) { // 只有管理员和维修工能查所有报修单 }

这种方式的好处是权限规则集中定义，代码可读性高。但注意别过度设计，像“同为学生的两个用户之间能不能看彼此信息”这种细粒度权限，在毕设里没必要用RBAC框架去实现——简单地在查询条件里加user_id=当前登录用户ID就够了。

JWT还有一个细节要提醒：Token过期时间别设太长。有些同学为了演示方便，把Token有效期设成7天，结果就会遇到“管理员把某个用户的账号禁用了，但他还能用旧Token访问系统”的问题。解决思路是设置一个合理的过期时间（建议4小时），同时管理员禁用用户时把该用户的Token版本号+1，让旧Token失效。这部分的解释在答辩时反而是一个加分项，能体现出你对会话安全的理解。

3.2 报修单提交的前后端校验链路

报修提交功能看似简单，实际有两条校验链路必须覆盖。前端的校验主要是表单必填项和格式校验：故障描述不能为空，报修地址不能为空，图片最多上传9张。注意防重复点击——用户连点两次提交按钮，会产生两条重复报修单，这在演示时很出丑。解决方案是前端提交时用loading状态禁用按钮，同时后端再做一层幂等控制：比如同一个用户同一地址同一描述，5分钟内不能重复提交。

后端校验要更狠一点。除了字段非空校验，还要检查提交的base64图片大小是否超过限制（建议单张不超过5MB），检查用户是否被禁用。图片上传的建议做法是先上传到本地目录或OSS，数据库只存访问URL，不要把图片base64直接存进MySQL，不然表会迅速膨胀且查询缓慢。

维修工回填处理结果时，同样要看状态：只有“维修中”的工单才能回填结果，而且回填后状态要自动跳到“待验收”，前端界面应该在这个动作之后刷新工单列表并给出明确提示。这行逻辑我在很多项目里都见过写漏的，漏了之后就会出现“工单状态和操作历史对不上”的数据脏乱问题。

3.3 三层架构的代码组织之道

后端代码的组织方式直接决定你这套系统好不好维护。我的习惯是标准的controller/service/mapper三层架构，再用一个名为common的包放通用类。实体类（entity）和数据库表字段一一映射，DTO（数据传输对象）只承载接口需要的字段，VO则用于给前端返回组装好的数据。有些人图省事，直接用Map作为Controller返回值，这在外人接手时会非常混乱，而且不容易让TypeScript帮你在前端生成类型。

Service层要尽量干净，只写业务逻辑，把事务控制交给SpringBoot的@Transactional注解。注意事务的使用场景：当一次请求涉及多次写操作时（比如新建任务的时候同时派单、记录操作日志），必须开启事务，否则中途某个写入失败会出现数据不一致。这也是答辩时容易被问到的一个点。

MyBatis Plus的使用方面，我建议只在单表操作时用它的BaseMapper自带方法，多表联查和复杂统计则自己写XML映射。既省去大量样板代码，又能在答辩时坦然回答“我了解SQL如何编写”，而不是只会调用封装好的方法——这个问题问倒过不少只依赖QueryWrapper的同学。

4. 前端Vue实现与前后端联调细节

4.1 页面与路由的设计布局

前端部分，我把整体布局设计成左侧菜单栏+右侧内容区，用Vue Router管理路由。不同角色的登录用户，看到的菜单项各不相同：学生看到“我的报修”“提交报修”“公告”“个人中心”;管理员额外多出“报修审核”“维修工管理”“数据统计”;维修工看到的是“待处理任务”“历史工单”。

这里要留意路由守卫。路由守卫是前端权限的底线，比如一个非管理员用户直接访问/admin路径下的页面，会被router.beforeEach拦截并跳转到403页面。它属于体验层面的保护，真正的数据安全必须靠后端。我在带学生项目时反复强调：前端的路由守卫是“防君子不防小人”，你藏了按钮、拦了路由，但别人照样能直接调后端API，所以后端鉴权绝不允许省略。

4.2 用Vuex/Pinia管理全局状态

登录用户的信息、角色、Token这些数据，几乎每个页面都要用。放进全局状态管理里是最合理的。Vue 2项目用Vuex，Vue 3项目用Pinia。实际项目里我建议把用户信息放Pinia，同时持久化到localStorage，这样刷新页面后登录态不会丢。需要注意的安全细节是：不要把密码存进localStorage，存一个脱敏后的用户对象+Token即可。SessionStorage也行，它的好处是关闭浏览器后自动清空，但用户体验上，用户关掉浏览器重新打开页面就得重新登录，考虑到管理系统要长期挂着使用，localStorage更合适。

页面间的数据交互要注意参数传递方式。比如报修详情页，学生从列表页点击某条记录后进入详情，最简单的做法是路由带id参数，详情页用id重新请求后端接口。不要直接把整个报修对象通过路由参数传递，因为对象序列化进URL会变长甚至报错，而且刷新页面后参数会丢失。

4.3 利用Element UI快速搭建后台界面

前端界面不要从零手写CSS，直接使用Element UI（Vue 2）或Element Plus（Vue 3）的组件库。表格用el-table，分页用el-pagination，表单用el-form，弹窗用el-dialog，消息提示用el-message。这一套组合下来，前端代码量可以压缩到原生写法的三分之一不到，而且界面风格统一美观。

列表页做成“搜索条件+表格+分页”三个组件的组合体，搜索条件包括状态、日期范围、关键字。这里有个请求参数的细节要注意：每次切换查询条件、页码时，都要重置页码为1，否则你在第3页搜索“卫生间漏水”，后端返回的却是从第31条开始的结果，对不上搜索条件。这个问题很多同学一开始没注意，演示时被导师指出“搜索结果不在第一页”会非常尴尬。

4.4 前后端联调与异步请求封装

联调阶段最重要的事情是统一axios实例的封装。我在项目里会创建一个request.js文件，做三件事：设置baseURL，添加请求拦截器自动带上Token，添加响应拦截器统一处理错误码。比如后端返回401时前端自动跳登录页，返回500时弹出统一的错误提示。后端返回结构也建议统一成{code, message, data}的格式，前端判断code是否等于200，而不是直接拿data去渲染，这对后序扩展非常有利。

跨域问题在联调时几乎必现。本地开发时前端跑在8080，后端跑在8081，浏览器会发起跨域请求。解决办法有两种：前端用Vite或Webpack的代理转发，或者后端加CORS跨域配置。我更推荐第一种，因为生产环境中前后端本来就是同源部署，前端代码在开发阶段通过代理把/api路径下的请求转发到后端，这样生产环境就不需要额外的跨域处理了。如果你用第二种方式在后端全局放开CORS，演示阶段看起来一切正常，但部署后如果没配置好反而多一个排查点。

5. 项目打包、部署与文档交付全流程

5.1 前端打包与后端jar包生成

毕业设计交付的时候，评委很可能会要求你现场展示一个能跑起来的系统，所以打包部署这一步千万别等到最后一天才做。前端部分，先在项目根目录执行npm run build，Vue会自动生成一个dist目录，里面是编译后的静态文件。这里要注意，dist目录里的文件不要直接双击打开，因为路由用的是history模式，直接打开会404，必须放到Nginx或用Nginx托管。

后端部分比较简单，在pom.xml里确认打包方式是jar包，然后在IDEA里执行mvn clean package即可。如果打包时报内存不足，可以调整Maven的MAVEN_OPTS。拿到的jar包直接用java -jar xxx.jar即可启动。建议在application.yml里把数据库连接、端口等配置外置到环境变量，方便部署时按实际情况修改，不用重新打包。

这里提醒一个非常常见的部署坑：端口占用。后端启动时如果提示“Port already in use”，在Linux下执行netstat -tlnp查一下被谁占用，然后杀掉相应进程或改配置端口。Windows下则用netstat -ano定位PID再在任务管理器里结束。这个排查方法在答辩现场路过一次就长记性了。

5.2 Nginx反向代理与前后端同源部署

生产环境推荐前后端“同源部署”，即都放到一台服务器的80端口下，通过不同路径区分。在Nginx的server块里，/根路径指向前端dist目录，/api路径反向代理到后端jar包监听的8081端口：

server { listen 80; server_name your-domain.com; location / { root /opt/apartment-repair/frontend/dist; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8081; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

try_files这行是路由history模式的关键——否则刷新前端页面时会找不到对应路径。这一点你在本地可能不容易察觉，但部署后刷新某个子页面时如果404，八成就是try_files没配置。

Nginx启动后要注意，别用默认的80端口和已有网站冲突。如果同一台服务器已经运行了别的Web服务，就把server_name写清楚，或者换用其他端口。SAN证书的HTTPS配置不强制，但如果你有域名，加一张SSL证书会显得项目更专业，这部分文档网上很多，照着做即可。

5.3 论文与部署文档的撰写策略

很多同学代码写完了，论文拖到最后一周才动手，结果写得极其痛苦。我建议的流程是：先搭论文框架，再边写代码边补充内容。因为论文里的很多截图和操作截图，都是开发过程中顺手留下来的，等全部开发完再回头补截图，界面数据已经是改过的版本了，前后对不上，答辩时被质疑会很难受。

论文的结构我建议这样安排：第一章绪论（背景、意义、国内外现状）、第二章相关技术介绍、第三章系统需求分析（功能性需求+非功能性需求）、第四章系统设计（架构设计+数据库设计）、第五章系统实现（每个模块的文字描述+截图+核心代码片段）、第六章系统测试（功能测试用例表+结果分析）、第七章总结与展望。注意，核心代码要放，但不要整段堆上去，每段代码配两三句说明，讲清楚这段代码解决什么问题、用了什么关键API。

部署文档写得越详细越省事。把从装JDK、装MySQL、初始化数据库、打包、部署Nginx、启动jar包，到最终访问系统验证功能的每一步写清楚。我建议带目录、带截图、带每一步的验证方法。这份文档不光是交付物，更是你自己答辩前复习的“逃生手册”——万一现场环境有问题，照着文档快速排查比临时想解决方案靠谱得多。

6. 常见问题与排错经验实录

6.1 数据库相关高频问题

这类问题我在指导毕设时见得太多了。第一个是MySQL 8.0的密码认证方式。MySQL 8默认用caching_sha2_password，而某些老版本的JDBC驱动不认识它，连接时报Public Key Retrieval is not allowed。解决方法是在JDBC连接URL后加allowPublicKeyRetrieval=true，或者把驱动升级到8.0对应的版本。如果你装的是5.7，则要注意字符集乱码问题，连接URL里加useUnicode=true&characterEncoding=utf8。

第二个是初始化SQL执行报错。很多交付的源码都带一个.sql文件，要求在本地导入。导入时数据库的字符集如果和SQL文件里不一致，中文数据会变成乱码。建议统一用UTF-8，导入前先执行SET NAMES utf8mb4。第三位是端口冲突，MySQL默认3306端口，如果被占用会导致服务无法启动，排查时可以用命令查询端口占用后改掉MySQL配置或者杀掉占用进程。

6.2 前端与后端联调排错

开发过程中最常见的场景是：前端页面上报了个400或500错误，后端控制台却没看到明显异常。这时候第一件事不是看代码，而是打开浏览器的开发者工具Network面板，看具体请求/响应内容和状态码。如果是400，检查参数名是不是对不上，SpringBoot接收前端字段时如果用了@RequestBody，那么前端请求头Content-Type必须是application/json，且JSON字段名要和后端实体/Map的key一致。我见过太多因为前端多传了一个无关字段导致后端序列化报错的例子。

如果是跨域报错，页面会提示CORS policy相关字样。开发环境强烈建议用Vite代理，具体在vite.config.js里配置：

server: { proxy: { '/api': { target: 'http://localhost:8081', changeOrigin: true } } }

后端如果开启了CORS，要在SecurityConfig（如果有Spring Security）里放行相关路径。这个微小的配置会让你的联调体验显著提升。

另一个高频错误是后端返回数据中时间字段格式不对。SpringBoot默认返回的时间是UTC格式，前端显示出来是“2025-06-01T07:30:00.000+00:00”这样，非常戳眼睛。解决思路是配置JSON序列化的日期格式，比如在application.yml里设置spring.jackson.date-format=yyyy-MM-dd HH:mm:ss，时区设为GMT+8。这样前端拿到的就是友好的字符串，不用再做二次处理。

6.3 打好“答辩安全牌”的实操建议

最后给你一个很有用的检查清单，答辩前一天逐项过一遍：

• 管理员账号、维修工账号、学生账号三个角色的演示账号是否都已经准备好，能在答辩现场30秒内登录进去
• 数据库服务是否已设置为开机自启，避免现场重启后访问数据库失败
• 前端打包后的dist目录和时间戳、后端jar包是否是最新版本，避免“代码是新的，跑的是旧的”
• 备用方案：准备一台本地虚拟机或者备用服务器，当主演示环境出现问题时，5分钟内能切到备用环境
• 演示数据要“带戏”：提前造几组有图片、有完整状态流转的历史报修单，方便演示时直接展示不同状态的界面

答辩现场最忌讳的就是“卡在一个报错上5分钟”。哪怕你平时很熟练，也建议提前走一遍从启动到演示的完整流程，把每一步可能出问题的地方提前修好。我见过有学生演示时报修图片临时加载不出来，就是因为图片存在本地，后端重启后目录路径变了，存储目录没做统一配置。这种小问题完全可以在部署文档里预先给出一段“启动前检查”列表，现场按单排查，效率最高。

这个项目后续还能怎么扩展？如果你学有余力，可以往两个方向走：一是接入微信小程序，把学生报修端放到小程序里，方便移动端直接拍照上传;二是给数据统计页面加图表展示，用ECharts做月度趋势折线图和维修类型饼图。这些扩展不会改变系统核心架构，但对找工作时展示你的前端数据可视化能力很有帮助。回到最初说的那句话——这类系统的灵魂是工单状态流转，把生命周期管清楚了，后端的逻辑、前端的交互、数据库的设计就都顺理成章了。