在线考试平台这个题，在Spring Boot相关的课程设计和毕业设计里，出现频率真的非常高。它表面上是一个“系统开发”题目，实际做起来却要覆盖多角色权限、题库组织、组卷策略、考试状态流转、自动判分、成绩统计这一整条业务链路。相比单纯的增删改查，这类项目更考验你对业务流程的理解，以及碰到边界情况时能不能把逻辑做严谨。

我当时做这个项目时，花了大量时间在数据库设计和判分一致性上，后期反而很轻松。今天就把完整的设计思路、核心表结构、关键代码逻辑，以及那些在调试中踩过的坑一次说清楚。无论你是准备做课程设计，还是想拿一个完整的Spring Boot练手项目，这篇文章都能直接参考。

1. 项目整体设计与技术选型

1.1 为什么在线考试平台用Spring Boot最合适

先说实话：课设和毕设阶段，完全不需要上微服务那一套。在线考试平台的用户量和使用场景很集中，业务边界也很清楚，本质上就是一个标准的单体Web系统。Spring Boot在这种场景下简直是量身定做的，自带内嵌Tomcat，打包成jar文件就能跑，把“本地起服务”的成本降到极低。同学拿到源码后，装好JDK、MySQL、Maven，改一下数据库连接就能把项目跑起来，这在后期答辩演示时优势很大。

Spring Boot还有一个实际好处：生态对这类系统覆盖得很好。登录鉴权有Spring Security或JWT，持久层用MyBatis-Plus，Excel导入用POI或EasyExcel，统计图表直接前端引入ECharts，每个环节都有大量可查的资料。相比SSM要手动配置一大堆XML，Spring Boot用起步依赖把常见的配置都收拢了，新手只需要关注自己代码的部分即可。我试过很多次，对时间紧的同学来说，Spring Boot确实是性价比最高的选择。

从答辩角度讲，Spring Boot还能引出“自动配置”“内嵌容器”“起步依赖”“约定优于配置”这些高频面试点。你只要在项目里把JWT鉴权、拦截器、全局异常处理、事务控制都用上，面试官问起来就有具体案例可以讲，而不是停留在“我调用过某个接口”这种层面。

1.2 角色与权限设计

三类角色是考试平台的标配：学生、教师、管理员。我建议把它们放在同一张用户表里，用role字段区分，不要拆成三张表。原因是登录入口只有一个，所有角色的校验逻辑可以统一走同一套JWT鉴权，后续扩展角色也很方便。

• 学生：查看考试列表、开始考试、交卷后查看分数和答卷解析、查看个人成绩曲线。
• 教师：维护题库、创建试卷、手动选题或随机组卷、在线阅卷、查看所授课程的成绩统计。
• 管理员：管理系统基础数据，比如课程、班级、用户账号，重置密码，查看全站统计。

权限控制在课设阶段最实用的方案是拦截器加注解，不需要把Spring Security整个搬进来。实现方式是这样的：定义一个@RequireRole注解，标注在Controller方法上，拦截器里解析当前登录用户的角色，角色不匹配就返回统一格式的错误信息。这种方式代码量不大，而且很好讲清楚权限设计的思路。

1.3 核心模块划分

整个系统按功能拆成六大模块：系统管理、用户认证、题库管理、试卷管理、在线考试、成绩统计。其中组卷和在线考试是这个项目区别于普通管理系统的核心，也是设计文档里最值得展开写的内容。

动手写代码之前，建议先把业务状态线画出来：教师创建试卷并发布考试 -> 学生进入考试生成试卷快照 -> 学生答题并提交 -> 客观题自动判分 -> 主观题进入人工阅卷 -> 成绩发布 -> 学生查看成绩和解析。这个流程里每个节点都有自己独立的表结构和状态字段，理清了后面写代码会顺很多。

2. 数据库设计：考试系统的地基

考试平台的大部分逻辑问题，根源在表结构上。表关系设计好了，业务代码只是盖楼；表关系设计乱了，后面所有模块都会跟着打补丁。下面按模块拆开讲。

2.1 用户与课程模块

