Spring Boot与Vue 3在线考核系统开发实战：核心功能与部署指南

1. 项目定位与整体思路

1.1 为什么“在线考核系统”是毕设的稳妥之选

每年做毕设，最怕的就是题目选大了收不住，选小了没东西写。前端课程在线考核系统这个题目，我建议很多学生选它，核心原因是它处在一个非常舒服的中间地带：业务逻辑足够清晰，不外乎用户、题库、考试、成绩这几张表；技术栈又足够完整，前端有富交互页面、倒计时、答题卡、代码编辑器，后端有鉴权、组卷、判分、统计分析，每一步都能写出实实在在的东西。

另一个关键点在于，这个题目的受众极其明确——它服务的对象就是学前端的学生自己。相比那种“某单位信息化管理系统”的虚浮感，“前端课程考核”把业务场景牢牢绑定在你熟悉的领域里，你需要实现的那些功能——选择题、判断题、简答题，甚至前端代码题——恰好是你自己每天在学的东西。答辩的时候老师问起业务逻辑，你随口就能解释清楚，根本不用临时背台词。

还有个非常现实的好处：这类系统的需求文档、表结构、接口设计在网上有大量成熟案例可供参考，但又不是那种烂大街到让评委一眼看穿的项目。你只要在题库类型上做出特色，比如加入前端特有的代码纠错题、CSS效果比对题，整个项目的创新点就立住了。想看成一个“加了点专业味道的在线考试系统”，这既没有过度创新导致工期失控，又能和纯粹的管理员CRUD区分开。

1.2 核心需求拆解：一个真实的在线考试到底需要什么

在设计之初，我没有急着写代码，而是先把自己代入三个角色：学生、老师和系统管理员，分别列了一版“最想要的功能清单”。

从学生视角来看： 我要能登录、能看到老师发布的考试列表、能按时进入考试、答题过程中要有倒计时提醒、交卷之后能立刻看到分数（至少客观题要能秒出分）、考完还能回看错题和正确答案。

从老师视角来看： 我要能维护课程题库（区分章节、难度、题型）、能按照规则从题库里抽题组卷、能控制考试的开始和截止时间、能设置及格线，并且要看得到班级的整体成绩分布，知道哪些知识点学生掌握得不好。

从管理员视角来看： 其实老师能做的事管理员都能做，管理员额外关心的是用户管理——学生账号怎么批量导入、老师账号怎么分配权限、考试数据怎么备份。

这三份需求清单合并之后，系统功能边界就非常清楚了：用户管理模块、题库管理模块、试卷管理模块、在线考试模块、成绩管理模块。没有多余的“AI智能推荐”和“人脸识别监考”，不是因为做不到，而是对毕设来说，这些容易失控的功能会让整个项目失衡。考试系统最硬的骨头是“答题交互”和“判定逻辑”，把精力集中在这些刀刃上，项目质量才扛得住答辩追问。

1.3 技术选型：为什么锁定Spring Boot + Vue 3 + MySQL

技术选型这件事，我见过太多学生在第一步就摔跟头——上来就搞微服务、搞Redis、搞消息队列，最后项目都没跑起来。毕设的核心原则是稳，选那些你熟悉、资料多、跑起来不折腾的技术。

后端我建议用Spring Boot。国内高校对Java生态的接受度最高，Spring Boot把大量繁琐配置都自动处理了，一个@RestController就能暴露接口。你写的每个知识点都能在答辩时掰开揉碎讲清楚：IoC容器怎么管理Bean、Spring Security怎么拦截请求、JWT怎么无状态鉴权。如果你对Node.js更熟，换成Express也能做，但为了迎合多数评委老师的认知习惯，Spring Boot是性价比最高的选择。

前端框架锁定Vue 3，原因有三：第一，Vue的上手曲线平缓，组合式API对新手非常友好，ref和reactive两个函数就能搞定大部分状态管理；第二，Element Plus组件库实在太全了，表格、表单、对话框、步骤条全部开箱即用，省下的时间可以去打磨考试页面的交互细节；第三，Vue在国内前端圈子里的渗透率极高，任何一个报错你都能在CSDN、掘金上搜到现成解法，这是React暂时比不了的。

