简介一套基于Python的人脸识别课程考勤管理系统项目实例面向具备Python编程基础并熟悉Web开发、数据库及计算机视觉的高校师生、研发人员和教育技术从业者可替代传统课堂点名提升考勤效率和公平性既适合智慧校园场景落地也可作为人工智能与软件工程的综合教学案例。压缩包内仅有一份docx文档体积约115KB内容从项目背景、目标意义、挑战解决方案、系统总体架构到人脸检测与定位、人脸对齐与特征提取、实时身份匹配、考勤业务逻辑及MySQL表结构设计均有详细展开。文中给出人脸采集、检测裁剪、特征库构建、实时识别与考勤记录写入的关键代码示例并融入隐私保护、鲁棒性与扩展性设计便于读者按目录逐段实践。目前已有97人学习下载。读完可掌握OpenCV、face_recognition与Flask/FastAPI、Tkinter的整合方式理解数据库接口与识别流程的协同设计为独立开发可落地的考勤系统打下扎实基础。1. 人脸识别考勤系统选型Python自建还是买现成的门禁机教室或公司门口的人脸识别门禁机已经很多了但真拿它做课程考勤你会发现它是个黑匣子识别逻辑改不了员工或学生打卡记录导不出更别说按课程、按班级、按周统计迟到缺勤。基于Python的人脸识别考勤系统把整条链路摊开——摄像头取帧、人脸检测、特征提取、比对写库、GUI展示考勤报表每一步都握在自己手里。它适合有Python基础的学生做课程设计或毕业设计也适合小团队做内部考勤系统既能学到计算机视觉的落地流程又能把SQLite或MySQL的增删改查、GUI设计一起练到。2. 人脸识别链路与算法选型检测、对齐、特征提取、比对2.1 人脸检测、对齐、特征提取、比对四步链路不能省哪步很多人以为人脸识别就是把摄像头里的脸和数据库里存的脸比一下实际跑起来会发现不是这么回事。完整链路是四步先做人脸检测在画面里把人脸框出来再做对齐用眼睛、鼻尖、嘴角这些关键点把歪着的脸摆正然后是特征提取把一张脸压缩成一个128维或512维的向量这一步才是数字身份证最后是相似度比对算两个向量的欧氏距离或余弦距离距离小于阈值就判定为同一个人。考勤场景里有个常见误判把大量精力花在GUI和数据库上识别环节却用OpenCV自带的Haar级联分类器。Haar级联能跑通演示但它是老办法人脸角度稍微偏一点、戴个眼镜、光线暗一点就检测不到。做课程考勤这种要长期用的系统我一般不建议拿它当主力方案它更适合做入门演示帮你理解检测框长什么样。真正的考勤系统特征提取环节至少要用dlib或深度学习模型否则开学季几十个人排队打卡那一幕会直接卡到怀疑人生。2.2 人脸识别算法选型OpenCV、dlib、face_recognition、ArcFace怎么选选错算法库是这个项目最常见的翻车点。我按实际场景列一个对比表方便你对着自己的硬件条件选。方案检测模型特征维度适合场景主要缺点OpenCV Haar LBPHHaar级联局部二值模式直方图极简教学Demo角度、光照敏感识别率低dlib 自训练模型HOG或CNN人脸检测128维桌面端考勤、会员识别CNN模型在CPU上吃性能face_recognition封装dlib的HOG/CNN128维快速原型、课程项目安装依赖dlib编译环境麻烦InsightFace/ArcFaceRetinaFace/MTCNN512维工业级刷脸门禁、大门考勤模型体积大对硬件有要求face_recognition这个库封装了dlib用起来最省事也是很多Python人脸识别课设的默认选择它底层把检测、对齐、提特征、比对都包好了适合把重点放在考勤业务上的项目。ArcFace这类方案识别精度更高但模型大、依赖重单人开发的小系统没必要一上来就上。真实项目里有个更务实的做法快速原型用face_recognition验证流程确认考勤逻辑没问题再替换成InsightFace也不迟。2.3 相似度阈值是玄学吗欧氏距离与余弦相似度的参数设置阈值调参看起来像玄学其实是可以量化的。face_recognition默认用欧氏距离tolerance默认0.6意思是距离小于0.6就算同一个人。实际考勤里我一般调到0.5因为你宁可让一个人多刷一次也不想让他误打卡成别人。ArcFace那边用的是余弦相似度常见判定区间在0.4到0.6附近但不同模型训练的分布不一样不能直接拿别人项目里的阈值套。我见过很多项目直接硬编码0.5就上线结果晴天一个样、阴天另一个样。靠谱的做法是拿一小批数据把阈值量化出来注册10个人每人不同光线拍20张两两算距离把同一个人的距离分布和不同人的距离分布画出来找两者交界处作为阈值。下面这段代码就是用NumPy统计类内类间距离的简化版选型阶段跑一遍比上线后拍脑袋调参靠谱得多。import numpy as np def estimate_threshold(encodings_by_person): encodings_by_person: dict, key为人员编号, value为该人员所有特征向量列表 返回同一人距离均值、不同人距离均值以及建议阈值 same_dists, diff_dists [], [] ids list(encodings_by_person.keys()) for i in ids: feats encodings_by_person[i] # 当前人员的所有特征 # 类内距离同一个人特征两两算欧氏距离 for j in range(len(feats)): for k in range(j 1, len(feats)): same_dists.append(float(np.linalg.norm(feats[j] - feats[k]))) # 类间距离与其他人算距离 for h in ids: if h i: continue other_feats encodings_by_person[h] for feat_a in feats: for feat_b in other_feats: diff_dists.append(float(np.linalg.norm(feat_a - feat_b))) same_mean np.mean(same_dists) diff_mean np.mean(diff_dists) print(f类内距离均值: {same_mean:.3f}, 类间距离均值: {diff_mean:.3f}) print(f建议阈值: {(same_mean diff_mean) / 2:.3f}) return (same_mean diff_mean) / 2这段代码的作用不是直接放进考勤系统而是算法选型时用来定调如果类内距离和类间距离分得很开说明当前模型适配你的数据如果两类距离大量重叠就别调了该换模型或补样本。参数说明np.linalg.norm默认计算L2范数对应欧氏距离特征向量维度必须一致128维对128维混用不同模型算出来的距离没有任何意义。定阈值这一步看着麻烦但能省掉上线后反复调参的血泪时间。3. 系统设计与数据库四张表的结构和GUI布局3.1 考勤系统需求拆解最少四张表考勤系统不是只有一张打卡记录表那么简单。最少要有学生表、课程表、考勤表、管理员表四张。学生表存学号、姓名、专业、人脸特征编码、照片路径课程表存课程名、老师、上下课时间考勤表才是核心存学号、课程ID、打卡时间、考勤状态管理员表用来做登录控制。为什么不能只靠一张表因为你要按课程统计出勤率按班级筛选迟到名单没有课程表做关联报表只能是一锅粥。下面是我常用的SQLite建表结构。face_encoding字段用BLOB类型保存128维float数组的二进制比存成文本再解析快得多也省空间。CREATE TABLE student ( id INTEGER PRIMARY KEY AUTOINCREMENT, student_no TEXT UNIQUE NOT NULL, name TEXT NOT NULL, major TEXT DEFAULT 未设置, face_encoding BLOB, photo_path TEXT, create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE course ( course_id INTEGER PRIMARY KEY AUTOINCREMENT, course_name TEXT UNIQUE NOT NULL, teacher TEXT, start_time TEXT, end_time TEXT ); CREATE TABLE attendance ( attendance_id INTEGER PRIMARY KEY AUTOINCREMENT, student_no TEXT, course_id INTEGER, check_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP, status TEXT DEFAULT 正常, FOREIGN KEY(student_no) REFERENCES student(student_no), FOREIGN KEY(course_id) REFERENCES course(course_id) ); CREATE TABLE admin ( admin_id INTEGER PRIMARY KEY AUTOINCREMENT, username TEXT UNIQUE NOT NULL, password TEXT NOT NULL );建表逻辑说明student_no在student表和attendance表里都是TEXT类型并且attendance表通过外键关联到student表保证不会出现打卡了但没这个人的脏数据。check_time用DEFAULT CURRENT_TIMESTAMPPython插入时不需要手动填时间数据库会自动打点。status字段预留了正常迟到缺勤状态位实际判断迟到是在写入比较时用course表的start_time算出来的不在建表里写死。3.2 数据库连接封装SQLite起步MySQL迁移的三个注意点课程设计阶段用SQLite最省事就一个文件不需要安装服务。但很多企业场景要求用MySQL多人并发这时要把连接的逻辑封装一下方便切换。我一般建一个db.py专门管连接业务代码不直接碰sqlite3或pymysql这样后面改数据库类型只动一个文件。import sqlite3 from contextlib import contextmanager DB_PATH attendance.db contextmanager def get_db(): conn sqlite3.connect(DB_PATH) conn.row_factory sqlite3.Row try: yield conn conn.commit() except Exception: conn.rollback() raise finally: conn.close()逻辑说明contextmanager把连接包装成上下文管理器业务代码用with get_db() as conn:拿到的就是带行字典功能的连接取字段可以写成row[student_no]而不是row[0]可读性高很多。事务处理也放进来了有异常就回滚防止人脸特征写了一半、考勤记录没写成这种状态。从SQLite迁移到MySQL时要改三个地方一是把sqlite3换成pymysql或mysql-connector-python二是连接参数要带charsetutf8mb4否则中文姓名在部分服务器上会变成问号三是SQLite的AUTOINCREMENT和MySQL的AUTO_INCREMENT语法略有差异建表语句要顺手改掉。数据库修改结构也有讲究MySQL表建好后再加字段要用ALTER TABLE course ADD COLUMN location TEXT不要删表重建考勤数据丢了没有后悔药。3.3 GUI设计Tkinter还是PyQt主界面与四个功能页GUI选型上Tkinter和PyQt都有人用。Tkinter是Python标准库不需要额外装打包体量小做考勤系统的登录页、注册页、打卡页、报表页完全够用。PyQt控件更漂亮能做qss皮肤但打包体积大还要理解信号槽机制新手一上来容易被框架本身绊住。我一般建议课程项目用Tkinter把时间花在人脸识别和业务逻辑上。GUI布局用ttk.Notebook做标签页是标准做法四个功能页对应四个Tab人脸注册页负责拍照和录入特征考勤打卡页放视频画面和打卡提示考勤报表页用表格展示记录系统设置页放管理员密码和数据库连接信息。import tkinter as tk from tkinter import ttk class AttendanceApp: def __init__(self, root): self.root root self.root.title(Python人脸识别考勤系统) self.root.geometry(900x600) self.notebook ttk.Notebook(root) self.notebook.pack(fillboth, expandTrue) self.init_tabs() def init_tabs(self): self.reg_tab ttk.Frame(self.notebook) self.check_tab ttk.Frame(self.notebook) self.report_tab ttk.Frame(self.notebook) self.settings_tab ttk.Frame(self.notebook) self.notebook.add(self.reg_tab, text人脸注册) self.notebook.add(self.check_tab, text考勤打卡) self.notebook.add(self.report_tab, text考勤报表) self.notebook.add(self.settings_tab, text系统设置)逻辑说明先创建Notebook作为总容器再建四个Frame子页面挂上去之后每个Tab里再放按钮、标签、表格等组件。这样一个主窗口就能承载考勤系统的全部功能切换页签时不会丢视频画面的状态。参数说明geometry(900x600)设主窗口宽高也方便在显示不足的笔记本上调整fillboth配合expandTrue让Notebook铺满整个窗口避免界面在部分分辨率下缩成一团。4. 核心代码实现用Python跑通注册、打卡、报表三个流程4.1 人脸注册流程拍照、检测、提取特征、写入数据库注册流程是整个系统中数据质量的第一道关。打卡时识别不准八成是注册照片拍得不合格。我在注册页会让摄像头连续出画面用户在画面里看到自己的脸框套住后才点注册然后取当前帧做人脸检测和特征提取。脸部位置信息来自face_recognition库的检测框特征提取出来的128维浮点数组直接用tobytes()转成字节串存进student表的face_encoding BLOB字段。import face_recognition import cv2 import sqlite3 import numpy as np def register_face(student_no, name, frame): 注册学生从一帧画面中检测人脸并提取特征写入数据库 Args: student_no: 学号 name: 姓名 frame: BGR格式的摄像头画面 rgb cv2.cvtColor(frame, cv2.COLOR_BGR2RGB) boxes face_recognition.face_locations(rgb, modelhog) if not boxes: raise ValueError(没有检测到人脸请正对摄像头) # 用检测框取出当前帧人脸的特征编码 encodings face_recognition.face_encodings(rgb, boxes) if not encodings: raise ValueError(提取特征失败请换个光线角度再试) conn sqlite3.connect(attendance.db) try: conn.execute( INSERT INTO student (student_no, name, face_encoding) VALUES (?, ?, ?), (student_no, name, encodings[0].tobytes()), ) conn.commit() finally: conn.close() return boxes[0]逻辑说明先把OpenCV默认的BGR帧转成RGB因为face_recognition内部是按RGB处理的不转的话检测框位置会偏但不容易发现。face_locations返回的是上、右、下、左四个值传给face_encodings可以直接用丢给OpenCV画框时注意顺序要调整。参数说明modelhog是默认检测模型CPU就能跑如果机器还不错想更准改成modelcnn但速度会慢一截。注册完返回检测框可以让GUI在画面上画个绿色框给用户一个直观反馈。4.2 实时打卡流程摄像头取帧、人脸比对、写考勤打卡流程比注册多了比对这一步。视频流每取一帧就做人脸检测和编码拿当前帧的128维向量和数据库里的所有已知向量逐个算欧氏距离最近的距离小于阈值就判定为本人然后插入attendance表。这里有个细节同一人在一帧里可能被检测到多张脸我只取距离最近的那个人脸避免误把后排同学当成打卡人。def check_attendance(frame, course_id): 实时打卡从帧中识别人脸匹配成功后写入考勤记录 Returns: (matched_student_no, matched_name) 或 None rgb cv2.cvtColor(frame, cv2.COLOR_BGR2RGB) boxes face_recognition.face_locations(rgb, modelhog, number_of_times_to_upsample1) encodings face_recognition.face_encodings(rgb, boxes) if not encodings: return None conn sqlite3.connect(attendance.db) rows conn.execute(SELECT student_no, name, face_encoding FROM student).fetchall() known_encodings [ np.frombuffer(r[face_encoding], dtypenp.float64) for r in rows ] matched None for enc in encodings: # 距离取最小距离小于0.5认定为同一个人 distances face_recognition.face_distance(known_encodings, enc) min_idx int(np.argmin(distances)) if distances[min_idx] 0.5: matched rows[min_idx][student_no] break if matched is not None: conn.execute( INSERT INTO attendance (student_no, course_id) VALUES (?, ?), (matched, course_id), ) conn.commit() conn.close() return matched逻辑说明face_distance函数拿已知特征列表和当前编码做两两距离计算返回一个数组np.argmin直接取距离最近的人不需要手写循环。0.5这个阈值是默认0.6收紧了一档如果你发现有人经常打不上卡就把它放到0.55如果出现误打卡成别人就收紧到0.45。注意course_id是调用方传入的从GUI当前选择的课程得到不是从摄像头画面里猜的。写入考勤前没有查重会导致一个人一节课能打多次卡后面报表里去重用WHERE加上DATE(check_time)和student_no组合就能处理但更建议插入前先查一次同一学生同一课程同一天只能有一条记录。4.3 考勤报表与GUI联动查询、展示、导出Excel报表页是考勤系统价值最大的一块老师最后看的就是这个。单独把查询逻辑拿出来主要是避免业务代码里到处写SQL。报表按天查询用JOIN把三张表关联起来考勤表只存学号和时间课程名、姓名从对应表里取。展示用TTK的Treeview组件导出用Excel方便老师归档。def query_attendance_by_date(date_str): 按日期查询考勤明细 conn sqlite3.connect(attendance.db) sql SELECT a.student_no, s.name, c.course_name, a.check_time, a.status FROM attendance a JOIN student s ON a.student_no s.student_no JOIN course c ON a.course_id c.course_id WHERE DATE(a.check_time) ? ORDER BY a.check_time conn.row_factory sqlite3.Row rows conn.execute(sql, (date_str,)).fetchall() conn.close() return rows def fill_report_treeview(treeview, date_str): 把查询结果灌进Tkinter的Treeview表格 rows query_attendance_by_date(date_str) treeview.delete(*treeview.get_children()) for row in rows: treeview.insert(, end, values( row[student_no], row[name], row[course_name], row[check_time], row[status], ))逻辑说明DATE(a.check_time)把时间戳截成日期和界面上的日期输入框比对参数化查询用?占位符而不是字符串拼接这一点在考勤系统里尤其重要学号是用户输入内容直接拼SQL有被注入的风险。fill_report_treeview先清空表格再做插入这样刷新报表不会出现旧数据残留。导出Excel可以顺手用pandas一行代码就能把查询结果变成表格文件。但注意pandas读DataFrame时中文列名在部分Windows终端会乱码导出到xlsx本身没问题如果只是打印到控制台才需要处理编码问题。GUI设计到这里基本闭环了注册页写人脸特征打卡页写考勤记录报表页读出来展示数据库、GUI、人脸识别三部分串成一条线。5. 避坑与排查人脸识别考勤系统的五个翻车现场5.1 现象一CPU占用拉满识别一卡一卡现象摄像头一开CPU飙到90%以上画面像幻灯片点完打卡要等好几秒才出结果。原因face_recognition里modelcnn的检测模型在CPU上计算量极大分辨率越高越吃力这和rapidocr这类OCR模型在CPU上跑是一样的道理——深度学习模型吃起CPU来毫不留情。解决方案打卡模块全部切回modelhog把画面宽度缩到320像素再送进检测原图照样存检测用缩略图参数number_of_times_to_upsample降到1这是检测小脸时上采样的次数默认就够设成2或3会让CPU直接冒烟。5.2 现象二光线一变就识别失败现象早上能识别下午拉上窗帘就频繁未识别。原因注册时只存了一张光线良好的照片特征向量对光线的鲁棒性差加上阈值调得过紧光线一变距离就超过阈值。解决方案注册界面引导用户在不同光线、不同角度拍三张以上存成一个人的多条编码比对时同一个人取所有注册编码里最小的距离不要只比一张。在GUI里加一个补录人脸的功能考勤识别失败时让学生当场再录一张这是现场最快最实用的后悔药。5.3 现象三中文乱码和Tkinter报错现象SQLite里存的是正常中文界面上却显示成问号或者把中文写进代码文件后一运行就报SyntaxError。原因在Windows下Python源文件没声明UTF-8时文件里的中文字符串会被按系统GBK编码解释写SQL和显示就全乱套MySQL场景则是连接串没指定字符集。解决方案所有Python文件第一行写# -- coding: utf-8 --数据库连接统一用UTF-8SQLite本身没有字符集概念乱码大概率是写入前字符串就已经错了先检查print出来是否正常再看是不是控制台编码问题。MySQL连接串加上charsetutf8mb4建库时也用utf8mb4改一个地方的事别偷懒。5.4 现象四重启程序后特征全丢了现象注册完当时能打卡关掉程序再打开数据库里学生记录还在但识别老是失败提示找不到人脸。原因有些同学为了省事把已注册特征放在一个全局Python列表里注册时写入内存重启后列表空了打卡时没有数据可比。解决方案注册时就把face_encoding写成BLOB到SQLite启动时统一加载到内存做缓存。注意从SQLite读BLOB时要用np.frombuffer(blob_data, dtypenp.float64)还原成向量原始特征维度是128维转错了类型会在比对时报维度不一致的错误。5.5 现象五摄像头被占用GUI直接TclError现象程序启动后还没到打卡页就报TclError或者上一次程序没关干净第二次运行直接打不开摄像头。原因Windows下摄像头的占用是排他的上次程序崩溃时cv2.VideoCapture没有释放端口被占住了。解决方案摄像头初始化前后都加保护性逻辑视频循环不要放在Tkinter主线程里跑否则窗口会假死常见做法是用线程子线程取帧、定时用after把帧更新到Label上。血泪经验每次调试前先看一眼任务管理器有没有残留python.exe进程有这个习惯能省下大量怀疑人生的时间。6. 进阶技巧与验证用向量化比对和离线缓存把识别提速6.1 用NumPy向量化替换逐个人脸循环比对先看一段对比代码。很多人打卡比对时喜欢for循环遍历所有已知特征一次两次还行学生数量上百之后每帧都循环一遍速度立刻掉下来。向量化写法是把所有已知特征堆成一个大矩阵一次性对当前人脸向量做全量距离计算known_array np.array(known_encodings) # shape (N, 128) enc np.array(current_encoding).reshape(1, -1) # shape (1, 128) distances np.linalg.norm(known_array - enc, axis1) min_index int(np.argmin(distances))逻辑说明known_array是N行128列的矩阵减去1行128列的当前特征得到N行128列的差值矩阵np.linalg.norm对axis1按行求L2范数结果就是N个欧氏距离。这个操作在NumPy底层是C语言算的比纯Python循环快一个数量级。参数说明axis1不能漏漏了会变成对整个矩阵求范数得到的是标量而不是距离数组。6.2 特征离线缓存把特征存BLOB还是npy注册人数多以后每次启动都从SQLite读全部特征再做np.frombuffer转换也有几十毫秒的耗时。常见做法是启动时把特征矩阵直接存成cache.npy后面第二次启动直接np.load几毫秒加载完。要注意增删人员后重建缓存否则缓存里还有旧人、数据库里已删除比对时会出现数据库没这人但缓存有的脏数据。像easyai这类商业人脸识别SDK集成度高但自建Python方案的优势就在于这些缓存策略和阈值完全可控这正是自己做考勤系统的价值。6.3 识别准确率怎么验证系统上线前不要只拿自己一张照片试。我习惯拉3到5个人每人模拟10次打卡每次分别站在不同光线和角度下记下正确识别次数、误识别成别人次数、漏识别次数。考勤场景有个原则宁可漏识别让人重新刷一次也不能误识别成别人。如果漏识别明显先调高阈值如果误识别明显先加注册样本而不是死磕阈值。我现在做这类系统第一件事是先确认目标机器有没有GPU、摄像头分辨率是多少没有GPU就把CNN模型这个念头直接掐掉改HOG。这个习惯帮我避免了很多次现场翻车希望帮到你。本文还有配套的精品资源点击获取