简介一份基于Spring Boot的在线考试系统毕业设计文档面向高校师生、Java开发者以及需要完成课程设计或毕业设计的读者核心目标是解决传统线下考试效率低、资源分配不均等问题。压缩包内共有1个docx文件包体大小约3.88MB内容完整便于阅读和二次编辑。目前已有121人学习/下载受到一定关注。文档详细介绍了Spring Boot框架、Java编程语言和MySQL数据库在系统中的应用采用经典MVC架构将系统划分为管理员、教师、学生三大功能模块并具体说明管理员对试题、用户、成绩的管理教师发布考试、设置试题、查看成绩的流程学生查看安排、参加考试、查询成绩的体验同时涵盖前端界面、后端逻辑、数据库表用户、试题、考试设计、安全策略及测试优化等实现细节。读者可参考其需求分析与系统设计思路作为毕业设计论文撰写、在线考试项目开发或学习Spring Boot整合实践的实用资料。 在线考试系统算是Java Web方向里最经典的“入门级完整项目”之一每年毕业设计、课程设计、甚至企业内部培训考核系统都能看到它的影子。但你真去搜一圈会发现一个尴尬的事实网上现成的开源考试系统不少可要么太重、要么太老、要么业务逻辑写得一团糟想二次开发还不如自己从头搭一套。这篇文章我就以“基于Spring Boot的在线考试系统”为线把从需求分析、技术选型、数据库设计到核心业务落地的完整思路过一遍。重点讲几个我最常被问到的地方试卷和答题记录怎么存、考试交卷的并发怎么写、跨浏览器适配到底要防什么、以及上线前哪些配置不改会出事。适合正在做同类项目的学生也适合想快速搭一套内部考试系统的开发朋友参考。1. 为什么还要自己动手写一套在线考试系统先说点实际的。整个系统拆开看无非就是用户登录、题库管理、试卷生成、在线答题、自动阅卷、成绩统计这几块。单独拎出任何一块都不算难但把它们串起来形成一个完整闭环需要处理不少边界情况比如考试中途刷新页面、交卷超时、同一账号多处登录、选择题和简答题混排等。这些恰恰是拿来练手或做毕设最有价值的部分。很多人会问有现成的在线考试平台为什么不用这个得分场景。如果是学校大规模统考确实应该用商业产品或成熟的部署方案但如果你只是需要一个嵌入到已有系统里的考试模块或者你想在简历上写清楚“一个从零开发的完整系统”那自己动手的意义就完全不一样了。Spring Boot在这类场景下非常合适起步快、约定优于配置、生态成熟社区里随便一搜就是解决方案。另外从学习角度说这个项目能一次覆盖Web开发的主线知识——REST API设计、ORM操作、缓存与消息队列、权限控制、前端联调、部署上线。你不光是在写一个“考试系统”而是在把这些平时零散接触的技术点真正串起来。做完以后再去看其他管理系统类的项目基本就是换皮重写。2. 从需求到模块先把边界画清楚再动手写代码很多初学者拿到题目就急着建工程、写实体类结果写到一半发现需求理解偏了或者功能范围失控返工成本特别高。我建议先花一到两天把需求边界和业务流程理清楚。2.1 三种角色和核心流程在线考试系统最常见的角色划分是三种管理员、教师、学生。当然你也可以拆出“阅卷教师”之类的角色但多数情况下三种就够用了。管理员维护用户、管理班级/院系、配置系统参数、查看全局统计。教师维护题库、组卷、发布考试、人工阅卷简答题、查看成绩报表。学生参加考试、查看个人成绩和答卷详情。核心流程可以概括成这样一条线教师创建试卷 → 添加试题或从题库随机抽题 → 设置考试时间和时长 → 发布考试 → 学生在规定时间内作答并交卷 → 系统自动判客观题 → 教师人工评主观题 → 学生查看成绩。把这条链路记住整个系统的模块划分和数据库设计就有了方向。2.2 七个功能模块怎么划分我在实际设计时将系统拆成了七个基础模块用户认证模块登录、登出、修改密码、Token刷新。题库管理模块单选、多选、判断、简答四类题型的增删改查支持按知识点和难度筛选。试卷管理模块创建试卷、从题库选题、随机组卷、设置考试时间与时长、发布与回收。在线考试模块进入考试、倒计时、逐题作答、自动保存答案、交卷。阅卷模块客观题自动判分主观题由教师逐份评分。成绩模块成绩查询、成绩统计报表、成绩导出。系统管理模块用户管理、角色权限、操作日志。这七个模块不是七选一而是一整套闭环。很多网上流传的代码只做到了前四个模块成绩统计和主观题阅卷经常被砍掉导致系统“只能考不能评”答辩时很容易被问住。3. 关于技术选型我的一些实际考虑技术选型这件事不能光看“什么火就用什么”。考试系统的本质是一个事务性强、实时性要求中等偏上的Web应用选型要围绕这个本质展开。3.1 Spring Boot 3 MyBatis Plus而不是 JPASpring Boot本身没什么争议版本尽量选3.x——Spring Framework 6的底层已经全面基于Jakarta EE规范性能、线程模型都比2.x时代更有优势。持久层我更推荐MyBatis Plus而不是Spring Data JPA原因有三点第一考试系统的查询条件通常比较复杂按题型、难度、知识点、时间范围多条件组合MyBatis的XML或注解SQL写起来更直观第二MyBatis Plus自带的BaseMapper已经覆盖了单表CRUD的大部分场景代码量不比JPA多第三这套系统的开发者往往是学生或初级工程师MyBatis的调试排查经验在行业里更通用简历上也更站得住。另外建议在依赖里加上mybatis-plus-jsqlparser它的作用是在分页查询时自动优化SQL避免分页参数拼接出错。这个坑我在早期项目里踩过——LIMIT语句被拼到了复杂子查询里导致总数统计完全不对排查了小半天。3.2 Redis 在这套系统里扮演的三个角色Redis在考试系统里绝不是装饰品它至少承担三件事验证码存储登录时生成的图片验证码或短信验证码用SET key value EX 120存到Redis设置持久化策略为noeviction即可过期由Redis自动清理比存在Session里干净得多。考试信息缓存试卷的题目列表、考试时间配置等热点数据首次从数据库加载后缓存到Redis减少数据库压力也提升进入考试时的加载速度。限流与防刷登录接口和交卷接口一定要做限流。登录用简单的计数器限流即可交卷接口更关键后面我会单独讲。有一点要注意不要把用户的答题进度存在Redis里当“实时保存”Redis毕竟不是强持久化存储万一宕机丢数据用户答了半小时的题全没了这锅谁都背不起。正确的做法是答题中间态保存到本地浏览器localStorage加数据库的双保险Redis只做短周期缓存。3.3 前端选型与交互方案如果是为了快速完成项目直接用Thymeleaf模板引擎也能做完但如果你有点前端基础我建议用Vue 3 Element Plus做前后端分离。原因不只是“好看”而是考试界面的交互逻辑很重倒计时、题目切换、答题卡、未答提醒这些东西用模板引擎写起来非常痛苦分离以后前后端各管各的维护成本低得多。不过前后端分离会引入跨域问题。开发环境我用vite.config.js里配置server.proxy转发生产环境则让Nginx把/api前缀的请求反向代理给Java服务这样浏览器视角里始终是同源请求不需要CORS配置也不会有奇怪的问题。这个方案我强烈建议保留比后端加CrossOrigin简单一百倍。4. 数据库设计的几个关键决策数据库设计是这类系统的灵魂。改表结构在这类项目里代价特别高——数据一旦积累起来改字段就意味着要写迁移脚本、要修复脏数据所以我花了不少时间在前期把表结构想清楚。4.1 五张核心表的结构我把核心业务表归纳为五张sys_user用户表字段包括id, username, password, real_name, role, department_id, create_time等。question_bank题库表字段包括id, question_type, content, options, answer, analysis, difficulty, knowledge_point。其中options我用JSON类型存储选项列表answer也用JSON存储这样可以同时支持单选、多选、判断、填空等多种格式。exam_paper试卷表字段包括id, title, duration, total_score, pass_score, start_time, end_time, status, creator_id。exam_paper_question试卷题目关联表字段包括id, paper_id, question_id, question_order, score。这样一份试卷可以有多道题一道题也可以出现在多份试卷里。exam_record考试记录表字段包括id, paper_id, user_id, start_time, submit_time, objective_score, subjective_score, total_score, status。exam_answer答卷明细表字段包括id, record_id, question_id, user_answer, is_correct, score。这六张表基本覆盖了主体业务。exam_paper_question这种中间表很多人会漏但如果不建它你就只能把题目ID用分隔符硬拼到试卷表里查询时再拆字符串费劲不说还容易出错。4.2 试题选项存法、答卷记录存法的取舍这是一个很有代表性的问题。我见过不少教程把“选项ABCD”拆成option_a、option_b、option_c、option_d四个字段看起来好像挺直观但一旦题目要加第5个选项或者选项是图片、公式这种设计就直接崩了。我的做法是用JSON类型存整个选项数组Java侧用一个ListString字段接收配合MyBatis Plus的JacksonTypeHandler自动做类型转换既灵活又干净。答卷明细表我一开始也想用JSON字段把学生所有答案一次性存进去后来放弃了。原因是客观题自动判分需要逐题比对主观题需要教师逐题给分如果用一个大JSON每次判分都要把整个JSON取出来再解析查询慢、逻辑绕、还不好写SQL统计得分率。拆成一行一题之后成绩统计、错题汇总都变成了简单的GROUP BY后边你一定会谢这个决定。5. 在线考试主链路的实现顺序在线考试系统不要急着先去写“保存答案”我建议按照这个顺序实现核心业务认证 → 组卷 → 考试中间态 → 交卷判分 → 成绩展示。每一步都建立在上一步之上调试起来非常顺。5.1 登录认证与权限拦截登录这块通常用JWT但不建议自己手写一套复杂的认证框架。我用的方案是Spring Security JWT但只保留核心能力关闭默认表单登录自己写一个OncePerRequestFilter做Token校验。核心代码大致长这样Component public class JwtAuthenticationTokenFilter extends OncePerRequestFilter { Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException { String token request.getHeader(Authorization); if (StringUtils.hasText(token) token.startsWith(Bearer )) { Claims claims JwtUtil.parseToken(token.replace(Bearer , )); if (claims ! null) { Long userId Long.valueOf(claims.getSubject()); SysUser user userService.getById(userId); if (user ! null) { UsernamePasswordAuthenticationToken authentication new UsernamePasswordAuthenticationToken(user, null, List.of(new SimpleGrantedAuthority(ROLE_ user.getRole()))); SecurityContextHolder.getContext().setAuthentication(authentication); } } } filterChain.doFilter(request, response); } }密码存储用BCryptPasswordEncoder这个默认自带盐值别再用MD5一点都不费事但安全档次差出去很远。5.2 组卷策略和考试状态管理组卷实现上分两种一种是教师手工从题库挑题目调整每题的分数另一种是设置好规则比如“单选题10道、每题2分多选题5道、每题3分”系统按规则随机抽题。随机抽题我建议在SQL层面做用ORDER BY RAND()在题库量不大时完全够用别把题库全部load到内存再洗牌浪费且没必要。SELECT * FROM question_bank WHERE question_type SINGLE AND difficulty 3 ORDER BY RAND() LIMIT 10;考试进行中的状态管理是整个系统最需要注意的边界场景。我的做法是学生点击“开始考试”时后端会检查当前时间是否在start_time和end_time之间并且没有已提交的记录然后创建一条exam_record记录并返回给前端。倒计时由前端负责展示但后端不能只依赖前端报来的时间——交卷时要求前端把开始时间和答题时长带回来后端做二次校验超时就拒绝交卷。这不是不信任用户而是防止有人在浏览器里改个时间就绕过时间限制。5.3 自动阅卷与成绩统计客观题自动判分没有太多技术含量纯比拼对逻辑单选题、判断题直接equals比对多选题要额外判断答案匹配度我的策略是全对才给满分漏选不给分这个在组卷时可以配置。主观题的处理交卷后客观题分数立即算好主观题分数置为0状态标记为“待人工阅卷”教师在后台逐题打分后汇总总分。public BigDecimal calculateObjectiveScore(ListExamAnswer answers, MapLong, QuestionBank questionMap) { BigDecimal score BigDecimal.ZERO; for (ExamAnswer answer : answers) { QuestionBank q questionMap.get(answer.getQuestionId()); if (q ! null answer.getUserAnswer().equals(q.getAnswer())) { answer.setIsCorrect(true); answer.setScore(q.getScore()); score score.add(q.getScore()); } } return score; }5.4 交卷瞬间的并发压力处理这是整套系统里最考验设计功力的一环。几十上百人同时点交卷如果所有请求都直接打到MySQL在高并发下很可能出现连接池耗尽、响应超时。我参考了网上讨论比较多的做法也结合了Spring Boot Redis Stream的实现方式用Redis Stream做一道缓冲。交卷请求到达后先校验Token和考试状态通过后把recordId和答卷明细封装成一条消息发布到Redis Stream里接口立刻返回“交卷成功”。后端启动一个消费者使用XREADGROUP拉取消息完成客观题判分和总分汇总再异步写入MySQL。// 生产者 redisTemplate.opsForStream().add( exam:submit:stream, Map.of(recordId, recordId.toString()) ); // 消费者简化示例 StreamOperationsString, Object, Object ops redisTemplate.opsForStream(); ListMapRecordString, Object, Object records ops.read( Consumer.from(exam-group, consumer-1), StreamReadOptions.empty().count(10).block(Duration.ofSeconds(2)), StreamOffset.create(exam:submit:stream, ReadOffset.lastConsumed()) );这里有个细节消费端处理完消息后要手动确认ACK否则Redis Stream会一直保留未确认消息导致重复消费。设计这样的流程后交卷接口的压力被削峰填谷地转移到异步消费者数据库不再被瞬时打满实测百人同时交卷也很稳定。6. 跨浏览器与兼容性问题其实没那么多坑“跨浏览器支持”被列在热搜词里确实是因为很多项目在验收时被这个问题坑过。但坦白说现在主流浏览器对于ES6和CSS3的支持已经相当好了真正的坑往往不在浏览器本身而在一些被忽略的细节上。6.1 真正的问题来自哪里我调试时遇到最典型的三个问题时间格式化差异new Date(2025-06-01 14:00:00)在Chrome和Firefox里都正常但在老版本Safari里会因为时间分隔符是空格而解析失败返回Invalid Date。解决办法是统一在后端返回ISO8601格式的时间字符串例如2025-06-01T14:00:00前端再解析或者干脆后端把时间换算成时间戳返回。localStorage 读写权限在部分企业浏览器禁用Cookie和localStorage的组合场景里前端代码直接读取localStorage.getItem(token)会抛异常。稳妥做法是做一层封装读不到Token就走无痕模式提示而不是让整页白屏。旧版浏览器的日期组件Element Plus的日期选择器在IE和旧版Edge上表现会不一致但现在还在维护这些浏览器的场景已经很少建议直接声明最低支持Chrome 90 / Firefox 90 / Edge 90的基线省去一半兼容性工作。6.2 时区、时间格式这类容易被忽略的问题如果考试系统允许分布在跨时区的用户使用那时间就不能只存一个本地字符串。我的建议是数据库统一用DATETIME存储UTC时间或者干脆存TIMESTAMPJava后端使用LocalDateTime配合系统时区做转换前端显示时再用Intl.DateTimeFormat转成用户本地时区。如果系统只在一个校区内部用时区问题不大但“存UTC、显示本地”这个好习惯建议养成万一以后扩展了你会感谢当年的自己。还要提一个容易被忽视的问题服务端返回给前端的时间不要用字符串拼接一定要用BigDecimal或Long型时间戳或者ISO标准字符串。有次我在联调时发现前端考试倒计时总是差8小时排查半天发现是后端在JSON序列化时将LocalDateTime转成了UTC时间前后端在时间上产生了隐式转换。7. 上线前必做的几项安全与稳定性检查系统开发完不等于能用至少还要过一遍安全基线检查。我整理了几项每次上线前都会逐条确认的清单。7.1 Actuator端点的收敛Spring Boot自带的Actuator很有用能暴露健康检查、指标、环境信息等端点。但默认配置如果直接暴露在公网等于是把家底亮给别人看——/actuator/env能读到环境变量/actuator/beans和/actuator/mappings能猜出你的业务结构和信息。社交平台上关于此类端点暴露的讨论也一直很多重点不在于“漏洞”本身而是使用姿势。我的建议是在生产环境只开启health和prometheus两个端点并且用management.server.port把端口隔离到内网management: endpoints: web: exposure: include: health,prometheus endpoint: health: show-details: never server: port: 9091这样外网访问不到9091端口health也不暴露具体组件细节既保证了监控可用又不会泄露敏感信息。7.2 Micrometer 接入 Prometheus既然Spring Boot支持很好的指标暴露就顺手把Micrometer接上。依赖加一个micrometer-registry-prometheus配置好上面两个端点Prometheus那边只要定期从/actuator/prometheus拉取数据就行。对考试系统而言我重点盯这几个指标http.server.requests、jvm.memory.used、redis.connection.pool.usage。前两个是通用指标第三个是Redis连接池的使用率——交卷高峰期如果这个指标飙升很快说明Redis的连接池配置需要调大或者消费速度要跟上。有监控和没有监控的区别在系统出问题的时候是天壤之别。Grafana的仪表盘模板网上有很多现成的导入一个JVM Spring Boot的Dashboard即可不需要自己从零画。我的经验是不要为了监控搭一大堆基础设施能把“服务活着、接口响应慢不慢、连接池用满没有、GC是否频繁”这几个问题回答清楚就已经超过大部分同类系统了。7.3 密码策略、SQL注入和越权防护充数不做的不说这三条一定不能省用户密码必须BCrypt加密并且管理员不能明文看到用户密码只能重置。所有SQL都使用MyBatis的#{}参数占位不要用${}拼接。这个基本算是底线要求MyBatis Plus封装的查询天然防注入但如果你有时候自己手写SQL注意这一点。越权防护是很多毕设项目的重灾区。最常见的问题学生可以直接访问/api/paper/1查看整张试卷的JSON数据而正常的考试流程是进入考试后才逐题下发。后端每个接口都必须在校验Token之后再校验角色和资源归属不能只靠前端菜单隐藏。另外登录接口和查询成绩接口建议都做基于IP的限流防止被脚本刷。用Redis做简单的计数即可通常不用引入完整的限流框架。8. 踩过的坑和一些实用小技巧最后一个部分分享一点实际开发中攒下的经验不一定高大上但能帮你少走不少弯路。在交卷接口里我一开始同步做了“判分→更新成绩→写答卷明细”三步结果在并发测试中数据库连接池被拖垮。后来改成Redis Stream异步消费的架构后问题解决。遇到这种瞬时写密集的场景优先考虑异步化。试卷发布后的内容变更要考虑“版本”。教师发布后如果还能修改试题已经生成的考试记录里题目的分数可能对不上。最简单的方案是发布后只允许修改考试时间不允许编辑题目如果需要修改就复制一份新试卷再发布。学生的答题记录建议每次作答操作就更新到数据库中不要等最后统一提交。否则万一考试中途浏览器崩溃、网络断掉学生刷新页面之后所有答案都丢了体验非常差。我的做法是学生每作答一题前端发出一次PUT /api/exam/record/{recordId}/answer然后后端更新对应exam_answer记录交卷时再走异步判分流程。前端倒计时要和后端时间保持同步。前端用本地时间计时一旦用户改了本地系统时间倒计时就会失效。所以进入考试时后端返回一个serverTime时间戳前端基于这个时间戳做倒计时计算不直接用new Date()。卷面的题序和分值需要和题库解耦。也就是说试卷中的题目标题可以重复分值可以由教师在组卷时覆盖题库默认分值这一切都通过exam_paper_question中间表完成。一开始想省事直接把题库的分值作为试卷分值后来发现不同教师想给同一道题配不同分值的时候根本做不到只能老老实实加中间表字段。根据我实际做下来的体会这套系统最大的价值不在于用了多少技术栈而在于强迫你把一个完整的业务流程从头到尾走了一遍从需求分析到数据库设计从前端联调到并发处理从安全基线到监控部署。把这些关键点都过一遍之后你的Spring Boot能力就是“用过且踩过坑”的经验级别而不是“看过文档”的纸面级别。后面不管是换个“实验室预约系统”还是改成“在线答题平台”换的只是业务外壳核心架构思路完全可以平移复用。本文还有配套的精品资源点击获取