人脸识别考勤系统Python毕设：从摄像头到数据库的完整实现

简介：人脸识别技术已从实验室走向课堂与办公场景，考勤作为高频刚需，正经历从人工点名到自动识别的转变。其背后原理并不神秘，通常由人脸检测、对齐、特征编码与比对四段流水线构成，核心是提取128维或更高维的特征向量，通过欧氏距离判断是否为同一人。在Python生态中，借助face_recognition、OpenCV与Flask，即可搭建一套可运行的Web考勤应用，前端调用摄像头截帧上传，后端完成特征匹配并落库，兼顾采集、识别与防重复签到。此类项目不仅适合毕业设计演示，也是理解Web应用前后端协作的实战样本。本文以一例基于人脸识别的上课考勤系统为主线，拆解从数据库表设计到阈值调优的完整链路，为学习者提供可复现的工程思路。

1. 教室点名还在喊“到”，这套人脸识别考勤系统盯上了那 5 分钟

教室门禁机上的人脸识别见多了，但大学课堂里，点名还是靠喊一声“到”。一节课 40 分钟，点名花掉 5 分钟，后排还能找人代答。这个 Python 毕设标题——基于人脸识别的上课考勤系统，要解决的就是这件事：前端页面打开摄像头，自动识别画面里的人脸；后端录入界面把学生照片、姓名、学号建档，识别通过后自动落一条考勤记录。它适合两类人：一是正在做毕业设计或课程设计的在校生，需要一套能演示、能答辩、能跑通的完整方案；二是刚学完 Python 基础、想拿真实项目练手的人。这个项目把摄像头调用、图像处理、Web 后端、前端页面串了一遍，做完它，你对“一个 Web 应用怎么跑起来”的理解，会比看十遍教程都深。

2. 人脸识别流水线拆开看：检测、对齐、编码、比对的最短可用实现

很多第一次做人脸识别的同学，把整个人脸识别当成一个黑匣子：塞一张照片进去，蹦一个名字出来。真去拆项目才知道，它是一条四段流水线。搞懂每一段的输入输出，后面调参、定位 bug 才不会抓瞎。

2.1 一条流水线四个环节，参数藏在两个地方

人脸识别的标准流水线是：人脸检测、人脸对齐、特征编码、特征比对。人脸检测负责从整张图里找出“哪里有人脸”，输出每个人脸的边界框坐标；人脸对齐用眼睛、鼻子、嘴的关键点做仿射变换，把脸摆正、缩放到统一尺寸；特征编码把摆正的人脸映射成一个固定长度的向量，face_recognition 用的是 128 维浮点向量；特征比对把这个向量和数据库里预先存好的向量算欧氏距离，距离小于阈值就认为是同一个人。

你会发现，需要调参的地方其实只有两个：检测阶段选模型，比对阶段定阈值。中间的对齐和编码，框架帮你做完了。理解了这个结构，你再去读 face_recognition 或 OpenCV 的代码，就知道每个函数在流水线上处于哪个位置，报错信息也不再是天书。常见的误用是把人脸检测的输出顺序搞错，face_locations 返回的不是 (x, y, w, h)，而是 (top, right, bottom, left)，按错顺序画框，人脸框永远画歪，这个我后面踩坑部分还会再提。

2.2 三套方案怎么选：OpenCV Haar、face_recognition、InsightFace

人脸识别从传统方法到深度学习有好几代演进，毕设选型时不用赶时髦，够用、能讲清、跑得动是三条硬标准。常见的有三套方案。

毕设我一般选 face_recognition。原因很实在：接口短，几行就能完成提取和比对，新手能看懂；社区资料多，报错几乎都能搜到答案；dlib 的模型文件几十 MB，单机就能跑，不像深度模型那样先配 CUDA 再下载几个 G 的权重。有人会说 EasyAI 这类现成人脸识别接口更省事，也有人坚持上 ArcFace 把精度顶到 99%，那是进阶的事。毕业设计答辩要的是“你理解这套原理并且自己实现了流程”，而不是“你调用了一个看不见的服务”。

2.3 最小自测代码：一张图的比对先跑通，再谈系统

动手写系统之前，我习惯先用 20 行代码验证环境，确认模型能加载、比对能出距离。这一步能过滤掉一堆环境问题，免得写到一半才发现 dlib 装不上。

