简介基于Python的人脸识别考勤系统项目实例以docx文档形式完整呈现面向具备Python基础并希望掌握AI与后端开发的高校师生、研发人员解决传统课堂点名效率低、易代签等考勤管理问题。文档以课程考勤管理为场景围绕OpenCV、face_recognition完成人脸检测、特征提取与匹配结合Flask/FastAPI后端与Tkinter桌面GUI覆盖项目背景、目标意义、技术架构、算法流程、挑战解决方案、模型架构、数据库表结构MySQL、前后端交互直至系统部署与优化方向的全流程。资源包共1个docx文档大小仅115KB内含人脸采集、检测裁剪、特征库构建、实时识别、考勤记录写入等模块化代码示例并配有结构清晰的目录与分章节叙述便于逐步复现同时涉及复杂环境鲁棒性与数据隐私安全。目前已有97人学习下载适合作为毕业设计、课程设计或智慧校园教学案例参考可直接借鉴其工程化框架进行二次开发与功能扩展。1. 人脸识别考勤系统为什么值得自己做方案边界与适合人群很多课程考勤还停留在纸质点名或扫码签到代答到、刷个码就走的情况屡禁不止市面上的人脸识别门禁机虽然成熟但对学生来说是个黑匣子识别逻辑、阈值、数据库都不让动。这套基于 Python 的人脸识别考勤系统正好卡在“工业级门禁太贵太封闭”和“纯扫码考勤太容易造假”之间用 OpenCV 抓摄像头画面跑人脸检测和特征编码跟注册库里每个学生的 128 维特征做距离比对命中后把签到记录写进 MySQL再用 Tkinter 做一个能现场看到识别结果的操作界面。对计算机视觉大作业、毕业设计和 50 人以内的小班考勤来说这条路是最短实现路径但它不是万能的人脸识别门禁系统设计对逆光、大侧脸、遮挡多的场景会明显吃力。看完这篇你能得到一套能跑通、能演示、能扩展出花样的完整方向而不是只会在教程里跑个 demo 的体验。2. 拆出核心识别链路人脸检测、特征编码与比对阈值2.1 选型为什么课程考勤用 face_recognition 而不是 OpenCV LBPH做课程考勤之前先要选对底层的“人脸识别算法”。OpenCV 自带的 LBPH 人脸识别器几乎零依赖pip 装完 opencv-python 就能用训练一个模型也只要几十行代码但它在侧脸、表情变化、教室灯光偏黄偏暗的情况下准确率掉得很快。而 face_recognition 库封装了 dlib 的人脸检测与人脸关键点对齐能输出 128 维特征向量识别精度明显高一档且 API 简单适合“学生配合着看镜头”这种相对友好的考勤场景。DeepFace、InsightFace 这类深度学习方案的精度更高但模型动辄上百 MB普通教室电脑用 CPU 跑实时考勤会卡到不可用杀鸡用牛刀。环境准备这一步我建议把 Python 装成 3.8 或 3.9 的 64 位版本然后按顺序装依赖。Windows 上最容易出问题的不是 face_recognition而是 dlib它需要本地编译所以要先有 CMake 和 Visual Studio 的 C 生成工具# 建议先确认 python 版本python --version pip install opencv-python pip install cmake pip install dlib pip install face_recognitiondlib 编译失败时绝大多数情况是缺少 VS Build Tools 或 CMake 版本过旧先单独把这两项装好再重试 pip install dlib。开发环境用 PyCharm 还是 VSCode 都可以课程设计类项目我更推荐 PyCharm因为它对 Tkinter 的调试和虚拟环境管理更直观如果电脑配置一般VSCode 轻量但需要自己手动指定解释器并配好 python 插件新手容易在环境配置上白耗一个下午。这套依赖顺序是我踩了多次坑后固定下来的先 opencv再 dlib最后 face_recognition因为后者的安装脚本会自动探测 dlib 是否可用。2.2 注册流程把一张照片变成可比对的 128 维特征向量考勤系统的第一步不是识别而是“注册”——把每个学生的照片转成特征向量存起来。这里的关键是保证注册照片质量。如果允许上传任意照片就有学生拿证件照、自拍、朋友圈照片混进来后续识别率会非常不稳定。更稳妥的常见做法是用同一个摄像头现场拍一张正脸照再跑下面的注册函数import face_recognition def register_student(image_path, student_id): # 加载图片face_recognition 会自动转成 RGB 数组 image face_recognition.load_image_file(image_path) # 先用 HOG 模型检测人脸位置要求必须且只能检测到一张脸 face_locations face_recognition.face_locations(image, modelhog) if len(face_locations) ! 1: raise ValueError( f{image_path} 中应包含且仅包含一张人脸实际检测到 {len(face_locations)} 张 ) # num_jitters10 表示对同一张脸做 10 次重采样取平均特征更稳定 face_encoding face_recognition.face_encodings( image, known_face_locationsface_locations, num_jitters10 )[0] # 把 ndarray 类型转成 bytes 后交给数据库层存储 from database import save_face_encoding save_face_encoding(student_id, face_encoding.tobytes()) return face_encoding这段代码里的参数值得细说。model 参数有 hog 和 cnn 两种前者基于梯度直方图计算量小CPU 跑得快适合注册和实时识别后者基于卷积神经网络对模糊、角度变化更鲁棒但速度慢很多适合处理单张图精度要求高的场景。在课程考勤里我全部用 hog因为教室里的学生基本是正脸没必要为个例牺牲速度。num_jitters 默认是 1对光线不稳定的人脸图调到 10 之后编码会更稳代价是注册时间变长但对每名学生只在注册时执行一次这个成本完全可接受。face_encodings 返回的 ndarray 是 128 个 float64 组成的向量直接存数据库必须是二进制不能 str 强转这里先 tobytes() 做序列化读取时再用 np.frombuffer 还原具体陷阱在第 4 章展开。2.3 实时识别与考勤判定阈值、置信度和单次签到防重注册完成之后考勤时的识别链路就是“抓帧 → 检测人脸 → 提取编码 → 与库里所有人比对 → 返回距离最近的一条”。比对不是玄学核心是两个函数compare_faces 做布尔判定face_distance 算欧氏距离。我的识别函数这样写import numpy as np import face_recognition def recognize(unknown_frame, known_encodings, known_ids, tolerance0.5): # 定位当前帧里的所有人脸 face_locations face_recognition.face_locations(unknown_frame, modelhog) if len(face_locations) 0: return [] # 提取这些人脸的特征向量 face_encodings face_recognition.face_encodings(unknown_frame, face_locations) results [] for face_encoding in face_encodings: if len(known_encodings) 0: results.append((unknown, 1.0)) continue # 布尔列表每个位置表示是否在 tolerance 距离内匹配 matches face_recognition.compare_faces( known_encodings, face_encoding, tolerancetolerance ) # 欧氏距离越小越相似 distances face_recognition.face_distance(known_encodings, face_encoding) best_idx int(np.argmin(distances)) if matches[best_idx]: results.append((known_ids[best_idx], float(distances[best_idx]))) else: results.append((unknown, float(distances[best_idx]))) return results这里最容易理解偏的是 tolerance 参数。它默认是 0.6含义是“允许的最大欧氏距离”超过就算不匹配。0.6 不是银弹班级人数少、摄像头分辨率高、光照稳定时0.45 到 0.5 更安全反之如果学生经常低头、戴帽、光线忽明忽暗0.55 到 0.6 能减少漏识别但误识别风险也随之上升。我的习惯是把 tolerance 做成配置文件里的项考勤开始时能临时调跑完一天再根据考勤日志里的 confidence 字段回看。每个命中结果都带 distance这个值会被写进考勤表不是为了展示而是事后排查“当时是不是认错了人”的依据。识别链路单独跑通后再和签到逻辑对接识别到已注册学生且距离低于阈值才进入考勤写入流程识别为 unknown 的人在界面上提示“未登记”不写入任何数据。这样保证了考勤记录每一条都来自一次真实的人脸匹配而不是摄像头里随便有个人就自动打卡。3. MySQL 课程考勤数据库与 Tkinter GUI从识别结果到“已签到”3.1 考勤系统数据库设计三张表撑起课程、学生、签到记录进度走到这里识别已经能返回“谁来了”下一步是把“谁来了”稳定落库。课程考勤管理系统的核心数据可以拆成三张表课程表、学生表、考勤记录表。不需要设计成复杂的权限多角色系统三张表已经是课程考勤的最小完整集合。建表 SQL 如下CREATE DATABASE face_attendance DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; CREATE TABLE course ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, semester VARCHAR(20) NOT NULL, INDEX idx_course_semester (semester) ) ENGINEInnoDB; CREATE TABLE student ( id INT PRIMARY KEY AUTO_INCREMENT, student_no VARCHAR(20) NOT NULL UNIQUE, name VARCHAR(50) NOT NULL, face_encoding BLOB COMMENT 128个float64序列化后约1024字节 ) ENGINEInnoDB; CREATE TABLE attendance ( id INT PRIMARY KEY AUTO_INCREMENT, student_id INT NOT NULL, course_id INT NOT NULL, attend_date DATE NOT NULL, check_time DATETIME NOT NULL, confidence DOUBLE COMMENT 人脸比对欧氏距离越小越可信, status TINYINT DEFAULT 1 COMMENT 1正常签到, 2教师补签, UNIQUE KEY uk_stu_course_date (student_id, course_id, attend_date), CONSTRAINT fk_att_student FOREIGN KEY (student_id) REFERENCES student(id), CONSTRAINT fk_att_course FOREIGN KEY (course_id) REFERENCES course(id) ) ENGINEInnoDB;几个设计点单独说一下。face_encoding 用 BLOB 而不是 VARCHAR是因为特征序列化后是二进制字节VARCHAR 会被隐式转成字符串读出来再做 np.frombuffer 时经常报长度不对。attendance 表的唯一索引 uk_stu_course_date 是防重复签到的最后一道保障哪怕界面逻辑漏判数据库层也能阻止同一学生同一天同一课程出现两条记录。confidence 字段保存识别时的欧氏距离这是审计用的任课老师如果事后质疑某条签到记录可以直接查这个值是否在正常分布内。status 字段为补签留了口子人脸识别漏检不等于缺勤教师手动补签时写 2。数据库连接这一层课程设计常见的错误是每次操作都新开连接、用完不关。窗口多了之后连接数飙升MySQL 默认 max_connections 会被打满报 “Too many connections”。我用连接池统一管起来这里用的是 DBUtils 的 PooledDB# db.py import pymysql from dbutils.pooled_db import PooledDB pool PooledDB( creatorpymysql, maxconnections10, mincached2, maxcached5, host127.0.0.1, userroot, passwordroot, databaseface_attendance, charsetutf8mb4, cursorclasspymysql.cursors.DictCursor ) def get_conn(): return pool.connection()连接池的好处是连接用完放回池子而不是销毁GUI 多线程环境下不会频繁创建销毁连接也不会出现连接泄漏。maxconnections 给 10 对这个规模已经足够调大反而增加 MySQL 端压力。连接时 charset 必须写 utf8mb4否则中文名在写入时偶尔会被拦这个问题会单列在避坑章节里。如果你的课程设计不要求 MySQL把 creator 换成 sqlite3 也能跑但并发写入时 SQLite 会锁库教室场景可能几十个人同时打卡我不建议省这一步。3.2 Tkinter GUI 的模块划分主窗口、摄像头预览与课程选择GUI 方案我用 Tkinter不用 PyQt5。PyQt5 界面更现代控件更丰富但打包体积大、学习成本高课程设计答辩时很容易被追问“为什么不用 Qt”——这个问题的答案应该写在项目文档里Tkinter 是标准库、零额外依赖、适合轻量演示。这套系统界面只做三件事左边摄像头画面实时预览右边课程下拉框加签到日志列表底部开始考勤和补签按钮。代码骨架如下import tkinter as tk from tkinter import ttk from PIL import Image, ImageTk class AttendanceApp: def __init__(self, root): self.root root self.root.title(人脸识别课程考勤系统) self.root.geometry(900x600) # 左侧摄像头画面区 self.video_label ttk.Label(root, text摄像头画面, anchortk.CENTER) self.video_label.place(x10, y10, width560, height460) # 右侧功能面板 right_panel ttk.Frame(root) right_panel.place(x580, y10, width300, height580) ttk.Label(right_panel, text选择课程).pack(anchortk.W, pady5) self.course_combo ttk.Combobox(right_panel, statereadonly) self.course_combo.pack(filltk.X, pady5) self.load_courses() ttk.Label(right_panel, text签到日志).pack(anchortk.W, pady5) self.log_text tk.Text(right_panel, height16) self.log_text.pack(filltk.BOTH, expandTrue, pady5) btn_frame ttk.Frame(right_panel) btn_frame.pack(filltk.X, pady10) ttk.Button(btn_frame, text开始考勤, commandself.start_attendance).pack(sidetk.LEFT) ttk.Button(btn_frame, text停止考勤, commandself.stop_attendance).pack(sidetk.LEFT, padx6) ttk.Button(btn_frame, text手动补签, commandself.manual_makeup).pack(sidetk.LEFT) def load_courses(self): conn get_conn() try: with conn.cursor() as cur: cur.execute(SELECT id, name FROM course WHERE semester2024-2025-1) rows cur.fetchall() self.course_combo[values] [f{r[id]} - {r[name]} for r in rows] finally: conn.close() def log(self, message): # 时间戳和消息一起追加到日志区不 remove 旧内容 from datetime import datetime self.log_text.insert(tk.END, f[{datetime.now():%H:%M:%S}] {message}\n) self.log_text.see(tk.END)布局上用 place 配合 pack摄像头区域固定尺寸、右侧面板自动撑满是我试过几种布局里最稳的。grid 在新手手里容易写出控件重叠pack 与 place 混用反而简单清晰。load_courses 里把课程 ID 和名称拼在一起放进下拉框后面解析时 split 一下就能拿到 course_id省一次数据库查询。这里有个显式关闭连接的细节虽然连接池会自动回收但用 with 块 finally 是习惯避免长事务占用连接。摄像头画面刷新不能直接放在 Tkinter 主线程里因为 mainloop 是单线程事件循环摄像头 read 是阻塞的放主线程会导致窗口拖拽时画面卡死。常见的处理方式是开一个子线程跑 VideoCapture把帧放进 queue主线程用 after 定时取帧刷新界面import queue import threading import cv2 frame_queue queue.Queue(maxsize2) def capture_loop(camera_index0): cap cv2.VideoCapture(camera_index) cap.set(cv2.CAP_PROP_FRAME_WIDTH, 640) cap.set(cv2.CAP_PROP_FRAME_HEIGHT, 480) while True: ok, frame cap.read() if not ok: continue if frame_queue.full(): try: frame_queue.get_nowait() # 丢旧帧保证界面显示最新画面 except queue.Empty: pass frame_queue.put(frame) def update_video(self): try: frame frame_queue.get_nowait() rgb cv2.cvtColor(frame, cv2.COLOR_BGR2RGB) img Image.fromarray(rgb) imgtk ImageTk.PhotoImage(img) self.video_label.configure(imageimgtk) # 关键保存引用否则图像会被垃圾回收导致黑屏 self.video_label.image imgtk except queue.Empty: pass self.root.after(10, self.update_video)queue 的 maxsize 设为 2是为了避免摄像头线程无限堆积帧导致界面看到的画面越来越滞后。put 前先 get_nowait 丢旧帧是视频显示的标准做法理解成“宁可少显示一帧也不能越积越卡”。self.video_label.image imgtk 这行是无数人翻车的地方PhotoImage 如果没有引用会被回收界面显示黑屏但没任何报错这属于典型的“看起来像玄学、实际是生命周期”的问题。分辨率设置成 640x480一方面降低 CPU 负担另一方面 face_recognition 的 HOG 检测对过大图像反而会变慢识别精度并不会因为分辨率翻倍而线性提升。3.3 签到写入流程识别命中、防重复签到与未登记人员处理识别线程一旦返回了 student_id就进入签到写入流程。这里有两个层面要防重复界面层先查一次给友好提示数据库层用唯一索引兜底。我的写入函数这样写def check_in(self, student_id, course_id, confidence): conn get_conn() try: with conn.cursor() as cur: # 先查再插给界面一个明确的“已签到”提示 cur.execute( SELECT id FROM attendance WHERE student_id%s AND course_id%s AND attend_dateCURDATE(), (student_id, course_id) ) if cur.fetchone(): return already cur.execute( INSERT INTO attendance (student_id, course_id, attend_date, check_time, confidence, status) VALUES (%s, %s, CURDATE(), NOW(), %s, 1), (student_id, course_id, confidence) ) conn.commit() return ok except pymysql.IntegrityError: # 并发场景下唯一索引拦截重复插入 conn.rollback() return already finally: conn.close()先查再插在单线程 GUI 里看起来是多余的但考勤识别子线程和界面按钮事件不是同一条执行路径万一手动补签和自动识别同时触发数据库唯一索引才是真正的防线。IntegrityError 捕获后返回 already而不是抛异常是因为对考勤系统来说“重复签到”不是错误是业务状态。confidence 存成 DOUBLE记录人脸比对的欧氏距离方便后续分析阈值是否合理。未登记人员unknown在识别函数里已经过滤不会走到这个写入函数界面上只提示“未登记人员”你可以记录频次但不落库。4. 人脸识别考勤系统避坑与排查5 个让项目当场翻车的常见问题4.1 注册照片和摄像头画面不是同一路光线识别率低的头号原因现象注册时用手机自拍或校园卡照片识别时整节课下来只有三分之一学生能成功签到其他人全部 unknown。原因人脸识别算法对人脸纹理敏感手机自拍的美颜、磨皮、滤镜已经改变了面部特征分布即使不开美颜宿舍暖光灯和教室白炽灯的白平衡差异也会让同一张脸的 128 维特征向量偏离注册时的位置。这个偏移可能不大但叠加 tolerance 阈值后就足以从“匹配”变成“不匹配”。解决注册过程强制走摄像头现场拍摄且注册和考勤使用同一台设备、同一个机位。我一般把注册界面做成“对准屏幕框内的脸按空格拍照”拍完立刻用第 2 章的 register_student 提取特征如果检测到不是一张人脸就重拍。这样注册时和考勤时的光照、视角、摄像头色彩倾向基本一致比任何算法调参都管用。4.2 阈值紧绷绷把 0.5 改成 0.45误识别少了漏识别却多了现象初始 tolerance 用默认 0.6A 同学第一次签到成功第二次同一角度却失败同一个班里B 同学总是被识别成 C日志里 confidence 都在 0.5 上下晃。原因欧氏距离的分布跟班级人数、摄像头分辨率、学生戴不戴眼镜都有关系。0.6 是 face_recognition 作者在公开测试集上的经验值不是为你这个教室调出来的。当类内距离同一个人不同帧之间的差异接近 0.55而类间距离不同人之间的最小差异低到 0.5 以下时固定阈值必然两头漏。解决启动考勤前先跑一次标定脚本把全班注册照和实时抓拍照两两比对生成类内距离和类间距离两组数据取两者分布重叠最少的地方做阈值。常见做法是把阈值区间设在 0.45 到 0.6 之间低于 0.45 会拒掉大量正常签到高于 0.6 会出现跨人误签。标定脚本的落地版我在第 5 章给出每周跑一次把当周光线下的最优阈值存进配置文件。4.3 特征向量存进 MySQL 后变成乱码BLOB 与序列化陷阱现象注册时一切正常重启系统后从数据库读出学生特征做比对全员 unknownlog 里没有任何异常只有 distance 明显偏大。原因注册时把 face_encoding 这个 ndarray 直接 str() 成字符串塞进了 TEXT 字段或者用 pickle 序列化后存 VARCHAR读出来再用 eval 还原。类型对不上是其一字符串里含有的换行、空格、括号被 MySQL 隐式转换后np.frombuffer 得到的数组长度根本不是 128比对结果自然全是乱的。解决写入时用 ndarray.tobytes() 转成纯二进制存 BLOB 字段读取时用 np.frombuffer(data, dtypenp.float64) 还原不要经过任何字符串环节。示例写入用 save_face_encoding(student_id, face_encoding.tobytes())读取时 SELECT face_encoding FROM student WHERE student_no%s拿到 bytes 后 np.frombuffer(row[face_encoding], dtypenp.float64)。如果发现 length 不等于 1024说明存进去的铁定不是 float64 的 128 位先检查建表字段是不是 BLOB。4.4 Tkinter 预览黑屏 / OpenCV 摄像头被占用子线程抢设备现象点“开始考勤”后界面摄像头区域全黑不报错或者程序第二次启动时 OpenCV 报 “Cannot open camera”必须重启电脑才能恢复。原因两个典型。一是摄像头读取被放进了 Tkinter 主线程mainloop 被阻塞界面永远等不到刷新。二是启动时创建了 VideoCapture 但没正确释放或者同时开了两个线程分别创建了 cap第一个没 release第二个就打不开设备。解决所有 cv2.VideoCapture 操作集中在 capture_loop 这一个子线程里主线程只负责用 after 从 queue 取帧停止考勤时先置一个退出标志位让循环退出再调用 cap.release()。不要在识别线程里反复 open 和 close 摄像头。判断线程是否退出不要用 threading.Event.wait 之后的强行 join因为 Tkinter 主线程 render 会一直卡住更稳的做法是识别帧循环里检查 queue 是否还有数据没有就自然休眠 10ms让出 CPU。4.5 中文姓名在 MySQL 和 Tkinter 里乱码现象数据库里 name 字段显示“张伟”正常Python 读出来后变成 “?????”或者 SQL 插入时报 “Incorrect string value: ‘\xE5\xBC\xA0’ for column”。原因建库时字符集不是 utf8mb4或者 pymysql 连接参数没写 charset也可能 Windows 终端默认 GBKprint 到控制台时乱码但库里其实没问题。三处来源混在一起时新手很容易误判为“数据库坏了”。解决建库 SQL 里显式指定 DEFAULT CHARACTER SET utf8mb4pymysql 连接串里写 charsetutf8mb4Python 文件头部加# -*- coding: utf-8 -*-Windows 下如果控制台仍然乱码检查环境变量 PYTHONIOENCODINGutf-8。Tkinter 本身对 Unicode 支持良好只要数据源头干净界面显示中文不会有问题。这五条坑我几乎每做一个人脸识别课程项目都会踩到至少三条尤其是第一条和第三条它们不是代码 bug是数据环境问题调试器看不出任何异常只能靠对比注册特征和识别特征的分布才能定位。5. 把考勤系统做到能交付阈值自动调优、多线程抓帧和补签策略一个能演示的考勤 demo 和一个能真正用一学期的考勤系统差别就在三个细节阈值有没有数据支撑、识别间隔有没有控制、以及人脸识别失败之后有没有人工补救通道。先看阈值标定。我每门课开课前会拿着全班注册照和现场抓拍照跑一遍这个脚本把类内距离与类间距离的分布算出来取交点附近的值作为本周 tolerance。实现不复杂核心逻辑是对每组“同一张脸的不同帧”和“不同人的脸”各算一次 face_distancedef calibrate_threshold(known_encodings, known_ids, test_encodings, test_ids): in_distances, out_distances [], [] for k_enc, k_id in zip(known_encodings, known_ids): for t_enc, t_id in zip(test_encodings, test_ids): dist face_recognition.face_distance([k_enc], t_enc)[0] if k_id t_id: in_distances.append(dist) else: out_distances.append(dist) # 取类内最大与类间最小的中点作为推荐阈值 if not in_distances or not out_distances: return 0.5 return round((max(in_distances) min(out_distances)) / 2, 3)类内距离越小说明这个人的特征越稳定类间距离越大说明同学之间区分度越好推荐阈值取两者中间能让漏识别和误识别同时最小化。这个数值每次课程、每个教室都可能不同写入考勤系统的配置文件后下次启动自动读取。再说识别间隔。每帧都跑 HOG 检测加编码CPU 占用会持续飙高风扇声比学生说话声还大。我在识别线程里加一个简单逻辑同一张人脸框稳定出现 5 帧以上才开始比对比对之后 10 秒内对同一 student_id 不再重复写库。这个 10 秒窗口足够处理学生移动、低头、回头再转回来的情况又不会让同一个人一节课产生几十条记录。结合数据库唯一索引三重防重算是交功课级的严谨。最后是补签策略。算法再好也有漏检学生迟到了两分钟、戴了口罩、或者坐在逆光角落人脸识别没认出他不代表他没来上课。我的界面上保留“手动补签”按钮教师勾选日志里的未识别记录选择学生和课程写入 status2 的补签记录。这既保留了人脸识别自动化的效率又给了教师最终裁决权答辩时被问“识别错了怎么办”也能拿出完整方案。这套系统我带过的课程设计里从零到跑通最快一个周末但到能真正拿到教室用靠的是上述三条标定阈值、控制识别节奏、保留人工兜底。我第一次实机测试时就是吃了逆光的大亏全班一半人签不上到后来把注册和考勤统一在同一环境、阈值改成标定值第二批测试准确率才稳定住。这些小教训希望帮到你。本文还有配套的精品资源点击获取