数据库选MySQL没什么悬念——免费、去中心化、学校机房基本都装了。ORM层面我用MyBatis-Plus而不是JPA，因为它写CRUD几乎不要动脑，BaseMapper自带增删改查，分页查询一个Page对象搞定，特别适合毕设这种“以业务交付为主”的场景。前端构建工具用Vite，开发时热更新快到飞起，比旧的Webpack体感好太多。

整个技术栈串起来就是：Vue 3 + Vite + Element Plus做前端，Spring Boot + MyBatis-Plus做后端，MySQL做存储，JWT做登录鉴权。这里我想多强调一句：这个组合不是“最潮”的，也不是“性能最强”的，但它是“三个月内一个人能完成、答辩老师认可、将来扩展也不费劲”的。选型最忌讳的就是炫技，项目跑不起来，再新的技术都是零分。

2. 系统架构与数据库设计

2.1 前后端分离的整体架构

整个系统的架构图在我脑子里是这样的：前端项目跑在localhost:5173，后端跑在localhost:8080，两者完全分离，通过RESTful API通信。前端所有页面都用Vue Router做单页应用路由切换，用户登录后拿到JWT令牌，存进localStorage，后续每个请求都在Authorization请求头里带上这个令牌，后端用拦截器统一校验。

有人可能问，为什么不直接用传统的Thymeleaf服务端渲染？答案很现实：前后端分离是当前行业的默认方案，你答辩时必然会被问到“你这个项目是前后端分离的吗”。如果答案是否，老师可能直接怀疑你没接触过真正的企业开发。前后端分离还有一个实际好处——前端调试UI时根本不用等后端，后端接口没写好就先用Mock数据顶着，开发效率提升非常明显。

接口设计遵循RESTful风格：

• POST /api/auth/login 登录
• POST /api/auth/register 注册
• GET /api/exams 获取考试列表
• POST /api/exams/{id}/start 开始考试
• POST /api/exams/{id}/submit 提交试卷
• GET /api/exams/{id}/score 查询成绩

接口的粒度要掌握好：不要一个接口干所有事，也不要拆得太碎导致前端调四五次才拿到一个页面数据。我的习惯是按页面维度设计接口，比如“获取考试详情页数据”就一次返回考试基本信息+题目列表+考试时长，前端拿到就能直接渲染，避免加载时反复请求的尴尬。

2.2 数据库表设计：六张表撑起整个系统

数据库是整个系统的地基，地基歪了，上面写再多代码都白搭。我的设计是六张核心表，这次一并分享出来。

用户表（user）

登录密码一定不能用明文，这是答辩时安全性的加分点。我用的BCrypt加密，Spring Security自带的加密器，一行代码调用BCryptPasswordEncoder即可，既安全又能在答辩时解释“为什么彩虹表攻击没那么容易奏效”。

课程表（course）

题目表（question）

题目表是题库管理的核心，options字段我用JSON字符串存储，比如["A. Vue", "B. React", "C. Angular", "D. jQuery"]，这样一个字段搞定所有题型的选项。answer字段同样灵活：单选题存"A"，多选题存"A,C"，判断题存"true"，简答题存标准答案文本。

试卷表（exam）

试卷题目表（exam_question）

这就是手动组卷的经典设计。老师先创建试卷，然后从题库里选题目往试卷里加，每道题单独设置分值。考试的时候就去查这张关联表，按id排序把题目带出来。

成绩表（exam_result）

answers字段的设计花了我一点心思：用JSON存储整张试卷的全部用户答案，比如{"questionId": 21, "userAnswer": "A", "isCorrect": true}组成的数组。这么设计的好处是，判分时一次查出所有答案批量处理，回看考试详情时也只要一条记录就能还原全过程，不需要单独的“答题明细表”。

