简介面向计算机专业毕业设计该校园报修系统以Spring Boot与Vue为基础完整覆盖报修管理、维修记录、评价反馈等业务流程。论文严格按照毕业设计规范撰写包含绪论、相关技术介绍、需求分析、系统设计、系统实现、系统测试、总结与展望等章节并在需求分析中涉及技术、操作、法律可行性及用户需求、功能需求和非功能需求分析。系统设计部分详述了系统管理、用户管理、维修类型管理、维修工具管理、报修管理、维修记录、评价反馈等核心模块同时配以专业的系统架构图、用例图、顺序图、E-R图便于快速理解整体架构。压缩包内共1个docx文档大小1.22MB格式规范可直接查阅和编辑。已有58人学习适合毕业设计选题参考、系统架构学习及论文写作借鉴。1. 毕设选题年年撞车怎么在这道题里做出差异化校园报修系统在毕业设计里属于常青树级别的题目几乎每个学校、每届学生里都有几个人在做。如果你打开知网搜一圈会发现从JSP时代到SSH框架再到SpringBootVue这个题目已经被写了几千遍。但这不意味着它没有价值——恰恰相反选这道题的人多说明它的业务逻辑清晰、需求边界明确、工作量适中非常适合用来展示你对前后端分离开发的掌握程度。问题是大多数人做完之后都是一个模子用户提交报修单→管理员分配师傅→师傅接单处理→用户确认完成。四张表五六个接口两个角色跑通就完事。这样当然也能毕业但如果你想拿个不错的分数或者在面试时能把项目讲出亮点就必须在常规需求之上做一些别人没做的设计。我这次做的时候重点抓了三件事第一是报修全流程的状态机设计让工单流转可追踪、可回溯第二是维修师傅的派单策略不只是管理员手动分配而是加入了基于待处理工单量和技能标签的智能推荐第三是移动端适配因为没有单独做App而是把前端Vue项目直接做成了响应式布局让手机浏览器访问时也能有不错的体验。先说清楚这个项目的定位是一个非常典型的管理系统类作业核心价值在于完整的CRUD加业务流转。你不需要在上面堆砌微服务、消息队列、分布式锁这些过度设计的东西但你可以把单模块内部的逻辑做到精益求精。这篇文章我就按我实际开发的顺序把从技术选型、库表设计、后端接口、前端页面到部署上线的完整链路拆开讲顺便把我踩过的坑和最后答辩时被追问的问题也一并列出来。2. 技术栈选型为什么是SpringBootVue而不是其他组合2.1 这个组合解决的核心问题前后端分离是现在Web开发的主流形态。SpringBoot负责提供RESTful APIVue负责页面渲染和交互两边通过JSON数据通信。对于毕设来说这个组合最大的好处是分工清晰后端写业务逻辑前端写界面你可以在论文里把前后端通过接口联调作为系统架构的重点章节来写这比传统的JSPServlet或Thymeleaf模板渲染更有技术含量也更容易凑出篇幅合理的需求分析、概要设计、详细设计三段式结构。从学习成本的角度看SpringBoot本身就内置了Tomcat你不需要单独配置服务器一个mvn spring-boot:run就能起服务Vue配合Vue CLI或Vite脚手架几分钟就能搭建出工程骨架。这两样都是当前工业界的主流技能做完这个项目你简历上能写的技术栈也更有说服力。2.2 每个核心组件的作用边界在实际项目中我会把这套系统里的关键组件做一个清晰的职责划分组件版本建议在本系统里的职责SpringBoot2.7.x提供后端API服务整合MyBatis-Plus、JWT、全局异常处理MyBatis-Plus3.5.x数据访问层操作Wrapper查询、分页插件支持MySQL5.7或8.0存储用户、报修单、工单流转记录、评价等核心数据VueVue 2或Vue 3Vue 3 Vite前端工程负责三个角色的操作界面Element Plus / Ant Design Vue最新稳定版组件库表格、表单、弹窗、消息提示都靠它JWTjjwt0.9.1或0.11.x无状态登录认证拦截器校验TokenLombok1.18.x减少实体类的getter/setter样板代码Hutool5.8.x工具类验证码生成、日期处理、随机ID等有一点要特别提醒如果你的SpringBoot版本选的是3.x以上那JDK必须用17及以上而且MyBatis-Plus、jwt等相关依赖的坐标和兼容性都会变。毕设场景里我建议直接用SpringBoot 2.7.x配JDK 1.8这套组合经过了大量生产环境验证网上遇到的坑基本都有人填过了你踩雷的概率最低。2.3 数据库选型与版本细节MySQL选5.7还是8.0如果你要写存储过程或者用窗口函数做统计报表8.0更合适如果只是普通增删改查5.7完全够用。我用的是8.0主要考虑是字符集默认utf8mb4对表情符号这类特殊字符支持更好。另外数据库连接驱动需要注意版本匹配8.0的驱动类名是com.mysql.cj.jdbc.DriverURL里必须加上serverTimezoneAsia/Shanghai否则会有时区报错。3. 数据库设计从报修单流转角度反推表结构3.1 五张核心业务表的关系拆解我见过很多同学的数据表设计是从有哪些角色出发的——一个用户表、一个报修单表、一个管理员表、一个师傅表。这种做法没有错但问题是报修单和用户、师傅之间的关联关系会写得比较混乱。更好的思路是从工单流转的生命周期反推数据模型报修单被创建时是学生发起的被接单时归属到某个师傅名下被处理时状态要推进处理完成后学生要评价这每一步落在表上都需要有对应的字段支撑。我设计了这样五张核心表sys_user用户表保存学生、维修师傅、管理员的公共信息用户名、密码密文、手机号、角色类型、头像用role字段区分三种身份。这里不拆三张表的好处是登录逻辑统一一个接口处理完认证坏处是三种角色的扩展字段都要塞在同一张表里比如师傅需要技能标签、学生需要宿舍楼栋信息。我的处理方式是公共字段放主表私有扩展字段通过user_profile表学生表和repair_worker表师傅扩展表单独存。repair_order报修单主表核心字段包括报修编号业务单号、报修人ID、报修类型水、电、木工、网络等、故障描述、报修图片、楼栋房间号、紧急程度、当前状态待派单/已接单/处理中/待验收/已完成/已取消、派单师傅ID、创建时间、完成时间。你会发现这张表本身就能支撑一个报修单列表页的全部展示需求不需要每次查询都去关联用户表。repair_flow工单流转记录表这是我做差异化设计的关键。每次状态变更都往这张表里插一条记录order_id、from_status、to_status、operator_id、operator_name、operate_time、remark。这相当于给报修单加了一份档案学生能看到师傅几点接单几点到达中间有没有退回重新指派答辩时这块内容既是创新点又是加分项。repair_evaluation评价表报修单完成后学生可以对维修质量、师傅响应速度、服务态度进行打分并留言。sys_notice通知公告表管理员发布的校园通知比如停水停电检修计划前端首页轮播展示。3.2 状态流转的字段约束与边界情况状态字段我建议用tinyint数字类型存储而不是字符串比如0待派单、1已接单、2处理中、3待验收、4已完成、5已取消、6已驳回。数字的好处是排序和比较快坏处是语义不直观但前后端约定好枚举含义后完全没问题。边界情况要想清楚如果师傅接单后发现故障自己处理不了要能退回管理员重新派单如果长时间没人接单要允许管理员手动指派如果学生提交后想取消报修只有待派单状态才能取消一旦师傅接单了就只能联系管理员操作。这些规则我会在后端Service层用状态机校验来做——不是简单地接收前端传过来的目标状态而是先判断当前状态是否允许执行某个操作不允许就抛出业务异常。3.3 索引与字段设计的几个细节教训repair_order表一定要给user_id和status建联合索引因为页面端最常做的查询就是某个人当前有哪些状态的工单。报修编号不建议直接用数据库自增ID我用的Hutool的IdUtil.getSnowflakeNextIdStr()生成19位雪花ID展示给用户的格式是BX20250114001这种既能看出年份月份也不会暴露系统数据量。图片存储我没有用OSS或者云存储而是保存到本地磁盘目录并在数据库存相对路径配合SpringBoot的静态资源映射暴露出来。毕设场景够用但如果上线生产环境肯定要换对象存储这个在论文里要提一句。所有表都加上create_time、update_time、deleted逻辑删除三个公共字段MyBatis-Plus的自动填充功能可以统一维护这些字段。4. 后端架构Master数据权限与业务边界划分4.1 Controller-Service-Mapper三层的具体落地方式网上SpringBoot项目教程满天飞但真正到写代码时很多人还是会混淆Controller里该写多少逻辑。我的分层原则很明确Controller只做参数接收和结果封装所有业务规则都在Service层验证数据访问只发生在Mapper层。以提交报修单这个接口为例接口路径是POST /api/order前端传来的JSON长这样{ repairType: 1, description: 宿舍灯管闪烁怀疑即将烧坏, images: [/upload/20250114/xxx.jpg], building: 3号宿舍楼, room: 502, emergencyLevel: 2 }Controller层拿到DTO后只校验基本的非空参数然后调用RepairOrderService.createOrder(userId, dto)。Service层要做的事包括根据userId查询用户信息确认角色是学生防止师傅或管理员冒充学生提交生成报修业务编号组装RepairOrder实体状态设为待派单插入主表同时往repair_flow表插入一条初始流转记录如果有需要给管理员发送站内通知。Service层方法加上Transactional事务注解保证至少第4步里订单插入流转记录插入是原子的——要么都成功要么都回滚。4.2 权限控制拦截器、JWT与角色校验的三层防线整个系统的权限模型是三类角色互不可越权学生student只能操作自己的报修单创建、查看详情、取消待派单状态的单子、确认完成、评价维修师傅worker只能看派给自己的工单并执行接单、开始处理、完成处理、申请延期等动作管理员admin能看到全部工单进行派单、驳回、强制完成、公告管理、用户管理等全局操作。JWT的过滤器去解析每个请求头里带的Authorization: Bearer token把userId和role塞进一个ThreadLocal上下文里后续Service层做数据权限判断时直接从上下文取当前用户。除了登录接口和验证码接口其他接口都要求Token有效。只靠JWT校验还不够数据权限要放在Service层做二次拦截。比如学生查自己的工单列表SQL层面就必须强制带上WHERE user_id 当前登录用户id不能依靠前端传参来过滤——否则我可以随便改请求参数里的userId看到别人的报修单这是一个很典型的越权漏洞。4.3 全局异常与统一返回体让前端少写一万行判断前后端分离项目里最痛苦的事之一就是后端接口返回格式不统一。有的接口直接返回对象有的接口出错时返回字符串前端拿着数据还要各种判断。我在项目里定义了一个统一的返回体ResultTData public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(操作成功); result.setData(data); return result; } public static T ResultT error(String message) { ResultT result new Result(); result.setCode(500); result.setMessage(message); return result; } }配合RestControllerAdvice全局异常处理器把参数校验异常、业务异常、数据库异常统一包装成这个格式。前端axios拦截器里只需要判断res.data.code 200其他情况统一弹message提示代码干净很多。4.4 报表统计后端聚合接口的设计思路论文里一定要有系统功能测试章节最常见的内容就是展示几个统计图表。我在系统里为管理员设计了一个仪表盘页面需要三类数据报修单按状态的分类统计待派单有多少、进行中有多少、已完成有多少近7天每日新增报修单趋势各维修类型的占比水、电、木工、网络的饼图。这三类数据我没有让前端循环调列表接口自己算而是在后端写了一个聚合查询接口。用MyBatis-Plus的QueryWrapper配合select指定分组字段返回一个Map。复杂的SQL写在XML里也方便。前端ECharts直接拿数据填充。5. 前端Vue从脚手架到响应式适配的完整实践5.1 Vue项目初始化与工程配置前端工程用Vite初始化命令就一行npm create vitelatest repair-web -- --template vue装完基础依赖后我额外安装了这些包包名用途vue-router前端路由管理控制页面跳转pinia状态管理存储用户信息、登录态axiosHTTP请求封装统一baseURL和拦截器element-plusUI组件库表格、表单、弹窗、日期选择器echarts图表库负责仪表盘统计可视化sassCSS预处理器方便写嵌套样式和公共变量需要特别注意的是Element Plus在Vue 3中的完整引入和按需引入的区别。毕设项目直接全量引入最省事在main.js里app.use(ElementPlus)就够了不要在这个环节上花时间折腾自动按需导入插件除非你的项目打包后体积真的过大。5.2 路由懒加载与登录守卫三套角色的界面我拆成了三个大模块学生端、师傅端、管理端各自有布局组件和子页面。路由配置用动态import()实现懒加载首屏只加载必要的JS访问哪个页面才加载哪个模块的代码。路由守卫的逻辑很简单router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (!token to.path ! /login) { next(/login) return } if (token to.path /login) { next(/) return } next() })实际项目里还会加一个角色判断如果学生登录后手动输入/admin开头的地址导航守卫必须拦截并重定向到首页。我这里的做法是路由meta里标记roles: [admin]守卫里比对当前用户角色。5.3 表格与表单报修单列表页的完整实现思路报修单列表是系统的核心页面学生要看自己提交的单子师傅要看派给自己的单子管理员要看全部单子。同一个页面组件根据当前登录角色决定请求哪个接口——后端本身有三个不同的接口URL前端用同一套表格组件接收数据。表格列包括报修编号、报修类型用tag标签显示不同颜色、故障描述超出一定长度用文字提示、楼栋房间、紧急程度、当前状态、提交时间、操作按钮。操作按钮根据状态和角色判断显示哪个待派单状态的单子显示取消按钮师傅端显示接单开始处理完成处理学生端在师傅完成后显示确认完成和去评价管理员显示派单驳回。表单部分我用了Element Plus的el-form配合rules校验规则报修类型、楼栋房间、故障描述是必填项图片上传用el-upload组件手动上传到后端/api/upload接口把返回的图片URL填进表单字段。5.4 移动端适配没有App也要让手机能用现在学生报修大概率是用手机操作的所以我给前端页面做了响应式适配。我的做法不算复杂用SCSS的媒体查询在min-width: 768px条件下显示桌面端布局小于这个宽度时把表格列精简成卡片列表按钮区域放大表单布局改为单列。Element Plus的el-col栅格系统本身就支持响应式断点大部分页面稍微调整一下栅格比例就能适配。这一步在答辩时是一个很好讲的亮点——本系统采用响应式设计在不开发独立移动端应用的前提下覆盖了学生手机端的报修场景这句话可以放在论文的系统特色小节里。6. 派单机制从手动指定到带权重的智能推荐6.1 为什么需要派单算法报修单创建后如果只靠管理员手动分配管理员必须熟悉每个师傅的当前工作量、擅长技能、接单效率这在小规模测试里没问题但一旦报修单多了就很容易分配不均同一个师傅堆了20个单子另一个师傅闲得慌。我在系统里做了一个简单的推荐逻辑不追求多复杂但至少解决了推荐谁的问题。6.2 推荐规则的三个维度当一个新报修单进入待派单状态管理员的派单页面会调用一个推荐接口返回三个候选师傅按推荐指数从高到低排列。推荐指数的计算权重如下技能匹配度40%权重报修单有repairType水、电、木工、网络师傅的扩展表里有skill_tags字段存一个或多个技能标签。技能完全匹配的师傅得满分不匹配的此项为0。当前待处理工单数40%权重师傅名下处于已接单或处理中状态的工单越少得分越高。我用了一个简单公式max(0, 1 - 当前单量/10)单量为0时得1分10单以上得0分。历史评价分20%权重从评价表聚合每个师傅最近10次评价的平均分归一化到[0,1]。总分的计算逻辑是score 技能分*0.4 负载分*0.4 评价分*0.2。前端拿到推荐候选后展示在派单弹窗里管理员可以一键采纳也可以忽略推荐手动搜索师傅。6.3 延展思考这个算法能替换成什么在论文的系统改进方向里我写了一段关于基于排队论和GPS定位的派单优化的展望如果学校足够大维修师傅分布在校园不同位置可以结合距离因子来优化推荐模型如果对人工派单的公平要求更高可以引入简单的贪心算法让每个新工单自动分配给当前负载最低的且技能匹配的师傅。这段展望不写代码都没关系但论文评审老师看到你的思考深度印象分会高不少。7. 安全与异常那些不写就会出事的细节7.1 登录安全验证码、加密存储与防暴力破解登录页我用了Hutool生成图片验证码后端接口GET /api/captcha返回一个UUID作为captchaKey和Base64图片字符串缓存到Redis里有效期5分钟。登录时提交captchaKey和captchaCode后端比对缓存里的值不一致直接返回验证码错误。密码不能明文存用BCrypt加密——Spring Security自带BCryptPasswordEncoder也可以单独引入spring-security-crypto这个依赖只用到加密工具类不用引入整套Security。登录成功时比较加密后的密文是否匹配。防暴力破解我做得比较简单用户连续输错密码5次账号锁定15分钟用一个Map在内存里记录失败次数。如果要严谨一点应该换Redis并设置过期时间不过毕设场景内存Map也够用。7.2 JWT过期与续期策略JWT的过期时间我设置成2小时。前端axios响应拦截器里判断状态码如果返回401说明Token过期弹出提示并跳转登录页重新登录。这里有个体验优化——如果用户在填写报修表单时正好过期表单内容会全部丢失很恼人。所以我在ajax请求里做了Token即将过期提前刷新的逻辑解析JWT的exp字段如果剩余时间小于30分钟调用一个/api/auth/refresh接口用refreshToken换新Token透明地替换后续请求里的Header。7.3 文件上传的安全边界图片上传接口如果不做任何限制会被拿来上传恶意脚本或者超大文件把磁盘塞满。我用MultipartFile的getOriginalFilename()做后缀白名单校验只允许jpg、png、jpeg、gif、webp格式文件大小限制在5MB以内。SpringBoot的配置文件里设置spring: servlet: multipart: max-file-size: 5MB max-request-size: 20MB文件名用UUID重命名不保留用户原始文件名避免路径穿越和重名覆盖问题。上传后的文件保存到服务器的/upload目录通过自定义静态资源映射暴露访问路径Configuration public class WebMvcConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceHandler(file: System.getProperty(user.dir) /upload/); } }7.4 异步通知维修进度变化时主动触达用户系统里有一个小功能是状态变更通知用户。如果每次状态变更好都直接同步发送短信或站内信接口响应会变慢。我引入了Spring框架自带的Async注解在Service层把插入通知记录这个操作声明为异步执行这样主流程的事务提交不受影响通知的延迟在毫秒级。记得在主启动类上加EnableAsync开启异步支持。8. 联调、打包与上线部署别等答辩前一天才想起这一步8.1 前后端联调的CORS与代理配置开发环境下前端跑在http://localhost:5173Vite默认端口后端跑在http://localhost:8080浏览器会有跨域限制。我的处理方案是后端配置一个CorsFilter允许所有来源、所有方法、所有Header跨域请求。生产环境下前后端如果部署在同一台服务器同一个域就不存在跨域问题可以把这个Filter的allowedOrigins收紧。后端CORS配置示例Configuration public class CorsConfig { Bean public CorsFilter corsFilter() { CorsConfiguration config new CorsConfiguration(); config.addAllowedOriginPattern(*); config.addAllowedMethod(*); config.addAllowedHeader(*); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration(/**, config); return new CorsFilter(source); } }8.2 Maven打包与Nginx配置后端打包用mvn clean package -DskipTests生成一个可执行的Jar包。直接java -jar就能运行。前端打包是npm run build产物生成到dist目录。生产环境我用Nginx同时托管前端静态文件和后端API反向代理关键配置如下server { listen 80; server_name your-domain.com; # 前端静态文件 root /usr/share/nginx/html; index index.html; # 解决Vue Router history模式刷新404问题 location / { try_files $uri $uri/ /index.html; } # 后端API反向代理 location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } # 上传图片访问 location /upload/ { proxy_pass http://127.0.0.1:8080; } }8.3 Docker化部署省去环境配置的重复劳动如果评委老师当场要求你在他的电脑上跑一下演示环境不一致导致的尴尬场面我见过太多了。更好的选择是把整个项目Docker化MySQL容器 后端应用容器 前端Nginx容器用docker-compose up -d一键启动。我写了一个最简单的Dockerfile放在后端项目根目录FROM openjdk:8-jdk-alpine COPY target/repair-system.jar app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, /app.jar]前端则在官方nginx:alpine镜像基础上把dist目录拷贝进去。MySQL用官方镜像挂载一个数据卷第一次启动时自动执行初始化SQL脚本。这套方案在答辩演示时非常加分——评委还没开始问问题你已经把应用跑起来了。9. 实测踩坑记录五个真实遇到的疑难杂症9.1 MyBatis-Plus分页插件失效问题MyBatis-Plus 3.5.x版本使用分页必须显式注册PaginationInnerInterceptor而且如果你用的是SpringBoot 2.7.x这个拦截器可以正常生效。我遇到的问题是配置了拦截器但分页没有拦截到SQL最后发现是MyBatis-Plus版本和MyBatis版本不兼容——3.5.2版本需要配套MyBatis 3.5.13以上后来升级依赖解决。9.2 Vue 3中Element Plus的日期组件赋值类型报错el-date-picker绑定的值类型是Date或字符串数组后台返回的字符串格式如果不是YYYY-MM-DD HH:mm:ss前端格式化会报错。我在封装接口时统一把时间字段用dayjs格式化成标准字符串后再赋值给组件。9.3 JWT在自定义拦截器里放行的白名单问题登录接口、验证码接口、上传文件的静态路径、Swagger的UI资源路径都必须排除在JWT拦截器外。我最初忘了放行Swagger资源导致打开接口文档页面时一片空白排查了很久才意识到是拦截器把静态资源也拦了。放行规则里建议用Ant路径匹配registry.addInterceptor(jwtInterceptor) .addPathPatterns(/**) .excludePathPatterns(/api/auth/login, /api/captcha, /upload/**, /swagger-resources/**, /v3/api-docs/**, /doc.html/**);9.4 数据库连接池连接超时导致偶发500错误本地测试时一切正常部署到服务器之后第二天来访问发现第一次请求特别慢甚至直接报500后面再刷新就正常。这个典型原因是MySQL默认的wait_timeout是8小时连接池里的空闲连接超过这个时间被服务端断开程序还在用陈旧连接访问自然报错。解决方案是在application.yml里配置spring: datasource: hikari: connection-test-query: SELECT 1 idle-timeout: 30000 max-lifetime: 60000max-lifetime必须小于MySQL的wait_timeout这样连接池会在服务端断开前主动把连接回收。9.5 答辩时最容易被问到的三个刁钻问题我总结了三个大概率被评委追问的点你可以提前准备好答案如果多个学生同时提交报修同一个师傅的数据会不会错乱—— 回答思路报修单提交是Insert操作不需要锁派单时用乐观锁repair_order表加一个version字段更新状态时SET version version 1 WHERE id ? AND version 旧版本更新行数为0说明被人抢先操作提示当前订单已被处理请刷新。这个方案比select for update并发性能更好。你的系统如何防止SQL注入—— 回答思路MyBatis的#{}预编译机制可以防注入项目里所有需要拼接表名或排序字段的地方都用了白名单校验不允许用户直接传入任意字符串。数据库一个用户有几千条报修记录列表会卡顿吗—— 回答思路列表页面固定分页大小20条SQL带了索引可以通过EXPLAIN查看执行计划验证是否走了索引如果数据量继续增长可以引入Redis缓存热点数据或者做读写分离。10. 论文写作时的功能测试数据准备毕设论文里系统测试这一章不能只贴几张截图就完事至少要有功能测试用例表和性能测试数据。我准备了一套可以直接复制的测试模板测试编号测试功能操作步骤预期结果实际结果是否通过TC-001学生登录输入正确账号密码点击登录跳转学生端首页显示用户名与预期一致通过TC-002学生登录失败输入错误密码提示用户名或密码错误与预期一致通过TC-003提交报修单填写完整信息并上传图片报修成功状态为待派单与预期一致通过TC-004提交报修单缺字段不填故障描述直接提交表单校验拦截提示必填与预期一致通过TC-005管理员派单选择师傅点击派单工单状态变为已接单师傅端可见与预期一致通过TC-006师傅完成工单师傅端点击完成处理状态变为待验收学生端可确认与预期一致通过TC-007学生评价维修填写评分和评价内容评价保存成功师平均分更新与预期一致通过TC-008越权访问学生角色直接访问管理端接口返回403无权限提示与预期一致通过性能测试可以在论文里放几张JMeter的聚合报告截图模拟100个并发用户同时访问系统响应时间平均值小于500ms错误率0%。虽然没有真正对标生产环境但体现出你有性能意识足够了。这套系统从想法到完整跑通我前前后后改了三个版本。第一个版本只做了最基础的增删改查第二个版本加了工单流转记录和评价体系第三个版本才算把派单推荐、响应式适配、Token续期这些体验类细节补全。如果你正在做相似的题目我的建议是先把主流程跑通再逐步叠加微创新而不是一开始就想做一个功能齐全的大系统——后者大概率会在某个环节卡壳然后整个项目停摆很久。做毕设不是做产品先把账面上的功能完整展示出来后面每一步优化都是在给自己加分。本文还有配套的精品资源点击获取 校园报修系统SpringBoot+Vue全栈开发实战：状态机与智能派单
简介面向计算机专业毕业设计该校园报修系统以Spring Boot与Vue为基础完整覆盖报修管理、维修记录、评价反馈等业务流程。论文严格按照毕业设计规范撰写包含绪论、相关技术介绍、需求分析、系统设计、系统实现、系统测试、总结与展望等章节并在需求分析中涉及技术、操作、法律可行性及用户需求、功能需求和非功能需求分析。系统设计部分详述了系统管理、用户管理、维修类型管理、维修工具管理、报修管理、维修记录、评价反馈等核心模块同时配以专业的系统架构图、用例图、顺序图、E-R图便于快速理解整体架构。压缩包内共1个docx文档大小1.22MB格式规范可直接查阅和编辑。已有58人学习适合毕业设计选题参考、系统架构学习及论文写作借鉴。1. 毕设选题年年撞车怎么在这道题里做出差异化校园报修系统在毕业设计里属于常青树级别的题目几乎每个学校、每届学生里都有几个人在做。如果你打开知网搜一圈会发现从JSP时代到SSH框架再到SpringBootVue这个题目已经被写了几千遍。但这不意味着它没有价值——恰恰相反选这道题的人多说明它的业务逻辑清晰、需求边界明确、工作量适中非常适合用来展示你对前后端分离开发的掌握程度。问题是大多数人做完之后都是一个模子用户提交报修单→管理员分配师傅→师傅接单处理→用户确认完成。四张表五六个接口两个角色跑通就完事。这样当然也能毕业但如果你想拿个不错的分数或者在面试时能把项目讲出亮点就必须在常规需求之上做一些别人没做的设计。我这次做的时候重点抓了三件事第一是报修全流程的状态机设计让工单流转可追踪、可回溯第二是维修师傅的派单策略不只是管理员手动分配而是加入了基于待处理工单量和技能标签的智能推荐第三是移动端适配因为没有单独做App而是把前端Vue项目直接做成了响应式布局让手机浏览器访问时也能有不错的体验。先说清楚这个项目的定位是一个非常典型的管理系统类作业核心价值在于完整的CRUD加业务流转。你不需要在上面堆砌微服务、消息队列、分布式锁这些过度设计的东西但你可以把单模块内部的逻辑做到精益求精。这篇文章我就按我实际开发的顺序把从技术选型、库表设计、后端接口、前端页面到部署上线的完整链路拆开讲顺便把我踩过的坑和最后答辩时被追问的问题也一并列出来。2. 技术栈选型为什么是SpringBootVue而不是其他组合2.1 这个组合解决的核心问题前后端分离是现在Web开发的主流形态。SpringBoot负责提供RESTful APIVue负责页面渲染和交互两边通过JSON数据通信。对于毕设来说这个组合最大的好处是分工清晰后端写业务逻辑前端写界面你可以在论文里把前后端通过接口联调作为系统架构的重点章节来写这比传统的JSPServlet或Thymeleaf模板渲染更有技术含量也更容易凑出篇幅合理的需求分析、概要设计、详细设计三段式结构。从学习成本的角度看SpringBoot本身就内置了Tomcat你不需要单独配置服务器一个mvn spring-boot:run就能起服务Vue配合Vue CLI或Vite脚手架几分钟就能搭建出工程骨架。这两样都是当前工业界的主流技能做完这个项目你简历上能写的技术栈也更有说服力。2.2 每个核心组件的作用边界在实际项目中我会把这套系统里的关键组件做一个清晰的职责划分组件版本建议在本系统里的职责SpringBoot2.7.x提供后端API服务整合MyBatis-Plus、JWT、全局异常处理MyBatis-Plus3.5.x数据访问层操作Wrapper查询、分页插件支持MySQL5.7或8.0存储用户、报修单、工单流转记录、评价等核心数据VueVue 2或Vue 3Vue 3 Vite前端工程负责三个角色的操作界面Element Plus / Ant Design Vue最新稳定版组件库表格、表单、弹窗、消息提示都靠它JWTjjwt0.9.1或0.11.x无状态登录认证拦截器校验TokenLombok1.18.x减少实体类的getter/setter样板代码Hutool5.8.x工具类验证码生成、日期处理、随机ID等有一点要特别提醒如果你的SpringBoot版本选的是3.x以上那JDK必须用17及以上而且MyBatis-Plus、jwt等相关依赖的坐标和兼容性都会变。毕设场景里我建议直接用SpringBoot 2.7.x配JDK 1.8这套组合经过了大量生产环境验证网上遇到的坑基本都有人填过了你踩雷的概率最低。2.3 数据库选型与版本细节MySQL选5.7还是8.0如果你要写存储过程或者用窗口函数做统计报表8.0更合适如果只是普通增删改查5.7完全够用。我用的是8.0主要考虑是字符集默认utf8mb4对表情符号这类特殊字符支持更好。另外数据库连接驱动需要注意版本匹配8.0的驱动类名是com.mysql.cj.jdbc.DriverURL里必须加上serverTimezoneAsia/Shanghai否则会有时区报错。3. 数据库设计从报修单流转角度反推表结构3.1 五张核心业务表的关系拆解我见过很多同学的数据表设计是从有哪些角色出发的——一个用户表、一个报修单表、一个管理员表、一个师傅表。这种做法没有错但问题是报修单和用户、师傅之间的关联关系会写得比较混乱。更好的思路是从工单流转的生命周期反推数据模型报修单被创建时是学生发起的被接单时归属到某个师傅名下被处理时状态要推进处理完成后学生要评价这每一步落在表上都需要有对应的字段支撑。我设计了这样五张核心表sys_user用户表保存学生、维修师傅、管理员的公共信息用户名、密码密文、手机号、角色类型、头像用role字段区分三种身份。这里不拆三张表的好处是登录逻辑统一一个接口处理完认证坏处是三种角色的扩展字段都要塞在同一张表里比如师傅需要技能标签、学生需要宿舍楼栋信息。我的处理方式是公共字段放主表私有扩展字段通过user_profile表学生表和repair_worker表师傅扩展表单独存。repair_order报修单主表核心字段包括报修编号业务单号、报修人ID、报修类型水、电、木工、网络等、故障描述、报修图片、楼栋房间号、紧急程度、当前状态待派单/已接单/处理中/待验收/已完成/已取消、派单师傅ID、创建时间、完成时间。你会发现这张表本身就能支撑一个报修单列表页的全部展示需求不需要每次查询都去关联用户表。repair_flow工单流转记录表这是我做差异化设计的关键。每次状态变更都往这张表里插一条记录order_id、from_status、to_status、operator_id、operator_name、operate_time、remark。这相当于给报修单加了一份档案学生能看到师傅几点接单几点到达中间有没有退回重新指派答辩时这块内容既是创新点又是加分项。repair_evaluation评价表报修单完成后学生可以对维修质量、师傅响应速度、服务态度进行打分并留言。sys_notice通知公告表管理员发布的校园通知比如停水停电检修计划前端首页轮播展示。3.2 状态流转的字段约束与边界情况状态字段我建议用tinyint数字类型存储而不是字符串比如0待派单、1已接单、2处理中、3待验收、4已完成、5已取消、6已驳回。数字的好处是排序和比较快坏处是语义不直观但前后端约定好枚举含义后完全没问题。边界情况要想清楚如果师傅接单后发现故障自己处理不了要能退回管理员重新派单如果长时间没人接单要允许管理员手动指派如果学生提交后想取消报修只有待派单状态才能取消一旦师傅接单了就只能联系管理员操作。这些规则我会在后端Service层用状态机校验来做——不是简单地接收前端传过来的目标状态而是先判断当前状态是否允许执行某个操作不允许就抛出业务异常。3.3 索引与字段设计的几个细节教训repair_order表一定要给user_id和status建联合索引因为页面端最常做的查询就是某个人当前有哪些状态的工单。报修编号不建议直接用数据库自增ID我用的Hutool的IdUtil.getSnowflakeNextIdStr()生成19位雪花ID展示给用户的格式是BX20250114001这种既能看出年份月份也不会暴露系统数据量。图片存储我没有用OSS或者云存储而是保存到本地磁盘目录并在数据库存相对路径配合SpringBoot的静态资源映射暴露出来。毕设场景够用但如果上线生产环境肯定要换对象存储这个在论文里要提一句。所有表都加上create_time、update_time、deleted逻辑删除三个公共字段MyBatis-Plus的自动填充功能可以统一维护这些字段。4. 后端架构Master数据权限与业务边界划分4.1 Controller-Service-Mapper三层的具体落地方式网上SpringBoot项目教程满天飞但真正到写代码时很多人还是会混淆Controller里该写多少逻辑。我的分层原则很明确Controller只做参数接收和结果封装所有业务规则都在Service层验证数据访问只发生在Mapper层。以提交报修单这个接口为例接口路径是POST /api/order前端传来的JSON长这样{ repairType: 1, description: 宿舍灯管闪烁怀疑即将烧坏, images: [/upload/20250114/xxx.jpg], building: 3号宿舍楼, room: 502, emergencyLevel: 2 }Controller层拿到DTO后只校验基本的非空参数然后调用RepairOrderService.createOrder(userId, dto)。Service层要做的事包括根据userId查询用户信息确认角色是学生防止师傅或管理员冒充学生提交生成报修业务编号组装RepairOrder实体状态设为待派单插入主表同时往repair_flow表插入一条初始流转记录如果有需要给管理员发送站内通知。Service层方法加上Transactional事务注解保证至少第4步里订单插入流转记录插入是原子的——要么都成功要么都回滚。4.2 权限控制拦截器、JWT与角色校验的三层防线整个系统的权限模型是三类角色互不可越权学生student只能操作自己的报修单创建、查看详情、取消待派单状态的单子、确认完成、评价维修师傅worker只能看派给自己的工单并执行接单、开始处理、完成处理、申请延期等动作管理员admin能看到全部工单进行派单、驳回、强制完成、公告管理、用户管理等全局操作。JWT的过滤器去解析每个请求头里带的Authorization: Bearer token把userId和role塞进一个ThreadLocal上下文里后续Service层做数据权限判断时直接从上下文取当前用户。除了登录接口和验证码接口其他接口都要求Token有效。只靠JWT校验还不够数据权限要放在Service层做二次拦截。比如学生查自己的工单列表SQL层面就必须强制带上WHERE user_id 当前登录用户id不能依靠前端传参来过滤——否则我可以随便改请求参数里的userId看到别人的报修单这是一个很典型的越权漏洞。4.3 全局异常与统一返回体让前端少写一万行判断前后端分离项目里最痛苦的事之一就是后端接口返回格式不统一。有的接口直接返回对象有的接口出错时返回字符串前端拿着数据还要各种判断。我在项目里定义了一个统一的返回体ResultTData public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(操作成功); result.setData(data); return result; } public static T ResultT error(String message) { ResultT result new Result(); result.setCode(500); result.setMessage(message); return result; } }配合RestControllerAdvice全局异常处理器把参数校验异常、业务异常、数据库异常统一包装成这个格式。前端axios拦截器里只需要判断res.data.code 200其他情况统一弹message提示代码干净很多。4.4 报表统计后端聚合接口的设计思路论文里一定要有系统功能测试章节最常见的内容就是展示几个统计图表。我在系统里为管理员设计了一个仪表盘页面需要三类数据报修单按状态的分类统计待派单有多少、进行中有多少、已完成有多少近7天每日新增报修单趋势各维修类型的占比水、电、木工、网络的饼图。这三类数据我没有让前端循环调列表接口自己算而是在后端写了一个聚合查询接口。用MyBatis-Plus的QueryWrapper配合select指定分组字段返回一个Map。复杂的SQL写在XML里也方便。前端ECharts直接拿数据填充。5. 前端Vue从脚手架到响应式适配的完整实践5.1 Vue项目初始化与工程配置前端工程用Vite初始化命令就一行npm create vitelatest repair-web -- --template vue装完基础依赖后我额外安装了这些包包名用途vue-router前端路由管理控制页面跳转pinia状态管理存储用户信息、登录态axiosHTTP请求封装统一baseURL和拦截器element-plusUI组件库表格、表单、弹窗、日期选择器echarts图表库负责仪表盘统计可视化sassCSS预处理器方便写嵌套样式和公共变量需要特别注意的是Element Plus在Vue 3中的完整引入和按需引入的区别。毕设项目直接全量引入最省事在main.js里app.use(ElementPlus)就够了不要在这个环节上花时间折腾自动按需导入插件除非你的项目打包后体积真的过大。5.2 路由懒加载与登录守卫三套角色的界面我拆成了三个大模块学生端、师傅端、管理端各自有布局组件和子页面。路由配置用动态import()实现懒加载首屏只加载必要的JS访问哪个页面才加载哪个模块的代码。路由守卫的逻辑很简单router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (!token to.path ! /login) { next(/login) return } if (token to.path /login) { next(/) return } next() })实际项目里还会加一个角色判断如果学生登录后手动输入/admin开头的地址导航守卫必须拦截并重定向到首页。我这里的做法是路由meta里标记roles: [admin]守卫里比对当前用户角色。5.3 表格与表单报修单列表页的完整实现思路报修单列表是系统的核心页面学生要看自己提交的单子师傅要看派给自己的单子管理员要看全部单子。同一个页面组件根据当前登录角色决定请求哪个接口——后端本身有三个不同的接口URL前端用同一套表格组件接收数据。表格列包括报修编号、报修类型用tag标签显示不同颜色、故障描述超出一定长度用文字提示、楼栋房间、紧急程度、当前状态、提交时间、操作按钮。操作按钮根据状态和角色判断显示哪个待派单状态的单子显示取消按钮师傅端显示接单开始处理完成处理学生端在师傅完成后显示确认完成和去评价管理员显示派单驳回。表单部分我用了Element Plus的el-form配合rules校验规则报修类型、楼栋房间、故障描述是必填项图片上传用el-upload组件手动上传到后端/api/upload接口把返回的图片URL填进表单字段。5.4 移动端适配没有App也要让手机能用现在学生报修大概率是用手机操作的所以我给前端页面做了响应式适配。我的做法不算复杂用SCSS的媒体查询在min-width: 768px条件下显示桌面端布局小于这个宽度时把表格列精简成卡片列表按钮区域放大表单布局改为单列。Element Plus的el-col栅格系统本身就支持响应式断点大部分页面稍微调整一下栅格比例就能适配。这一步在答辩时是一个很好讲的亮点——本系统采用响应式设计在不开发独立移动端应用的前提下覆盖了学生手机端的报修场景这句话可以放在论文的系统特色小节里。6. 派单机制从手动指定到带权重的智能推荐6.1 为什么需要派单算法报修单创建后如果只靠管理员手动分配管理员必须熟悉每个师傅的当前工作量、擅长技能、接单效率这在小规模测试里没问题但一旦报修单多了就很容易分配不均同一个师傅堆了20个单子另一个师傅闲得慌。我在系统里做了一个简单的推荐逻辑不追求多复杂但至少解决了推荐谁的问题。6.2 推荐规则的三个维度当一个新报修单进入待派单状态管理员的派单页面会调用一个推荐接口返回三个候选师傅按推荐指数从高到低排列。推荐指数的计算权重如下技能匹配度40%权重报修单有repairType水、电、木工、网络师傅的扩展表里有skill_tags字段存一个或多个技能标签。技能完全匹配的师傅得满分不匹配的此项为0。当前待处理工单数40%权重师傅名下处于已接单或处理中状态的工单越少得分越高。我用了一个简单公式max(0, 1 - 当前单量/10)单量为0时得1分10单以上得0分。历史评价分20%权重从评价表聚合每个师傅最近10次评价的平均分归一化到[0,1]。总分的计算逻辑是score 技能分*0.4 负载分*0.4 评价分*0.2。前端拿到推荐候选后展示在派单弹窗里管理员可以一键采纳也可以忽略推荐手动搜索师傅。6.3 延展思考这个算法能替换成什么在论文的系统改进方向里我写了一段关于基于排队论和GPS定位的派单优化的展望如果学校足够大维修师傅分布在校园不同位置可以结合距离因子来优化推荐模型如果对人工派单的公平要求更高可以引入简单的贪心算法让每个新工单自动分配给当前负载最低的且技能匹配的师傅。这段展望不写代码都没关系但论文评审老师看到你的思考深度印象分会高不少。7. 安全与异常那些不写就会出事的细节7.1 登录安全验证码、加密存储与防暴力破解登录页我用了Hutool生成图片验证码后端接口GET /api/captcha返回一个UUID作为captchaKey和Base64图片字符串缓存到Redis里有效期5分钟。登录时提交captchaKey和captchaCode后端比对缓存里的值不一致直接返回验证码错误。密码不能明文存用BCrypt加密——Spring Security自带BCryptPasswordEncoder也可以单独引入spring-security-crypto这个依赖只用到加密工具类不用引入整套Security。登录成功时比较加密后的密文是否匹配。防暴力破解我做得比较简单用户连续输错密码5次账号锁定15分钟用一个Map在内存里记录失败次数。如果要严谨一点应该换Redis并设置过期时间不过毕设场景内存Map也够用。7.2 JWT过期与续期策略JWT的过期时间我设置成2小时。前端axios响应拦截器里判断状态码如果返回401说明Token过期弹出提示并跳转登录页重新登录。这里有个体验优化——如果用户在填写报修表单时正好过期表单内容会全部丢失很恼人。所以我在ajax请求里做了Token即将过期提前刷新的逻辑解析JWT的exp字段如果剩余时间小于30分钟调用一个/api/auth/refresh接口用refreshToken换新Token透明地替换后续请求里的Header。7.3 文件上传的安全边界图片上传接口如果不做任何限制会被拿来上传恶意脚本或者超大文件把磁盘塞满。我用MultipartFile的getOriginalFilename()做后缀白名单校验只允许jpg、png、jpeg、gif、webp格式文件大小限制在5MB以内。SpringBoot的配置文件里设置spring: servlet: multipart: max-file-size: 5MB max-request-size: 20MB文件名用UUID重命名不保留用户原始文件名避免路径穿越和重名覆盖问题。上传后的文件保存到服务器的/upload目录通过自定义静态资源映射暴露访问路径Configuration public class WebMvcConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceHandler(file: System.getProperty(user.dir) /upload/); } }7.4 异步通知维修进度变化时主动触达用户系统里有一个小功能是状态变更通知用户。如果每次状态变更好都直接同步发送短信或站内信接口响应会变慢。我引入了Spring框架自带的Async注解在Service层把插入通知记录这个操作声明为异步执行这样主流程的事务提交不受影响通知的延迟在毫秒级。记得在主启动类上加EnableAsync开启异步支持。8. 联调、打包与上线部署别等答辩前一天才想起这一步8.1 前后端联调的CORS与代理配置开发环境下前端跑在http://localhost:5173Vite默认端口后端跑在http://localhost:8080浏览器会有跨域限制。我的处理方案是后端配置一个CorsFilter允许所有来源、所有方法、所有Header跨域请求。生产环境下前后端如果部署在同一台服务器同一个域就不存在跨域问题可以把这个Filter的allowedOrigins收紧。后端CORS配置示例Configuration public class CorsConfig { Bean public CorsFilter corsFilter() { CorsConfiguration config new CorsConfiguration(); config.addAllowedOriginPattern(*); config.addAllowedMethod(*); config.addAllowedHeader(*); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration(/**, config); return new CorsFilter(source); } }8.2 Maven打包与Nginx配置后端打包用mvn clean package -DskipTests生成一个可执行的Jar包。直接java -jar就能运行。前端打包是npm run build产物生成到dist目录。生产环境我用Nginx同时托管前端静态文件和后端API反向代理关键配置如下server { listen 80; server_name your-domain.com; # 前端静态文件 root /usr/share/nginx/html; index index.html; # 解决Vue Router history模式刷新404问题 location / { try_files $uri $uri/ /index.html; } # 后端API反向代理 location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } # 上传图片访问 location /upload/ { proxy_pass http://127.0.0.1:8080; } }8.3 Docker化部署省去环境配置的重复劳动如果评委老师当场要求你在他的电脑上跑一下演示环境不一致导致的尴尬场面我见过太多了。更好的选择是把整个项目Docker化MySQL容器 后端应用容器 前端Nginx容器用docker-compose up -d一键启动。我写了一个最简单的Dockerfile放在后端项目根目录FROM openjdk:8-jdk-alpine COPY target/repair-system.jar app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, /app.jar]前端则在官方nginx:alpine镜像基础上把dist目录拷贝进去。MySQL用官方镜像挂载一个数据卷第一次启动时自动执行初始化SQL脚本。这套方案在答辩演示时非常加分——评委还没开始问问题你已经把应用跑起来了。9. 实测踩坑记录五个真实遇到的疑难杂症9.1 MyBatis-Plus分页插件失效问题MyBatis-Plus 3.5.x版本使用分页必须显式注册PaginationInnerInterceptor而且如果你用的是SpringBoot 2.7.x这个拦截器可以正常生效。我遇到的问题是配置了拦截器但分页没有拦截到SQL最后发现是MyBatis-Plus版本和MyBatis版本不兼容——3.5.2版本需要配套MyBatis 3.5.13以上后来升级依赖解决。9.2 Vue 3中Element Plus的日期组件赋值类型报错el-date-picker绑定的值类型是Date或字符串数组后台返回的字符串格式如果不是YYYY-MM-DD HH:mm:ss前端格式化会报错。我在封装接口时统一把时间字段用dayjs格式化成标准字符串后再赋值给组件。9.3 JWT在自定义拦截器里放行的白名单问题登录接口、验证码接口、上传文件的静态路径、Swagger的UI资源路径都必须排除在JWT拦截器外。我最初忘了放行Swagger资源导致打开接口文档页面时一片空白排查了很久才意识到是拦截器把静态资源也拦了。放行规则里建议用Ant路径匹配registry.addInterceptor(jwtInterceptor) .addPathPatterns(/**) .excludePathPatterns(/api/auth/login, /api/captcha, /upload/**, /swagger-resources/**, /v3/api-docs/**, /doc.html/**);9.4 数据库连接池连接超时导致偶发500错误本地测试时一切正常部署到服务器之后第二天来访问发现第一次请求特别慢甚至直接报500后面再刷新就正常。这个典型原因是MySQL默认的wait_timeout是8小时连接池里的空闲连接超过这个时间被服务端断开程序还在用陈旧连接访问自然报错。解决方案是在application.yml里配置spring: datasource: hikari: connection-test-query: SELECT 1 idle-timeout: 30000 max-lifetime: 60000max-lifetime必须小于MySQL的wait_timeout这样连接池会在服务端断开前主动把连接回收。9.5 答辩时最容易被问到的三个刁钻问题我总结了三个大概率被评委追问的点你可以提前准备好答案如果多个学生同时提交报修同一个师傅的数据会不会错乱—— 回答思路报修单提交是Insert操作不需要锁派单时用乐观锁repair_order表加一个version字段更新状态时SET version version 1 WHERE id ? AND version 旧版本更新行数为0说明被人抢先操作提示当前订单已被处理请刷新。这个方案比select for update并发性能更好。你的系统如何防止SQL注入—— 回答思路MyBatis的#{}预编译机制可以防注入项目里所有需要拼接表名或排序字段的地方都用了白名单校验不允许用户直接传入任意字符串。数据库一个用户有几千条报修记录列表会卡顿吗—— 回答思路列表页面固定分页大小20条SQL带了索引可以通过EXPLAIN查看执行计划验证是否走了索引如果数据量继续增长可以引入Redis缓存热点数据或者做读写分离。10. 论文写作时的功能测试数据准备毕设论文里系统测试这一章不能只贴几张截图就完事至少要有功能测试用例表和性能测试数据。我准备了一套可以直接复制的测试模板测试编号测试功能操作步骤预期结果实际结果是否通过TC-001学生登录输入正确账号密码点击登录跳转学生端首页显示用户名与预期一致通过TC-002学生登录失败输入错误密码提示用户名或密码错误与预期一致通过TC-003提交报修单填写完整信息并上传图片报修成功状态为待派单与预期一致通过TC-004提交报修单缺字段不填故障描述直接提交表单校验拦截提示必填与预期一致通过TC-005管理员派单选择师傅点击派单工单状态变为已接单师傅端可见与预期一致通过TC-006师傅完成工单师傅端点击完成处理状态变为待验收学生端可确认与预期一致通过TC-007学生评价维修填写评分和评价内容评价保存成功师平均分更新与预期一致通过TC-008越权访问学生角色直接访问管理端接口返回403无权限提示与预期一致通过性能测试可以在论文里放几张JMeter的聚合报告截图模拟100个并发用户同时访问系统响应时间平均值小于500ms错误率0%。虽然没有真正对标生产环境但体现出你有性能意识足够了。这套系统从想法到完整跑通我前前后后改了三个版本。第一个版本只做了最基础的增删改查第二个版本加了工单流转记录和评价体系第三个版本才算把派单推荐、响应式适配、Token续期这些体验类细节补全。如果你正在做相似的题目我的建议是先把主流程跑通再逐步叠加微创新而不是一开始就想做一个功能齐全的大系统——后者大概率会在某个环节卡壳然后整个项目停摆很久。做毕设不是做产品先把账面上的功能完整展示出来后面每一步优化都是在给自己加分。本文还有配套的精品资源点击获取