用户表是最基础的表，我一般在user表之外还会设计课程表和学生选课表，这样学生和教师的关系不会绑死在一个字段里。

用户表字段大概是这样：id、username、password、real_name、role、student_no、class_name、status、create_time。注意密码不能存明文，建议用BCrypt加密。很多同学喜欢用MD5，但实际项目里BCrypt在每次加密时生成不同的盐，相同密码加密后的结果都不一样，安全性明显更好。

课程表字段比较简单：id、course_name、teacher_id、class_name、create_time。选课表把学生和课程关联起来：id、student_id、course_id。为什么要单独设计选课表？因为一个学生可以选多门课，一门课也有多个学生，典型的多对多关系，必须用中间表承接。

2.2 题库与试卷模块

题库表是整个系统的核心资产。我常用的字段是：id、course_id、type、title、options、answer、analysis、score、difficulty、create_time。type字段区分单选、多选、判断、简答四种题型。options字段的存储方式，我用的是“A.xxx|B.xxx|C.xxx|D.xxx”这种字符串格式，简单直观。你当然也可以用JSON格式，更规范。但对课设而言字符串足够，只要写入时做好格式校验，后面判分就不会出问题。

判断题答案我喜欢存“T”和“F”，不存汉字的“正确/错误”。这样判分就是简单的字符串比较，省去各种编码和空格问题。

试卷表字段可以设计成：id、paper_name、course_id、total_score、duration、start_time、end_time、status、create_by。考试时间范围、考试时长、总分这些关键业务属性都放在这里。另外需要单独建一张试卷题目关联表paper_question，字段包括：id、paper_id、question_id、sort。这里有个细节：组卷时生成的题目顺序要固化成sort字段，不要让学生每次刷新看到的题目顺序都不一样，否则考试体验很差。

下面是一张核心建表SQL示例：

CREATE TABLE `question` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `course_id` BIGINT NOT NULL COMMENT '所属课程', `type` TINYINT NOT NULL COMMENT '1单选 2多选 3判断 4简答', `title` VARCHAR(500) NOT NULL COMMENT '题干', `options` VARCHAR(1000) DEFAULT NULL COMMENT '选项，用|分隔', `answer` VARCHAR(255) NOT NULL COMMENT '标准答案', `analysis` VARCHAR(1000) DEFAULT NULL COMMENT '解析', `score` INT NOT NULL DEFAULT 5 COMMENT '分值', `difficulty` TINYINT DEFAULT 1 COMMENT '1简单 2中等 3困难', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

2.3 考试记录与快照设计

考试记录表exam_record跟踪每一次考试实例：id、paper_id、student_id、start_time、submit_time、status、objective_score、subjective_score、total_score。status字段标记考试状态，比如ongoing、submitted、graded，这是整个考试流程的状态机核心。

学生每次作答的明细放在answer_record表：id、exam_record_id、question_id、student_answer、is_correct、score。考生提交一道题就保存一道题，交卷时再统一判分。

这里特别想强调“快照”这个设计。学生在进入考试那一刻，系统要把试卷题目、题目分数、标准答案一起复制到考试记录里，而不是交卷时再去题库实时读数据。我第一次做的时候没有快照，结果老师考试中途改了一道题的答案，之前已经交卷学生的成绩全变了。这个教训让我意识到，考试系统的一致性不能依赖“随时可变的业务数据”。快照字段会多占一点存储空间，但换来的是极高的数据稳定性，这个交易完全值得。

3. 核心功能模块实现与实操拆解

3.1 登录鉴权与全局用户态

登录模块我推荐用JWT方案。用户登录成功后，后端把用户id、角色、用户名放进token的claims里，前端后续请求在Authorization头带上token，后端配置拦截器统一解析。

为什么不用传统的Session？课设阶段用Session其实也没问题，但JWT更接近现在主流的接口风格，代码写出来也更好讲。用jjwt库，代码量不大：