这套表结构最大的优点是结构清晰、关系简单。六张表之间只有外键引用，没有复杂的多对多关系表（试卷-题目关联表算半个多对多）。对于毕设来说，这种“一眼能看懂”的设计比那些为了炫技搞出的十几张关联表要加分得多——老师问起来你能快速画出完整ER图，就已经赢了。

2.3 三种角色与权限控制

权限模型我用的是最经典的三种角色：学生（ROLE_STUDENT）、老师（ROLE_TEACHER）、管理员（ROLE_ADMIN）。权限控制在两个层面实现：

接口层面：后端用Spring Security + JWT做拦截。具体做法是写一个JwtAuthenticationFilter，继承OncePerRequestFilter，从请求头解析JWT，若令牌有效就把用户信息塞进SecurityContext。然后在SecurityConfig里配置：

• /api/auth/** 放行（登录注册不需要鉴权）
• /api/exams、/api/exams/*/start、/api/exams/*/submit 只要是登录用户就能访问
• /api/admin/** 仅管理员可访问
• /api/teacher/** 仅老师和管理员可访问

前端层面：Vue Router的全局前置守卫里判断localStorage中的用户角色，路由元信息里配置requiresRole字段：

javascript复制{
  path: '/teacher/exam-edit',
  component: ExamEdit,
  meta: { requiresRole: 'ROLE_TEACHER' }
}

用户没权限访问时，直接router.push('/403')展示无权限页面。有些人不理解为什么前后端都要做权限，总觉得重复了。其实这就是面试官常问的“前端权限和后端权限的关系”：前端权限只影响体验（隐藏不该看到的按钮、路由跳转拦截），后端权限才是真正的安全边界。你绕过前端直接调接口，后端必须给你弹403才算合格。

3. 核心功能设计与实现细节

3.1 前端反馈：题库管理的核心操作

题库管理这个模块，我建议做成一个独立的后台页面，老师进入后默认看到的是当前课程的全部题目，按题型和难度筛选项分好。新增题目时用Dialog弹窗，表单字段根据题型动态渲染——选“单选题”，就显示选项输入框；选“简答题”，就只显示题干和标准答案输入框。

这个模块的代码实现不算难，但是有一个地方值得反复打磨：选项的输入体验。我最终做成了“选项动态增减”模式，老师可以点“添加选项”按钮无限增加选项，也可以点删除图标去掉某个选项。对应的表单数据是一个数组options: ['', '']，每次增删就是对数组做push/splice操作。这里有个细节——题目保存之前要校验选项内容非空且不能重复，Vue的el-form提供了现成的自定义校验规则：

javascript复制const validateOptions = (rule, value, callback) => {
  const filtered = value.filter(item => item.trim() !== '')
  if (filtered.length < 2) {
    callback(new Error('至少需要两个选项'))
  } else if (new Set(filtered).size !== filtered.length) {
    callback(new Error('选项不能重复'))
  } else {
    callback()
  }
}

这个校验规则我用真实表单验证过，挺稳当。另外，老师编辑题目时，后端接口我设计成PUT /api/question/{id}，前端提交整个题目对象，由后端判断哪些字段更新了。这个方案对新手最友好——不用做字段级差分，直接全量更新即可，性能上对于毕设规模完全够用。

3.2 核心流程：在线考试全生命周期

在线考试是整张系统的心脏，我把它拆成了四个状态：待开始 → 答题中 → 已交卷（人工批改中）→ 已出分。前端用一个status字段控制页面渲染分支，后端同样维护这个状态，双方不一致时以后端为准——这能防止学生刷接口跳步骤。

开始答题的逻辑看起来简单，但实现时要绕过几个坑。学生点击“进入考试”后，前端先调POST /api/exams/{examId}/start，后端做三件校验：

1. 当前时间是否在考试起止时间范围内
2. 该学生是否已经交过卷（防止重复进入）
3. 该学生是否有未完成的考试记录

校验通过后，后端会创建一个“考试进行中”的记录并返回当前时间戳。前端拿到这个时间戳后，把duration（考试时长）和当前时间换算成截止时间戳，存进localStorage。这里有一个容易踩的大坑：倒计时要基于截止时间戳而不是本地倒计时值。如果学生中途刷新页面，本地变量全部重置，但截止时间戳还在localStorage里，重新登录后就能继续倒计时，不会被重置“偷走”时间。

交卷逻辑同样要处理边界情况。正常交卷时，前端把所有答题数据组装成answers数组，请求POST /api/exams/{examId}/submit，后端一次性接收并判分。需要处理的边界情况有三个：时间到了自动交卷、最后一题答完手动交卷、页面意外关闭后重新进入时“断点续答”。

时间到了自动交卷，我的实现方式是：前端倒计时归零后弹出“时间到，系统自动交卷”的提示，同时立刻调用submit接口提交当前已答数据。这里有个风险——网络请求还没发出用户就关闭了页面，数据就丢了。为了稳妥，我把每道题的答题状态实时同步到localStorage，学生每做一道题就缓存一道题的答案，即使自动交卷失败，重新进入时也能从缓存里恢复答案再交卷。

判分逻辑拆成两类处理。客观题（单选、多选、判断）是纯粹字符串比对：单选和判断直接equals，多选需要先把用户答案字符串拆成集合，判断是否与标准答案集合完全一致。简答题走人工批改流程：交卷后考试成绩记录里标记pendingReview状态，老师端出现“待批改列表”，老师打开后逐题打分并填写评语，系统自动计算总分。

3.3 组卷策略：让每次考试都不重样

组卷是老师端用得最多、也最能体现系统智能感的功能。我做出了两种模式：手动组卷和随机组卷。

手动组卷很容易理解——老师在题库里勾选题目，设置每题分值，生成试卷。为了体验更好，我做了一个“左侧题目列表 + 右侧已选题目面板”的经典布局，左侧按题型筛选，右侧实时统计已选题目数和总分。前端实现依赖一个selectedQuestions数组，勾选/取消只是对这个数组做增删，页面上通过computed自动算总分：

javascript复制const totalScore = computed(() => {
  return selectedQuestions.value.reduce((sum, q) => sum + q.score, 0)
})

随机组卷才是重头戏。老师选择题型分布（比如单选10题、多选5题、判断10题、简答2题），系统从题库中按规则随机抽取。这里我用MyBatis-Plus写了一个简单高效的方法：

java复制@Override
public List<Question> randomSelectQuestions(Integer courseId, String type, Integer count) {
    LambdaQueryWrapper<Question> wrapper = new LambdaQueryWrapper<>();
    wrapper.eq(Question::getCourseId, courseId)
           .eq(Question::getType, type)
           .orderByAsc(Question::getId)
           .last("LIMIT " + count);
    return questionMapper.selectList(wrapper);
}

有同学会质疑，orderByAsc(id)不是每次抽出来的都是同一批题吗？确实是。所以我加了一个洗牌策略：后端先把该课程下所有对应题型题目的ID查出来，在Java中用Collections.shuffle()打乱，再取前N个。你别嫌这方法土，它简单直观，答辩时老师一听就懂，而且不会引入复杂的SQL随机排序性能问题。

随机组卷之后，老师可以预览生成的试卷，觉得不满意就点“重新生成”，其实就是再次执行shuffle逻辑。建议加一个防呆设计：如果题库中符合要求的题目数量不足，前端弹出提示“题库资源不足，请减少抽题数量或补充题目”，避免生成出题目不够的残缺试卷。

3.4 成绩统计与可视化

成绩模块做得好不好，直接影响整个系统给人的“完成度”观感。如果只有一张成绩列表，那跟Excel有什么区别？我加了两个可视化组件，让系统显得“有数据分析能力”。

第一个是成绩分布直方图。老师点击某场考试后，前端调用GET /api/exams/{examId}/stats，后端返回一个数组，按分数区间统计人数：0-59、60-69、70-79、80-89、90-100。前端用ECharts渲染：

javascript复制const option = {
  xAxis: { type: 'category', data: ['0-59', '60-69', '70-79', '80-89', '90-100'] },
  yAxis: { type: 'value' },
  series: [{
    type: 'bar',
    data: distribution.value
  }]
}

第二个是知识点掌握度雷达图。这个功能考前端的同学看到会很有成就感：题目表里加一个knowledge_point字段，标记每一题考察的知识点（Vue响应式、组件通信、路由守卫、状态管理……），判分之后统计每个知识点的平均得分率，渲染成雷达图。老师在雷达图上能一眼看出班上学生对“组件通信”这块掌握得薄弱，这就是系统给教学带来的实际价值。

雷达图的实现不算复杂，后端返回一个{ knowledgePoint: '组件通信', accuracy: 62.5 }的数组，前端把它转换成Radar图的数据格式。视觉上五颜六色的雷达图在答辩演示时非常抓眼球的，老师看到这个模块的眼神完全不一样，值得花一晚上时间做出来。

4. 前端实战要点与考试交互细节

4.1 考试页面的布局设计和答题体验

考试页面是整个前端工程里交互最复杂的页面，值得单独拿出来讲。我的布局方案是经典的三段式：

• 顶部导航栏：课程名称、考试名称、倒计时（固定，不走动）
• 左侧区域：题目列表，按题号排列，已答题号高亮，点击题号快速跳转
• 中央区域：题号对应的题干、选项/输入区域，底部有“上一题”“下一题”按钮

这个三段式布局是绝大多数在线考试系统的标配，因为它最大限度地减少了学生的操作负担——不用滚动页面找题，点左侧题号就能直达。左侧的题号列表我用v-for渲染，根据当前答题状态计算类名：

javascript复制<div 
  v-for="(q, index) in questions" 
  :key="q.id"
  :class="{'answered': isAnswered(q.id), 'current': currentIndex === index}"
  @click="currentIndex = index">
  {{ index + 1 }}
</div>

已答题目的题号用实心背景色，未答的是空心，当前正在做的题目加边框高亮。这个视觉反馈看着简单，但实际做的时候需要从answers对象里实时判断题目是否已有答案，Vue的响应式系统能自动完成这个计算——只要answers是reactive对象，模板里调用isAnswered就会自动更新。

多选题的交互也值得注意。我用el-checkbox-group实现，但v-model绑定的数据要和题目ID关联。我的做法是：

javascript复制const answers = reactive({})
// 多选题更新
function updateMultiAnswer(questionId, checkedValues) {
  answers[questionId] = [...checkedValues].sort().join(',')
}

每次用户勾选或取消选项，就把当前选中的选项列表排序后拼接成逗号分隔字符串存入answers，判分时就拿这个字符串和标准答案比对。排序这个细节特别重要——不排序的话用户选“A,C”和“C,A”会变成两个不同的答案，明明都选对了却被判错。这个坑我是真实掉进去过的，当时测试的时候选反了顺序被判错，排查了半小时才发现是没排序。

4.2 倒计时的实现与异常兜底

倒计时的功能实现，常规做法是用setInterval每秒更新一次页面显示的剩余时间：

javascript复制const remainSeconds = ref(totalSeconds)
const timer = setInterval(() => {
  remainSeconds.value--
  if (remainSeconds.value <= 0) {
    clearInterval(timer)
    handleAutoSubmit()
  }
}, 1000)

但这样有一个隐患：倒计时数据是内存变量，页面一刷新就没了。另一个隐患是setInterval不够准确，浏览器切到后台标签页时可能被限流，导致倒计时变慢或者暂停。我的改进方案是：不依赖定时器累计，而是每次计算出“剩余时间 = 截止时间戳 - 当前时间戳”：

javascript复制const endTime = Number(localStorage.getItem('exam_end_time'))
const interval = setInterval(() => {
  const remain = Math.floor((endTime - Date.now()) / 1000)
  if (remain <= 0) {
    clearInterval(interval)
    handleAutoSubmit()
  } else {
    remainSeconds.value = remain
  }
}, 500)

这样哪怕页面卡顿、定时器跳帧，等下一次执行时还是会按照当前时间重新计算，误差只在刷新间隔内。把截止时间戳存localStorage还有一个好处：用户刷新页面后倒计时自动恢复，不会因为误刷页面就凭空多出几分钟。

掉线的兜底也要考虑：如果用户的网络突然断开，自动交卷请求失败怎么办？我的处理是：handleAutoSubmit里先尝试调用接口，失败的话把本地缓存的答案继续保存，然后跳转到“网络异常”提示页，用户恢复网络后重新进入时，系统会识别到“未提交成功”的考试记录，自动调起submit接口补交。

4.3 防止页面跳转和误操作交卷

在线考试最容易出事故的操作就是学生误点了浏览器的刷新按钮或者关闭标签页，整套答题数据直接归零。我在前端做了三层防护：

第一层：监听beforeunload事件，在考试进行中弹出浏览器的原生确认框：

javascript复制window.addEventListener('beforeunload', (e) => {
  if (examInProgress.value) {
    e.preventDefault()
    e.returnValue = '考试还在进行中，确定要离开吗？'
  }
})

第二层：使用Vue Router的onBeforeRouteLeave导航守卫，阻止路由跳走：

javascript复制onBeforeRouteLeave(() => {
  if (examInProgress.value && !confirm('考试未结束，确定要离开吗？')) {
    return false
  }
})

这两层合起来基本能挡住大部分误操作。注意它们作用不同——beforeunload管浏览器刷新/关闭，onBeforeRouteLeave管应用内部路由跳转。

第三层：交卷按钮增加双击确认弹窗。用户点击“交卷”后，弹出一个自定义Modal，显示已答题数和未答题数，并高亮提示“还有X题未完成，确认交卷？”。这里用el-message-box：

javascript复制const result = await ElMessageBox.confirm(
  `你还有 ${unansweredCount} 题未作答，确定交卷吗？`,
  '交卷确认',
  {
    distinguishCancelAndClose: true,
    confirmButtonText: '确认交卷',
    cancelButtonText: '继续答题'
  }
)

这个确认弹窗的效果非常直观，配合未答题目数量的数字提示，学生基本不会误点。

5. 前后端部署与答辩演示准备

5.1 环境准备与本地运行

部署这块我吃过不少亏，这次把最省心的路径写出来。开发环境要求：JDK 17、Maven 3.8+、Node.js 18+、MySQL 8.0。前端package.json里的依赖版本一定要锁定，别用^版本号，不然后面安装的依赖版本漂移会导致莫名的兼容性问题。

前端启动步骤：

bash复制npm install
npm run dev

如果npm install速度慢，建议先设置淘宝镜像源：

bash复制npm config set registry https://registry.npmmirror.com

后端启动步骤：

text复制1. 在MySQL中执行 project.sql 脚本，初始化数据库和示例数据
2. 修改 application.yml 中的数据库用户名密码
3. 在项目根目录执行 mvn spring-boot:run

前端默认跑在5173端口，后端跑在8080端口。由于前后端不同源，跨域问题必须提前处理。我在后端的WebConfig中配置了全局跨域：

java复制@Configuration
public class WebConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/api/**")
                .allowedOrigins("http://localhost:5173")
                .allowedMethods("GET", "POST", "PUT", "DELETE")
                .allowedHeaders("*")
                .allowCredentials(true);
    }
}

本地开发环境用这种简单粗暴的CORS方案完全够用。如果你把前端打包后放进Nginx部署，就不需要后端开CORS了，因为前端和后端域名一致，由Nginx做反向代理转发/api请求到8080端口即可。

5.2 答辩演示时的高光操作

一个线上考核系统，答辩现场最尴尬的事情就是“现场演示翻车”——数据库没启动、前端报错、网不好。我的建议是：提前录好一段2分钟的演示视频作为备份，同时现场也准备一份完整的演示脚本。

演示时不要从头到尾像流水账一样点一遍菜单，要有重点地展示核心亮点，每个模块展示都配套一句“为什么这么设计”。我建议的演示路线是：

1. 用老师账号登录，展示题库管理页，现场新增一道“前端代码纠错题”，展示表单的动态校验能力
2. 用随机组卷功能生成一份新试卷，强调“随机”逻辑，点一下“重新生成”演示试卷变化
3. 切换到学生账号，进入考试，完整答完一道单选题和一道多选题，展示答题卡高亮效果
4. 交卷后立即展示自动判分结果，然后进入成绩分析页，展示成绩分布直方图和知识点掌握度雷达图
5. 最后回到老师端，展示学生答案回看和人工批改简答题的流程

这套演示逻辑走下来大概5-8分钟，覆盖了系统的全部核心功能，每个环节都有互动感和视觉冲击力。答辩评委的记忆点绝对不只是“哦，有几个页面”，而是“这系统能自动判分、能随机组卷、还能做学情分析”。这就是高分毕业设计的底气。

5.3 扩展方向：万一有学生想冲一下高分

如果你的精力允许，有几个扩展方向能让项目从“良好”冲到“优秀”。

第一个方向是前端代码题的在线判题。前端课程考核系统如果只能考选择题，总觉得少了点灵魂。你可以接入一个编译判题服务，用Docker跑一个Node.js沙箱环境，学生提交前端代码后，后端把它扔进沙箱执行，比对输出结果。这个功能的工作量不小，但做出来之后整个项目的技术含量和谈资完全不一样。

第二个方向是考试防作弊措施的增强。可以做一个简单的“切屏检测”——监听visibilitychange事件，当页面从可见变为隐藏时记录一次切屏日志，考试结束后老师可以看到每个学生的切屏次数。这只是几行代码的事，但对“系统的完备性”提升巨大。

第三个方向是导出功能。成绩列表支持导出Excel，试卷支持导出PDF，这两个功能在企业开发中都是高频需求。用EasyExcel导出Excel、用iText库生成PDF，做起来不算难，但会让系统显得“成熟”。

扩展方向建议只选一个去实施，贪多嚼不烂。毕设的评分靠的是“一两个亮点+整体完成度”，而不是功能数量堆砌。把一个扩展点做到完整好用，远比三个半成品功能要打动人。

6. 常见问题与项目复盘

6.1 高频报错与排查思路

做这个项目的时间里，学生找我聊得最多的是下面几个报错，我直接把排查思路整理出来：

问题一：前端启动后发现页面白屏，控制台报错“Cannot read properties of undefined (reading 'xxx')”

这在Vue 3项目里常见原因是在模板中访问了一个还未初始化完成的对象属性。排查思路第一步，打开控制台看报错信息里究竟指向哪个变量名；第二步去代码里搜索这个变量的定义位置，十有八九是异步请求的数据还没返回就尝试读取了。解决办法是用v-if包裹依赖异步数据的渲染区域，或者给初始值赋一个空对象。你在接口返回前别让模板渲染，v-loading指令是个好帮手。

问题二：后端返回的JSON日期格式是一串数字

这是Java的时间序列化问题。Spring Boot默认用Jackson序列化LocalDateTime时，如果不指定格式会输出一个数组或时间戳。解决方式是在application.yml里统一配置：

yaml复制spring:
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    time-zone: GMT+8

配好之后前后端的时间格式就整齐划一了，再次强调时区也要配，不然前端显示的时间会差8小时。

问题三：请求返回401，但检查JWT过期时间明明没到

这个问题十有八九是JWT密钥或签发时间的问题。检查一下你生成令牌时用的signingKey和解析令牌时用的密钥是不是同一个。还有一个常见坑是服务器时间和本地时间不同步，导致JWT的exp字段校验失败。调试时可以先把verification的ignoreExpiration临时设为true，确认没问题后再改回来。

问题四：Element Plus的表格分页后搜索无效

做成绩管理时，搜索功能往往只搜索当前页的数据，这是把搜索逻辑写在前端分页之后所致。正确做法是搜索条件变化后重新请求后端接口，让后端根据keyword参数做模糊查询并重新分页返回。前端表格的分页数据永远以接口返回为准，本地只维护搜索表单。

6.2 从项目到回答：老师最爱问的几个问题

答辩环节的质量很大程度取决于你能不能用口语化的方式把系统讲清楚。我踩过的坑是：自己闷头做了几个月，一答辩就紧张，满脑子技术术语说不出来，老师听得也很累。我建议准备几个“话术模板”，把核心设计用大白话转述出来。

第一个问题：“你这个项目的难点是什么？”

千万别说“没有难点”。可以这样回答：在线考试系统的核心难点在于状态一致性——考试过程中的倒计时状态、答题状态、提交状态必须在前端刷新、断网等异常情况下保持一致。我的方案是把关键状态（截止时间、已答题目）持久化到浏览器本地存储，并在后端维护考试状态字段，前后端双重校验。这个回答既能体现工程思维，又能引出你做的防作弊和断点续答功能。

第二个问题：“为什么用JWT不用Session？”

回答思路是：Session需要服务端存储会话状态，如果将来系统要横向扩容部署多台服务器，Session同步会变成瓶颈。JWT是无状态的，服务器不需要保存会话数据，用户信息全部包含在令牌里，通过签名保证不被篡改。毕业设计规模下，这个选择的说法是站得住的。

第三个问题：“如果考试人数从一百变成一万，系统哪里会最先被打垮？”

这是压轴级的问题，回答得好非常加分。诚实又有深度的答案是：单机部署下，最先出现瓶颈的是数据库连接池——大量并发请求同时查数据库会把连接池资源耗尽。应对方案有两个方向，短期加连接池配置和缓存层（Redis缓存题目数据），长期做负载均衡和数据库读写分离。最后补一句“但毕业设计场景下，我的架构重心在业务完整性和逻辑正确性，性能优化更多是部署层面的问题”。这个回答既展示了思考深度，又不会因为过度承诺让自己难堪。

6.3 代码之外：时间规划与项目节奏

最后聊聊时间管理。很多毕设翻车的原因不在技术能力，而在节奏失控——前两个月玩，最后两周熬通宵也交不出完整系统。我的建议分四个阶段推进：

• 需求与建库阶段（第1周）：把功能清单写出来，角色权限定清楚，画出ER图和接口列表
• 后端开发阶段（第3~5周）：按模块顺序开发——用户鉴权 → 题库CRUD → 考试流程 → 成绩统计
• 前端开发阶段（第6~9周）：按页面顺序开发——登录/注册 → 后台管理页 → 考试页 → 成绩页
• 联调与打磨阶段（第10~12周）：前后端串接口、修Bug、完善细节、写文档、录演示视频

每个阶段结束给自己一个验收点：后端做完就该能通过Postman把所有接口调通；前端做完就该能把所有页面在Mock数据下跑起来；联调完成就该能真实走完“登录→考试→出分→统计”全流程。这个节奏看起来很慢，但每天只需要投入2-3小时，比临阵磨枪舒服太多，工程质量也完全是两个级别。

我个人在实际操作中的体会是，前端的课程在线考核系统最打动人的地方，恰恰不是某一项技术有多炫，而是整个业务逻辑闭环带来的满足感——学生登录进去能考试、交卷能出分、老师能看统计、管理员好维护，一个真实可用的系统从自己手里“长”出来。在动手之前把上面的坑和思路过一遍，你省下的绝对不止是一两周的返工时间。希望这些实战细节能帮你的毕设少走弯路，把项目做得稳稳当当。