赵阿Q毕设选题年年都有，但“基于springboot的人脸识别在线考试系统”这个题目，我从2020年带学生开始就一直在关注——它几乎是一个“标准答案型”的毕业设计题目。
一方面，Spring Boot技术上足够主流，规则引擎、自动装配、生态成熟度高，答辩时不容易被问倒；另一方面，人脸识别算法往题目里一放，系统档次立刻从普通的增删改查项目，拉高到“人工智能+教育”的交叉领域。再加上2020年以来线上考试常态化，防作弊需求真实存在，这个题目既有技术深度、又有落地场景，还有社会价值——答辩时你可以理直气壮地讲价值。
但我也必须说实话，这个题目想拿高分，不只是“跑通人脸识别”那么简单。很多人做完毕设才发现，人脸识别只占了整个系统的一小块，真正决定质量的是考试业务逻辑、防作弊机制、权限设计、异常处理这些“不性感”的部分。这篇文章我会按毕设的实际推进顺序，把架构设计、算法选型、数据库建模、核心代码实现、常见坑位全部拆开讲清楚，内容适配直接复现和答辩准备两个需求。
1. 毕设选题思路与整体方案拆解
1.1 为什么这个选题值得做
先说结论：这个题目在“技术性价比”上非常出色。
普通的管理系统毕设，比如“学生信息管理系统”“图书管理系统”，技术栈是Spring Boot + MyBatis Plus + Vue，你做出来也未必能拿高分，因为同质化太严重，答辩组老师每年看几百个雷同项目，审美疲劳了。
而加入“人脸识别算法”这个关键词，系统就具备了三个层次的创新点：算法层做特征提取与比对，应用层做活体检测与考试防作弊，业务层做在线考试流程管理。三个层次都有可以展开讲的东西，无论是写论文还是做答辩PPT，素材都非常充足，不愁没内容。
同时，这个题目非常贴近实际需求。传统的在线考试系统，最大的痛点是“你怎么知道屏幕前坐的是本人？”账号密码可以共享，切屏可以截屏作弊，摄像头监控只能威慑不能实证。而人脸识别技术的接入，让“考前身份核验+考试中随机抓拍比对”成为了可落地的方案——这个价值点，是纯管理系统的毕设完全不具备的。
1.2 技术选型背后的关键决策
技术栈选型上，我建议核心框架按“主流、够用、好讲”的标准来定：
后端用 Spring Boot 2.7.x 搭配 MyBatis Plus、MySQL 8.0；前端用 Vue 2 + Element UI（Vue 3 + Element Plus 也可以，但答辩时 Vue 2 的资料更多，有问题好查）。这两个组合是最常见的毕设搭配，遇到问题网上一搜一大把，不会被孤立在坑里。
人脸识别算法这一层，是最容易翻车的决策点。
我在带学生过程中见过三种做法：第一种是调用第三方API（百度AI、腾讯云人脸识别），优点是精度高、不用训练模型，缺点是答辩时老师一问“算法原理是什么”，学生支支吾吾说不清楚，这会被扣分；第二种是本地部署开源的深度学习模型，比如用 dlib、face_recognition 库，可以讲原理但环境配置复杂，Windows 下装 dlib 经常报错，学生心态容易崩；第三种是直接用 OpenCV 的 Haar Cascade 做检测，再用特征算子做比对，纯传统算法方案，精度一般但原理非常好讲。
我的建议是走“折中路线”：人脸检测用 OpenCV 的 Haar Cascade（简单、稳定、秒级加载），人脸特征提取和比对用 dlib + face_recognition 库（C++ 底层实现，Python 接口调用方便，特征提取用的是 ResNet 预训练模型）。这样你既不需要自己训练模型，又能在论文里写清楚“基于深度学习 ResNet 网络的人脸特征提取”，答辩时算法原理有东西可讲，技术上也可复现。
注意一点，人脸识别服务建议单独作为一个 Spring Boot 子系统跑在 8002 端口，主系统（考试业务）跑在 8080 端口。两个系统之间通过 HTTP 接口通信，主系统把摄像头采集的照片传到人脸识别服务，服务返回比对结果。这样的好处是：人脸识别服务能独立调试、独立部署，不拖累主系统的启动速度；论文里还能写“采用前后端分离+微服务思想，将算法模块独立部署，降低系统耦合度”——这句话在答辩时非常加分。
1.3 功能模块与业务边界划分
把整个系统的功能模块画一遍，你才能在编码前心里有数。这套系统我拆成三个端：
管理员端：题库管理（选择题、判断题、填空题）、组卷与考试安排、考生管理、考试监控（实时查看考生状态、抓拍记录）、成绩管理与统计分析。
教师端（可不做，很多毕设里教师端被合并进管理员端）：题库录入、阅卷（填空题自动批改），但为了控制工作量，建议教师和管理员共用一套后台，只通过角色权限区分菜单。
学生端：实名注册、人脸信息采集、考试列表、在线答题、人脸核验入口（考前验证、考试中随机抓拍）、查看成绩。
端与端的边界务必清晰。学生端的接口只处理与考试相关的操作，管理员端接口必须做角色权限校验，用 Spring Security 或拦截器统一处理，不能在 Controller 里到处写 if else 判断角色——这样既乱又容易被答辩老师追问安全问题。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 系统核心模块设计与数据库建模
2.1 数据库表结构设计的核心逻辑
数据库设计是整个系统的地基。我见过太多毕设项目，代码写了一半发现表结构不合理，回过头改表又改代码，浪费大量时间。所以建表前先把关系理清楚。
我给出的核心表结构如下：
- exam_user：用户表（用户ID、用户名、密码、角色、姓名、学号、人脸特征向量字段 face_feature、人脸状态 status、创建时间）
- exam_course：课程表（课程ID、课程名称、任课教师）
- exam_question：题库表（题目ID、课程ID、题目类型、题目内容、选项、正确答案、分值、难度）
- exam_paper：试卷表（试卷ID、试卷名称、课程ID、总分、考试时长、组卷方式）
- exam_paper_question：试卷与题目关联表（试卷ID、题目ID、序号、分值），解决“一份试卷包含多道题目、一道题目出现在多份试卷”的多对多关系
- exam_record：考试记录表（记录ID、考生ID、试卷ID、开始时间、交卷时间、得分、状态）
- exam_face_log：人脸识别日志表（日志ID、考生ID、考试记录ID、抓拍图片地址、比对相似度、识别结果、识别时间）
这个设计的核心意图，是让“人脸识别”和“考试业务”通过 exam_record 和 exam_face_log 两张表产生关联：一次考试开始前，系统在校验通过后在 exam_record 中插入一条记录；考试过程中，每隔几分钟抓拍一次，结果写入 exam_face_log，同时更新考试记录的状态。
实践中有个坑：很多人把人脸特征向量（128维的数组）直接存进 MySQL 的字段里，我强烈不建议这样做。128个浮点数转成 JSON 串存字段，查询和比对效率都会受影响。正确的做法是：用户的人脸特征向量直接存为文件（每个用户一个 .npy 或 .dat 文件），数据库的 face_feature 字段只存文件路径；考试抓拍时实时提取特征并做比对，比对完成后把特征释放掉，不落库。这个做法一方面性能好，另一方面也保护了用户的生物特征隐私——论文里写隐私保护设计时，这是实打实的素材。
2.2 在线考试核心业务流程梳理
考试流程是这个系统的心脏。我把整个流程用文字梳理一遍，你照着做就行，核心思路是“状态机驱动”：
考生登录进入考试列表 → 点击“开始考试”→ 弹窗提示进行人脸身份核验 → 系统调起摄像头 → 抓拍照片 → 上传到后端 → 后端调用人脸识别服务 → 提取当前抓拍照片的特征 → 与数据库预存特征比对 → 相似度超过阈值（建议0.6）→ 核验通过 → 创建考试记录 → 进入答题界面。
考试中的防作弊逻辑：前端定时任务每隔5~10分钟（随机间隔，防止规律被抓住）调起摄像头抓拍一次，照片提交到后端做比对。比对通过则无事发生，失败则记录日志并提示考生重新核验身份；连续三次失败，强制交卷并标记为作弊。
这里有个细节需要注意：考试结束判卷时，如果系统检测到该考生有作弊记录，成绩单上必须挂“异常”状态，但不能直接取消成绩——因为可能存在光线不好导致误判的情况，要做人工复核的兜底。这个设计体现了系统的公平性和容错性，答辩时被问“误判怎么办”“怎么保证公平”，你完全可以从容回答。
2.3 前后端分离的接口契约设计
前后端联调是毕设阶段最痛苦的一环，接口文档写清楚能省一半时间。我习惯用 R 对象做统一下发响应格式——前端的代码中到处能看到 Result.success(data) 和 Result.error(msg)，后端 Controller 统一返回 Result 对象，结构如下：
json复制{
"code": 200,
"message": "操作成功",
"data": {}
}
code 用 200 表示成功，500 表示业务异常，401 表示未登录或登录过期，403 表示无权限。前后端都按这个约定来，联调时基本不会出现“你等的是数组我传的是对象”这种无谓的撕扯。
关键的接口需要单独列出（这部分不用代码块，直接用表格对照即可）：登录认证接口、人脸特征注册接口、人脸核验接口、获取考试列表接口、创建考试记录接口、提交答案接口、手动交卷接口、获取考试成绩接口。接口路径建议统一以 /api 开头，版本号 /api/v1。
3. 人脸识别算法的工程化落地
3.1 识别方案选型与原理拆解
毕设答辩环节，老师必问的一个问题就是：“人脸识别的原理是什么？你的算法是怎么实现的？”
按我推荐的方案，这个问题的标准答法可以按三个步骤来讲：
第一步，人脸检测。利用 OpenCV 的 Haar Cascade 分类器在图片中定位人脸区域，输出人脸边界框坐标。这个分类器是基于 AdaBoost 算法训练出来的级联分类器，在检测阶段会快速排除大量非人脸区域，从而在 CPU 上也能做到实时检测。
第二步，人脸特征提取。将检测到的人脸区域，缩放到 dlib 要求的尺寸（通常是 150x150），输入预训练的 ResNet 模型，输出一个 128 维的特征向量。这个向量是人脸的数值化表示，欧氏距离越近，说明两张脸越可能是同一个人。
第三步，人脸比对。计算当前提取的特征向量，与数据库中预存的特征向量之间的欧氏距离，距离小于预设阈值，判定为同一人。举例说明：阈值 0.6 表示欧氏距离小于 0.6 判定同一个人，大于 0.6 判定不同人。这个阈值不是拍脑袋定的——需要采集一批同一个人不同角度、不同光线下的样本和不同人的样本，画 ROC 曲线来标定。在实际项目中，0.5~0.6 是常用取值范围。
用对话方式表述的话，也可以这样说：人脸识别本质上就是一个“先压缩再比对”的过程——把一张包含复杂光影、表情变化的人脸照片，压缩成一个只保留身份信息的 128 维数字序列；同一个人不同状态下的序列很近，不同人的序列很远。
3.2 人脸特征注册与核验的代码实现
人脸特征注册流程是这样的：学生注册账号后，上传一张正面免冠照片（或通过摄像头拍照），照片传给后端的人脸识别服务，服务端提取特征后保存为用户专属的 .dat 特征文件。
核心代码我用 Java 嵌入 Python 调用的方式实现。在 Spring Boot 主系统中，通过 ProcessBuilder 调用 Python 脚本来完成特征提取：
java复制public boolean registerFace(Long userId, MultipartFile photoFile) {
// 使用ProcessBuilder调用Python脚本进行人脸特征提取
ProcessBuilder pb = new ProcessBuilder(
"python3",
"/opt/face_recognition_service/register_face.py",
userId.toString(),
"/opt/face_recognition_service/tmp/"
);
// 保存上传的图片到临时目录：tmp/{userId}.jpg
File tmpFile = new File("/opt/face_recognition_service/tmp/" + userId + ".jpg");
photoFile.transferTo(tmpFile);
// 执行Python脚本
Process process = pb.start();
// 读取脚本输出的执行结果并解析
...
}
Python端的核心脚本逻辑如下：
python复制import face_recognition
import sys
user_id = sys.argv[1]
image_path = sys.argv[2]
# 加载图片并提取人脸特征
image = face_recognition.load_image_file(image_path)
encodings = face_recognition.face_encodings(image)
# 图片中没有检测到人脸，报错返回
if len(encodings) == 0:
print("NO_FACE_DETECTED")
sys.exit(1)
# 检测到多张人脸，返回错误
if len(encodings) > 1:
print("MULTIPLE_FACES_DETECTED")
sys.exit(1)
# 保存128维特征向量.npy文件到用户目录
file_path = f"./user_features/{user_id}.npy"
np.save(file_path, encodings[0])
# 返回成功标记及人员ID
print(f"SUCCESS:{user_id}")
识别核验的流程与之类似，额外增加了一步距离比对：
python复制import numpy as np
import face_recognition
# 当前抓拍图片提取特征
current_image = face_recognition.load_image_file(sys.argv[1])
current_encoding = face_recognition.face_encodings(current_image)[0]
# 从用户特征文件加载预存特征
saved_encoding = np.load(sys.argv[2])
# 计算欧氏距离
distance = np.linalg.norm(current_encoding - saved_encoding)
match = distance < float(sys.argv[3]) # 阈值从外部传入
# 输出相似度分数和比对结果
similarity = 1 - round(distance / 2, 4) # 归一化到0-1区间
print(f"MATCH:{match}:{similarity}")
类似度输出格式注意与前面的 Result 约定统一：MATCH:true:0.87 表示比对通过，相似度 0.87；MATCH:false:0.34 表示比对失败，相似度低。
3.3 活体检测与防作弊的关键处理
毕设项目大多数人都会忽略活体检测，但考试场景离不开它——因为学生完全可能拿一张打印的本人照片对准摄像头，照样能通过特征比对。
最简单的活体检测方案是“动作随机指令”：考生核验时，系统随机生成一个动作指令（如“请眨眼”“请张嘴”“请左转头”），利用 OpenCV 的摄像头实时画面做动作判定。这个做法的核心是调用级联分类器分别检测人脸、左眼、右眼、嘴巴的位置，根据检测结果判断动作是否完成：
- 眨眼检测：连续若干帧中，检测到眼睛从“可见”变为“不可见”再变回“可见”，计为一次眨眼
- 张嘴检测：嘴巴检测框的高度明显增大超过阈值，判定张嘴动作
- 转头检测：通过左右眼的相对位置变化判断头部偏转方向
动作随机指令 + 人脸特征比对，双因子认证。这个方案在答辩时很加分，因为“活体检测”本身就是人脸识别领域的热点方向，写在论文里能体现你对实际问题的思考和理解。
考试过程中的随机抓拍防作弊，也可以在轻量化的思路上操作：不要求比对通过才能继续答题，而是把抓拍识别结果作为后台异常检测依据。连续多次识别失败再触发强制核验流程，这样的交互对正常考生几乎无感，对作弊者则有持续的威慑力。这个策略叫做“异步防作弊”，比同步阻断体验好得多，也不影响考试系统本身的流畅度。
4. Spring Boot后端的核心实现细节与防作弊逻辑
4.1 项目初始化与工程结构组织
后端工程建议用 IDEA 直接初始化 Spring Boot 项目，Java 版本 8 或 11 均可，Spring Boot 版本 2.7.18 比较稳妥——太高版本可能踩坑，太低版本可能缺少依赖支持。核心依赖清单如下：
xml复制<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-security</artifactId>
</dependency>
<dependency>
<groupId>com.baomidou</groupId>
<artifactId>mybatis-plus-boot-starter</artifactId>
<version>3.5.2</version>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>8.0.33</version>
</dependency>
工程结构建议按包按职责划分，简洁清晰：
text复制com.example.exam
├── config // 配置类：CORS、拦截器、MyBatis-Plus分页
├── controller // 接口层
├── service // 业务层
├── mapper // 数据访问层（MyBatis-Plus）
├── entity // 数据库实体
├── dto // 请求响应对象
├── common // 统一返回、异常处理、工具类
一个非常常见的败笔是把所有逻辑硬塞进 Controller，Controller 又长又难维护。记住controller只负责参数接收和返回结果，业务逻辑都放service，数据层调用放mapper，分层清晰后写代码的速度反而更快。
4.2 登录认证与权限控制的实现思路
在线考试系统的安全要求比普通管理系统高，因为涉及到考试防作弊，谁登录的、什么时候登录的、什么IP、什么设备，最好都有记录可查。
我建议用 JWT + Spring Security 做认证控制。用户登录成功后，后端签发 JWT，前端在每一次请求的 Header 中带上 Authorization: Bearer {token}，后端通过 Spring Security 过滤器链校验 JWT，并在 SecurityContext 中存放当前登录用户的 ID、角色信息。
核心配置类如下（简化版）：
java复制@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {
@Bean
public JwtAuthenticationFilter jwtAuthenticationFilter() {
return new JwtAuthenticationFilter();
}
@Override
protected void configure(HttpSecurity http) throws Exception {
http.csrf().disable()
.sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS)
.and()
.authorizeRequests()
.antMatchers("/api/auth/**", "/face/**").permitAll()
.antMatchers("/api/admin/**").hasRole("ADMIN")
.antMatchers("/api/student/**").hasRole("STUDENT")
.anyRequest().authenticated()
.and()
.addFilterBefore(jwtAuthenticationFilter(),
UsernamePasswordAuthenticationFilter.class);
}
}
注意 /api/auth/** 必须放行，包括登录、注册、人脸特征上传；而 /api/admin/** 和 /api/student/** 分别限定角色。异常情况下（token过期、无权限）要由自定义 AccessDeniedHandler 和 AuthenticationEntryPoint 返回统一的JSON格式错误，不要让Spring Security默认的403页面直接返回HTML——前后端分离项目互相之间看到一串HTML错误页面，排查时会很崩溃。
4.3 考试防作弊的核心逻辑与定时任务实现
考试状态跟踪与强制交卷逻辑，是系统稳定运行的关键。我用一个专门的 ExamSessionManager 组件来管理考试会话状态机，避免逻辑分散在各处：
- 状态机流转：IN_PROGRESS（考试中）→ SUBMITTED（已交卷）→ FORCE_SUBMITTED（超时强制交卷）
- 未开始考试的记录，状态为 NOT_STARTED，一旦人脸核验通过，立即置为 IN_PROGRESS
- 答题过程中，每次提交答案都会同时更新考试记录的最后活跃时间
前端需要自动保存草稿——至少每30秒保存一次，防止浏览器崩溃或网络中断导致答题内容丢失。这不算复杂逻辑但非常考验细腻度。
考试超时强制交卷，用 Spring 的 @Scheduled 定时任务实现：
java复制@Component
public class ExamTimeoutTask {
@Autowired
private ExamRecordMapper examRecordMapper;
// 每30秒扫描一次考试中的记录
@Scheduled(fixedDelay = 30000)
public void forceSubmitTimeoutExams() {
List<ExamRecord> inProgressList = examRecordMapper
.selectList(new QueryWrapper<ExamRecord>()
.eq("status", "IN_PROGRESS"));
Date now = new Date();
for (ExamRecord record : inProgressList) {
Date deadline = DateUtil.offsetSecond(record.getStartTime(),
record.getDuration() * 60);
// 超过截止时间，强制交卷
if (now.after(deadline)) {
record.setStatus("FORCE_SUBMITTED");
examRecordMapper.updateById(record);
}
}
}
}
这个定时任务解决了很多毕设都会存在的“考试时间到了但是系统不交卷”的硬伤。在答辩现场演示时，如果能在有限的时间里操作一个已经到时间的考试让它自动交卷，那观感就是用心的标志。
4.4 全局异常处理与统一响应规范
在线考试系统的异常场景非常丰富——人脸核验失败、考试时间冲突、提交答案时考试已结束、上传图片没有检测到人脸、试卷不存在……每一种异常都应该在接口层返回规范、明确的提示信息。如果全靠 Controller 里的 try-catch，代码会很臃肿，改成全局异常处理器才是正路。
针对这个系统，有三类核心异常需要着重处理：
业务异常（考试时间冲突、试卷不存在）统一返回code 500和中文提示；参数校验异常统一返回code 400，附带“字段名+错误原因”的列表；未登录或token过期返回401，前端收到这个code后自动跳转登录页。
用 @RestControllerAdvice 实现全局异常处理，写一个自定义业务异常 BizException，吧若遇到需要抛错的业务场景直接 throw new BizException("考试已截止")，控制层保持简洁，异常处理逻辑全部集中在advice里。这个设计在代码评审和答辩中会被视为有工程的思维。
这里我还要专门提一下XSS注入问题。这个系统涉及学生提交、管理员录题等多入口文本输入，是XSS攻击的高发地带。如果项目要求高一些，可以加一个全局过滤器：在请求进入Controller之前统一对JSON请求体做XSS转义，把 <script> 这类危险标签转成安全的转义字符，存储时保留原文，展示时防止脚本执行。尤其是题目内容、选项内容这类字段，如果考试系统被注入了XSS，影响的不安全不仅仅是个人用户，而是所有参加考试的学生。真正上线前，做一轮安全自测非常值得。
5. 实现过程中的高频问题与排查方法
5.1 环境与依赖安装问题
Java后端环境相对好解决，但Python人脸识别环境的坑是真的多。下面这几个问题我几乎每年都遇到：
dlib 在 Windows 上安装失败（报 C++ 编译错误）。解决办法：不要用 pip 从源码编译，直接安装预编译的 whl 包：pip install dlib-19.22.0-cp38-cp310-win_amd64.whl（注意Python版本要匹配）。或者干脆用 Anaconda，conda 安装 dlib 会方便很多。
face_recognition 依赖的 dlib 版本冲突。在 Python 3.9 及以上环境，某些版本的 face_recognition 会与新版 dlib 不兼容，建议锁定：pip install dlib==19.22.0 face_recognition==1.3.0。
OpenCV 摄像头打不开或画面花屏。这通常不是代码问题，而是本机摄像头驱动被占用（别开 Zoom/微信视频同时用摄像头），将其他占用摄像头的程序关掉再测。在服务器无摄像头环境测试时，改用上传图片的方式走接口验证即可。
5.2 人脸识别准确率低的实战排查路径
人脸识别不像传统Web功能那样“是或否”分明，比对结果的准确性会受到各种因素干扰。在实际调试中，相似度不高、识别失败等异常状态最常见的原因有两类：
一类是图像质量。学生注册时上传的是生活照或用手机翻拍照片，拍摄角度歪斜、光线不足、分辨率太低，提取特征就不可靠。解决方案是注册时加入引导和校验逻辑——用摄像头实时拍照而非上传相册照片，且拍照时画一个人脸轮廓提示框，要求用户将人脸对准框内，并对实时画面做清晰度检测（OpenCV 的 Laplacian 算子方差大于阈值才允许拍照）。清晰度检测代码简单但效果好：
python复制import cv2
def is_clear(image_path, threshold=100):
img = cv2.imread(image_path)
gray = cv2.cvtColor(img, cv2.COLOR_BGR2GRAY)
# Laplacian方差衡量图像边缘强度，值越大越清晰
variance = cv2.Laplacian(gray, cv2.CV_64F).var()
return variance > threshold
另一类是环境干扰。比如考试中后台识别间隔太长、光线条件变化剧烈。识别阈值与间隔的配合需要调试，将阈值从 0.6 调到 0.65 可以提高误拒率但降低误纳风险——在线考试场景下，宁可误报也不要漏报，这个方向要清晰。
还有一个极易忽略的坑：考试成绩单中有一项“人脸识别不通过次数”的统计，如果这个字段为 0 但人脸日志表里明明有记录，那多半是之前日志的关联字段存错了——我在实测中就遇到过考试记录ID和日志ID没有正确关联，导致统计结果对不上。
5.3 考试高峰期并发与性能优化建议
毕设项目的性能一般要求不高，但答辩时被问到“如果同时5000人考试你的系统撑得住吗”这种问题，不能毫无准备。一般从三个层面优化：
数据库层：考试列表、题目列表查询频率最高，使用 MyBatis-Plus 的分页插件 + 索引优化。微信表中的 user_id、exam_id 必须建索引。人脸日志表只做插入和查询，不更新。
接口层：同一份试卷的题目详情是典型的读多写少数据，加入 Redis 缓存后大幅降低数据库压力。我的做法是：试卷发布时把题目详情序列化后写入 Redis，考生答题时直接走缓存；交卷时一次性把整张卷答案提交到后端批量判卷，而不是每题单独请求。判卷逻辑用 Java 8 Stream 批量处理，500道题在毫秒级完成。
抓拍与识别联动的性能瓶颈，要重点关注上传带宽：每次抓拍照片大小约200KB，如果每5分钟抓拍一次，一场90分钟的考试单人流量约3.6MB。5000人同时在线，存储和带宽都是压力。解决方案是前端先把图片压缩（Canvas压缩到500px宽度，JPEG质量0.7），再上传，图片体积可压缩至原来的1/5。
5.4 Spring Boot部署上线经验
毕设答辩前一般要求系统能远程访问，或者至少要在答辩现场跑得起来。部署环节我强烈建议用 Docker 一条龙搞定：MySQL 容器 + Spring Boot 后端容器 + Nginx 前端容器。
Docker 部署的核心要点是镜像构建和容器编排。前端 Vue 项目构建成静态文件后由 Nginx 托管，后端 Spring Boot 项目直接用 Dockerfile 构建镜像。
Spring Boot 的 Dockerfile 写法很简单：
dockerfile复制FROM openjdk:8-jdk-alpine
WORKDIR /app
COPY exam-system.jar /app/app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar", "--spring.profiles.active=prod"]
容器编排用 docker-compose.yml 把 MySQL、后端、前端三个服务拉起，注意服务和容器之间的网络通信要配置好。部署前最重要的事：所有配置不能写死在 application.yml，要写成环境变量注入的形式——数据库地址、数据库密码、人脸识别服务的地址，这些在线上和本机肯定不一样，写死了到时候不好改。
本人实测出现过的教训是：spring.datasource.url 中的 MySQL 容器名在 docker-compose 网络里能解析，但本地跑就解析不了，导致本地启动直接报”无法连接数据库”。所以给系统设计配置参数时要预留环境切换机制：default（本地开发）和 prod（服务器部署）两套配置，用 spring.profiles.active 在启动时指定。
6. 实操复盘：从0到交付的推进路线与效率技巧
6.1 按周拆解的落地计划
结合我一个学期的实操带教经验，把这个毕设从零到验收的时间线按周拆一下，你可以直接拿来对照使用，避免卡在某一环节失去节奏：
第1周：环境搭建（JDK、MySQL、Maven、IDEA、Python），初始化Spring Boot后端和Vue前端工程，实现登录注册接口。
第2周：完成数据库建表、用户角色管理、题库管理（管理员端增删改查）。
第3周：实现试卷生成逻辑——手动组卷方式，管理员在题库中勾选题目生成试卷。
第4周：实现考生考试核心流程——在线答题、答案自动保存、手动交卷。
第5周：人脸识别服务开发。先本地验证Python脚本能正常提取特征和比对，再封装成Spring Boot独立服务。
第6周：人脸识别与考试流程整合。注册时采集人脸，考前核验，考试中随机抓拍，写入日志。
第7周：角色权限完善、异常处理、统一响应格式、XSS防护基础版。
第8周：前端页面美化、管理员监控面板、学生端交互优化。
第9周：整体功能测试，边界场景覆盖（考试超时、强制交卷、人脸多次不过）。
第10周：部署上云，准备答辩材料（架构图、ER图、流程图），录制演示视频。
留出了两周缓冲期，因为人脸识别模块一定会踩坑，前端代码也不会一蹴而就，提前量是必需的。
6.2 效率提升的实操技巧
用 Postman 管理接口测试，每个功能模块写完立即在 Postman 验证一遍再联调前端，不要攒着一堆 bug 到最后一起调。
Vue 前端请求封装统一在 request.js 中处理，拦截器里统一携带 JWT token、统一处理401跳转。写业务接口时不要重复造轮子。
人脸识别服务单独跑，用本地 Python 脚本先在命令行调通，确认算法输出正确后再接入Spring Boot。千万不要上来就把算法嵌入主流程，否则环境问题、算法问题、业务问题三者交杂在一起，排查起来非常崩溃。
代码里写好注释。毕业设计代码是要查重的，不仅要让查重软件满意，更要让指导老师能快速看懂每个核心文件的作用——注释写得清楚，指导老师对你的印象分会有明显变化。
答辩前至少做三次完整演示，每一次都要从头模拟真实场景：注册账号→上传人脸→管理员创建考试→考生登录→人脸核验→答题→交卷→查看成绩。演示过程中不要刷新页面，不要切后台录入，不要出现“等我在数据库里改一下”这类动作。做过多次演练之后，你连潜在的翻车点都了然于心。
7. 写在最后：我的真实体会与经验建议
总结一下我做这套系统反复验证后最有价值的一条经验：毕设项目真正的难点不在“人脸识别算法”本身，而在于把一个写Demo式的算法稳定地嵌进一个真实业务流程中。很多同学要么花了两周去研究深度学习理论，结果算法没跑通业务也没做完；要么快速弄了个考试管理系统，人脸识别用静态图片测试就交差，结果真实摄像头环境各种翻车。真正理想的路径，是在稳定的业务架构上，用一个成熟的人脸识别库解决验证问题，再在论文和答辩中把算法原理讲透。这样论文既有工程落地内容，又有算法理论深度。
第二个强烈建议是做“防作弊设计”这个章节时，不要只写实现，要写清楚业务规则背后的动机检验。例如当考生单次人脸比对失败时，系统允许最多失败多少次再强制交卷？最大重试次数与相似度阈值之间的配合如何调试？这些决策形成的过程本身就极具工程价值，指导老师和评审委员一眼就能看出来你是认真思考过真实问题的。
最后分享一个让我学生受益的实操小技巧：答辩前把整套系统的所有配置文件、部署脚本、数据库初始化 SQL 扔到一个 Git 仓库里，录一个10分钟左右的系统演示视频（包含摄像头人脸核验的完整流程），上传到仓库的 README 中。答辩当天即使现场网络抽风、摄像头无法调度，你放一段提前录好的视频，也可以保住基本盘。很多同学的技术水平完全够，但就在这种细节点上栽了跟头，很遗憾。
这个项目做完之后，你可以顺手把它扩展成“智能监考平台”，加一个考生行为分析模块（头部姿态、视线方向检测），或者接一个消息队列做大规模异步批改。从毕业设计出发，它完全可以成为你简历上拿得出手的作品——毕竟，能独立完成一套含算法集成的全栈系统，这个能力本身，就是毕业设计希望证明的东西。