教室点名这件事做过老师的都知道有多费劲。五十个人的班一个个喊名字加答到快也要三四分钟还可能有人代答。要是选修课坐满一百多人光点名就能耗掉半节课。所以我一直在想能不能让手机自己把人脸认出来。后来我做的这个基于Android的人脸识别课堂考勤APP后端用SpringBoot管理端用Vue目标很直接学生进入教室后打开手机摄像头完成签到老师坐在讲台上就能看到实时出勤数据。完整链路是Android端采人脸特征SpringBoot后端负责比对与记录Vue管理端给教师查看统计。这篇文章把这个项目的设计思路、关键代码、踩坑过程都写出来适合正在做人脸识别考勤类毕业设计、或者想在企业内部落地课堂签到系统的开发者参考。我会尽量少讲大道理多给能直接用的实现方案。1. 项目整体设计与技术选型思路1.1 为什么非要做人脸识别考勤课堂考勤最怕的是“人到了但记录不到人没到却显示到了”。传统点名靠老师喊效率低实体卡可以找人代刷二维码签到容易被截图转发GPS定位签到也能让不在教室的同学远程操作。人脸识别把生物特征和本人绑定其他同学很难“借脸”这是它做考勤的天然优势。但我也得泼一盆冷水人脸识别不是万能的。光线差、戴口罩、低头玩手机、摄像头角度偏了识别率都会明显往下掉。所以从项目设计第一天起就要想清楚“识别失败了怎么办”而不是假设识别率100%。真正可用的考勤系统一定是识别主流程加人工兜底流程的组合。1.2 整体架构与三端职责这个项目拆成三个端职责非常清楚Android学生端人脸采集、本地特征提取、签到请求、查看个人考勤记录。SpringBoot后端用户鉴权、课程和班级管理、考勤记录、人脸特征库比对、统计报表接口。Vue管理端教师端负责创建课程、查看学生名单、导出考勤管理员端负责账号管理和全局统计。为什么后端选SpringBoot而不是Node或Go因为考勤业务里有事务、权限、定时任务、报表统计这些用SpringBoot生态是最省心的。管理端选Vue是因为组件化开发效率高做统计图表很方便。Android端为什么不用跨平台框架因为摄像头底层调用、实时预览、图像帧处理这些场景原生写起来更顺手遇到问题也好排查。1.3 人脸识别方案选型本地和云端混合人脸识别方案不是只有一种我对着三个方案比过方案优点缺点纯端侧识别离线可用、响应快特征库要同步到每台手机模型受性能限制纯云端识别模型统一、准确率稳依赖网络签到高峰并发压力大混合方案端侧检测提取特征后端只比对特征向量需要设计两段逻辑开发量稍大我更推荐混合方案。Android端把摄像头拍到的画面做人脸检测再提取成特征向量只把这个向量传给后端。后端和库里所有已注册学生的人脸特征做相似度计算返回是否匹配。这样网络传输量很小特征库统一维护在同一套数据库里以后要给小程序、平板端加签到入口也只需要复用后端的比对接口。有人问为什么不直接传照片。照片体积大传输慢还有隐私风险特征向量是不可直接还原成人脸的数值形式更适合做长期存储。这是我在这个项目里最坚持的一个设计决定。2. 数据库设计与核心接口定义2.1 核心表结构设计考勤系统的表结构我拆成了6张主表用户表、课程表、选课表、考勤记录表、人脸特征表、补签申请表。后面三张是关键我先给你看核心建表语句。CREATE TABLE user ( id BIGINT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, role TINYINT NOT NULL COMMENT 1学生 2教师 3管理员, real_name VARCHAR(50) NOT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE course ( id BIGINT AUTO_INCREMENT PRIMARY KEY, course_name VARCHAR(100) NOT NULL, teacher_id BIGINT NOT NULL, location VARCHAR(100), week_day TINYINT COMMENT 1-7, begin_time TIME, end_time TIME, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE course_student ( id BIGINT AUTO_INCREMENT PRIMARY KEY, course_id BIGINT NOT NULL, student_id BIGINT NOT NULL, UNIQUE KEY uk_course_student (course_id, student_id) ); CREATE TABLE attendance ( id BIGINT AUTO_INCREMENT PRIMARY KEY, course_id BIGINT NOT NULL, student_id BIGINT NOT NULL, attendance_date DATE NOT NULL, status TINYINT NOT NULL COMMENT 1正常 2迟到 3缺勤 4请假 5已补签, check_in_time DATETIME, face_image_url VARCHAR(255), UNIQUE KEY uk_attendance (course_id, student_id, attendance_date) ); CREATE TABLE face_feature ( id BIGINT AUTO_INCREMENT PRIMARY KEY, user_id BIGINT NOT NULL, feature_vector TEXT NOT NULL COMMENT 浮点数组JSON, photo_url VARCHAR(255), sample_count INT DEFAULT 1, create_time DATETIME DEFAULT CURRENT_TIMESTAMP );这里有几个设计要点可以重点说一下。考勤记录表的唯一键(course_id, student_id, attendance_date)是底线保障。如果没有这个唯一键同一课程同一天同一个学生可能因为重复提交产生多条记录后面的统计报表全乱掉。人脸特征单独建表不放在user表里是因为特征数据更新频繁而且长度不固定。feature_vector我用TEXT字段存JSON数组简单直接。如果团队里有更强的数据库基础可以考虑向量字段但这个规模的项目用TEXT完全够用不必为了炫技增加复杂度。2.2 接口设计思路接口尽量语义化让Android端和Vue端都能统一理解。核心接口我列成了表格接口方法作用说明/api/auth/loginPOST登录返回JWT Token/api/face/registerPOST注册人脸特征学生端采集完调用/api/attendance/check-inPOST签到上传特征向量加课程ID加定位信息/api/attendance/listGET考勤记录教师端按课程分页查询/api/attendance/statsGET统计出勤率图表展示用以签到接口为例请求体长这样{ courseId: 12, studentId: 88, faceFeature: [0.125, -0.036, 0.208], latitude: 31.2304, longitude: 121.4737 }为什么带上经纬度因为可以做一个简单的签到范围限制防止人不在教室也把课签了。但实际校园场景里GPS漂移很普遍校园内宿舍楼和教学楼距离可能只有一两百米太严格会把学生误判成不在场。我最后的做法是判断是否在学校范围半径500米内宁可稍微放宽也不要误伤。3. Android端人脸采集与识别流程实现3.1 人脸录入别一拍脑袋就存照片人脸录入是整个识别率的地基。很多项目一开始只让学生拍一张照片就完事结果课堂上换个光线就认不出来。我在录入页做了三遍采集每次间隔一秒让学生轻微转头、抬头保证不同角度都有样本最后对特征向量取平均再存到后端。这里有个容易犯的错不能只存原图。原图在比对时会受尺寸、光线影响很大必须把检测到的人脸区域标准化到固定尺寸再提取特征。关键代码我写成伪实现给你看class FaceRegisterActivity : AppCompatActivity() { private lateinit var cameraProvider: LifecycleCameraProvider private val faceDetector FaceDetector() override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) // 初始化摄像头预览这里省略CameraX绑定代码 } private fun onFaceDetected(bitmap: Bitmap) { val face faceDetector.detect(bitmap) if (face ! null face.confidence 0.85f) { val standardFace FaceUtils.alignAndResize(face.cropBitmap, 112, 112) featureList.add(faceDetector.extractFeature(standardFace)) if (featureList.size 3) { val avgFeature FeatureUtils.average(featureList) uploadToServer(avgFeature) } } } }这里的0.85置信度阈值不是拍脑袋定的。不同手机摄像头差异很大如果项目在暗光环境经常检测不到人脸可以适当调低到0.8但如果发现任意照片都能通过检测就要往上加。调参的过程最好拿一批真实手机录的视频去跑。3.2 签到时的比对逻辑学生打开APP进入签到页看到摄像头预览系统自动检测人脸并提取特征然后把特征向量传回后端由后端和库里的人脸特征做相似度比对。为什么比对不放在端侧因为特征库如果下发到每台手机每个学生的手机都要同步所有已注册学生的特征既占空间又涉及隐私。放后端统一控制阈值也方便后续扩展平板签到、网页签到等入口。比对策略我用的是余弦相似度sim cos(feature1, feature2)范围在-1到1之间通常大于0.82可以认为是同一个人。但不同模型的输出分布不一样不能照抄阈值。建议开发时拿至少50个人脸样本先跑一遍相似度分布画出“本人相似度”和“他人相似度”的分界线再定阈值。活体检测也要做最简单是动作指令屏幕随机显示“请眨眼”或“请张嘴”检测到对应动作才继续。太严格的活体检测会拖慢签到速度大班上课根本等不起。我最后只保留了非常轻量的“人脸检测加动作确认”应付照片攻击足够。3.3 摄像头调用与性能优化Android摄像头调用建议使用CameraXAPI清晰生命周期处理也简单。我踩过不少坑给你几个实用结论预览分辨率不要开太高1080p足够。分辨率越高每帧图像处理越慢。每次检测前先把帧转成灰度图既省内存又加快检测速度。人脸检测和特征提取放到单独的HandlerThread里不要占用主线程否则卡顿明显学生一着急就会退出重进。签到结果要立刻反馈识别成功、识别失败、等待中三种状态用不同颜色提示避免学生不知道现在是什么情况。我实测在中端手机上从摄像头取帧到拿到特征向量大约需要300毫秒加上网络请求整个签到过程稳定在1秒内。这个速度在50人的课堂上已经很舒服了。4. 后端考勤逻辑与服务端实现4.1 考勤状态与判定规则考勤不能只分“出勤”和“缺勤”还要区分迟到、请假、补签。我的规则是状态判定条件正常上课前10分钟到上课后10分钟内签到迟到上课后10分钟到30分钟签到缺勤课程结束后未签到请假教师后台手动标记已补签学生在规定时间内申请教师审批状态判断的Java代码public static int judgeStatus(LocalDate date, LocalTime courseBegin, LocalTime now) { if (now.isBefore(courseBegin.minusMinutes(10))) { return STATUS_EARLY; // 太早到了不能算签到这里可特殊处理 } if (now.isBefore(courseBegin.plusMinutes(10))) { return STATUS_NORMAL; } if (now.isBefore(courseBegin.plusMinutes(30))) { return STATUS_LATE; } return STATUS_ABSENT; }这个规则要和任课老师确认。有些老师觉得迟到5分钟就不该算正常有些老师觉得提前到也算到课。代码里把判断逻辑集中到一个工具类方便后续按不同课程配置规则。4.2 Controller和Service实现后端用SpringBoot核心签到接口长这样RestController RequestMapping(/api/attendance) public class AttendanceController { Autowired private AttendanceService attendanceService; PostMapping(/check-in) public ResultString checkIn(RequestBody CheckInRequest request) { try { attendanceService.checkIn(request); return Result.success(签到成功); } catch (BizException e) { return Result.error(e.getCode(), e.getMessage()); } } }真正关键的是Service层Service public class AttendanceService { Autowired private FaceFeatureMapper faceFeatureMapper; Autowired private AttendanceMapper attendanceMapper; Transactional public void checkIn(CheckInRequest request) { // 1. 根据学生ID查人脸特征 FaceFeature feature faceFeatureMapper.findByUserId(request.getStudentId()); if (feature null) { throw new BizException(该学生未注册人脸); } // 2. 相似度比对 double sim FaceCompareUtil.compare(feature.getFeatureVector(), request.getFaceFeature()); if (sim SIM_THRESHOLD) { throw new BizException(人脸匹配失败); } // 3. 判断当前时间状态并写入考勤记录 int status AttendanceStatusUtil.judgeStatus( LocalDate.now(), getCourseBeginTime(request.getCourseId()), LocalTime.now()); Attendance attendance new Attendance(); attendance.setCourseId(request.getCourseId()); attendance.setStudentId(request.getStudentId()); attendance.setAttendanceDate(LocalDate.now()); attendance.setStatus(status); attendance.setCheckInTime(LocalDateTime.now()); attendanceMapper.insertOrUpdate(attendance); } }注意insertOrUpdate不是现成框架内置方法需要自己实现。最简单的逻辑是先用唯一键查一次存在就更新不存在就插入。但直接用这个方法在高并发下会有竞态问题更稳妥的方式是依赖数据库的INSERT ... ON DUPLICATE KEY UPDATE在SQL层面解决重复插入。4.3 并发与防刷课堂签到有一个特点学生差不多都在同一分钟操作相当于把请求集中打进来。如果每秒钟只有几个请求写库完全没问题但如果一百人同时发数据库连接池很容易打满。我的处理思路有三层签到请求不做复杂计算先往Redis写一个去重标记同一个学生不能重复提交。把最终写库操作放进线程池异步执行前端只要收到“已受理”就认为成功不必等SQL提交完。数据库唯一索引兜底防止并发下重复数据。这里不推荐引入消息队列。课堂考勤的数据量并不大引入消息队列会把开发运维复杂度拉高。异步线程池加唯一索引足够。5. Vue管理端搭建与数据看板5.1 页面模块划分Vue管理端是给教师和管理员用的两个角色看到的菜单不一样。教师端核心页面包括工作台今日课程卡片显示当前时间是否有课。课程管理创建课程、维护选课学生名单。考勤记录按课程和日期查看签到明细支持导出Excel。补签审批处理学生提交的补签申请。管理员端比教师端多出用户管理和全局统计。权限控制我用路由前置守卫根据登录返回的角色字段动态生成菜单。这里要提醒一句前端控制显示只是用户体验后端接口必须做角色校验否则学生直接调接口就能绕过权限前面做再漂亮都没用。5.2 图表统计怎么做考勤报表一定要有图否则老师面对几十个零散记录很难一眼看出问题。我用开源图表组件库生成折线图和柱状图展示课程出勤率趋势和学生个人出勤趋势。图表接口返回统一结构{ courseName: 软件工程实践, total: 52, normal: 44, late: 3, absent: 5, rates: { normal: 0.846, late: 0.058, absent: 0.096 } }前端拿到数据后直接塞给图表组件不需要做二次计算。这里有个经验统计接口最好在后端聚合好不要返回几十条明细让前端循环算否则课程数量一多页面就会卡顿。5.3 Axios封装与Token处理管理端所有接口都通过Axios请求我封了一个request模块请求前从localStorage取Token放到Authorization头。响应统一处理业务错误码遇到401自动跳登录页。文件下载接口用单独封装防止Token丢失或流处理错误。封装的标准是页面组件里只关心业务数据不关心请求细节。多人开发时如果每个人写自己的请求逻辑后面改Token方式就得全局搜一遍。6. 开发中踩过的坑与优化建议6.1 人脸识别在日常课堂里的翻车现场我第一次做真实测试的时候一个班四十多人很快发现不是每个学生都能顺利签到。第一类是光线问题。靠窗学生逆光脸是黑的角落学生光线不足检测不到人脸。解决办法是在摄像头预览层加一个亮度提示太暗时提示学生“请向亮处移动”不要让签到流程静默失败。第二类是角度问题。学生低头看手机时脸离镜头太近或太偏特征提取效果差。我在UI上画了一个人脸轮廓框要求学生把脸对准框内体验上清晰很多。第三类是戴口罩。这个我最后选择用后端教师手动确认的方式如果连续三次识别失败系统自动给教师端发一条异常记录教师点击确认后手动标记为到课。人脸识别解决绝大多数场景剩下个别场景交给人工兜底是这套系统能真正落地的关键。6.2 网络与后端的高频问题实际跑起来后最头疼的不是人脸识别而是网络。教室里的校园网信号经常不稳定Android端请求超时是很常见的事。我做了两个改动前端请求设置合理超时时间默认3秒。不要用10秒否则排队等太久体验很差。识别成功但请求超时的场景允许一键重试重试时带上同一个请求ID后端根据ID做幂等处理避免重复写入。还有一次压测发现并发上来后数据库连接池报错。排查发现默认连接池只有10条太小了调整到30后好了很多。我又给签到服务加了一个简单的信号量限流超过200并发就返回“当前签到人数过多请稍后重试”总比让数据库崩溃强。6.3 阈值校准与模型迭代最后说一个容易被忽视的点人脸特征模型不是一劳永逸的。学生换了发型、戴了眼镜特征会有变化。我在系统里保留了“重新录入人脸”入口并且加了一个特征动态校准逻辑每次成功比对时把新特征按一定权重更新到该学生的历史特征向量里类似于滑动平均。这样特征库会跟着学生一起“生长”一段时间后识别会稳定很多。但这个逻辑要谨慎。如果每次都无脑更新一旦发生误识别特征库会被污染。我的做法是只有相似度高于0.9时才更新0.82到0.9区间只做记录不更新这样既保持稳定性又不会让异常数据破坏特征库。7. 这套系统还能往哪些方向扩展7.1 课堂场景之外的复用做完整套项目之后我发现这套架构完全可以复用到其他场景。第一个是会议签到。参会人员入场时用同一套Android端扫脸后端把课程ID换成会议ID签到逻辑基本不用改。第二个是实验室门禁不需要做复杂门锁在门口放一台Android平板学生扫脸后在管理端留痕就行。第三个是考务系统考试入场时验证考生身份防止替考。这些场景的核心链路都是一样的端侧提取人脸特征后端比对记录。只是业务字段和展示页面不同。所以我把后端的人脸比对服务设计成独立模块不绑定考勤表任何业务需要身份验证直接调用同一个比对服务就行。7.2 扩展前先想清楚边界扩展看着都很美好但落地时每一样都是工作量。人脸识别最核心的还是识别率、速度、体验三者之间的平衡而不是功能越多越好。比如会议签到参会人数可能上千后端识别接口的并发压力比课堂高一个量级实验室门禁要24小时运行对设备稳定性的要求完全不同考务系统一旦识别失败必须有人工仲裁流程不能直接把人拦在考场外。这些都是扩展时的边界条件设计时要提前想好。如果一开始就把系统设计成三端分离再把人脸比对抽成独立服务后续扩展其实是顺水推舟的事。最后再分享一个小技巧别一上来就写复杂算法先用手头手机录几段视频把检测置信度和相似度阈值跑出分布再决定怎么定参数。参数有据可依后面才不用反复返工。这套课堂考勤APP做完我最大的体会是“考勤系统不难难的是把细节做稳”尤其是兜底流程和阈值校准这两个地方值得多花时间。