每年毕设季，在线考试系统都是Java方向的热门选题，SpringBoot版本基本成了标配。这个题目看着简单，但真正做到答辩不虚、代码不水，需要想清楚几个关键问题：组卷怎么做随机、考试过程中的计时与保存怎么保证不丢数据、答题卡交互如何兼顾流畅与准确。这篇内容就是围绕“Java在线考试系统的设计与实现”这个毕设题目展开，从需求拆分、表结构设计到核心代码实现，再到我实际踩过的一些坑，整体过一遍，适合正在做类似选题、或者想把系统做得更像落地产品的同学参考。
这个项目不复杂，但比单纯的CRUD系统多了一层“考试业务状态”的约束。比如考试开始后不能随意修改试卷，交卷之后成绩的幂等写入，学生断网重连后的进度恢复，这些都属于“看着不起眼、做起来要命”的点。把这些问题处理好了，项目质量和答辩加分完全不一样。
1. 项目整体设计与需求拆解
1.1 这个题目为什么值得做，难点到底在哪
很多人第一反应是：在线考试系统不就是题库、试卷、考试、成绩四张表，再加一个前端页面吗？如果只做到这一步，确实是个普通的增删改查项目。但为什么每年都有那么多同学挂在答辩上？因为老师会追问一些实际问题：随机组卷怎么保证不重复？多选漏选怎么判分？考试时间到了没交卷怎么处理？
这些追问背后的核心就是“状态管理”和“边界条件”。在线考试系统本质上是一个带时间约束、带并发写入、带权限隔离的业务系统。学生答题、老师组卷、管理员管用户，三种角色的行为都作用在同一套数据模型上，必须把角色权限、数据状态、业务流程串起来，系统才能真正跑通。
1.2 角色划分与功能矩阵
我设计系统时，把用户分成三种角色：学生、教师、管理员。不要搞得太多，毕设阶段三种角色已经足够展示你对RBAC权限模型的理解。
| 角色 | 核心功能 | 说明 |
|---|---|---|
| 学生 | 在线考试、查看成绩、考试记录 | 最关键的是考试过程中的体验与数据安全 |
| 教师 | 题库维护、组卷、创建考试、阅卷 | 技能点是理解“试卷模板”与“具体试题”的区别 |
| 管理员 | 用户管理、数据概览 | 负责最基础的账号维护与系统整体情况 |
这三种角色的需求是递进的：学生看到的是考试页面，教师管理的是题与卷，管理员看的是人和全局。设计时不要把三种角色的逻辑混在一起，服务层接口按角色分开，代码会清爽很多，答辩时也方便讲。
1.3 技术选型：为什么是SpringBoot这套组合
这个题目最稳妥的技术组合是：后端SpringBoot + MyBatis-Plus + MySQL，前端Vue + Element UI，前后端分离。如果你对前端不熟，也可以直接改用Thymeleaf做服务端渲染，工作量更小，但答辩时技术亮点会少一些。
为什么不建议用传统的SSM？SSM本身没有问题，但SpringBoot把配置简化太多了。同样是写一个接口，SSM要配置web.xml、spring-mvc.xml、spring-dao.xml，SpringBoot一个启动类就搞定。毕设时间本来就紧，把精力放在业务逻辑上更划算。
JWT和Session怎么选？如果做前后端分离，我建议用JWT。它天然适合跨域场景，也方便做登录拦截。Session的话要考虑分布式Session问题，毕设单机部署虽然够用，但从设计上讲JWT更贴合这种接口化架构。Spring Security对毕设来说偏重，我最终选择了JWT + 拦截器的方式，代码量少，讲起来也直观。
2. 数据库设计与表结构规划
2.1 核心表与字段定义
表结构是整个系统的地基。我的实际设计是六张核心表：用户表、试题表、考试表、试卷表（考试与试题的关联）、答卷表、答题明细表。
先看用户表，字段不用多，够用就行：
| 字段 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| username | varchar(50) | 登录名，唯一 |
| password | varchar(100) | BCrypt加密后的密码 |
| real_name | varchar(50) | 姓名 |
| role | varchar(20) | student / teacher / admin |
| create_time | datetime | 创建时间 |
注意password字段长度至少要60以上，因为BCrypt加密结果长度是60，很多同学设成32位，注册就疯狂报错。
试题表是题库管理的核心，重点在于区分题型和保存题目内容：
| 字段 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| question_type | tinyint | 1单选 2多选 3判断 4简答 |
| content | text | 题干 |
| option_a / option_b / option_c / option_d | varchar(255) | 四个选项 |
| answer | varchar(50) | 正确答案 |
| analysis | text | 答案解析 |
| difficulty | tinyint | 1容易 2中等 3困难 |
| category_id | bigint | 所属知识点分类 |
| create_by | bigint | 创建人（教师） |
判断题我一般把题干放在content里，answer字段存“T”或“F”，不用额外存选项。简答题没有ABCD选项，四个选项字段留空即可，answer字段存参考答案，阅卷时由教师人工判断。
考试表负责一场考试的整体信息：
| 字段 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| title | varchar(100) | 考试名称 |
| start_time | datetime | 开始时间 |
| end_time | datetime | 结束时间 |
| duration | int | 考试时长（分钟） |
| total_score | int | 总分 |
| pass_score | int | 及格分 |
| status | tinyint | 0未发布 1进行中 2已结束 |
| create_by | bigint | 创建教师 |
这里有一个关键逻辑：一场考试可以包含多道试题，一道试题也可以出现在多场考试里，所以需要一张中间表。我命名为exam_paper，每行代表“某场考试中的某道题及该题分值”。
2.2 答卷类表：记录考试轨迹的关键
学生参加了哪场考试、答了什么题、得了多少分，不能只存一个最终成绩。我设计了exam_record和exam_record_detail两张表。
exam_record存一次考试的总体记录：
| 字段 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| exam_id | bigint | 考试ID |
| user_id | bigint | 学生ID |
| start_time | datetime | 实际开始时间 |
| submit_time | datetime | 提交时间 |
| score | decimal(5,1) | 最终得分 |
| status | tinyint | 0考试中 1已交卷 2缺考 |
exam_record_detail存每一道题的作答明细：
| 字段 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| record_id | bigint | 答卷ID |
| question_id | bigint | 试题ID |
| my_answer | varchar(500) | 学生答案 |
| is_correct | tinyint | 0错误 1正确 |
| score | decimal(5,1) | 该题得分 |
这套设计的好处是：成绩统计、题目正确率分析都可以从明细表里直接查出来，后期扩展“知识点掌握度分析”功能也不用改表结构。
2.3 数据库设计中的三个细节
第一，所有业务表都要加create_time，但不要滥用逻辑删除。做过一套系统你就知道，把题目物理删掉之后，历史试卷上的题目就变成空白了。我采用逻辑删除，加一个deleted字段，查询时统一过滤，既保证历史数据可追溯，又不用搞复杂的数据库外键。
第二，时间字段统一用datetime，Java端实体用LocalDateTime。如果在字段上加@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")，前端接收到的才是格式化后的字符串，不然你会发现Vue页面上时间显示成一段数字，还得自己格式化。
第三，成绩字段用decimal(5,1)，不要用int。多选和简答可能产生半分，如果用int，0.5分的题就没法判了。
3. 核心功能实践与关键代码
3.1 登录鉴权：JWT + 拦截器的组合
用户表里role字段是权限标识，但接口层面怎么限制学生不能调教师接口？我的做法是自研一个轻量级注解校验，核心思路是：登录成功签发JWT，前端每次请求把它放在Header里，后端写一个拦截器统一解析，再配合注解检查角色。
先看JWT工具类的核心逻辑。我用的JWT版本是0.9.1，过期时间设置成2小时。这里注意，不要写死签名密钥硬编码在代码里，放配置文件就行：
@Component public class JwtUtil { @Value("${jwt.secret}") private String secret; @Value("${jwt.expire}") private long expire; public String createToken(Long userId, String role) { return Jwts.builder() .claim("userId", userId) .claim("role", role) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + expire)) .signWith(SignatureAlgorithm.HS256, secret) .compact(); } public Claims parseToken(String token) { return Jwts.parser().setSigningKey(secret).parseClaimsJws(token).getBody(); } }拦截器的主要职责是解析Token并把用户信息放到ThreadLocal里，方便后续Controller直接获取当前用户。
public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (token == null || token.isEmpty()) { throw new BusinessException(401, "未登录"); } Claims claims = jwtUtil.parseToken(token.replace("Bearer ", "")); UserContext.set(claims.get("userId", Long.class), claims.get("role", String.class)); return true; } }角色校验我通过自定义注解+拦截器实现。定义@RequireRole注解，拦截器里读取HandlerMethod上的注解，再比对当前用户角色：
if (handler instanceof HandlerMethod) { RequireRole requireRole = ((HandlerMethod) handler).getMethodAnnotation(RequireRole.class); if (requireRole != null && !requireRole.value().contains(role)) { throw new BusinessException(403, "无权限访问"); } }这个方案比Spring Security轻量，而且面试时能讲清楚每个环节的原理，不容易翻车。
3.2 随机组卷算法：怎么抽才能不重复、不偏科
组卷是教师端的核心功能。教师创建考试时，需要选定题型分布和难度比例，系统从题库里随机抽题。最粗暴的做法是纯随机，但纯随机可能导致一张卷子全是简单题，或者知识点高度重复。
我的思路是“按分组配额随机抽取”。教师配置组卷规则时，可以指定：
- 单选题10道，每题4分，其中容易3道、中等5道、困难2道
- 多选题5道，每题6分，其中中等3道、困难2道
- 判断题10道，每题1分，不限定难度分布
- 简答题2道，每题10分，限定困难等级
服务端实现时，先用一个分组查询，把满足条件的题目ID列表全部查出来，然后根据该组的抽题数量，对ID列表做随机打乱，取前N个。这里有一个最常见的坑：同一道题可能同时满足多个分组条件，比如一道“Java并发”的题，它既是多选又是困难题，如果直接按分组抽，可能会被抽进两道不同分组，导致一张试卷里出现重复题目。
规避方法是我最终抽选结果放入一个全局的题目ID集合，每抽完一组就检查是否已存在，存在则重新从池子里补充抽取。如果你用的是MySQL，还可以考虑ORDER BY RAND() LIMIT N，但题量一大性能会差，我建议还是先查ID再在内存里洗牌。
组卷完成之后，把“考试ID + 题目ID + 题目分值”批量插入exam_paper表。注意批量插入时使用批量SQL语句，不要一条条insert，否则几百道题会插入几百次，性能难看。
3.3 考试计时与自动交卷：前端倒计时与后端校验
在线考试最怕的就是时间上出问题。学生开始考试时，点击“开始考试”，后端生成exam_record记录，写入start_time。考试结束时间不是简单拿服务器当前时间加duration，而是用start_time + duration计算deadline。
前端拿到考试信息后，用setInterval做分钟和秒的倒计时。为了防刷新导致倒计时重置，我把deadline时间戳存到localStorage里，页面重新加载后先读取localStorage里的剩余时间，再启动倒计时。
自动交卷的后端逻辑才是重点。学生可能关闭浏览器、断网，服务器不能依赖前端主动交卷。我的做法是一套状态校验：
@Scheduled(fixedRate = 60000) public void autoSubmitExpiredExams() { // 查询所有status=0（考试中）且当前时间大于deadline的考试记录 List<ExamRecord> records = examRecordMapper.selectExpiredRecords(LocalDateTime.now()); for (ExamRecord record : records) { // 未提交的自动交卷，计算客观题得分 submitExam(record.getId()); } }定时任务作为兜底，前端倒计时到0时也会主动调用交卷接口，二者并不冲突。学生主动交卷时，后端检查当前时间是否早于deadline，如果已经超时，以deadline为准强制交卷，防止客户端时间被恶意改慢以后延长时间。
交卷接口的幂等性也要考虑。比如连续点击两次交卷，第二次请求应该直接返回第一次的结果，而不是再算一遍成绩，否则成绩可能被覆盖。我的实现是在exam_record里增加一个status字段，交卷之前先比对status，只有“考试中”状态才允许执行交卷逻辑，交卷后立刻把status更新为“已交卷”。
3.4 自动阅卷：客观题核心逻辑与主观题人工兜底
阅卷分两类：客观题（单选、多选、判断）系统自动判分，主观题（简答题）由教师人工阅卷。自动判分不能写成一堆if-else，我把判分策略封装成一个接口，不同题型的策略分开实现：
public interface ScoreStrategy { BigDecimal calculateScore(String correctAnswer, String userAnswer, BigDecimal questionScore); }单选和判断的处理很简单，比对字符串是否完全一致，一致得满分，不一致得0分。多选题要复杂一点，我的策略是：答案完全一致得满分；多选或漏选得0分。如果你希望漏选给半分也可以配置，但毕设答辩时老师更喜欢“规则清晰”的方案，我采用的原则是“全对才得分”。
public class MultiScoreStrategy implements ScoreStrategy { @Override public BigDecimal calculateScore(String correctAnswer, String userAnswer, BigDecimal questionScore) { // 正确答案标准化：如 "A,B,C"，排序后比较 if (normalize(correctAnswer).equals(normalize(userAnswer))) { return questionScore; } return BigDecimal.ZERO; } }简答题的初始得分为0，交卷后exam_record的状态变为“待批阅”，教师在教师端可以逐份批改。批改完成后成绩更新到exam_record_detail，同时汇总回exam_record的score字段。
4. 前端页面与交互体验
4.1 页面结构与路由划分
前端我用Vue2 + Element UI，路由按角色分块。登录页是独立的，登录成功后根据角色跳转到不同的首页。学生端路由包括考试列表、答题页、考试记录、成绩查询；教师端是题库管理、组卷、考试管理、阅卷管理；管理员端是用户管理和系统概览。
整体页面数量不需要太多，大约15个左右的Vue组件就足够了。关键是把Axios的封装做好，统一处理Token和错误码。我在request拦截器里给每个请求追加Authorization头，在response拦截器里统一处理401跳登录、403提示无权限，这样每个页面不用重复写错误处理逻辑。
4.2 考试答题页：答题卡、标记与自动保存
考试页是前端工作量最大的部分，也是体验好坏的关键。我先说布局：左侧是答题卡面板，展示所有题目题号和“已答/未答/标记”三种状态；中间是题目区域，支持上一题/下一题切换；顶部是考试标题和倒计时。
答题卡状态用颜色区分，已答题目标记为蓝色，未答题目标记为灰色，做了标记的题目标记为橙色。这个逻辑不复杂，用examRecordDetail的作答状态就能算出来。关键是要在切题时实时更新状态，比如学生切到下一题，当前题目的答案存到本地state里，同时答题卡颜色立刻变化。
自动保存我用的是watch + debounce。每当答案变化，前端先更新本地状态，然后定时器每隔30秒把当前所有未提交答案批量提交到后端临时保存接口。这样即使学生误关了浏览器，再次打开也能从服务端恢复答题进度。
这里有一个细节：临时保存和正式交卷的接口要分开。临时保存更新的是exam_record_detail里的my_answer字段，但不参与判分；正式交卷才触发判分逻辑。如果临时保存直接触发判分，学生中途改了答案，成绩也会跟着变，逻辑就乱了。
4.3 跨域与时间格式这些联调细节
前后端分离必然遇到跨域问题。我前后端联调时踩过不少坑，所以这里单独说。后端要配置CORS，前端开发环境配proxy。生产部署时，前端build产物可以直接丢进SpringBoot的static目录，就不会有跨域问题了。
时间格式的问题是前端最容易忽视的。后端返回LocalDateTime默认会被Jackson序列化成数组或时间戳，必须统一给LocalDateTime字段加@JsonFormat注解，前端才能正常展示。我在项目里是写了一个Jackson全局配置类，注册JavaTimeModule并设置格式，这样以后加任何实体类都不用再单独处理时间字段。
5. 常见问题排查与避坑指南
5.1 同一道题被抽两次，组卷结果有重复
这个问题前面提过。排查时先查exam_paper表，你会发现同一道题的记录出现在同一场考试里。原因是多组抽题时没有交叉去重。我的修复是在内存里维护一个Set存储已选题目ID，每组抽取后立即放入Set，下一次抽题时先从候选列表里排除Set中已有的ID，再随机选。这属于典型的“思路简单但容易漏”的问题，答辩前一定要自测多组条件组合。
5.2 学生交卷后成绩一直不显示
最常见的原因不是判分逻辑出问题，而是事务没提交。批量判分时，如果中途出现异常，整个事务回滚，但前端已经提示交卷成功了，成绩就变成空。我的建议是：交卷接口用@Transactional，把“更新状态 + 逐题判分 + 汇总总分”放在同一个事务里，同时在判分前先校验exam_record的status，防止重复计算。还有一个场景是定时任务自动交卷和主动交卷并发执行，这时要用乐观锁。我在exam_record表加version字段，update时带where version = ?，更新成功才说明抢到交卷权限。
5.3 数据库时间与服务器时间相差8小时
这个坑几乎是必踩。MySQL连接的url里加上serverTimezone=Asia/Shanghai，同时Jackson序列化时设置时区为GMT+8。如果还是没有生效，检查MySQL数据库本身的时间默认值。我一般推荐在Java端统一处理，数据库整体用UTC，展示时再转北京时间。不过毕设答辩更倾向于直接看到北京时间，所以最简单的方法是连接串写死Asia/Shanghai，实体类字段全用LocalDateTime，基本不会出问题。
5.4 学生考试中断网、刷新的恢复方案
很多同学只做了“断网提示”就结束了，实际上它会成为老师追问的重点。我的做法是考试中每30秒自动保存一次作答记录到服务端，页面加载时先查有没有“考试中”状态的记录，有的话弹窗提示“是否继续上次考试”，确认后恢复数据。恢复时把已提交的题目答案回填到答题卡中，倒计时仍以服务端deadline为准。这样即使学生换了一台电脑，只要登录同一账号，也能继续考试。
5.5 项目管理与答辩演示建议
最后聊点项目管理方向的内容。这类系统代码量不小，建议从第一天就用Git管理，每次完成一个模块就提交一次，写清楚commit信息。答辩演示时，不要直接展示代码，而是先跑通一条完整流程：教师建题库、组卷、发布考试，学生参加考试并交卷，教师阅卷，学生查看成绩。这条流程能走通，系统就算闭环了。
顺带说一句，在线考试系统的题库和组卷逻辑非常值得扩展。如果答辩时间充裕，可以给组卷规则加上“知识点权重”，或者给成绩统计加一个“错误率最高题型Top5”的可视化图表。这些扩展点都是在同一套表结构上做的，不需要重新设计数据库，性价比很高。我个人实际做完这个项目后的体会是：像这种业务链路完整、边界场景多的题目，反而是容易做出区分度的毕设，关键不是把功能堆得多高，而是把每个“如果学生……怎么办”想清楚。你愿意在这些细节上多花几小时，答辩时就能少很多被动。