import face_recognition # 加载注册照片并提取人脸特征，取第 0 张脸 known_img = face_recognition.load_image_file("known.jpg") known_enc = face_recognition.face_encodings(known_img) if not known_enc: raise SystemExit("known.jpg 里没检测到人脸") # 加载测试照片，提取里面所有人脸 unknown_img = face_recognition.load_image_file("unknown.jpg") unknown_encs = face_recognition.face_encodings(unknown_img) # 逐张做欧氏距离比对，阈值取 0.6 for enc in unknown_encs: dist = face_recognition.face_distance([known_enc[0]], enc)[0] same = "通过" if dist < 0.6 else "不通过" print(f"欧氏距离: {dist:.3f} -> {same}")

这段代码把流水线四个环节压缩成了三个函数调用：load_image_file 负责读图，face_encodings 内部完成检测、对齐、编码，face_distance 输出欧氏距离。关键参数有两个：一是 face_encodings 对一张照片会返回多张人脸的编码列表，取下标时要确认取的是哪张脸；二是 0.6 这个阈值，它是 dlib 的默认推荐值，但不是金标准。我在实际项目里会把阈值放到 0.5 到 0.55 之间，考勤是“把陌生人挡在外面”的场景，宁可个别同学要重刷，也不要放进来一个代签的人。

跑通这 20 行，接下来做录入和考勤就有了地基。环境安装确实要折腾一下：Python 版本建议 3.9 到 3.11，在 cmd 里执行 pip install face_recognition opencv-python flask，numpy 会作为依赖自动装上。Dlib 在 Windows 上偶尔编译报错，多半是缺 CMake 和 Visual Studio Build Tools，直接找预编译的 wheel 包是最省心的解法。这类问题都属于“第一次难受，装完再也不碰”。

3. 后端录入界面：特征采集、SQLite 建表与一个能用的 Flask 接口

3.1 录入界面录什么：一张照片加一个学号，存的是特征不是脸

标题里说的“后端录入界面”，翻译成实际操作就是管理员打开的一个录入网页：输入学号、姓名，上传或拍摄学生照片，点击提交。但录入的信息不是一个 JPG 那么简单。录入界面要完成的动作是给学生拍一张照，后台检测到人脸后提取 128 维特征，再把“学号 + 姓名 + 特征向量”绑定，写进数据库。

之所以不直接存照片，有三个原因。第一，比对速度：考勤时要遍历整个库算距离，特征向量是浮点数组，比读图再编码快一个数量级。第二，隐私：学生照片属于敏感个人信息，库里只存特征向量，导出系统时不会泄露照片；第三，可更新性：同一个学生可以录多份特征，比对时取最小距离，能明显降低光线和角度带来的影响。

3.2 三张表把学生、特征、考勤拆开

数据库我用 SQLite，零配置、单文件，毕设完全够用。表结构按职责拆成三张：students 存学生基础信息，face_features 存特征向量，一个学生可以多条，attendance 存签到记录。外键把三张表串起来，考勤表只关联 student_id，不直接存姓名，避免改名时数据杂乱。

CREATE TABLE students ( id INTEGER PRIMARY KEY AUTOINCREMENT, student_no TEXT UNIQUE NOT NULL, name TEXT NOT NULL, created_at TEXT DEFAULT (datetime('now', 'localtime')) ); CREATE TABLE face_features ( id INTEGER PRIMARY KEY AUTOINCREMENT, student_id INTEGER NOT NULL, feature BLOB NOT NULL, -- 128 维 float32 序列化后存入 sample_index INTEGER DEFAULT 0, -- 第几张样本 FOREIGN KEY (student_id) REFERENCES students(id) ); CREATE TABLE attendance ( id INTEGER PRIMARY KEY AUTOINCREMENT, student_id INTEGER NOT NULL, course_time TEXT NOT NULL, -- 哪节课，如 2026-06-01 08:00 check_in_at TEXT DEFAULT (datetime('now', 'localtime')), UNIQUE (student_id, course_time), FOREIGN KEY (student_id) REFERENCES students(id) );

代码里值得解释的是 feature 字段的类型。face_recognition 提取出的 128 维向量是 numpy 数组，不能直接塞进 SQLite，要先用 tobytes() 转成 bytes 再存 BLOB，读出来时用 np.frombuffer() 还原成 float32 数组。attendance 表上的 UNIQUE(student_id, course_time) 是防重复签到的数据库层兜底，即使前端按钮被连点两次，第二次插入也会因唯一约束失败，这比只在前端做按钮置灰可靠得多。course_time 不要只存日期，同一学生上午下午各有一节课，日期相同但课程时间不同，照样能正常记录。

3.3 Flask 接收入口：校验人脸、提取特征、落库返回

