十年匠心定制 · 商业建站与技术教学双线并行 咨询热线:400-886-1026 service@lmnt.cn
ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

Java毕设实战:Spring Boot+Vue实验报告管理系统开发全解析

Java毕设实战:Spring Boot+Vue实验报告管理系统开发全解析 做实验报告管理系统这个题目在Java毕设里算是一个很经典的“管理系统”赛道。但说实话如果不把需求边界想清楚很容易做成一个“啥都有但啥都不好用”的CRUD堆砌。这套系统的核心价值是把高校实验室里“提交报告、批改打分、成绩统计”这条繁琐链路搬到线上省去学委收文件、老师一个个下载再打包评分的重复劳动。本文我会从真实开发者的视角把这个系统的拆解过程完整讲一遍包含场景分析、技术选型逻辑、数据库设计、前后端主流程落地以及我在实际开发中踩过的坑和能直接复用的经验适合正在做同类Spring Boot Vue毕设或课设的同学参考。1. 实验报告管理系统到底要解决什么问题很多同学拿到“实验报告管理系统”这个题目第一反应是先把用户表、角色表、实验表、报告表建好然后开始堆增删改查。但真正动工之前我建议先花一天时间想清楚一件事谁在用这套系统他们各自最痛的点是什么。1.1 三个角色的真实使用场景这套系统一般涉及三类用户学生、教师、管理员。每个角色的使用路径完全不同如果一开始没有这种视角做出来的页面和接口很容易“四不像”。学生对系统的核心诉求是在截止时间之前把实验报告交上去提交之后能随时看到老师有没有批改、得了多少分、评语是什么。最忌讳的是“交了之后石沉大海”所以系统里必须给到明确的状态反馈比如“已提交、待批改、已批改、被退回”。教师的核心诉求是发布实验任务、设定截止时间然后集中审阅学生交上来的实验报告给出分数和评语。教师端最需要的不是花哨的图表而是一个能快速定位“哪些学生还没交、哪些已经批改”的清单以及批量操作能力。管理员的核心诉求更简单维护学期、课程、班级、教师和学生的基础数据。实际调研中我发现一个很常见的现象——大部分管理员希望直接导入Excel批量建号而不是在页面上一个一个添加学生。如果你决定做这个系统这个需求值得优先考虑因为它是毕设答辩时很加分的亮点。1.2 功能列表收敛哪些做哪些不做建议把功能收敛成一组清晰的主干流程而不是什么都塞进去。一个稳妥的方案是保留以下核心模块用户认证模块登录、退出、修改密码基于JWT做无状态认证。实验任务管理教师发布实验任务设置截止时间支持编辑和关闭任务。实验报告提交学生选择对应任务填写报告富文本内容或上传附件支持在截止前重复修改。教师批改模块按任务查看提交列表在线打分、填写评语支持一键查看未交名单。成绩统计模块按任务查看成绩分布支持学生端查看个人成绩与评语。基础数据管理用户管理、课程管理、班级管理管理员可批量导入数据。像在线实验报告查重、自动批改、图形化统计这类功能听起来很高端但如果是毕设建议先不放进去或者作为“后续扩展点”在论文里提不要在核心链路上卡自己。1.3 为什么Spring Boot Vue是这一题的最优解这组合几乎成了这类管理系统的“标配”。从后端看Spring Boot让项目起步成本极低内嵌Tomcat、自动配置、配合MyBatis-Plus之后普通的CRUD接口几乎不用写SQL。从Java生态角度看Spring Boot对跳转、拦截器、文件上传、异常处理这些Web开发高频需求都有非常成熟的解决方案调试和维护成本比传统SSH框架低一个量级。前端选Vue则是因为组件化开发非常适合“不同角色看到不同界面”这种场景。教师端需要的是数据表格、评分表单学生端需要的是任务卡片、提交流程管理员端需要的是表单页和导入页。这些用Vue Element Plus做出来页面美观度在毕设答辩里也很加分。更关键的是Vue的生态资料充足遇到问题基本都能搜到方案。2. 数据库设计从一次“提交报告”的动作反推表结构数据库设计是这类系统的地基。我的习惯不是先画ER图而是把核心业务流程走一遍找出所有必须存下来的数据节点再反推表结构。这个系统的核心动作有三个教师发任务、学生交报告、教师给评分。所有表结构都应该围绕这三个动作展开。2.1 核心表的职责划分我最终的库表设计方案是五张核心表加三张辅助表核心表分别是用户表、实验任务表、实验报告表、评论/评分表、课程表辅助表包括班级表、学期表和操作日志表。用户表是最关键的表我个人不建议拆成“学生表”“教师表”“管理员表”三张而是用一张sys_user表加上role字段来区分。原因很简单拆表会让权限判断和跨角色查询变得非常繁琐而用角色字段配合接口层拦截既能满足需求又省事。sys_user表的核心字段包括id、username、passwordBCrypt加密后、real_name、role取值teacher/student/admin、class_id、create_time。实验任务表是教师端的主战场核心字段有id、title、description、course_id、teacher_id、deadline、status取值为进行中/已截止/已关闭。这里有一个容易被低估的细节deadline用datetime类型而不是date因为实验报告的提交截止往往精确到具体时间比如“周五晚上24点之前”。实验报告表是整个系统的数据核心我建议设计成“一份任务下一名学生最多一条报告记录”也就是task_id和student_id做联合唯一索引。这样设计的好处是后续查询“某个学生是否有提交记录”就变成查一条记录而不是查列表再判空。字段包括id、task_id、student_id、content长文本存富文本内容、file_path或file_url存附件下载地址、submit_time、status0草稿、1已提交待批改、2已批改、3被退回。评分表单独拆出来的原因是一份实验报告可能经历多次批改退回如果只用一个表保存最新分数历史批改记录就丢了。评分表记录report_id、score、comment、review_time、reviewer_id每次批改都新增一条记录学生能查到的永远是最后一条但教师后台能看到完整的评分轨迹。2.2 报告状态流转状态机设计要绝不含糊实验报告的状态是这个系统最核心的领域逻辑它直接决定了前端按钮的可用性和后端接口的业务判断。我在项目里用了integer类型的status字段取值含义如下0表示草稿学生保存了内容但尚未正式提交此时教师不可见。1表示已提交待批改学生点击“正式提交”后进入此状态教师端能看到并进入批改流程。2表示已批改并打分了这是正常流程的终态。3表示被教师退回通常因为格式不合格或内容抄袭退回时教师必须填写评语学生看到状态后可以在原报告基础上修改并重新提交重新提交后状态回到1。状态流转的约束不要只在前端做后端必须同步校验。否则学生只要绕过前端直接调接口就能把状态从草稿改成已批改。我们在ReportController里统一做了状态变更的合法检查任何非法跳转都会抛出业务异常。2.3 文件存储数据库只存路径绝不存文件本体实验报告经常需要附带LabVIEW截图、电路图、Excel数据表这类附件所以系统必须支持文件上传。我的设计是上传的文件存到服务器本地的一个upload目录数据库里只保存文件的相对路径或URL。这样比直接把文件转成base64存数据库要高效得多也方便后续迁移到OSS或MinIO。本地存储时有一个坑需要注意Spring Boot默认的静态资源映射不会自动映射到upload目录。需要在配置类里加一个addResourceHandlers把/upload/**映射到项目外的物理目录。别小看这一步很多人做完上传功能发现图片加载不出十有八九是这里没配置。3. 后端落地认证、上传、批改打分的主链路实现后端是整个系统的逻辑核心。我不会把每个接口都列出来而是挑三条“踩坑价值最高”的主链路详细讲JWT认证拦截、文件上传处理、教师批改打分的业务一致性。3.1 登录认证用JWT加拦截器而不是堆Spring Security毕设级别的实验报告管理系统其实没必要引入全套Spring Security配置量和学习成本都比较高。更务实的是JWT生成Token 自定义拦截器校验逻辑清晰且能写进论文的技术原理部分。具体实现是登录成功后用用户ID、用户名、角色生成一个token设置过期时间我设置的是2小时响应给前端。前端把token存在localStorage每次请求在请求头里带Authorization字段。后端写一个AuthInterceptor拦截所有/api/**请求从请求头取出token并解析校验通过后把userId和role放进request的attribute里供后续接口使用校验失败则返回401状态码。需要注意一点拦截器一定要配置放行路径否则注册接口和登录接口也会被拦截导致死循环。我一般这样配置放行/api/auth/login、/api/auth/register其余所有/api/**都走拦截器。另外跨域问题如果用了axios注意默认的Authorization请求头不在允许范围内需要在后端配置CorsFilter显式允许该请求头。3.2 报告上传MultipartFile的完整处理链路实验报告上传是学生端的核心操作涉及前端选文件、后端接收、校验、存储、回返回URL五个环节。后端接口用RequestParam(file) MultipartFile file接收上传。存储路径的设计上我推荐按天或按月建子目录避免所有文件堆在一个目录下造成文件数过多。比如路径格式是upload/report/2025/06/文件名用UUID拼接原始后缀防止文件名冲突。文件校验一定不能省空文件直接拒绝大小限制需要手动在application.yml里配Spring Boot默认为1MB实验报告随便一个PDF或截图就可能超过这个值我没记错的话会直接报MaxUploadSizeExceededException后缀白名单只允许文件上传doc、docx、pdf、png、jpg、zip这几种常见格式。前端用Element Plus的el-upload组件时我建议采用受控模式自定义http-request方法手动用FormData把文件传给接口这样最容易定位问题。很多同学直接使用组件默认的action属性指向后端接口遇到前后端分离部署时很容易出现URL拼接错误。3.3 教师批改打分状态与评分的一致性保障教师批改接口接受三个业务参数reportId、score、comment。很多同学会在这个接口里直接更新report表的score字段和status字段并把状态置为2。但这里存在一个隐患——如果后续要支持“退回重交”单纯改一行就丢掉了批改历史。更好的做法是接口里同时启动一个事务往评分表插入一条新记录然后更新report表的状态字段。两者要么同时成功要么同时失败。更新report表时用updateById传入实体让MyBatis-Plus只更新非空字段。否则如果前端没传score比如只退回不改分很容易把score覆盖成null。判断报告当前状态必须等于1也就是“已提交待批改”否则直接拒绝。这个校验在并发场景下尤其重要避免出现教师反复提交两次打分。我在这个接口上还加了一个小扩展批改完成之后通过Spring的事件机制异步通知学生。这个通知不必做得很复杂邮件或站内信都可以。站内信会比邮件简单很多因为它不需要额外配置SMTP服务器只需要在通知表里插一条数据学生端轮询即可。4. 前端实现教师端和学生端的差异化交互设计前端我用的是Vue3 Vite Element Plus没有引入复杂的微前端或状态管理库而是用route meta 路由守卫来区分角色菜单。整体项目结构保持最简api目录放axios封装views目录按角色细分components目录放公共组件。4.1 Vue工程结构与路由权限控制前端工程我推荐按模块划分目录而不是按页面类型划分。具体来说views下面拆成admin、teacher、student三个子目录再放一个common目录存放404页面和登录页。这种结构的好处是后续加权限控制时每个角色的页面天然被隔开。路由权限控制是前端的核心防线。我在每个路由的meta里加了requiresAuth和roles数组然后在router.beforeEach里做三件事一是判断有没有token没有就强制跳转登录页二是有token但访问的是登录页就直接跳首页三是解析token里的角色信息与当前路由meta里的roles做比对角色不匹配就跳转403页面。这个方案比在API层做权限判断更直观用户没有权限的菜单在侧边栏根本不会渲染出来体验上更友好。4.2 学生端提交报告页面的表单细节学生端最主要的页面是“我的实验任务”和“提交报告”。实验任务列表我用卡片而不是表格来展示因为任务信息比较简单卡片能展示标题、截止时间、状态标签三个信息视觉上更直观。每个卡片的操作按钮随着状态变化草稿状态显示“继续编辑”已提交状态显示“查看详情”被退回状态显示“修改并重新提交”。提交报告页面是整个系统交互最复杂的页面。我用了一个el-tabs组件分成两个页签富文本编辑和附件上传。富文本编辑器我选了wangEditor它提供了完整的Vue3适配包中文文档也比较友好。附件上传区域使用el-upload的拖拽模式但文件列表默认展示的是文件名我会在on-success回调里把接口返回的fileUrl保存到一个表单数组里这样才能在提交时把附件一起带过去。这里要特别注意校验顺序否则会出现“报告内容没填也能提交成功”的bug。提交按钮触发时的校验逻辑是若要修改内容或新增附件先走保存接口拿到最新report的ID后再调用正式提交接口而不是一次请求同时做两件事。4.3 教师端批改操作台的交互优化教师端的核心页面是“待批改列表”和“批改详情”。待批改列表我采用了“一屏式”设计左侧是学生列表点击某个学生时右边直接展示报告内容和批改表单这样可以极大减少无效点击次数。批改详情页里报告内容用iframe嵌入富文本的内容时要注意XSS隐患我默认过滤掉所有
返回列表