String token = Jwts.builder() .setSubject(userId.toString()) .claim("role", user.getRole()) .claim("username", user.getUsername()) .setExpiration(new Date(System.currentTimeMillis() + 1000 * 60 * 60 * 12)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact();

密钥放在application.yml里，不要硬编码。拦截器里解析token失败就返回401，成功就把用户信息放进ThreadLocal，Service层需要当前用户时直接取。这个方案对前端也很友好，后面如果想把页面升级成Vue分离版，接口可以原封不动地复用。

3.2 题库管理与Excel批量导入

录入题目是最耗时的工作，所以题库模块一定要支持Excel批量导入。Apache POI是常用方案，读取xlsx文件后遍历每一行，解析出题型、题干、选项、答案、解析、分值，然后批量写入数据库。

批量导入最常见的坑有几个：

• xls和xlsx格式兼容问题，建议统一使用xlsx，读取方式不一样。
• 空行和空单元格会解析出null，需要判空处理，否则入库时报错。
• 答案格式不规范，比如多选题写成“A,B,C ”带空格，或“ABC”不带逗号。导入时最好统一清洗成规范格式。

导入完成要给教师明确的反馈：成功多少条、失败多少条、哪一行哪一列格式有问题。不要闷头导入完就什么都不提示。这里可以写一个导入结果对象，包含成功数量和失败原因列表。

3.3 手动/自动组卷逻辑

组卷是考试平台最有“业务味”的模块。手动组卷比较好理解：教师从题目列表里勾选题目加入试卷，设置分值，保存时校验总分。

自动组卷我建议做成“按题型设置数量，按难度分布抽题”。核心是随机抽题SQL：

List<Long> questionIds = questionMapper.selectList( new LambdaQueryWrapper<Question>() .eq(Question::getCourseId, courseId) .eq(Question::getType, type) .eq(Question::getDifficulty, difficulty) .last("ORDER BY RAND() LIMIT " + count) ).stream().map(Question::getId).collect(Collectors.toList());

MySQL的ORDER BY RAND()在几十万级数据量的场景下会有性能问题，但课设阶段的题库规模小，直接使用完全没问题。如果你想把项目做得更亮眼，可以在设计文档里专门提一句这个方法的适用边界，再引出其他更优的随机方案，面试时这是加分点。

组卷保存前一定要校验总分。比如试卷设置了100分，但勾选的题目加起来只有90分，必须给出提示。我见过不少项目这里没有校验，学生考完成绩统计总是对不上，后来查原因就是总分虚标。

3.4 在线考试、自动判分与成绩统计

在线考试模块是整个系统最需要谨慎的地方，核心在状态管理。

学生点击“开始考试”后，后端先创建一条exam_record，状态设为ongoing，记录start_time。答题时前端每保存一题就调用一次接口，后端把答案写入answer_record。交卷有两种入口：学生主动点击交卷，或考试时间到触发自动交卷。前端倒计时只是体验优化，负责在最后一秒提醒用户，真正的超时兜底逻辑必须在后端。

后端交卷方法要做的事：

1. 检查exam_record当前状态，如果已提交直接拒绝，防止重复提交。
2. 遍历所有answer_record，对客观题自动判分。
3. 累加客观题得分，主观题标记为待阅卷。
4. 更新exam_record状态和成绩字段。

客观题判分逻辑很直接：

String correct = question.getAnswer(); String studentAnswer = answerRecord.getStudentAnswer(); if ("single".equals(question.getType()) || "judge".equals(question.getType())) { boolean isCorrect = correct.equalsIgnoreCase(studentAnswer.trim()); answerRecord.setCorrect(isCorrect); if (isCorrect) { answerRecord.setScore(question.getScore()); } }

多选题的判分规则可以根据需要定义。常用的有“全对才得分”和“多选/漏选得一半分”两种。实际项目里，规则的定义应放在单独的类里，通过一个接口类定义判分策略，不同的题型用不同的实现。这样做的好处是后续如果要加不定项选择这类新题型，直接扩展实现类就行，不需要改动判分主流程。

成绩统计建议做三个维度：班级平均分、分数段分布、每题正确率。前端用ECharts展示柱状图和折线图，底部数据从后端统计接口读。统计SQL会有一些连表查询，建议用注解SQL或XML写清楚，别在Java代码里拼字符串SQL。

4. 开发过程中的那些坑与解决方法

4.1 时间与时区

时区问题几乎每个项目都会遇到。症状很典型：数据库存的时间比实际时间少8小时，或者前端拿到的时间是一个数组而不是字符串。

解决办法分三部分：

• MySQL连接串加上serverTimezone=Asia/Shanghai。
• 实体类时间字段统一用LocalDateTime，不要Date和LocalDateTime混用。
• 在application.yml里配置Jackson格式化，让LocalDateTime输出成字符串。

配置Jackson的写法：

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

这三个配置都设置好后，时间问题基本能一次性解决。

4.2 试卷快照与答案一致性

前面说快照设计专门打了一个伏笔，这里再展开。考试系统不能因为后台改题影响已经产生的成绩。我最初做的时候，answer_record里只存了question_id，交卷后从题库实时读题目解析和答案。后来老师考完修改了一道题的答案，“历史考试”的解析页面也跟着变了，数据完全对不上。

正确做法是在answer_record表里冗余存储题目内容、标准答案、题目分数。也就是快照。作答明细里看到的就是考试那一刻的试卷，跟题库里后来怎么改都无关。这是考试系统最核心的数据一致性设计，写文档时要着重讲。

4.3 POI的版本冲突

POI的版本冲突是导入功能最常见的报错源头。表现是运行时抛出NoSuchMethodError，排查起来比较费劲。原因通常是项目里同时存在多个org.apache.poi的间接依赖，版本不一致。

我的建议是：能用EasyExcel就尽量用EasyExcel，它内部把poi版本统一管理了，少操很多心。如果必须直接用POI，那就检查所有pom依赖里有没有引入多个不同版本的poi和poi-ooxml，只保留一个统一的版本。

4.4 分页插件与事务控制

MyBatis-Plus分页必须配置PaginationInnerInterceptor，否则page方法返回的数据不对，这是最常见的问题之一。很多同学写了分页代码但忘了注册插件，查出来的total永远是0，还以为是SQL写错了。配置方式很简单，在MyBatis配置类里添加一个MybatisPlusInterceptor Bean即可。

事务控制要重点放在交卷接口上。交卷和判分是一个整体操作，任何一步报错都必须回滚，不能让学生交了卷但成绩没有生成。方法上加上@Transactional，同时注意不要把耗时操作放在事务里。比如自动判分时循环里一条条更新数据库，整个事务时间会拉长。更优的做法是先循环判断结果，收集要更新的对象，最后统一调用updateBatchById批量更新，能明显缩短事务耗时。

5. 常见问题排查速查与项目扩展方向

5.1 常见问题速查表

5.2 生产级扩展方向

如果时间允许，这几个方向特别适合作为答辩和面试亮点：

• 防切屏功能：监听浏览器页面可见性变化，切屏超过设定次数后自动交卷或在后台标记异常记录。
• 题目顺序和选项随机：学生进入考试时，把试卷快照里的题目顺序、选项顺序打乱。这个功能做起来不复杂，但能从“防作弊”角度展示思考深度。
• Redis缓存热点试卷：把经常被学生同时访问的试卷缓存起来，减少数据库压力。
• 在线阅卷页面：为简答题提供评分界面，支持按得分点关键词快速给分。
• WebSocket强制收卷：教师可以实时推送收卷指令到在线考试的学生端。

这些扩展每一个都足够在答辩证里单独讲两分钟，而且实现难度可控。不要一上来就全部铺开，选一个做透就行。

我个人在实际操作中的体会是：做这类项目，最重要的一步是把数据库设计想清楚，特别是快照和状态字段。代码本身大多是对表数据的流转和加工，但如果你在设计阶段就预留好冗余字段、状态字段、时间字段，后面会遇到的问题至少减少一半。还有一点，最终交付时源码、数据库脚本和一份能按步骤跑起来的说明文档都要齐全。课程设计和毕业设计考察的，恰恰是你把完整流程想清楚并交付清楚的能力。

如果你正卡在某个模块上，优先看数据库设计和判分逻辑这两块，它们是最容易出现隐性bug、也最值得花时间打磨的地方。把这条主线跑通之后，这个项目能做到的深度，远不止一个普通的“系统开发”课设那么简单。