后端录入界面的核心是一个 POST 接口，接收学号、姓名和照片文件。接口要做三件事：检测照片里有没有人脸；提取特征；写入数据库。检测不到人脸时不能静默成功，要返回明确错误让前端提示“请正对摄像头重拍”。

import io import numpy as np import face_recognition import sqlite3 from flask import Flask, request, jsonify from flask_cors import CORS app = Flask(__name__) CORS(app) # 允许前端跨域调用 @app.route("/api/register", methods=["POST"]) def register(): student_no = request.form.get("student_no") name = request.form.get("name") file = request.files.get("photo") if not all([student_no, name, file]): return jsonify({"code": 1, "msg": "学号、姓名和照片不能为空"}) # 读取图片并检测人脸 img = face_recognition.load_image_file(io.BytesIO(file.read())) encodings = face_recognition.face_encodings(img) if not encodings: return jsonify({"code": 2, "msg": "照片里没有检测到人脸，请正对摄像头重拍"}) # 特征序列化后入库 with sqlite3.connect("attendance.db") as conn: cur = conn.cursor() cur.execute("INSERT INTO students(student_no, name) VALUES(?,?)", (student_no, name)) student_id = cur.lastrowid feature_bytes = encodings[0].tobytes() cur.execute("INSERT INTO face_features(student_id, feature) VALUES(?,?)", (student_id, feature_bytes)) conn.commit() return jsonify({"code": 0, "msg": "录入成功", "student_id": student_id})

接口三个参数要说明：request.form.get 读取表单字段，适合前端 FormData 提交；照片文件用 request.files 拿；face_encodings 只取第 0 张脸，如果照片里有多人，第 0 张未必是学生本人，所以录入场景我会在前端引导让脸部占画面大部分，或者在后端先做人脸检测，检测到多张脸直接报错“画面里只能有一张脸”。录入的快门质量比数量重要，一次拍清远胜拍五张模糊的，这是识别率的直接决定因素。录入页面前端很简单，一个内联表单，学号输入框、姓名输入框、文件上传控件、提交按钮，提交时 new FormData() 把文件 append 进去，用 fetch POST 到 /api/register 就行。

如果你希望用 Vue3 做录入页，Flask 这边完全不用改，跨域已经由 CORS 打开，前端用 axios 传 FormData 即可。很多人纠结“后端到底用 Flask 还是 FastAPI”，毕设我建议 Flask，教材多、查错快。Java Spring Boot 也能做考勤系统，但人脸部分既然 Python 生态最顺手，全栈 Python 是写代码最少的路径。

4. 前端签到页与考勤落库：摄像头取帧、特征比对和去重签到

4.1 为什么识别放后端：浏览器不是吃模型的地方

签到流程的前端长这样：页面打开、摄像头启动、学生面对镜头点“签到”，页面返回“张三 签到成功”。这里有一个架构决策：人脸识别跑在后端 Flask，前端只负责取帧上传。为什么不直接在浏览器里跑 face_recognition？一是 dlib 这类模型跑在浏览器需要额外打包，工程复杂，演示时还容易卡；二是模型和数据库都在后端，管理方便；三是前后端职责分离，签到页只干一件事，拿画面换结果，这也是前后端分离项目实战里最典型的交互模式。

如果你想把它升级成 Vue3 单页应用，前端换成 axios 调同一个接口就行，后端路由不用动。这里有一个前端部署小经验：签到页更新后，浏览器可能缓存旧 JS，我给 script 标签加上版本号参数强制刷新，比如 app.js?v=20260601，比让用户手动清缓存省事得多。

4.2 前端页面：打开摄像头、截帧、提交一帧

前端核心代码就三段：启动摄像头、截帧、上传。getUserMedia 负责打开摄像头，canvas 负责从视频流里截一帧，fetch 负责把这一帧 POST 给后端。

<video id="video" width="640" height="480" autoplay></video> <button id="btnCheckIn">签到</button> <script> const video = document.getElementById("video"); // 启动摄像头 navigator.mediaDevices.getUserMedia({ video: true }) .then(stream => { video.srcObject = stream; }) .catch(err => console.error("摄像头启动失败:", err)); document.getElementById("btnCheckIn").onclick = async () => { // 从视频流截取一帧，缩放到 640x480，JPEG 压缩后上传 const canvas = document.createElement("canvas"); canvas.width = 640; canvas.height = 480; canvas.getContext("2d").drawImage(video, 0, 0, 640, 480); const blob = await new Promise(resolve => canvas.toBlob(resolve, "image/jpeg", 0.9)); const fd = new FormData(); fd.append("frame", blob, "frame.jpg"); const resp = await fetch("/api/checkin", { method: "POST", body: fd }); const data = await resp.json(); alert(data.msg); // "签到成功: 张三" 或 "未识别，请重试" }; </script>

