做了几年考试类项目从学校里的课程测验到企业内部的认证考核这套系统算是我手里迭代次数最多、沉淀最完整的一套源码。标题里的“企业级Web在线考试系统”说白了就是一套前后端分离的考试管理平台后端用SpringBootMyBatis前端用Vue数据库落在MySQL上。很多刚入门的朋友看到“完整源码”就想着下载下来跑通就算完事但我更想带着你把里面每一处设计为什么这么做、哪些坑我踩过、哪些逻辑改都没法改一次讲清楚。这套东西能做什么一是管理端管理员维护用户、班级/部门、题库、试卷、考试、成绩二是考生端在线考试、倒计时、自动保存、交卷出分。适合谁看如果你正在学SpringBootVue想找一个能写进简历的真实项目或者你在公司/学校需要快速搭一套考试系统还不太想从零造轮子再或者你已经跑通了源码想搞清楚里面缓存、批量插入、并发交卷这些关键源码的意图——这篇文章都能给你实实在在的参考。1. 项目整体设计与架构拆解1.1 技术选型背后的逻辑为什么是这四个组件先说一个经常被问的问题为什么考试系统要用SpringBootVueMyBatisMySQL这套组合而不是Spring Cloud微服务或者用JPA、PgSQL之类的方案答案很简单这是一套“企业级”但又不是“海量并发”的系统。企业内部的考试系统用户量级通常在几百到几万人并发高峰出现在集中开考那一刻但远没到需要微服务横向扩展的程度。SpringBoot最大的价值是让后端开发回归业务本身内嵌Tomcat打一个jar包就能跑Vue负责前端交互组件化开发让试卷渲染、倒计时、答题卡这种强交互页面写起来非常顺手MyBatis胜在SQL可控考试系统的复杂查询随机抽题、多条件筛选、成绩统计用SQL手写比用ORM自动生成要直白得多也更容易做SQL级优化MySQL就不用多说了部署简单、生态成熟、文档多招人容易。相比之下如果一上来就上Spring Cloud Alibaba那套注册中心、网关、分布式事务对于考试系统这种单体就能搞定的场景就是纯属给自己加戏。技术是服务业务的不是用来堆砌简历的。1.2 前后端分离架构与部署形态这套系统是标准的前后端分离结构但“分离”并不是简单地把代码分成两个目录就完了还涉及接口约定、跨域处理、打包部署、权限传递一整条链路。后端结构上按SpringBoot习惯做了分包com.exam ├── controller // 接口层只做参数接收与结果封装 ├── service // 业务层考试流程、阅卷、成绩计算都在这里 ├── mapper // MyBatis接口层 ├── entity // 数据库实体 ├── dto // 前端交互数据对象避免直接把实体暴露给前端 ├── vo // 视图对象统计图表、成绩单等 ├── config // 配置类拦截器、跨域、WebMVC ├── utils // JWT工具、Excel导入工具等 └── common // 统一返回结构、异常处理、常量前端是标准的Vue工程Vue 2或Vue 3版本均可取决于你拿到的源码分支按路由拆成管理端和考试端。管理端走后台布局有侧边栏、数据表格、弹窗表单考试端单独一个页面路由不套后台框架只专注于答题、倒计时、交卷避免后台UI干扰考生注意力。部署形态上我实测推荐两种部署方式操作复杂度适合场景备注jar包 Nginx静态托管低小规模、单机部署前端npm run build产物放Nginx后端jar直接跑Docker Compose编排中需要快速迁移、多环境部署可把MySQL、后端、前端分别容器化前后端同域部署低避免跨域问题Nginx把/api反向代理到localhost:8080我大部分情况下选择第一种因为企业内部部署环境复杂很多服务器不让你随便装Docker一个jar包加一个Nginx配置是最省心的。等会第三章我会把部署步骤完整列出来。1.3 系统核心模块划分整套系统的功能模块按角色视角可以拆成三层。第一层是基础管理模块用户管理考生、管理员、阅卷老师、部门/班级管理、菜单权限管理。这一层是整个系统的基础没有它后续的“谁能考哪场考试”“谁能阅哪份试卷”全部无从谈起。第二层是考试业务模块题库管理单选、多选、判断、主观题、试卷管理手动组卷、随机抽题、考试管理发布考试、设置考试时间、及格线、参加人员、在线考试倒计时、答案自动保存、交卷、试卷批阅客观题自动判分、主观题人工阅卷、成绩管理成绩导出、统计分析。第三层是辅助模块系统日志、通知公告、数据备份。从这套模块划分就能看出“企业级”和“课设级”考试系统的本质区别在于课设通常只关心“能考、能打分”而企业级还需要考虑“谁有权限看什么数据”“成绩怎么导出给HR”“系统操作能不能追溯”。这些非考试核心但管理必备的能力才是职称晋升、绩效考核场景下的真正刚需。2. 核心功能模块与关键实现细节2.1 登录认证与权限控制JWT RBAC考试系统的登录认证我用的JWT理由很实际前后端分离后服务器不保存Session每次请求把Token带在Header里即可。尤其考试系统涉及多角色管理员、考生、阅卷老师不同角色能访问的接口必须隔离这时候用JWT配合RBAC基于角色的访问控制模型整个权限设计就很清晰。角色权限这块我也踩过坑。最开始我只在前端做了路由守卫后端接口没有任何权限校验结果有次测试用考生账号直接调管理员的接口数据脱了个光。所以现在这套源码里前后端双重校验前端做页面级控制后端做接口级控制核心接口必须标注所需角色注解。// 后端接口权限示例 PreAuthorize(hasRole(ADMIN)) PostMapping(/paper/create) public Result createPaper(RequestBody PaperDTO paperDTO) { return Result.success(paperService.createPaper(paperDTO)); }JWT的细节还有两点值得注意。一是Token过期时间不可能设得太长企业环境里一个考试最多两三个小时我一般设置Token有效期4小时加上一个role字段和一个userId字段不把敏感信息写进Token。二是一定要加拦截器校验SpringBoot里写一个HandlerInterceptor把需要放行的路径比如登录接口、静态资源排除掉。2.2 题库管理Excel批量导入的陷阱题库是考试系统的基础资产。如果系统不支持批量导入你让管理员一道题一道题录录入500道题可能就要一整天而且极易出错。所以这套系统里我专门做了Excel导入功能。具体实现是前端用Element UI的上传组件把Excel文件传至后端后端用EasyExcel解析为什么不用POI直接解析EasyExcel是阿里开源的解决了POI在大文件解析时内存占用过高的问题5000道题的Excel用POI直接读JVM内存容易吃紧EasyExcel采用流式解析一行一行读内存占用非常稳定。解析完成后需要做合规校验校验项规则不通过时的处理题干不能为空记录行号与错误原因选项数量单选4个、判断2个、多选4-6个跳过该题正确答案必须在选项范围内跳过该题题目类型1单选/2多选/3判断/4主观无法识别则报错这里有一个关键细节绝不能因为一行数据错了就整个Excel回滚。正确的做法是“逐行校验、记录errorList、返回导入结果清单”这样管理员能清楚看到“第3题缺选项”“第7题答案越界”等具体信息修正后重新导入即可。这个思路在企业场景下太重要了全有全无式的导入在真实工作中非常不实用。2.3 试卷生成策略固定试卷与随机组卷试卷模块是我认为整套系统里设计最微妙的部分。从业务视角来看考试系统不仅需要“固定一套题给所有人”还必须支持“随机抽题”模式否则一场考试下来相邻两个人题目一样抄答案的门槛太低了。随机组卷的经典做法是按规则抽题。// 从题库随机抽取N道指定难度、指定类型的题目 ListQuestion questions questionMapper.selectRandomQuestions( subjectId, // 科目ID questionType, // 题目类型 difficulty, // 难度系数 count // 抽题数量 );对应的SQL核心是ORDER BY RAND() LIMIT n。别笑这个写法在数据量小的时候够用但数据到几万条时性能会明显下降。我的优化思路是先查出符合条件的主键ID列表用RAND()做随机排序取前N个ID再用WHERE id IN (...)查全字段。另一个关键设计是试卷模板和考试场次分离。管理员先创建“试卷模板”比如单选20题、多选10题、判断10题、主观2题再发布考试时关联模板。这样“一套模板考试多场”就很正常比如同一个入职测验每周五考一场每场从题库里重新随机抽题试卷内容不同但结构一致成绩可比性就出来了。2.4 在线答题自动保存与防作弊基础考试过程中考生最怕的是什么辛辛苦苦答题结果网络抖动一下或者页面误刷新答案全没了。所以在线答题模块最重要的事不是样式好看而是“答案自动保存”。这里的实现方案有两种一种是定时提交每30秒把当前页面所有题目答案提交一次另一种是答题事件触发每答一题立刻通过异步请求保存。我推荐定时提交 离开页面时立即提交的组合。纯事件触发在考生快速点击时会产生大量请求后端并发压力大纯定时提交又可能丢失最后几分钟的答案。源码里我使用的是setInterval定时器每30秒把答案对象序列化后提交一次同时在beforeDestroy和beforeunload钩子里再主动提交一次。后端保存接口要做“幂等”同一个考生、同一道题、重复接收多次答案更新不会产生重复记录。具体实现方式是用复合唯一索引约束(exam_id, user_id, question_id)然后SQL用INSERT ... ON DUPLICATE KEY UPDATE这样一个接口既能处理首次提交也能处理覆盖更新还不需要先查再改。这段逻辑在并发场景下非常稳。2.5 自动阅卷与考试成绩计算客观题阅卷没什么黑魔法核心在于判分逻辑要可配置。单选做对得全分做错零分多选题如果采用“少选得部分分、多选错选零分”的规则判分逻辑就得在代码里写清楚策略。我实现的是一个ScoringStrategy接口不同题型实现不同的score()方法这样新增题型时不会把判分逻辑搅成一团。public interface ScoringStrategy { // 返回值是本题得分 double score(Question question, String userAnswer); } // 多选题判分策略完全匹配才得分或者按比例得分 public class MultipleChoiceScoringStrategy implements ScoringStrategy { Override public double score(Question question, String userAnswer) { String correctAnswer question.getCorrectAnswer(); // 全对才给分若开启“部分给分”则按交集比例折算 if (correctAnswer.equals(userAnswer)) { return question.getScore(); } // 默认策略只要不全部匹配记0分 return 0; } }主观题自动阅卷不现实系统会把主观题单独挑出来汇总给阅卷老师在批阅页面展示“考生答案 参考答案 得分框”简直就是一个简化版的工作流审批。成绩计算时客观题得分累加、主观题得分累加再计算总分、正确率最后落进成绩表里。还有个容易被忽略的细节是“交卷时间处理”。考试时间到了系统强制交卷但有些考生确实是在最后几秒点了交卷这时后端就出现两个“交卷事件”同时触发如果处理不当成绩会被重复计算或者覆盖。这个问题我放在第四章统一讲。3. 实操过程与关键环节实现3.1 数据库设计考试系统的表结构怎么落循着业务模块数据库核心表大概是这些数据表关键字段核心作用sys_userid, username, password, real_name, role用户统一表角色区分管理员/考生/阅卷人exam_questionid, subject_id, type, content, options, answer, score, difficulty题库表options用JSON字段保存选项集合exam_paperid, paper_name, total_score, duration, question_config试卷模板表记录题目配置规则exam_paper_questionid, paper_id, question_id, score若采用固定试卷用这张表关联具体题目exam_infoid, exam_name, paper_id, start_time, end_time, pass_score, status考试场次表exam_recordid, exam_id, user_id, submit_time, objective_score, subjective_score, total_score, status考试记录表也是成绩表exam_answerid, exam_record_id, question_id, user_answer, score考生答题明细表这里重点说明两个容易被课设思维误导的字段。一是exam_question里的options字段很多新手会建一个选项子表去存A/B/C/D但实际开发里直接存JSON字符串反而好使因为“题目选项”没有独立查询和关联需求存JSON省去一次次连表查询MyBatis里用TypeHandler就能自动把JSON字符串映射成ListString。二是exam_record和exam_answer必须设计成“一次考试记录对应多条答题明细”千万不能把答案拼成一个超长字符串存在考试记录表里——虽然这样省事但后续想按题目统计正确率、做知识点分析时你会后悔的。3.2 后端核心接口从题库到交卷的真实代码流程项目跑通的关键在于把核心流程在脑子里过一遍我把考试模块的主链路接口梳理出来你对照源码去看会清晰很多。首先是“进入考试”接口。考生点击“开始考试”后后端要做三步校验当前时间是否在考试时间段内、校验该考生是否有考试资格、创建考试记录并返回试卷详情。这时候需要注意返回给前端的试卷内容客观题要带着正确选项吗肯定不带。正确选项只留在后端交卷后判分用。这个“试卷内容脱敏”很容易忽略一旦把答案发给前端稍微懂点前端开发的人按F12就能看到答案整套考试就形同虚设。public StartExamVO startExam(Long examId, Long userId) { // 1. 校验考试时间段 ExamInfo exam examInfoMapper.selectById(examId); long now System.currentTimeMillis(); if (now exam.getStartTime().getTime() || now exam.getEndTime().getTime()) { throw new BusinessException(当前不在考试时间内); } // 2. 创建考试记录 ExamRecord record new ExamRecord(); record.setExamId(examId); record.setUserId(userId); record.setStatus(0); // 0-进行中 1-已交卷 examRecordMapper.insert(record); // 3. 组装试题去答案版 ListQuestionVO questionList paperService.getQuestionsWithoutAnswer(exam.getPaperId()); return new StartExamVO(record.getId(), exam.getDuration(), questionList); }其次是“提交答案”接口。前端定时/触发式提交的都是单个答案后端收到后执行on duplicate key update保证幂等。真正关键的是“交卷接口”。Transactional(rollbackFor Exception.class) public SubmitResultVO submitExam(Long recordId, Long userId) { // 防止重复交卷先查状态 ExamRecord record examRecordMapper.selectById(recordId); if (record null || !record.getUserId().equals(userId)) { throw new BusinessException(考试记录不存在); } if (record.getStatus() ! null record.getStatus() 1) { // 已交卷直接返回已有成绩保证幂等 return SubmitResultVO.of(record); } // 1. 强制将未提交的答案落库 // 2. 逐题调用ScoringStrategy判分 // 3. 汇总成绩更新考试记录 // 4. 更新状态为已交卷 return SubmitResultVO.of(updatedRecord); }交卷方法上加Transactional是必须的因为整个交卷流程涉及读取所有答案、逐题判分、记录成绩、更新状态多个操作任何一步失败都应该整体回滚避免出现“考生交卷了但成绩没算出来”的怪象。3.3 前端关键页面与组件倒计时与答题卡体验前端最核心的页面是考试答题页。这个页面要同时处理好几种任务渲染不同题型组件、维护答题状态、管理倒计时、支持答题卡快速跳转。组件拆分的话建议至少拆成这些QuestionCard.vue单题展示组件根据questionType动态渲染单选/多选/判断/主观题。AnswerSheet.vue右侧答题卡展示题号和作答状态已答/未答/当前。ExamTimer.vue倒计时组件到最后一分钟显示红色警示时间到自动交卷。ExamPage.vue考试页面根组件负责汇总所有题目答案、定时保存、调用交卷接口。倒计时这里有个非常容易被忽略的问题不能在前端用setInterval单纯递减计数考生只要刷新页面倒计时就重置了。正确做法是后端在“开始考试”接口里返回serverTime服务器当前时间前端根据服务端开始时间 考试时长 - 当前时间来计算剩余时间。即便考生刷新后端也能通过考试记录里的开始时间重新算出剩余时间。用服务端时间做基准还有一个好处管理员设置考试延时或个别考生补时都能在后端灵活调整。答题卡组件虽然看起来就是个九宫格按钮但它的状态更新逻辑很体现基本功——不能每次都遍历所有题目重新判断而是监听每题的userAnswer变化把已答题目数量计算出来实时更新进度条。这个我实测数据量大的时候性能差别很明显。3.4 本地部署与联调从零跑通这套项目我把从拉取源码到本地跑通的完整步骤写在这里跟着做基本不会卡壳。后端环境准备JDK 1.8或11看源码里的pom.xml配置、Maven 3.6、MySQL 5.7或8.0。数据库用Navicat或命令行执行项目的sql脚本创建数据库和表。注意核对application.yml里的数据库名、用户名、密码改成你自己本地的。启动后端进入后端根目录执行mvn spring-boot:run或者用IDEA直接运行启动类。看到“Started ExamApplication in x.xxx seconds”就说明后端起来了。前端环境准备安装Node.js推荐14或16版本版本太高容易踩坑、npm或yarn。启动前端进入前端目录执行npm install安装依赖再执行npm run dev默认跑在localhost:9528这类端口。联调验证访问前端地址管理员账号登录先创建题库、导入题目再创建试卷、发布考试然后切换考生账号参加考试最后回管理员端查看成绩。这一步里常见的坑有几个。第一个坑是MySQL 8和MySQL 5.7的驱动/时区配置不同8.0版本必须在application.yml的数据库连接URL后面加?serverTimezoneAsia/ShanghaiuseSSLfalse否则启动会报时区或SSL错误。第二个坑是前端npm install时网络慢或版本冲突建议配置淘宝镜像源或者直接用yarn安装。第三个坑是端口冲突确认后端8080端口、前端9528端口没有被其他程序占用。4. 常见问题与排查技巧实录4.1 前后端联调跨域与请求404前后端分离后“跨域”是第一道坎。联调时前端axios请求后端接口报CORS错误是最典型的问题。解决方案有两种一种是在后端SpringBoot里配置全局跨域另一种是在Nginx部署时通过反向代理把跨域转为同域。本地开发推荐后端配置CrossOrigin或全局CorsFilterConfiguration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOrigins(http://localhost:9528) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true); } }部署到服务器后就不再依赖后端跨域了用Nginx做反向代理更干净server { listen 80; server_name exam.example.com; location / { root /opt/exam-front; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }这里还要提醒一个现象很多人后端启动成功前端也启动成功但请求接口时返回404。排查思路不是先怀疑代码而是先看Nginx配置里有没有把/api路径代理过去再看前端request.js里的baseURL是不是/api开头最后看后端接口的RequestMapping前缀是否匹配。顺序乱了容易被表象带偏。4.2 MySQL时区与SSL连接异常这一节我单独写因为数据库连接问题在MySQL 8上实在太普遍了。报错信息通常长这样The server time zone value Öйú±ê׼ʱ¼ä is unrecognized或者SSL connection error。原因很简单MySQL 8的时区默认是系统时区通常是UTC而中国所在的时区是东八区同时MySQL 8默认开启SSL而本地开发环境通常没有配置有效的SSL证书。解决办法是在数据库连接URL上追加上参数url: jdbc:mysql://localhost:3306/exam_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue这里四个参数各有各的用处useUnicode和characterEncoding保证中文不乱码serverTimezone解决时区问题useSSLfalse关闭SSL生产环境如果在内网且没有合规证书关掉是合理的allowPublicKeyRetrievaltrue针对MySQL 8某些版本连接时提示public key retrieval not allowed的问题。4.3 MyBatis映射字段为Null或值为0用MyBatis的时候最容易出现的一个现象是数据库字段明明有值查出来却是null或者查出来明明是1Java实体里却是0。遇到这种问题时第一反应不是怀疑数据库而是看实体属性名与表字段名是否对得上。比如数据库字段叫question_typeJava实体属性叫questionType默认情况下MyBatis是不会自动把下划线转驼峰的必须在application.yml里开启mybatis: configuration: map-underscore-to-camel-case: true还有一个细节是MyBatis的缓存机制。默认情况下MyBatis的二级缓存是关闭的如果你发现修改了SQL后结果没变十有八九是Session缓存或者开启了二级缓存没有清理。建议在联调阶段把Mapper层的cacheEnabled设为false定位逻辑问题不要被缓存干扰。4.4 并发交卷与重复提交问题我在2.5节提到过“交卷时间到了考生在最后一秒疯狂点交卷按钮”的场景。如果你在交卷接口里只写了“先查记录状态如果已交卷就返回”这种逻辑在高并发下会有一个经典的竞态问题两个请求同时查到状态为“未交卷”然后同时去判分、同时去更新成绩最后数据被覆盖。解决方案有两个层面。第一个层面是Java代码层面加锁但分布式部署时本地锁会失效考试系统虽然很少多节点部署我还是建议用数据库层面的唯一约束来兜底。第二个层面更实用在exam_record表加一个version字段更新时使用乐观锁UPDATE exam_record SET total_score #{totalScore}, status 1, version version 1 WHERE id #{id} AND version #{version} AND status 0如果更新影响行数为0说明记录已经被其他请求更新过了这时候直接返回已有的成绩即可。这是我实测下来最稳妥的交卷防重方案比Synchronized关键字可靠得多。4.5 题库数据量大时查询性能优化随着题目数量增长题库列表页、随机抽题、成绩统计都可能变慢。处理思路按优先级来优化手段具体操作见效程度索引优化exam_question表给subject_id、question_type加联合索引高分页查询列表页用PageHelper或MyBatis-Plus分页禁止全表查高随机抽题优化先用子查询取ID再用IN查字段避免ORDER BY RAND()全表排序中成绩统计物化成绩汇总统计走定时任务或缓存不在请求链路实时聚合中索引这块最容易被忽略的其实是exam_answer表因为这张表的量级是最爆炸的一场1000人考试的答题明细就有几万条。给exam_record_id加索引是考试成绩查询和统计的底线保障。4.6 防止答案泄露与考试安全写到最后一条我想把它单独拎出来因为这属于考试系统的“非功能性需求”却往往是甲方最在意的点。除了第三章说的“返回试卷时去掉正确答案”还有几个细节防止考生请求题目详情接口跳题拼接后端要校验每个题是否属于当前考试试卷。防止前端控制台篡改倒计时以服务端时间判定交卷前端倒计时只是个展示器。防止接口被直接调用交卷交卷接口要校验当前时间是否在考试时间范围内超时未交卷时后端点“强制交卷”而不是依赖前端触发。图片上传类的题目答案要做好文件类型校验不能让考生上传恶意文件。考试系统的安全设计不是做得越复杂越好而是要围绕“成绩可信”这一核心目标去设计。把上面这几条做进源码里基本就能挡住90%的普通作弊尝试。我做这套系统最大的体会是很多朋友拿到源码第一件事就是启动、点点页面然后觉得“跑通了会了”。但碰到真实需求时比如考试中途断网、考生双击交卷、管理员要批量导入5000道题还是两眼一抹黑。建议你按这篇文章的脉络把题库导入、随机组卷、自动保存、交卷防重、成绩统计这五条主链路在源码里亲手走一遍把每条链路的表结构、SQL、判分逻辑串起来这套源码才算真正变成你自己的东西。