肝博士杨明博大夫在线考试系统搭配人脸识别算法，这几年在毕业设计里出现频率一直很高。你可能也发现了，传统的账号密码登录只能证明“有人知道密码”，根本证明不了屏幕前坐的是不是考生本人，而人脸识别恰好补上了这个缺口。基于 Spring Boot 做人脸识别在线考试系统，听起来好像很复杂，其实拆开就三块：Spring Boot 提供后端服务和考试业务，人脸识别算法负责身份核验，前端负责交互和摄像头采集。这篇文章我按我实际做完这套系统的经验，从需求拆解、算法选型、库表设计、核心链路实现，到部署排坑、答辩包装，完整过一遍。适合正在做这个选题的本科毕业生，也适合想快速把“人脸核身”能力集成进业务系统，但还不清楚怎么下手的工程师。
1. 项目整体设计与需求拆解
1.1 这个项目解决的到底是什么问题
在线考试最让人头疼的从来不是“能不能答完题”，而是“怎么保证答题的人是对的人，并且过程中没有作弊”。传统方案里，登录校验、切屏检测、答题时间限制都只能解决部分问题。账号可以被借用，切屏检测可以被虚拟机绕过，真正能直接绑定“物理本人”的手段，最直观的就是人脸识别。
这里要明确一点，人脸识别算法在考试系统里承担的不是单纯“登录换头像”的功能，它需要解决两个问题：考前身份核验和考中状态监控。考前核验考的是“你声称自己是张三，那你得长得像张三”；考中监控考的是“答题过程中坐在屏幕前的人始终是张三”。很多初做这个题目的人只做了前者，考中完全放开，那就失去了人脸识别的核心价值。
我建议把需求描述成一句话：系统需要在考生进入考试前完成人脸认证，同时在整个答题周期内进行周期性的人脸抽帧比对，一旦发现当前人脸与注册人脸不匹配，就记录异常并触发预警。这个表述既能让评审老师快速理解你的系统边界，也能让后续的开发目标非常聚焦。
1.2 系统模块划分与业务流梳理
按角色拆，系统至少要有三类用户：考生、教师、管理员。考生端负责注册人脸、参加考试、随时响应抽帧验证；教师端负责创建试卷、安排考试场次、查看异常记录；管理员端负责用户管理、考试数据统计、全局监控日志查询。人脸识别相关的能力不属于任何单一角色，它作为公共模块被考试流程调用。
在实际设计中，我把整套系统拆成了六大模块：用户权限模块、考试管理模块、在线答题模块、人脸引擎模块、异常监控模块、数据统计模块。用户权限模块用 Spring Security 或 Sa-Token 做登录鉴权；考试管理模块负责试卷、题目、场次、考生关联关系；在线答题模块负责题目展示、答案暂存、交卷判分；人脸引擎模块是整个项目的核心差异点，负责图片采集、特征提取、特征入库、相似度比对；异常监控模块负责抽帧验证、异常告警、记录查询；数据统计模块给教师和管理员提供考试通过率、异常次数等维度的报表。
业务流上我建议设计成：管理员创建考试并分配考生，考生进入考试前先做人脸注册，进入考试页面时先进行一次人脸比对，通过后开始计时答题，答题期间后台按照固定间隔调用摄像头抓帧比对，比对失败触发弹窗提示并记录异常，交卷后教师端能看到整场考试的人脸校验汇总。
1.3 技术选型：为什么是 Spring Boot + 人脸识别算法
Spring Boot 在毕业设计这个场景里几乎是“标准答案”。原因很实在：起步快，不用像 SSM 那样写大量 XML 配置；生态好，连接数据库、做权限、发邮件、对接第三方服务都有现成起步依赖；招人眼熟，评审老师基本都认这套技术栈。对于以“完成一个能演示、能交差、能答辩”为目标的毕设来说，与其选一个冷门框架彰显个性，不如用 Spring Boot 把业务做扎实。
人脸识别算法的选型就稍微需要点策略了。目前可选路径大概有三条：调用云服务 API，例如百度人脸识别、阿里云人脸比对，需要申请 Key，识别效果最好但依赖网络且部分功能收费；使用离线开源库，例如 OpenCV 的人脸检测加人脸识别模型、JavaCV 封装，或者通过 Python 的 dlib、FaceNet、ArcFace 提取特征；自研轻量模型，严格训练成本太高，毕设不太建议。
我的建议是：如果毕业设计周期短，优先选“离线本地模型为主，云 API 备用”的方案，理由很简单——答辩现场的网络环境不可控，一旦云端 API 超时，演示就翻车了。离线模型虽然在极端角度和暗光下不如商业 API，但完全够用，而且你可以把整个调用链路讲清楚，这在答辩时反而是加分项。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 人脸识别算法原理与落地方案
2.1 人脸识别的四个核心步骤
人脸识别不是“拍张照片和原图比一下”这么简单，标准流程分四步：人脸检测、人脸对齐、特征提取、特征比对。人脸检测解决的是“脸在哪”的问题，模型会输出一个包含人脸的矩形框；人脸对齐解决的是“脸的姿态正不正”的问题，通过眼睛、鼻子、嘴角等关键点把脸矫正到标准角度；特征提取是关键中的关键，它把一张人脸图像压缩成一个固定长度的向量，比如 128 维或者 512 维；特征比对则是计算待验证人脸向量与库中注册向量之间的相似度，一般用余弦相似度或欧式距离。
我能用生活化的类比来解释：把人脸向量想象成身份证上的“数字指纹”，每张脸经过模型编码后都生成一串独一无二的数字组合。两张脸像不像，就看这两串数字之间的距离大不大。距离越小，越可能是同一个人。这个思路在工程上的好处是，你不需要在系统里存高清人脸照片，只需要存特征向量，既节省存储空间，也有利于隐私保护。
2.2 主流算法方案选型对比
拿我做过的项目来对比几种具体方案。OpenCV 内置的 Haar Cascade 人脸检测器速度极快，但只解决检测问题，识别能力比较弱，适合做“框出人脸”的展示，不适合作为核心认证算法。dlib 提供人脸检测加 128 维特征提取，配合 HOG 特征或者 CNN 模型，纯 CPU 环境也能跑，但速度一般，对比时用欧式距离，阈值定在 0.6 以下效果比较好。FaceNet 是谷歌提出的经典方案，把特征层拉到一个紧凑的欧式空间，用三元组损失训练，准确率更高，但模型较大，需要 Python 环境配合。
从工程实现角度，我在实际项目里用的组合是：Python FastAPI 服务负责算法部分，承载人脸检测、特征提取和比对接口，Spring Boot 后端通过 HTTP 调用该服务。理由很直接，Java 生态里的人脸识别库成熟度不高，而 Python 的 AI 库资源丰富、调用简单。Spring Boot 只负责业务编排和数据处理，人脸服务独立部署，两个进程互不干扰。这样既保住了毕设的“Spring Boot 含量”，又让算法部分不至于成为黑盒。
2.3 在 Spring Boot 工程里怎么接算法能力
把算法封装成一个独立的“人脸引擎服务”后，Spring Boot 这边的对接就很干净了。我在项目中定义了一个 FaceEngineClient，在 application.yml 里配置人脸服务的地址，客户端负责把图片文件或 Base64 字符串 POST 给算法服务，拿到特征向量数组，再执行入库或比对操作。
这里有一个容易踩坑的细节：图片传输格式。如果你直接把摄像头抓拍的原图文件传给算法服务，网络开销大，解析也慢。我建议前端通过 canvas 把视频帧压缩成 JPEG 后转 Base64，再传给后端，后端原样转发给算法服务。控制在一张图 100KB 以内，体感上是秒级返回的。另外，特征向量在数据库里建议用字符串类型存储，比如把 float 数组转成逗号分隔的字符串或者 JSON 数组，因为大多数关系型数据库对向量类型支持不友好，这样最简单。
3. 实操过程与关键环节实现
3.1 工程初始化与依赖准备
创建 Spring Boot 工程时，我建议用 Spring Initializr 生成，版本选 2.7.x 或 3.x，根据你自己的 JDK 环境来定。必选的依赖包括 Spring Web、Spring Data JPA 或 MyBatis Plus、MySQL Driver、Lombok、Validation。如果要做前后端分离，还可以引入 Spring Security，但毕设场景里我建议用简单的拦截器加上 Sa-Token 或 JWT，学习成本更低，也更容易讲清楚鉴权原理。
下面是 pom.xml 里我实际用到的核心依赖片段：
xml复制<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>com.baomidou</groupId>
<artifactId>mybatis-plus-boot-starter</artifactId>
<version>3.5.5</version>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>8.0.33</version>
</dependency>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
</dependency>
工程目录结构我建议按功能分包，而不是按技术分层包。具体到单体项目里，可以拆成 config、controller、service、mapper、entity、dto、common、face 这几个包。把 face 单独拎出来是因为人脸识别相关的客户端封装、结果对象、异常定义都集中在这一块，后续如果换算法服务，只需要改这一个包，业务代码完全不用动。
3.2 数据库设计：人脸特征怎么存
在线考试系统的表结构不算复杂，但人脸特征这块要设计合理。核心表我拆成了：用户表、考试表、考试考生关联表、试卷表、题目表、答题记录表、人脸特征表、人脸验证日志表。
人脸特征表是关键。我给它设计的主要字段包括：id、user_id、face_vector、image_url、create_time、update_time。其中 face_vector 字段存特征向量数组序列化后的字符串，image_url 存注册时的原始照片地址，方便教师端人工核对。这里要注意，人脸照片属于敏感信息，前端采集时必须通过弹窗告知考生“照片仅用于本次考试身份核验”，数据库里的图片不能裸存，建议存储路径走对象存储或者本地受控目录，至少字段值不要直接暴露在 API 返回结果里。
人脸验证日志表记录了每次验证的结果，包括 exam_id、user_id、verify_type（考前核验或考中抽检）、similarity、is_passed、face_image_url、created_time。有了这个表，教师端可以很直观地看到“张三在 9:15 那次随机抽检中相似度只有 0.52，系统判定为异常”。这不仅是功能，还是你答辩演示时最有说服力的数据来源。
3.3 考前身份核验链路实现
考前核验流程我设计成四步：考生点击“进入考试”，系统先检查该考生是否已注册人脸；如果未注册，前端打开摄像头采集，把抓拍图传给后端做人脸特征提取，特征向量写入人脸特征表；如果已注册，前端采集一张当前画面图片，后端提取特征后与库中特征比对，返回相似度和是否通过。
比对接口的逻辑我用伪代码来表示，方便你理解：
java复制public VerifyResult verifyFace(String imageBase64, Long userId) {
// 调用人脸引擎服务提取当前图片特征
float[] currentVector = faceEngineClient.extractFeature(imageBase64);
// 从数据库读取该用户已注册特征
String storedVectorStr = faceFeatureMapper.selectByUserId(userId).getFaceVector();
float[] storedVector = parseVector(storedVectorStr);
// 计算相似度，建议使用余弦相似度
double similarity = cosineSimilarity(currentVector, storedVector);
boolean passed = similarity >= threshold;
// 记录日志，无论是否通过都落库
saveVerifyLog(userId, similarity, passed);
return new VerifyResult(similarity, passed);
}
阈值怎么定？这是很多新手会问的问题。我用余弦相似度，阈值设置在 0.75 左右。这个值不是拍脑袋定的，而是拿注册时的照片和十几张同一人在不同光线、角度下的自拍测试后得到的平衡点。阈值太高会导致本人误判，太低会让相似的人混进来。做完整项目后，你应该准备一组测试照片，把阈值变化对正确率的影响记录下来，这本身就是答辩时的效果展示材料。
3.4 考中异常监控与告警实现
考中抽帧是提升系统含金量的关键功能。我采用的方案是：考生进入答题页面后，前端每隔 30 秒从视频流中抽取一帧，压缩后发送到后端，后端与注册特征比对，相似度低于阈值就记录一次异常。前端同时做切屏检测，当用户切出浏览器标签页、切到其他应用、或者同时出现两个人脸时，也触发一条异常记录。
后端不能傻等前端上报就完事，还要防止有人直接绕过前端接口，伪造“验证通过”的结果。我在接口里加了验证时间戳和考生当前答题状态校验，每次上报必须带上考试会话 ID，后端检查该会话确实处于进行中状态才接受结果。虽然这个方案在绝对安全性上比不过监考摄像头，但从毕设角度来说，已经体现了防作弊思维。
定时抽帧建议用前端定时器实现，不要用后端定时任务。原因是浏览器端的摄像头权限和视频流都在前端，后端主动抓帧还得反过来调摄像头，工程复杂度高且不现实。前端定时抽帧配合后端校验，既符合实际情况，也减少了无效请求对服务端的压力。
这段逻辑的核心代码大致是这样的，前端发送抽帧验证请求：
javascript复制setInterval(() => {
const frame = captureFrame(); // canvas截取视频帧并压缩
const payload = {
examSessionId: sessionId,
imageBase64: frame,
timestamp: Date.now()
};
fetch('/api/face/random-verify', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify(payload)
}).then(res => res.json()).then(data => {
if (!data.passed) {
showWarningModal('人脸核验未通过，请确保本人正对屏幕');
}
});
}, 30000);
3.5 系统部署与运行配置
Spring Boot 项目最终打成一个可执行 jar 包，部署方式我推荐用 Docker，既方便迁移，也方便你在答辩环境里快速拉起整套服务。写一个 Dockerfile，基础镜像选 eclipse-temurin:8-jre 或 17-jre，把 jar 包拷贝进去，EXPOSE 8080 端口。人脸识别服务如果是 Python 写的，单独写一个 Dockerfile，用 FastAPI 的 Uvicorn 启动，通过 Docker Compose 把两个服务串联起来。
配置方面，我强烈建议把数据库连接、人脸服务地址、阈值这些参数外部化，放到 application.yml 里，不要写死在代码中。一个典型配置片段如下：
yaml复制server:
port: 8080
spring:
datasource:
url: jdbc:mysql://localhost:3306/exam_system?useUnicode=true&characterEncoding=utf8
username: root
password: 123456
face:
engine-url: http://localhost:8000
similarity-threshold: 0.75
cache-expire-time: 60
人脸识别服务属于 CPU 密集运算，接口响应时间不稳定。我在后端对最近一小时内的相似度结果做了简单缓存，同一个考生如果短时间内重复验证，直接复用上一次的结果，避免频繁调用算法服务。这在实际考试场景很有用，比如考生因为临时弹窗触发多次抽帧验证，每 5 秒一次和每 30 秒一次，对服务的压力差别很大。
4. 常见问题与排查技巧实录
4.1 人脸检测失败、误识别率偏高的典型原因
我调试时遇到的第一类问题就是“明明看着像本人，系统却判定不通过”。排查到最后，问题通常不在算法，而在照片质量。比如考生注册时用的是翻拍的旧照片，光线差，背景杂乱；而考中抓拍时摄像头又逆光，导致人脸的亮度分布差别巨大。解决办法有三个：注册照片必须强制实时拍摄，不能用上传文件的方式导入；考中抓拍前对人脸区域做亮度均衡处理；比对之前先检测人脸框是否有效，如果人脸占整张图的比例过小，就提醒考生离屏幕近一点。
误识别偏高则大概率是阈值设定问题。建议你在实验环境里跑一轮阈值扫描，记录不同阈值下的误识率和拒识率，找到交叉点附近的取值。如果发现相似的人之间特征向量距离也很近，可以考虑更换更强的人脸特征提取模型，或者在同一模型的前提下增加样本数量，也就是给每个考生注册时多拍两张不同角度的照片，分别提取特征存库，比对时取最高分。
4.2 高并发下的性能抖动怎么处理
真实答辩或者演示时，不太可能遇到几千人同时开考的场景，但你还是应该提前让系统具备一定抗压能力。最容易成为瓶颈的不是 MySQL，而是人脸算法服务。特征提取是计算密集型的，一个 CPU 核同时只能处理有限的请求，并发高了以后，接口延迟会从几百毫秒飙升到几秒。
我的处理思路是异步化。把“人脸验证”这个动作从考试主链路中剥离出去：考生点击“进入考试”时，接口立刻返回“验证处理中”，同时把验证任务丢进线程池或者消息队列，后台拿到结果后更新验证状态，前端轮询或者通过 WebSocket 收到结果。这样的用户体验反而更好，考生不需要一直盯着转圈等待。另外，给算法服务加一层请求队列，控制并发数，防止瞬间请求打垮服务。
4.3 代码安全与隐私合规方面的坑
人脸数据是敏感个人信息，处理不当容易翻车。我见过不少毕设系统直接把用户照片通过接口返回给前端，任何人拿到用户 ID 都能看照片，这是很典型的隐私漏洞。正确做法是：接口只返回“是否通过验证”和“相似度数值”，原始照片只在后台管理页面由管理员查看，并且每次查询都记录操作日志。照片的存储路径建议使用 UUID 重命名，不要用用户 ID 直接命名，防止遍历。
另外，上传接口也要做防护。很多人会在系统里加一个上传照片的功能，如果没做文件类型校验，攻击者可能上传一个包含恶意脚本的文件然后通过 URL 访问。我建议实现一个全局过滤器，对上传的图片做 Content-Type 校验、大小限制、文件名重写，并且用白名单方式允许 .jpg、.jpeg、.png 三种格式。对 PDF 等其他类型文件的上传，同样走过滤器做内容清洗，防止嵌在文件里的危险代码被执行。
4.4 从 jar 包到工程：关于维护与二次开发的实操经验
做完项目后，不可避免会涉及“把打包好的 jar 再还原成可维护工程”的需求。比如你换了一台电脑，源码找不到了，只剩一个 jar 包，这时候就需要用到反编译工具。Java 的反编译工具链已经很成熟，常见的有 IDEA 自带的 FernFlower、CFR、Procyon。实际做法是用 IDEA 直接把 jar 包拖进项目，或者用 CFR 命令行一次性解出全部源码。但我要提醒你几点：反编译出来的代码，注释会全部丢失，泛型擦除导致类型信息不完整，Lambda 表达式可能被还原成内部类，看着能懂，但想直接编译回原样基本不可能。所以它只适合学习思路和恢复业务逻辑，不适合作为日常开发的代码基准。
正确的开发姿势是把源码纳入 Git 管理，每次改动提交一次，环境配置放到外部文件。这样即使 jar 包部署在服务器上，你也能随时从仓库拉取源码继续迭代。毕业设计阶段养成这种习惯，比任何工具技巧都重要。顺便提一句，Spring Boot 项目的启动 banner 生成器挺有意思，不过那只是锦上添花的东西，别把精力花太多在涂鸦上。
5. 让毕设从“能跑”变成“能打”
5.1 用效果数据给项目背书
答辩时最怕评审老师说“这个项目看起来就是一个普通管理系统”。避免被贴标签的最好办法，是你主动拿出数据，用结果证明系统有效。我在项目里做了一个评测模块，准备了三组测试样本：A 组是 20 名考生各自正常注册和考中抓拍的照片；B 组是 20 名考生戴帽子、侧脸、光线较暗条件下的照片；C 组是他人冒充，比如用另一部手机展示注册照片冒充本人。
用这三组样本跑下来，统计正确识别率、误识率、平均响应时间，做出一张表格。A 组识别率基本在 95% 以上，B 组在 80% 左右，C 组绝大多数情况会被拦截。这张表放到演示 PPT 里，比你空口说“识别的很准”有说服力得多。同时，把抽帧验证的日志表打开，显示某位考生在考试期间有三次抽帧相似度全部高于 0.9，没有任何异常，另一个考生有一次相似度只有 0.4，系统自动打了异常标记，这些真实记录就是系统价值的直观证明。
5.2 答辩演示的设计思路
演示环节千万别一上来就打开 IDEA 跑代码，评审没耐心看代码，也看不懂。我的建议是准备一条“剧情线”：管理员创建考试，导入考生名单；考生登录系统，采集人脸并注册；进入考试，摄像头自动打开，考前核验通过；答题过程中故意切走页面一次，弹窗提示并记录异常；交卷，教师端查看考试统计和人脸验证日志。这条线走下来，系统所有核心功能都展示了，而且节奏紧凑。
过程中有几个细节要提前演练：摄像头权限要在浏览器设置里预授权，最好用本机地址而不是 HTTPS 证书过期的地址；演示用的光线要充足，不要在暗光下开摄像头；提前准备一张备用照片，万一识别失败可以解释为光照问题并换角度重试。最关键的是，如果方案是“Spring Boot + 独立人脸服务”，演示时要把两个服务都启动好，并且先跑一次接口连通性测试，避免现场出现连不上算法服务的乌龙。
5.3 面试与答辩高频问题应答要点
这个项目在答辩和求职面试里被问得最多的几个问题，我提前整理一下。第一个问题：“人脸识别的阈值是怎么确定的？”不要回答“我选的 0.75”，而要说“我通过测试集扫描，统计不同阈值下的误识率和拒识率后取的平衡点”，顺便把 4.1 节提到的测试流程讲一遍，这个问题就稳了。
第二个问题：“为什么不直接用 SDK 或者云 API？”正确思路是承认云 API 效果好，同时说明离线方案可控、可私有化部署、不依赖外部网络，这在考试场景里更稳妥。顺带提一句“如果生产环境对识别率要求更高，可以把算法层替换为云 API，业务层不用改动”，这体现了架构的扩展性。
第三个问题：“考中抽帧如何防止考生绕过前端上报？”如实讲三件事：一是后端校验考试会话状态，二是伪造请求会因缺失有效会话 ID 被拒绝，三是异常日志和考试成绩关联，教师端可以人工复核。哪怕这个方案不完美，也比你支支吾吾强得多。
第四个问题：“特征向量存数据库，上万考生会慢吗？”你需要给出方案思路：相似度比对先经过所在考场分组，只比对同考场考生，再配合阈值快速过滤，还可以引入 Redis 缓存近期活跃考生的特征向量。这种问题考察的不是你的最终答案，而是你的分析路径。
我做完这套基于 Spring Boot 的人脸识别在线考试系统后最深的体会是：这个项目的成败，通常不取决于人脸识别模型本身有多高级，而取决于你把“识别”这个动作嵌入到考试流程中的方式是否合理、可信、可解释。算法只要选型靠谱、阈值调参到位，剩下的功夫全在业务细节里。如果你正在做这个选题，我建议你把 80% 的精力花在考试全流程的逻辑闭环上，把考前、考中、考后的数据串成一条看得见的证据链，答辩时不慌，面试时也能讲出层次。最后再分享一个小技巧：把核心接口都留一个手工测试页面，比如人脸入库、单次比对、日志查询，演示时你会感谢这些看似简陋的后台页面帮你在突发状况下快速救场。