这段代码有三个值得注意的地方。getUserMedia 需要 HTTPS 或者 localhost 环境，直接用 IP 访问会被浏览器拦掉，调试时用 127.0.0.1 最省事。canvas 截帧的分辨率我固定为 640×480，这是速度和精度的折中，2K 摄像头截全图不仅上传慢，后端检测大图也慢。JPEG 质量 0.9 足够，人脸特征提取对压缩失真不敏感，没必要传原图。另外按钮点击后要立刻置灰 disabled，等请求返回再恢复，这是前后端对重复提交都做校验的标配做法，防止学生手抖连点两次产生重复记录。

4.3 后端识别路由：多脸取最大、阈值比对、防重落库

后端识别路由拿到这一帧图片后做四步：检测人脸、提取特征、和库里所有人比对、写入考勤记录。下面代码里 Flask、numpy、io 等沿用 3.3 的导入。

@app.route("/api/checkin", methods=["POST"]) def check_in(): file = request.files.get("frame") img = face_recognition.load_image_file(io.BytesIO(file.read())) locations = face_recognition.face_locations(img, model="hog") encodings = face_recognition.face_encodings(img, locations) if not encodings: return jsonify({"code": 1, "msg": "没有检测到人脸"}) # 多人同框时，取画面面积最大的人脸做主识别目标 areas = [(b[2]-b[0]) * (b[3]-b[1]) for b in locations] target_enc = encodings[areas.index(max(areas))] # 遍历库中全部特征，取最小欧氏距离 with sqlite3.connect("attendance.db") as conn: rows = conn.execute( "SELECT s.id, s.name, f.feature FROM face_features f " "JOIN students s ON s.id=f.student_id" ).fetchall() best_id, best_name, best_dist = None, None, 0.6 for sid, name, feat in rows: feature = np.frombuffer(feat, dtype=np.float32) dist = face_recognition.face_distance([feature], target_enc)[0] if dist < best_dist: best_dist, best_id, best_name = dist, sid, name if best_id is None: return jsonify({"code": 2, "msg": "未识别，请再试一次"}) # 写入考勤记录，数据库唯一约束兜底防重复 try: with sqlite3.connect("attendance.db") as conn: conn.execute( "INSERT INTO attendance(student_id, course_time) VALUES(?,?)", (best_id, current_course_time()), # 格式如 "2026-06-01 08:00" ) except sqlite3.IntegrityError: return jsonify({"code": 3, "msg": f"{best_name} 已签到"}) return jsonify({"code": 0, "msg": f"签到成功: {best_name}"})

识别路由的关键点有三个。face_locations 的 model="hog" 表示用 HOG 检测器，CPU 上跑得快，一张 640×480 图大概几十到一百毫秒；换成 model="cnn" 精度高但慢，实景演示时体感卡顿。多人同框的处理是取面积最大的人脸，考勤机前通常是单个学生，背景里的同学脸更小，选最大脸基本就是目标，但这也意味着学生站位不能太靠后。阈值我在系统里用 0.6，比 2.3 节最小验证代码的 0.55 宽松一些，因为上课场景里学生的角度、发型、光线变化大，卡得太死会把个别同学拦在外面。考勤写入失败还有一种可能就是 course_time 的格式对不上，全程序要统一用一个 current_course_time() 函数生成课程时间，别一个接口一个写法。

5. 避坑清单：从摄像头黑屏到识别率翻车，五个调了一晚上的问题

做毕设的人大多经历过“代码没问题，演示翻车”的时刻。人脸识别考勤这种带摄像头、带模型、带前端的项目，翻车点和纯后端项目完全不同。我把最常见的五类问题按现象、原因、解决写出来，照着排查能省一个通宵。

5.1 摄像头前的坑：采集质量与权限

第一个坑：注册时照片挺清晰，考勤时却频繁“未识别”。现象是同一学生在录入界面录了好几张，签到时还是识别失败。原因是注册照片和签到画面的光线、角度差异太大，比如注册照片是手机自拍，考勤画面是教室顶光，人脸特征对光线非常敏感。解决方法是注册时也用签到同款摄像头和同款画面，录入界面上加一个“实时取帧”按钮而不是只支持上传照片，并且每个学生录 2 到 3 次，分别拍正脸、微侧脸，比对时取最小距离。很多项目把这个坑甩给算法，其实是采集环节偷了懒。

