在线考试系统课设实战：Spring Boot状态机与倒计时安全设计-代码聚汇网

在线考试系统课设实战：Spring Boot状态机与倒计时安全设计

菲律宾梁朝伟·2026-09-26·阅读 24 GEO检测（免费）

在线考试系统Spring Boot状态机

|难度：普通|阅读约 33 分钟

1. 先想清楚：这个课设到底要展示什么

最近帮几个学弟学妹看课程设计代码，“在线考试答题管理系统”几乎是 Java Web 方向默认选题。但说实话，十份代码里能让我觉得“可以拿去答辩”的，大概只有两三份。不是功能太少，而是很多同学把课设写成了一个“管理系统”——用户增删改查、角色权限、界面换皮做得很勤快，唯独考试本身的核心链路（答题、计时、判分、交卷）做得稀碎。

这个问题很典型。课程设计跟企业项目最大的区别，是它有一个非常明确的展示窗口：演示时老师会站在旁边看你操作。如果演示仅仅是从列表点到详情，从A页面跳到B页面，老师心里只会有一个印象——“这不就是个CRUD吗？”反过来，如果能在演示中看到一套真实可用的考试流程，有状态流转、有时序约束、有异常兜底，哪怕界面朴素一点，也能给你很高的评价。

所以动手写代码之前，先确定这个项目的边界。我的建议是列一张表，把“必做”和“不做”写清楚：

必做模块	功能说明
登录与角色区分	学生 / 教师两类角色，权限不同
题库与试卷管理	教师录入题目，组建试卷，配置分值
在线考试流程	学生进入考试、答题、倒计时、交卷
自动判分与成绩查看	客观题自动判分，学生查看分数
考试状态管理	未开始、进行中、已交卷、已判分

不做（课设阶段）	原因
复杂随机组卷算法	消耗大量时间，且答辩时很难在几分钟内展示清楚
主观题智能批改	需要引入算法模型，超出课设范畴
大规模高并发架构	单机 + 数据库足够，过度设计反而难解释
学情分析图表	看着炫，但对核心链路帮助不大，最后两天有空再加

我的经验是：课设的分数天花板，取决于“核心链路是否完整闭环”，而不是功能数量。 一个能跑通“创建试卷 -> 学生进入考试 -> 倒计时归零自动交卷 -> 客观题判分 -> 成绩回显”的项目，比一个做了八个模块但相互不联通的项目高出一个档次。

整体数据流其实很清晰：

教师登录系统，录入题目，创建一张试卷，设置考试时长和开始/截止时间。
学生登录后，在“可参加的考试”列表里看到这张试卷，点击开始考试。
服务端生成一条考试记录（Attempt），初始化状态为“进行中”。
学生逐题作答，前端实时把答案保存到服务端；倒计时由服务端时间戳驱动。
学生主动交卷，或倒计时归零系统强制交卷。
服务端根据试卷配置的判分规则，对客观题自动评分，生成成绩单。
学生端查看成绩，教师端可以查看考试统计和参加名单。

这条链路里，最容易出问题的不是哪个接口复杂，而是“状态一致性”。比如学生刷新页面后能不能继续考试、到点之后服务端怎么处理还在答题的会话、交卷瞬间发生了什么。这些才是真正值得花时间的点。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 技术选型：别追求“最先进”，追求“能解释”

技术选型这件事，很多同学容易走极端。要么用自己在学校刚学的基础Servlet+JSP，要么反过来堆一堆微服务组件。我的建议是走进阶但不激进的主流组合：Spring Boot + MyBatis-Plus + MySQL + Redis + Vue 3 + Element Plus。这套组合有几个非常明确的优势。

2.1 后端为什么选 Spring Boot

课程设计答辩时，老师大概率会问“为什么选这个框架”。Spring Boot 的回答成本最低：它基于 Spring 生态，自动配置简化了传统 SSM 的大量 XML 配置，内嵌 Tomcat 让部署变得简单，社区资料也是所有框架里最多的。

如果后端用原生 Servlet，代码能跑，但是业务稍微复杂一点就会陷入大量重复模板。比如考试记录状态更新、判分逻辑、异常处理，每写一个接口都要处理请求解析、参数校验、事务边界，时间全耗在非核心逻辑上。Spring Boot 的 @RestController、@Service、@Transactional 把这些问题收敛得很干净。

2.2 ORM 选 MyBatis-Plus 的理由

