Spring Boot+Vue 3在线考试系统：核心设计、随机抽题与防作弊避坑指南

简介一款专为在线考核场景打造的轻量级在线考试系统源码前端采用Vue渐进式框架组织交互界面后端使用Java处理业务逻辑与数据交互面向高校课程测评、企业内训及毕业设计参考人群。压缩包仅642KB共含88个文件既有44个Java源文件与12个Vue组件也包含配置、数据、脚本与少量界面图片覆盖从后端服务到前端页面、再到项目配置的完整结构。目前已有98人学习系统支持考生在浏览器端在线答题教师可在后台完成试题录入、试卷组装与发布、查看学生成绩等任务借助清晰的文件划分还可理解前后端分离开发中的接口配合、组件复用与数据传递思路。配套许可证与基础说明文件便于合规使用和快速跑通项目适合作为在线教育类系统开发的起步模板。1. 轻量级在线考试系统不是又一个CRUD是流程引擎与随机策略的考验在线考试系统的需求在国内教育软件、企业内训SaaS里常年排在前五但多数团队把它当成普通增删改查项目来规划结果一到真实考试日就暴露问题。这个标题给出的技术栈是JavaVue落点是轻量级与源码意味着你不需要K8s、不需要微服务、不需要引入工作流引擎只用Spring Boot加一个Vue 3项目就能把一套可用的考试闭环撑起来。适合三类人正在找Java课程设计或毕业设计题目的学生想给公司搭内部考核工具的后端工程师以及想快速验证在线考试产品原型的独立开发者。它要解决的核心不只是试卷管理而是考试过程中最容易垮掉的三个环节随机抽题的并发一致性、考试状态的防作弊同步、前端倒计时与后端截止时间的对齐。2. 技术选型Spring Boot Vue 3这套组合的边界在哪2.1 轻量级不是砍功能而是砍掉不必要的复杂度标题里“轻量级”三个字是最容易被误解的地方。有的团队一上来就引入Spring Cloud Alibaba、Nacos、Redis集群结果一个五十人同时考试的小系统要拉起五个服务。这里说的轻量级我理解是单体应用加最小中间件一个Spring Boot服务承载全部REST接口一个MySQL数据库存考试全量数据本地会话用JWT完成考试状态用数据库行级锁控制。这套组合在同时在线几百人的场景下完全够用而你省掉的是服务注册发现、配置中心、消息队列带来的部署和运维负担。真正的成本瓶颈往往在带宽和数据库连接池不在应用层。2.2 后端选型Spring Boot 3.x与MyBatis-Plus是稳妥默认值做在线考试系统后端框架选型我一般直接落在Spring Boot 3.x加JDK 17或者JDK 21持久层用MyBatis-Plus而不是原生MyBatis。理由很直接这个项目的核心复杂度在考试流程控制不在SQL写法。MyBatis-Plus的分页插件、LambdaQueryWrapper、自动填充时间字段都能把CRUD代码量压到三分之一以下。你要是背过Java面试八股文就知道MyBatis的Mapper动态代理原理在面试里是高频考点但写业务代码时把时间省下来处理考试状态机更值。有一个容易被忽略的取舍是不要用Spring Data JPA。在线考试系统的试题表、答卷表和考试记录表之间存在大量条件查询和分页统计而JPA在复杂查询上要么写JPQL要么用原生SQL混搭调试体验远不如MyBatis-Plus直接了当。JPA适合表关系清晰、更新频繁的ERP场景考试系统这种读多写少、统计逻辑多的场景MyBatis-Plus更顺手。2.3 前端选型Vue 3加Element Plus就够了别上重型图表库前端标题里只有Vue具体版本要自己定。现在新项目直接用Vue 3加Vite不要再用Vue 2加webpack。Vue 3的组合式API在处理考试页面的状态管理时比选项式API干净很多特别是倒计时、答题记录、切屏检测要同时联动的时候。组件库选Element Plus它有现成的表格、表单、分页、消息提示能覆盖系统管理端百分之八十的页面需求。关于Vue安装及环境配置我建议直接用Vite的create命令初始化项目Node.js版本20以上npm create vuelatest如果公司镜像源稳定依赖安装基本不会出问题。前端不要为了做试卷预览引入ECharts之类的图表库考试系统画不了几个统计图ECharts打包体积不算小等真有可视化需求时再加符合轻量级定位。2.4 项目结构单Maven模块比多模块更好维护很多教程会把考试系统拆成exam-common、exam-admin、exam-api三个Maven模块理由是复用。对于源码教学和课程设计我并不推荐。多模块会带来依赖管理成本和IDE调试时的模块切换开销而对一个单体Spring Boot服务来说包路径划分足够。我常用的结构是controller/service/mapper/entity/dto五层包配上config、security、exception三个支持包。下面用一张表说明各包职责包名职责关键类示例controller接收REST请求做参数校验ExamController、PaperControllerservice业务逻辑抽题、判分、交卷ExamService、PaperGenerateServicemapperMyBatis-Plus数据接口ExamMapper、QuestionMapperentity数据库表映射实体ExamRecord、AnswerSheetdto前后端交互对象SubmitResultDTO、ExamPaperDTOconfig拦截器、跨域、线程池配置WebMvcConfig、JwtInterceptor3. 后端核心设计六张表撑起考试闭环3.1 数据模型设计六张表的字段与关系在线考试系统的最小数据模型是六张表user、question_bank、exam、exam_question、exam_record、answer_detail。其中exam_question是考试与试题的关联表也是承载随机抽题结果的核心位置。我没把试卷单独做成一张表因为“试卷”在这个系统里是一个运行态产物——它由exam定义规则在考试开始时实时生成。把试卷持久化会造成两个问题一是每次考试都要复制一份题量数据存储冗余二是如果题库后续修改历史成绩对应的实物试卷会与题库脱节。对于轻量级系统用关联表即时生成更能保持一致。每张表的字段设计也值得推敲。question_bank表除了题目、选项、答案外至少要冗余question_type和score两个字段。question_type用于区分单选、多选、判断题score直接参与判分逻辑避免在服务端写死每题分值。exam表要保存start_time、end_time、duration_minutes、total_questions、pass_score。前三个字段控制考试窗口后两个用于前端显示和自动判分阈值判断。exam_record表里我额外加了cheat_count和status字段前者记录切屏次数后者标记未开始、进行中、已交卷、超时交卷四种状态。3.2 登录与鉴权不用Security框架拦截器足够Spring Security在这个项目里属于重武器引入它要维护UserDetailsService、密码编码器、过滤器链三套配置对轻量级考试系统而言过度设计。我常用的是JWT加HandlerInterceptor的方案用户登录成功后签发一个有效期为两小时的Token前端每次请求把Token放在Authorization请求头里后端在拦截器中解析并校验。代码大约二十行逻辑清晰也方便在拦截器里统一做接口权限判断。贴一段核心拦截器代码Component public class JwtInterceptor implements HandlerInterceptor { Resource private UserMapper userMapper; Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登录接口和静态资源 if (request.getRequestURI().contains(/auth/login)) { return true; } String token request.getHeader(Authorization); if (token null || !token.startsWith(Bearer )) { throw new BizException(401, 未登录或登录已过期); } String tokenValue token.substring(7); // 解析JWT并获取用户ID建议用jjwt库版本选0.11以上 Long userId JwtUtil.parseToken(tokenValue); User user userMapper.selectById(userId); if (user null || user.getStatus() ! 1) { throw new BizException(401, 账号已被禁用或不存在); } // 把用户信息写入ThreadLocal后续业务代码可以直接取用 UserContext.set(user); return true; } }这段代码有两个细节建议按你的场景调整。第一个是token.substring(7)如果前端固定带上Bearer前缀这里取子串没问题如果团队有人漏加前缀会引发字符串截断异常所以在拦截器入口先做startsWith判断是必要的。第二个是UserContext用ThreadLocal保存用户信息在高并发场景下务必在afterCompletion里调用UserContext.clear()否则Tomcat线程池复用会串用户数据这是很典型的Java面试八股里的线程安全考点。3.3 随机抽题算法不要无脑ORDER BY RAND()随机出卷是这个系统的核心难点。如果直接在question_bank表上执行ORDER BY RAND() LIMIT 10数据量超过两千条时查询耗时就会明显上升因为MySQL会对全表生成随机数再排序而且不走索引。更严重的是并发考试请求同时执行这条SQL数据库CPU会瞬间飙高。我采用的方案是预生成题目ID集合后分段取样。具体逻辑是考试开始请求到达时先从question_bank表里查出符合条件的题目ID列表按题型分组。比如单选20题、多选10题、判断5题就分别查出各自ID数组然后用Java的Collections.shuffle打乱最后截取需要的数量。将选出的题目ID和顺序写入exam_question表随后的试卷展示和判分都以这张关联表为准。这个方案的并发安全点在“先插入考试记录再生成抽题”的顺序上要给exam_record表加考试唯一约束保证同一用户同一考试只能有一条记录避免前端重复请求导致同一份考试生成两次题。public ListQuestion generatePaperQuestions(Long examId, Long userId) { // 第一步创建考试记录锁定考试资格 ExamRecord record new ExamRecord(); record.setExamId(examId); record.setUserId(userId); record.setStatus(0); // 0未开始 1进行中 2已交卷 3超时 record.setCreateTime(LocalDateTime.now()); examRecordMapper.insert(record); // 第二步按题型分组从题库取题 Exam exam examMapper.selectById(examId); for (QuestionType type : QuestionType.values()) { ListLong allIds questionMapper.selectIdsByType(type, exam.getCourseId()); Collections.shuffle(allIds); ListLong chosenIds allIds.subList(0, Math.min(exam.getCountByType(type), allIds.size())); // 第三步把抽题结果写入考试题目关联表 for (int i 0; i chosenIds.size(); i) { examQuestionMapper.insert(examId, chosenIds.get(i), i 1); } } return examQuestionMapper.selectQuestionsByExamId(examId); }参数说明要留意三点countByType是从exam表里解析的题量配置建议在创建考试时就写明每种题型各多少道避免前端传参改不了规则Collections.shuffle是随机洗牌不需要设置种子subList返回的是视图只能读不能修改如果你想转成ArrayList再做后续操作就要用new ArrayList(subList)包一层。这里还有一个血泪经验selectIdsByType不能用MyBatis-Plus的LambdaQuery直接selectList整行要在Mapper接口里写成select id from question_bank where question_type #{type} and course_id #{courseId}只取出ID字段减少内存压力。3.4 自动判分逻辑多选题的严格判分与部分得分考试系统的判分逻辑不能只在Service层写几个if-else。我见过太多翻车案例当试卷里同时存在单选、多选、判断题时判分代码写成长串条件分支后期维护几乎是灾难。正确做法是定义一个判分策略接口每种题型实现一个策略类用Spring的ApplicationContext.getBeansOfType在启动时注册到Map里。这样加新题型时只写一个新的策略类不改原有代码。判分逻辑里最容易出错的是多选题判分。严格判分需求下多选必须全部选对才得分但部分企业的内部考试允许多选漏选给一半分这个规则不能写死在策略类里我建议在exam表中增加multi_choice_policy字段取值STRICT或PARTIAL。判分时先校验答案集合是否一致再按策略计算得分。下面这段是部分得分策略的模板方法public ScoreResult judge(String userAnswer, String correctAnswer, int score) { SetString userSet parseToSet(userAnswer); // A,B,C - Set SetString correctSet parseToSet(correctAnswer); // 先判断是否多选/错选有选错直接零分 for (String u : userSet) { if (!correctSet.contains(u)) { return ScoreResult.zero(score, 包含错误选项); } } // 严格模式数量不一致也零分部分模式漏选得分减半 if (userSet.size() ! correctSet.size()) { if (STRICT.equals(policy)) { return ScoreResult.zero(score, 选项数量不符); } return ScoreResult.half(score, 漏选得一半分); } return ScoreResult.full(score, 完全正确); }4. 前端实现路由守卫、倒计时与交卷状态的现场处理4.1 Vue 3项目搭建与vue-router守卫Vue 3前端不是简单的页面堆叠考试页面是强交互页面用户可能切后台、锁屏、误关闭标签页这些操作都会导致考试中断或数据丢失。我用Vue 3组合式API加vue-router的全局前置守卫来处理这些保护逻辑。创建项目后要做三件基础配置在router/index.js里注册考试路由时给meta字段打标记在axios拦截器统一注入Token并处理401跳转在主布局组件里监听beforeunload事件提示用户试卷未保存。这些配置对Vue冷启动来说属于必须步骤很多新手只关心页面长什么样忽略了路由跳转时题目状态是否还留在内存里在线考试系统最忌讳的就是内存状态驱动界面。路由守卫的典型场景用户点击浏览器的后退按钮应该被拦截并弹出确认提示用户主动修改URL跳转到其他页面应当被阻止。实现方式是在路由配置里给考试页面的路由对象加一个meta: { requiresExam: true }属性然后在beforeEach里判断下一跳是否包含该标记router.beforeEach((to, from, next) { // 验证登录态没有Token直接回到登录页 const token localStorage.getItem(exam_token); if (to.meta.requiresAuth !token) { next({ path: /login }); return; } // 考试页面任何离开动作都先确认 if (to.path /exam/start from.path ! /exam/start) { const confirmed window.confirm(考试尚未结束确定离开当前页面吗); if (!confirmed) { next(false); return; } } next(); });这段代码需要配合beforeRouteLeave使用——beforeEach只能拦截路由跳转拦截不了浏览器标签页的关闭和刷新。刷新操作由第4.3节的未提交答卷恢复机制兜底而关闭标签页要么提示用户要么接受现实考试系统真正要防的是刷新丢数据而不是关页面。4.2 倒计时组件把deadline交给后端时间戳倒计时是考试系统的核心交互。常见的错误做法是后端返回duration_minutes字段前端用setInterval自己倒数一刷新就重置。我在项目中要求后端接口在返回试卷时同时返回exam_end_time是后端服务器时间加考试时长计算出的绝对时间戳。前端倒计时只根据当前本地时间与这个时间戳的差值做展示不再自己累加。这样做有两个目的一是避免前端修改系统时间作弊二是天然处理了刷新恢复。倒计时结束后的交卷动作必须由后端兜底前端显示时间归零时调用交卷接口后端在ExamService.submitPaper里还要再做一次时间校验如果当前时间晚于截止时间则标记为超时交卷并禁用继续答题。前后端双重判断是防绕过的底线。const remainSeconds ref(0); const endTime examInfo.examEndTime; // 后端返回的时间戳单位毫秒 function startCountdown() { const updateRemain () { const now Date.now(); remainSeconds.value Math.max(0, Math.floor((endTime - now) / 1000)); if (remainSeconds.value 0) { // 倒计时归零自动调用交卷接口 clearInterval(timer); submitExam(timeout); } }; // 立即执行一次再启动定时器避免整数秒延迟 updateRemain(); const timer setInterval(updateRemain, 1000); }setInterval在浏览器标签页进入后台时会降低执行频率依赖它做精确倒计时必然翻车。更好的做法是在组件里同时监听visibilitychange事件用户切回来时立刻执行一次updateRemain把时间纠正到正确位置。这也是为什么不能用前端倒计时结果作为交卷凭据一切以服务端校验为准。4.3 答卷状态恢复localStorage做临时草稿箱用户刷新页面是最常发生的事故。如果答题记录只存在组件状态里而没有落盘刷新后所有答案全部丢失这会让用户直接崩溃。我在前端每切换一道题时就写一次localStorageKey按照exam_record_{userId}_{examId}规则设计Value是JSON对象包含题目ID和当前答案。每次加载试卷前先检查是否存在草稿如果存在就回显到界面上。localStorage方案只做草稿恢复不能当作最终答卷。最终答卷必须由用户点击交卷或倒计时结束后上传到后端数据库。草稿清空的时机是在交卷成功回调后。这样做有一个边界要注意多人共用同一台电脑时localStorage的Key带userId才能避免窜数据而userId从JWT解析出来后在前端可以存到sessionStorage登录页校验时需要判断同浏览器是否残留了上一个用户的草稿。function saveDraft(questionId, answer) { const draft JSON.parse(localStorage.getItem(exam_draft) || {}); draft[questionId] answer; // 考试答题属于高频写操作localStorage同步API足够 localStorage.setItem(exam_draft, JSON.stringify(draft)); }5. 避坑记在线考试系统最容易翻车的6个现场5.1 刷新后白屏Vue Router history模式与Nginx配置冲突现象用户进入考试页面后点击刷新页面直接404而不是回到当前试卷。原因Vue Router用了HTML5 History模式前端路由的URL是/exam/1部署到Nginx时没有配置try_files回退到index.htmlNginx找不到对应的静态文件于是返回404。解决生产环境要么改用createWebHashHistory把URL变成/#/exam/1要么在Nginx的server配置块里加一行location / { try_files $uri $uri/ /index.html; }。如果系统后续要考虑SEO用History模式并正确配置Nginx如果是内部考试系统完全不需要SEO直接用Hash模式更省事这种取舍比死记框架规则更有效。5.2 题库抽题出现重复题现象考试试卷中同一道题出现了两次且概率不稳定。原因我的抽题逻辑容易踩的一个坑就是先对所有题目ID做shuffle然后按题型分组时没有排除已选的题目。特别是在按题型顺序抽单选、判断、多选时如果某道题同时被标记为两个题型或者题库中同一条记录被插入了两个题型分类就会重复。解决建一个全局SetLong selectedIds每抽一道题就加入集合。下一次selectIdsByType查询时使用NOT IN (selectedIds)条件或者干脆在Java侧过滤。我倾向于Java侧过滤少一条动态SQL数据库执行计划更稳定。还有另一种来源的重复题是后端开了重试机制比如前端超时重发请求用户生成两次抽题请求发现数据库中产生了两个不同的试卷记录。解决方法是给exam_record表加(exam_id, user_id)联合唯一索引第二次插入直接抛异常业务层捕获后返回已存在的记录。5.3 前端时间与后端时间不一致导致提前交卷现象考生本地电脑时间快了五分钟倒计时显示已经结束但服务器时间还没到截止点考生被迫提前交卷。原因前端倒计时应该以服务端返回的时间戳为基准但有的实现里把时间处理成了new Date().getTime() duration * 60 * 1000天然依赖客户端时钟。解决后端生成试卷时直接计算截止时间戳前端严格使用它做差。如果还要更精确建议前端调用接口前做一次时间同步通过Date.now()与响应头里的Date字段对比或者由后端额外返回一个serverTime字段前端计算本地时间与服务器时间的偏移量offset所有倒计时计算都加上offset。这样即使客户端改时间倒计时也不会受影响。5.4 多选题判分用户答案为空字符串被错误判为正确现象用户没有作答的题目判分后居然得满分。原因用户答案默认是空字符串判断逻辑里如果先判断字符串非空则跳过那么空字符串与正确答案比较时长度判空逻辑没拦截住。解决判分方法入口第一行就判断StringUtils.isBlank(userAnswer)直接返回零分。这个坑特别隐蔽很多工程师写完判分逻辑自测时用的是正常答案存在空答案的边界测试没写。补一条单元测试把所有题型的空答案用例跑一遍比手工点页面更快找到问题。5.5 考试中切屏被误判现象网页弹窗、浏览器插件广告、微信弹窗导致页面失去焦点系统误判为切屏跳转。原因切屏检测一般用document.hidden监听页面可见性变化但这个事件对浏览器弹窗、插件遮罩层也会触发。我见过一个真实案例用户使用输入法的候选框弹出页面失去焦点三秒后系统判定作弊。解决切屏检测不能只看visibilitychange要配合window.onblur事件只在以下情况累计切屏次数页面隐藏超过五秒且下次可见时通过后端接口上报一次。五秒以内的隐藏视为误触不记录。这个阈值得在需求评审时约定不同考试的宽容度不一样我一般默认三秒到五秒之间。切屏次数在前端展示后端记录达到阈值时由管理员决定是否强制交卷技术方案不要自动踢人。5.6 并发交卷时成绩丢失现象用户点击交卷按钮后前端按钮没有置灰用户连点三次产生三条交卷请求。后端没有做幂等处理三次请求导致成绩被重复计算甚至数据库记录被覆盖成空分数。原因交卷接口没有做幂等设计也没检查考试记录状态。解决交卷接口第一步是校验exam_record.status只有状态为“进行中”时才能进入判分流程同时将状态更新为“已交卷”。由于上面加了update ... set status 2 where id ? and status 1这样的条件更新MySQL会锁匹配行天然拦截重复请求。如果返回影响行数为0说明记录状态不对直接返回“您已交卷请勿重复操作”。这种做法比在前端禁按钮更可靠因为按钮置灰只能防正常用户防不了脚本重放和弱网重试。6. 上线前最后一公里打包、验证与进阶方向经过前面几章的开发系统已经在本地跑通了但要真正上线到服务器至少要完成三件事环境分离配置、生产构建验证、考试全流程压测。第一件事把application.yml拆成application-dev、application-prod两套环境配置数据库连接、文件路径、日志级别都抽到环境变量里。不要在产品配置里保留能登录的测试账号这是安全底线。Maven打包命令mvn clean package -DskipTests生成的jar包建议指定Spring Boot的--spring.profiles.activeprod参数启动。前端打包用npm run build构建产物放到Nginx的HTML目录或者直接用Spring Boot的src/main/resources/static目录集成部署小型考试系统完全可以一个jar包跑完这也叫轻量级。第二件事做一次Vue安装依赖与构建的重现验证。不要把node_modules提交到Git锁住package-lock.json文件版本。部署机器上第一次构建时用npm ci而不是npm install后者会根据package.json重新解析依赖版本容易引入意外更新。这里我踩过坑本地用Vue 3.4测试环境因npm install拉到了3.5某个组件API行为变化导致打包报错从此统一用npm ci。第三件事手工过一遍考试全流程的异常用例登录后断网再连交卷时点两次考试倒计时归零后停留在页面不操作使用浏览器的DevTools修改本地时间。针对前三类场景后端日志里要能输出对应错误码和堆栈前端要给出可理解的提示文案。我强烈建议写一个JMeter脚本模拟一百个并发用户同时交卷观察数据库的exam_record表是否出现重复记录、answer_detail表的写入耗时是否超过一千毫秒。若有超过优化方向是先检查是否缺少合理索引再考虑把答案批量写入改成insert into ... values (...), (...)而不是循环逐条插入——如果读过MyBatis源码就知道Executor的批量执行模式对这类写入有明显性能差异。进阶方向上有两个值得投入的点。一是成绩统计分析数据库层用GROUP BY score_band做分段统计前端用简单的CSS柱状条呈现不需要图表库。二是考试批改的附件上传如果考试包含主观题建议引入阿里云OSS或MinIO试卷答题里的图片走前端直传后端只保存URL。这个改动会让系统不再严格“轻量”但是否值得看你的实际需求。最后留一个个人习惯每次改完考试状态机相关的代码我都会手动跑一遍六种状态迁移——未开始进入进行中、进行中交卷、进行中超时、超时自动交卷、已交卷重试、未考试直接交卷。这六条路径覆盖了线上百分之九十的异常投诉比任何设计文档都有用。这套JavaVue的在线考试系统技术栈的每一层你都可以找到成熟生态真正的门槛不在代码量而在把考试规则翻译成状态判断的细心程度。希望帮到你。本文还有配套的精品资源点击获取