第二个坑：浏览器提示摄像头启动失败，画面黑屏。现象是 getUserMedia 的 then 没执行，catch 里报 NotAllowedError，按钮点了没反应。原因是浏览器权限被拒，或者页面跑在 HTTP 非 localhost 域名下，浏览器出于安全策略直接禁止调用摄像头。解决方法是本地调试全部用 127.0.0.1，部署演示时把页面放上 HTTPS，或提前在浏览器设置里给该站点授信摄像头权限。这个坑在答辩教室最常见，教室电脑默认禁了摄像头权限，提前一天去试环境比现场解权限靠谱得多。

提示：答辩前一晚一定要在答辩用的那台电脑上完整跑一遍签到流程，换一台电脑就可能触发权限、驱动、分辨率三连坑。

5.2 请求链路里的坑：跨域、编码与性能

第三个坑：前端页面请求后端接口报跨域错误。现象是浏览器控制台出现 blocked by CORS policy，接口明明在 Postman 里能通，前端却调不通。原因是前端页面和后端 Flask 跑在不同端口，浏览器的同源策略拦下了请求。解决方法是 Flask 里装 flask-cors，初始化时 CORS(app) 一行搞定。这里有个小排查技巧：如果看到的是 401 或 404 而不是 CORS 报错，说明请求已经到达后端，是路由或鉴权的问题，别在跨域上浪费时间。

第四个坑：中文姓名入库后读出乱码，或者 face_recognition 加载中文路径图片报错。现象是 JSON 返回的 msg 变成一串 \u5f20\u4e09 这样的转义字符，前端直接显示出来很难看。原因是 Flask 默认 JSON 响应会做 ASCII 转义，前端拿到的是 unicode 码点而不是中文字符。解决方法是设置 app.config["JSON_AS_ASCII"] = False，让接口直接返回 UTF-8 中文。另一个中文坑是 dlib 在部分平台上读不了中文路径的图片，项目目录和图片文件名统一用英文，姓名只存数据库，别拿姓名当文件名。

第五个坑：识别一次要转圈两三秒，学生排队等到尴尬。现象是点击签到后响应时间很长，CPU 风扇狂转，演示观感很差。原因是每次请求都重新加载了一遍 dlib 模型，100 多 MB 的模型文件反复读盘，加上大图检测耗时。解决方法是确保模型全局只加载一次，face_recognition 的模型其实在第一次调用后常驻内存，关键是你别每次请求都开新进程；再把 canvas 截帧从 1280 缩到 640，检测数据量直接降到四分之一。如果还慢，检查是不是把 model 设成了 cnn，实景演示用 hog 足够，cnn 留给离线分析。

6. 验收别只靠演示顺利：三个验证指标和一个调阈值的脚本

6.1 三个验证维度：正确识别率、漏检率、误检率

毕设答辩时“演示顺利”是不够的，评审老师一定会问“你这个系统的准确率是多少”。我建议提前做一次简单的实验，自建一个测试集。每个学生录 3 组照片：正常光、暗光、侧脸，全部不进注册库，只用来测试。

漏检率看的是 face_locations 环节，误检率看的是比对阈值。两个指标互相拉扯：阈值调低，漏检率上升；阈值调高，误检率上升。所谓调阈值，就是在两者之间找一个平衡点。

6.2 一个脚本打印距离分布，阈值就有了依据

别凭感觉定 0.6。把测试集里“同一个人”的正样本距离和“不同人”的负样本距离全部算出来打出来，阈值取两类距离的分界点。

import face_recognition def collect_distances(known_enc, test_encs, is_same): distances = [] for enc in test_encs: d = face_recognition.face_distance([known_enc], enc)[0] distances.append((is_same, round(d, 3))) return distances # 用法：把同一个人不同光线下的照片设为 is_same=True # 把其他学生的照片设为 is_same=False # 结果可以 print 出来，也可以画成散点图观察 # 画图时注意把横坐标刻度调稀疏一点，不然贴在一起看不清

跑完打印所有 (is_same, distance) 后，你会看到正样本集中在 0.3 到 0.45，负样本集中在 0.5 到 0.8。选 0.5 左右作为阈值，两边都留余量，这个数值就是你答辩时回答“阈值为什么这么定”的依据。我自己的习惯是交项目前把注册信息从库里删掉，当成第一次使用的人重新走一遍录入和签到，用新光线、新设备、新距离下的首次跑通结果作为最终准确率，而不是拿已经反复验证过的老照片自欺欺人。人脸识别这种项目，数据采集环节偷的懒，最后都会十倍体现在演示翻车上。希望上面的思路能帮你把这个毕设做扎实，希望帮到你。

本文还有配套的精品资源，点击获取