纯 MyBatis 需要自己写大量 XML 映射，考试系统里嵌套查询、动态更新的场景不少，写起来繁琐。MyBatis-Plus 在 MyBatis 基础上内置了通用的 BaseMapper，单表 CRUD 不用写 SQL，多表查询再自己写 XML。对课设来说，它的查询条件构造器 QueryWrapper 和分页插件 PaginationInnerInterceptor 能省下大量时间。

当然，这不是说 JPA 不行。只是对大多数课设选题来说，MyBatis-Plus 的“SQL 可控 + CRUD 自动”平衡得比较好，出了问题更容易定位。

2.3 前端框架的选择逻辑

Vue 3 + Element Plus 在课设里几乎是“标准答案”。Element Plus 自带表格、表单、弹窗、消息提示、倒计时组件，能快速搭建管理端界面。Vue 3 的组合式 API（Composition API）比 Vue 2 的选项式更适合组织复杂交互：答题状态、倒计时、切屏监听这些逻辑，用 ref 和 reactive 管理起来很直观。

如果不会微前端、Vite 等新特性，其实不影响课设效果。前端框架的核心作用是快速产出可交互页面，而不是秀工具。

2.4 中间件：MySQL 负责持久化，Redis 负责临时状态

MySQL 存三类数据：用户、题库/试卷、考试记录。Redis 不是必须的，但引入之后有两个场景特别好用：

缓存答题中间态：学生每答一题，就同步存一份到 Redis，用考试记录ID做 Key，刷新页面不丢数据。
缓存可参与考试列表：首页读取学生可参加的考试时，如果每次都实时查数据库做一大堆时间判断，压力不小；用 Redis 缓存一下，5分钟过期，性能提升明显。

有的同学会担心 Redis 没学过，其实课设阶段只需要用到 String 和 Hash 两种结构，调用 set / get / expire 就够了。真要在答辩时被问到，就解释清楚“为什么把临时答题状态放 Redis 而不是数据库”——因为答题过程是高频率读写的，放数据库会频繁 update 同一行记录，增加锁竞争和磁盘 IO；Redis 基于内存，适合这种短期高频的中间状态，交卷后再把最终答案批量化写入数据库。

这里补一句选型心得：答辩时，老师更认可“知道我选它是因为什么”的候选人，而不是“我用它因为它流行”的候选人。 所以每个关键选型都准备一句话理由，比背十个框架特性有用得多。

3. 数据库设计：五张核心表和一条状态机

在线考试系统的数据模型不复杂，但有很多细节容易踩坑。我设计的是五张核心表：用户表（user）、试卷表（exam）、试题表（question）、考试记录表（attempt）、答题明细表（answer）。下面重点说后三张。

3.1 试卷与试题：选项和答案分离的表结构

试卷表和试题表是父子关系。试题表里不能直接存“正确答案”，因为一张试卷可以被不同的老师复用（虽然是课设，也要留出设计余地）。更关键的是，科目和难度不一定是固定枚举，如果写死在代码里，后续维护就是灾难。我一般把“标准答案”放在一张独立的选项表里，或者至少把题干、选项、答案拆成清晰的字段。

一张实用的 question 表结构大致如下：

sql复制CREATE TABLE `question` (
  `id`          BIGINT       NOT NULL AUTO_INCREMENT,
  `exam_id`     BIGINT       NOT NULL COMMENT '所属试卷ID',
  `q_type`      TINYINT      NOT NULL COMMENT '题型：1-单选，2-多选，3-判断',
  `content`     TEXT         NOT NULL COMMENT '题干',
  `options`     JSON         NULL COMMENT '选项列表：[{"key":"A","text":"..."}]',
  `answer`      VARCHAR(32)  NOT NULL COMMENT '正确答案，多选用逗号分隔，如A,B,C',
  `score`       INT          NOT NULL DEFAULT 0 COMMENT '分值',
  `sort_no`     INT          NOT NULL DEFAULT 0 COMMENT '题目顺序',
  PRIMARY KEY (`id`),
  KEY `idx_exam_id` (`exam_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

注意这里的 answer 字段，单选存一个字符，多选存 A,B,C 字符串。设计成字符串而不是 JSON，是为了判分时便于拆分比对。选项用 JSON 存，前端渲染时直接解析，后端不关心 UI 细节。

3.1.1 为什么正确答案不能直接放在题目列表的返回结果里

这是很多课设作者第一个踩坑点。如果把 answer 字段一并通过查询接口返回给前端，学生用浏览器 F12 就能看到所有答案，考试直接失去意义。所以查询试卷题目时，要单独写一个 VO（视图对象），里面只包含题干、选项、题型、分值，不包含正确答案。判分只能在服务端完成，答案永远不下发到浏览器。

3.2 考试记录表：体现状态设计的关键表

考试记录表（attempt）承载的是“一场考试的进行状态”。每个学生进入一场考试，就插入一条记录，所有后续操作都围绕这条记录的状态展开。

sql复制CREATE TABLE `attempt` (
  `id`          BIGINT       NOT NULL AUTO_INCREMENT,
  `exam_id`     BIGINT       NOT NULL,
  `student_id`  BIGINT       NOT NULL,
  `start_time`  DATETIME     DEFAULT NULL COMMENT '实际开始时间',
  `end_time`    DATETIME     DEFAULT NULL COMMENT '实际交卷时间',
  `deadline`    DATETIME     NOT NULL COMMENT '应该交卷的截止时间',
  `status`      TINYINT      NOT NULL DEFAULT 0 COMMENT '0-待开始，1-进行中，2-已交卷，3-已判分',
  `score`       INT          DEFAULT NULL COMMENT '最终得分',
  `version`     INT          NOT NULL DEFAULT 0 COMMENT '乐观锁版本号',
  `create_time` DATETIME     DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  KEY `idx_student_exam` (`student_id`, `exam_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

deadline 字段很重要。它代表“这场考试必须交卷的时间点”。学生进入考试时，服务端根据试卷设置的时长计算 deadline = now + duration。后面判断是否超时、倒计时归零自动交卷，都以这个字段为准。

3.2.1 状态机的定义与流转

我把状态定义成四个：待开始（0）、进行中（1）、已交卷（2）、已判分（3）。流转规则如下：

学生点击“开始考试”：插入一条 attempt 记录，status = 1，start_time = now，deadline = now + duration。
学生点击“交卷”：status 从 1 变成 2，end_time = now。
系统自动交卷：倒计时归零后，后台任务把 status = 1 且 deadline < now 的记录统一更新为 2。
判分完成：status 从 2 变成 3，score 写入字段。

这个状态机的好处是：任何时刻只要查一下 status，就能知道当前记录处于哪个阶段，前端按钮显示、后端接口行为都由它驱动。比如“重新进入考试”的判断逻辑就是——如果 attempt 状态是 2 或 3，说明已经交卷，不能再答题；如果状态是 1 且 deadline 还在未来，说明上次考试还没结束，应该恢复之前的答题进度，而不是重新生成记录。

3.3 答题明细表：存储每一次作答

答题明细表（answer）用来保存学生在某张试卷里对每一道题的作答。它和 attempt 是多对一关系。

sql复制CREATE TABLE `answer` (
  `id`          BIGINT      NOT NULL AUTO_INCREMENT,
  `attempt_id`  BIGINT      NOT NULL COMMENT '考试记录ID',
  `question_id` BIGINT      NOT NULL COMMENT '题目ID',
  `stu_answer`  VARCHAR(32) DEFAULT NULL COMMENT '学生作答，多选用逗号分隔',
  `correct`     TINYINT     DEFAULT 0 COMMENT '是否判对：1-对，0-错',
  `score`       INT         DEFAULT 0 COMMENT '本题得分',
  PRIMARY KEY (`id`),
  KEY `idx_attempt` (`attempt_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这道表在交卷时自动判分后回填 correct 和 score 字段，便于后续统计和展示。

3.3.1 中途答题记录要不要每次都写数据库

最初的方案是学生每答一题就 INSERT INTO answer，答错了再 UPDATE，交卷时再统一查出来判分。这在单用户课设环境下没问题，但有一个隐患：如果数据库事务处理不好，刷新页面时可能出现“有些题存了，有些题没存”的中间状态。更稳妥的方案是：答题过程中的中间态只放 Redis，交卷时批量落库。每次作答，直接覆盖 Redis 里 attempt:{id} 的整个答案 Map，交卷时一次性遍历写入数据库。这样做有两个好处：一是快，二是交卷时的数据一定是一致的，不会出现写了一半的脏数据。

4. 核心功能落地：判分、倒计时、防作弊与断点恢复

框架搭完，真正的难点集中在四个功能点上，每个单独说。

4.1 自动判分的实现逻辑

自动判分只针对客观题，三种题型三种策略：

单选题：学生答案与标准答案完全一致，得满分；否则 0 分。
判断题：和单选一样，本质上也是二选一。
多选题：方案很多。课设采用最简单的“全对才得分”：学生答案与标准答案按集合比较，完全一致才给分。如果想加区分度，可以设计成“漏选得一半分，错选得 0 分”，这需要在代码里单独写规则。

判分的关键是对答案做规范化处理。学生提交的答案可能是 "a,b,c"、"A B C"、"abc" 这种乱七八糟的格式，统一处理成大写后按逗号分割、排序，再和标准答案比较。用集合比较而不是字符串比较，能避免 "A,B" 和 "B,A" 这种顺序不一致导致的误判。

判分逻辑放在 Service 层的独立方法里，不要在 Controller 里写：

java复制public void gradeObjectiveQuestions(Long attemptId) {
    List<Answer> answers = answerMapper.selectList(
        new LambdaQueryWrapper<Answer>().eq(Answer::getAttemptId, attemptId));
    for (Answer answer : answers) {
        Question question = questionMapper.selectById(answer.getQuestionId());
        String std = normalizeAnswer(question.getAnswer());
        String stu = normalizeAnswer(answer.getStuAnswer());
        boolean correct = std.equals(stu);
        answer.setCorrect(correct ? 1 : 0);
        answer.setScore(correct ? question.getScore() : 0);
        answerMapper.updateById(answer);
    }
}

为什么判分必须走服务端而不是前端？原因刚才已经提到：答案字段不能下发到浏览器。前端只负责收集用户选择的选项 Key，提交后由服务端统一判分。这也是答辩时一个很好的提问点，主动在代码注释里写清楚可以加分。

4.2 倒计时：前端只做展示，后端才有裁判权

倒计时是考试系统里最容易引起纠纷的功能。我的原则是：前端倒计时永远只是用来展示，真正的超时判定必须依赖后端时间戳。

实现方式是：进入考试时，后端在 attempt 表写入 deadline 字段；前端发起考试请求时，接口返回 startTime 和 deadline。前端用一个本地定时器每秒计算 deadline - now，然后渲染到页面上。交卷接口调用时，后端再次校验当前时间是否超过 deadline——如果超过了，不接收答题数据，直接按超时自动交卷处理。

这里有个深坑：不能用前端定时器累加来生成倒计时。浏览器切后台后，定时器会被节流甚至挂起，用户从后台切回来时可能发现倒计时根本没走。另外，如果用户改了系统时间，或者页面长时间挂机，本地倒计时就会失真。所以每次渲染倒计时，都用 Date.now() 减去截止时间，而不是递减一个计数器。

扫描关卷的兜底逻辑有两层：

交卷请求到达后端时，统一判断 now > deadline。
定时任务每30秒扫描一次未交卷且超时的 attempt 记录，自动标记为超时交卷，再触发判分。

有了这两层，即使学生一直不交卷、直接把页面关掉，成绩也不会丢。

4.2.1 “还剩最后30秒”的处理细节

最后 30 秒是交卷冲突的高发区。如果前端在每次倒计时变化时都向后端发请求，比如“还剩29秒”“还剩28秒”，这个设计很烂——纯属浪费资源。正确做法是：只在页面进入后台/回到前台这两个时机向后端同步一次时间，或者每隔 10 秒做一次轻量校验。前端倒计时可以继续走本地展示，以保证 UI 流畅，但真正的准不准，还是以服务端为准。

4.3 题目乱序和选项乱序：让作弊成本变高

课设阶段做防作弊，不需要上人脸识别、摄像头监控那套，性价比最高的手段是“打乱顺序”。每次学生进入考试时，后端把题目顺序随机打乱，题目内部的选项顺序也随机打乱。

具体实现不复杂：

查询题目列表，在内存中用 Collections.shuffle() 打乱。
每个题目的选项 List 也用随机算法重排，同时更新选项的 Key。
前端渲染时，用打乱后的顺序展示。
判分时，仍然根据题目 ID 去数据库查标准答案，不受展示顺序影响。

这里要注意，乱序操作必须在每次进入考试时重新执行，而不是在创建试卷时执行一次。这样才能保证同一个学生每次刷新看到的顺序都不一样。随手做一个“题目快照”是另一种做法：在 attempt 表或者 Redis 里记录本次考试题目的展示顺序和选项顺序。不过课设阶段，只要每次进入考试重新 shuffle 并在 Redis 里保存一份即可。

4.4 切屏警告：效果大于功能

切屏检测很简单，前端监听 document.visibilitychange 和 window.blur，一旦页面失去焦点就记录一次“切屏事件”，弹出一个警告提示。后端在 attempt 表加一个 violation_count 字段，每次切屏由前端上报，后端累加。超过三次，在教师端考试统计里标红。

这个功能我不建议做成“切屏超过三次自动交卷”。原因很现实：有的学生不是故意切屏，可能是电脑弹了个通知、误触了快捷键。课设阶段，做成“记录 + 警告 + 教师可见”就够了，既展示了防作弊意识，又避免误伤真实使用者。

4.5 断点恢复：刷新页面不能丢进度

很多课设在“学生刷新页面后，考试进度全部丢失”这个场景上翻车。解决方案已经在 3.3 节说过：答题中间态放 Redis，而不是前端内存。每答一题，前端就把答案数组整体写入 Redis，Key 为 attempt:{attemptId}，结构上可以是一个 JSON 字符串，也可以是一个 Hash。学生刷新页面或重新登录后，调用“恢复考试”接口，后端从 Redis 里取出答案，回传给前端渲染。

如果担心 Redis 数据丢失（宕机），也可以在每次作答时同步写一条 answer 记录到数据库，但那样会频繁触发数据库更新。综合来看，课设阶段 Redis 完全够用，只要在交卷时把 Redis 的答案整体刷入数据库就行。

5. 踩坑实录：课设阶段的真实排查链路

本以为功能写完就大功告成，但实际部署和测试时连续踩了三个坑，每一个都值得拿出来说说。

5.1 坑一：最后几秒交卷，答题记录丢失

现象是：学生卡在倒计时归零时点击交卷，页面提示“交卷失败”，或者交卷后成绩缺失。排查过程如下：

先看服务端日志，发现交卷接口报了 DuplicateKeyException。答案明细表的主键冲突？有点奇怪。
进一步看代码，发现交卷接口在判断超时时会先调用一次“自动交卷”逻辑，把 attempt 状态改成“已交卷”，然后判分；与此同时，前端也发起了一次交卷请求，两条路径同时执行了。因为判分逻辑会先删除旧 answer 再插入新 answer，两条线程同时操作就撞了主键。
根因是状态流转没有并发保护，交卷操作不是幂等的。

修复方案是给 attempt 表加 version 字段做乐观锁。交卷时更新 SQL 带上版本号条件：

java复制int rows = attemptMapper.update(null, new LambdaUpdateWrapper<Attempt>()
    .eq(Attempt::getId, attemptId)
    .eq(Attempt::getStatus, 1)          // 只能是进行中状态才能交卷
    .eq(Attempt::getVersion, version))   // 版本号匹配才更新
    .set(Attempt::getStatus, 2)
    .set(Attempt::getVersion, version + 1);

rows 等于 0 说明并发下已经被其他请求抢占了，当前请求直接返回“已交卷”，不再执行重复判分。这样就把交卷操作做成了幂等。

经验是：任何涉及“状态变更”的接口，都要考虑“如果用户连点两次会怎样”。 加状态条件 + 乐观锁，是课设里最优雅的解决方案。

5.2 坑二：考试中途 F5 刷新，答题进度消失

这个现象前面已经埋了伏笔。最开始我实现的是“前端内存 + 最后统一提交”，所有答案都存在 JavaScript 变量里，刷新页面就全部回到初始状态。学生如果有事离开电脑，回来刷新一下就等于白考了。

排查思路很简单：问题出在“数据只存在于前端”。修复方式是引入 Redis 缓存中间态。前端每答一题或每次切换到下一题时，调用一次“暂存答案”接口，把整个答案数组覆盖写入 Redis。交卷时从 Redis 读出答案，再做一次合法性校验（有没有漏答的题，有没有超时）然后落库。

这里有个实现细节：为什么是“覆盖写”而不是“增量写”？因为学生可能会修改之前的答案，增量写入会留下多条历史值，覆盖写能保证 Redis 里的数据永远是最新的完整状态。

5.3 坑三：前端倒计时显示 0，后端却判定未超时

现象是：学生在倒计时 0 的时候还能正常交卷，而且系统没有判超时。起初以为是代码 bug，后来发现是考试时间设置的问题——试卷配置的结束时间是“18:00”，而不是“开始后 90 分钟”。如果学生 17:30 才进入考试，倒计时显示 30 分钟，但后端判定的截止时间是 18:00。这就尴尬了：前端显示还剩 30 分钟，实际后端只允许 30 分钟，不存在“前端显示0后端未超时”的问题。反过来，如果学生 17:10 进入，前端显示 50 分钟，后端 18:00 就截止，学生还剩 10 分钟时前端还在倒计时 40 分钟，点击交卷却被强制判定超时。

根因是：截止时间的计算口径不统一。

修复方案：统一由后端基于“开始时间 + 时长”计算 deadline，前端只拿这个 deadline 做展示。试卷配置字段改为 duration（分钟数），学生点击开始考试时，后端在 attempt 记录里写死 deadline = now + duration。此后无论前端怎么展示、时间怎么走，都以 attempt 表里的 deadline 为准。

这个坑特别值得在答辩时主动讲出来。因为它展示了设计者具备“前后端时间一致性”的意识，评委老师一般都会有兴趣。

5.4 坑四（顺带提醒）：批量更新写成循环单条 UPDATE

判分时如果逐题执行 updateById，一张 50 题的试卷就会触发 50 次 SQL，性能上很丑。学生交卷那一刻服务端要做的事情已经很多（读 Redis、校验合法性、判分、回填成绩），再叠加大批量单条更新，响应时间很容易飙到几秒。

改进方式是把答案数据组装成 List，用 MyBatis-Plus 的 saveOrUpdateBatch 或直接写一个批量更新 XML。课设阶段的规模，单用户并发很低，响应时间优化不明显，但这个设计思路体现了对数据库操作开销的敏感度，讲解代码时主动提一句很加分。

6. 演示与答辩：让课设发光的不只是代码

项目本身做完，接下来就是演示和答辩。很多同学代码写得很认真，一到演示就掉链子。这里分享几个我常用的实操技巧。

6.1 提前准备一套“饱满”的演示数据

演示现场最怕的是“点开一个列表，啥也没有”。老师看到空页面，第一反应就是“这个系统能用吗”。所以准备演示数据这件事，优先级特别高。至少要准备：

3 个教师账号，5 个学生账号。
每张试卷至少 10 道题，包含单选、多选、判断三种题型。
提前创建一场“已结束并判分”的考试，用于展示成绩列表和统计。
再创建一场“正在进行中”的考试，用于现场演示答题流程。

演示时先展示“已有数据”的场景，再演示“现场作答”的场景，节奏更从容。

6.2 主动讲自己的坑，比背功能更有说服力

答辩老师听过的项目介绍太多了，你光说“我用了 Spring Boot、Vue、Redis、MyBatis-Plus”他不会有任何印象。但如果你主动说“我在交卷接口上做了一个乐观锁，因为当时两个学生同时交卷时发现了重复判分的问题”，效果完全不同。这直接证明你不是在“做作业”，而是在“解决问题”。

可以从这几个方向挑一个讲：

倒计时到底由谁说了算（前后端时间一致性问题）。
刷新页面为什么不丢答题记录（Redis 中间态 + 交卷落库）。
选项和题目乱序是怎么避免作弊的（每次进入随机重排）。

每一个都对应一个真实场景，讲出来自然又具体。

6.3 演示节奏：90 秒跑通核心场景

演示不需要把所有功能都过一遍，90 秒足矣：

用学生账号登录，进入一场预设的进行中考试，答 3 道题。
切到另一个浏览器标签页再切回来，前端弹出切屏警告，后端记录加一。
刷新页面，看到答题进度还在。
点交卷，成绩立即出来。
切换到教师账号，查看该学生的成绩和切屏记录。

这五个步骤完整展现了“在线考试”的核心链路，每个步骤都对应一个功能模块，时间也控制在两分钟以内。

6.4 代码里留几个“有意识的设计”

答辩时老师可能会现场翻代码。提前在代码里准备几个可讲的点，比临时找要强：

判分策略独立成方法，方便扩展主观题人工评分。
状态机用常量类统一管理，避免魔法数字散落各处。
答案字段不下发给前端，返回 VO 单独剥离。
交卷接口带状态条件和乐观锁，保证幂等。

这些设计不是炫技，而是体现“工程意识”的小细节。老师看到这些代码，会知道你不是第一次写项目。

写在最后

做了这么多课设评审和辅导，我最大的感受是：在线考试系统看起来简单，真正做扎实需要认真对待状态管理和时间一致性。 很多同学把时间花在左一个页面右一个弹窗上，反而忽略了核心链路。如果你时间有限，优先保证“完整的考试闭环能跑通”，再把上面的倒计时、防切屏、断点恢复这些细节一个一个补上。代码里哪怕只有一条清晰的考试状态流转，答辩效果都会比十个炫酷页面好得多。希望这篇分享能帮你少走几个弯路，祝课设顺利。