基于人脸识别与MySQL的考勤管理系统设计与实现

人脸考勤系统，这类项目在网上是真不少见，但我接手过的几个相似项目里，大多都停在“能跑通 Demo”的阶段：摄像头一开，识别出来了，然后往屏幕上一丢，就完事了。真要做成一套可用、数据还能闭环的考勤系统，难点根本不在人脸识别模型本身，而是你把人脸特征存哪儿、怎么让 MySQL 承载识别结果、考勤规则怎么落到数据上。这篇文章，我就以“基于人脸识别和 MySQL 的考勤管理系统”为主线，把从设计到落地的完整路径过一遍。

整个项目可以拆成三块：人脸识别模块、数据库模块、考勤业务模块。人脸识别解决“你是谁”，数据库解决“怎么存”，业务模块解决“怎么用”。三块凑齐了，系统才能真正替代传统打卡机。这篇文章适合手里已经有点 Python 基础、想自己搞一套离线考勤系统的开发者，也适合在高校做课程设计或者在企业里做内部工具的人参考。我后面给的所有参数、SQL、代码片段，都是在实际调试中验证过的，你可以直接抄。

1. 项目整体设计与技术选型

1.1 考勤场景到底在解决什么问题

先把需求掰开来看。任何考勤系统，本质上就三件事：确认身份、记录时间、生成报表。但真到了落地阶段，你还会遇到一堆“隐性需求”，比如代打卡怎么防、光线差的时候能不能识别、一个人在同一天重复刷脸怎么处理、月底统计能不能一键导出来。

我在做这类系统时，习惯先画一遍用户流程：员工来到摄像头前，人脸被识别，系统判断当前时间是上班时段还是下班时段，写入签到记录或签退记录；管理员在后台能查某个人某天的上下班时间，也能拉出来一个月的汇总表。这套流程看似朴素，但每一步都会牵涉人脸识别准确率、数据库读写策略、考勤规则边界条件等因素。

如果只做识别而不做考勤业务，那充其量是个“人脸门禁”；如果只做数据库而不做识别，那和传统打卡软件也没区别。所以这个项目的核心价值就在两者的结合：把识别的结果实时转化为考勤记录，并支持后续统计查询。做完你会明显感觉到，真正花时间的不是算法部分，而是怎么把算法结果安全合理地写进数据库。

1.2 识别方案对比：为什么我选了离线库方案

人脸识别这部分有多种技术路线，我在选型时做了几个方向的对比。

一种是 OpenCV 自带的 LBPH 识别方案。它基于局部二进制模式直方图，属于传统机器学习，优点是环境依赖少、代码简单，但缺点非常致命：对光照变化、人脸角度很敏感，同一个员工换个光线就可能认不出来。在考勤这种需要高可靠性的场景里，我基本上直接排除。

另一种是云端人脸识别 API。精度高、接入快，但有个硬约束：每次识别都要把图片传上去，涉及隐私和网络成本。企业内部用可能无所谓，但有些项目明确要求数据不出内网，这条就卡死了。

最后就是我选定的方案：Python + face_recognition 库 + MySQL。face_recognition 底层基于 dlib，人脸特征用 128 维向量表示，在普通 CPU 上即可完成推理，单张人脸的特征提取耗时大约 0.1 到 0.2 秒，比对 1000 人的库也就是几十毫秒的事。完全离线部署，数据在自己手里，精度对于考勤场景来说足够（在控制环境和采集质量的条件下，正确率能做到 95% 以上，这个后面细说）。

我还对比过一个更重的方案：用 MTCNN 做人脸检测、ArcFace 做人脸特征提取，模型精度确实最高，但需要自己准备标注数据训练或微调，部署也要考虑 GPU 机器，对一个小型考勤系统来说有点杀鸡用牛刀了。如果你后续要做到几万人规模，再考虑也不迟。

技术选型这块，我的建议是：中小规模（几百人到千把人）离线考勤，face_recognition 方案性价比最高，开发周期也能压到一两周。

1.3 系统模块划分与数据流向

我把系统拆成四个模块：

• 注册模块：录入员工照片，提取人脸特征，写入 MySQL。
• 识别模块：调用摄像头实时识别，输出“是谁”以及“置信度”。
• 考勤业务模块：拿到识别结果后，结合当前时间，判断签退还是签到，更新或插入考勤记录。
• 管理端模块（可选）：提供查询、统计、导出报表的入口。

你可能注意到，我没有把摄像头单独列出来，是因为摄像头只负责“提供画面”，真正的识别在收到画面帧之后才开始。数据流向大致是这样的：摄像头采集 → 人脸检测定位 → 特征提取 → 与数据库中的特征比对 → 产生识别结果 → 写入考勤表。这条链路里，每一步都可能成为瓶颈，后面我会逐个说。

2. 数据库设计：把“人脸特征”和“考勤流水”安顿好

2.1 员工表设计：特征字段到底用什么类型

数据库设计是整个系统的地基，特别是员工表里要存人脸特征，这里有个细节很容易踩坑：特征是一个 numpy 浮点数组（128 个 float），你不能直接存成 VARCHAR，也不能用普通 BLOB 硬塞，需要考虑序列化格式和字段长度。

我的做法是先用 pickle 将 numpy 数组序列化，再用 base64 编码成字符串，最后存入 MEDIUMTEXT 字段。base64 的好处是存储内容对 MySQL 完全友好，不会出现二进制字符导致的写入异常。128 个 float64 值序列化后大约在 5KB 以内，MEDIUMTEXT 完全够用。

建表 SQL 大致如下：

CREATE TABLE employees ( id INT AUTO_INCREMENT PRIMARY KEY, emp_no VARCHAR(20) NOT NULL UNIQUE COMMENT '员工编号', name VARCHAR(50) NOT NULL COMMENT '姓名', department VARCHAR(100) COMMENT '部门', face_encoding MEDIUMTEXT COMMENT '人脸特征(base64)', photo_path VARCHAR(255) COMMENT '原始照片路径', created_at DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

有几个设计点要说明。emp_no 必须加唯一索引，它对应到每个员工，后续所有考勤记录都通过 emp_no 关联这个表。face_encoding 作为文本而不是 BLOB，主要是为了导出和排查方便，MySQL 客户端里能直接看到内容，不会出现一堆乱码。当然你也可以用 BLOB，后续读取时反序列化稍微省一步，但维护体验差一些。

2.2 考勤记录表与请假表：时间字段和状态字段怎么搭配

考勤记录表是整个系统写入最频繁的表，设计上要兼顾查询和防重复。

CREATE TABLE attendance ( id INT AUTO_INCREMENT PRIMARY KEY, emp_no VARCHAR(20) NOT NULL COMMENT '员工编号', work_date DATE NOT NULL COMMENT '考勤日期', check_in_time DATETIME COMMENT '签到时间', check_out_time DATETIME COMMENT '签退时间', status TINYINT DEFAULT 1 COMMENT '1正常 2迟到 3早退 4缺勤 5请假', UNIQUE KEY uk_emp_date (emp_no, work_date) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

关键设计有两处。第一，联合唯一索引 (emp_no, work_date) 保证一个员工一天只产生一条考勤记录，避免多次识别产生重复数据。第二，status 字段初始写入后，可能因为“迟到”变成“早退”吗？不会，我后面用状态位只做汇总标识，原始时间字段始终保留，这样即使你之后想重新计算某天是否迟到，也依然能从 check_in_time 里算出来。简单说，原始数据要留，状态字段本质是缓存，方便统计时直接聚合。

请假表单独建一张，结构不能和 attendance 混在一起，否则请假记录会搞乱每日考勤的唯一性。

CREATE TABLE leave_records ( id INT AUTO_INCREMENT PRIMARY KEY, emp_no VARCHAR(20) NOT NULL, leave_date DATE NOT NULL, leave_type VARCHAR(20) COMMENT '事假/病假/年假', reason VARCHAR(255), status TINYINT DEFAULT 0 COMMENT '0待审批 1通过 2拒绝', KEY idx_emp_leave (emp_no, leave_date) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

请假记录和考勤记录的联动是后续统计模块的工作：某天如果存在审批通过的请假记录，那当天考勤不判迟到早退，直接算请假。

2.3 索引与分表思考：当考勤数据超过百万行怎么办

考勤表的数据增长是线性的，假设公司有 500 人，一年就是 500 × 365 约 18 万条，三年就是 50 万条以上。这个量级在 MySQL 里其实并不大，但如果你在统计时直接对整表做 GROUP BY，查询会越跑越慢。

我的建议是两条腿走路。第一，索引一定建全：除了联合唯一索引，推荐再建 (work_date, emp_no) 普通索引，因为日报和月报都是按照日期维度来查询的，命中日期条件后，扫描结果集就小很多。第二，如果确实需要长期保留历史数据，可以考虑按年份归档，比如每年年初把上一年数据迁移到 attendance_2024 这种备份表，主表只保留当前年度和上一年度的数据。这种方案比 MySQL 分区简单得多，也几乎不增加开发成本。

3. 人脸识别模块的完整实现

3.1 环境搭建与依赖安装

这块我建议在 Python 3.8 到 3.10 之间操作，太新或者太旧都会遇到莫名的编译问题。核心依赖只有三样：

pip install opencv-python pip install face_recognition pip install pymysql

最容易出问题的是 face_recognition，它会连带安装 dlib，而 dlib 在 Windows 上需要 CMake 和 C++ 编译环境。如果安装报错，建议先去官网装好 Visual Studio Build Tools，勾选“使用 C++ 的桌面开发”工作负载，再重新安装。在 Linux 服务器上则要先装 CMake 和编译依赖，一句命令的事：

sudo apt install build-essential cmake

装完后用下面这段代码验证环境：

import face_recognition import cv2 img = face_recognition.load_image_file("test.jpg") faces = face_recognition.face_locations(img) print(f"检测到 {len(faces)} 张人脸")

如果是零张，大概率是图里人脸太小或者角度太大；如果报错提示无法加载图片，检查一下 opencv-python 是否正确，两者独立安装但存在版本兼容问题，我遇到过一次 opencv 4.x 读取图片后和 face_recognition 内部解码冲突的情况，后来统一升级到最新版本解决。

3.2 注册流程：从照片到特征入库

注册流程的目的是把员工的人脸特征从图片变成数据库里一条记录。核心代码如下：

import face_recognition import pymysql import base64 import pickle def register_employee(emp_no, name, department, photo_path): # 1. 加载图片并提取特征 image = face_recognition.load_image_file(photo_path) face_encodings = face_recognition.face_encodings(image) if len(face_encodings) == 0: raise RuntimeError("未在图片中检测到人脸，请更换照片或调整角度") if len(face_encodings) > 1: raise RuntimeError("检测到多张人脸，请使用单人证件照") encoding = face_encodings[0] # 128 维向量 # 2. 序列化特征 encoding_b64 = base64.b64encode(pickle.dumps(encoding)).decode("utf-8") # 3. 写入数据库 conn = pymysql.connect( host="localhost", user="root", password="123456", database="attendance_db", charset="utf8mb4" ) cursor = conn.cursor() sql = ("INSERT INTO employees (emp_no, name, department, face_encoding, photo_path) " "VALUES (%s, %s, %s, %s, %s)") cursor.execute(sql, (emp_no, name, department, encoding_b64, photo_path)) conn.commit() cursor.close() conn.close()

注意我做了两个人脸数量的判断，这不是多余代码。实际注册时，有人可能不小心提交了合影，如果代码不做拦截，特征向量会提取到第一张人脸，但没法和具体的人对应上，后期识别会出现张冠李戴。多人脸时直接拒绝注册，让操作人换张照片，这个体验更安全。

还有一个实操经验：注册用的照片质量，直接决定了后期识别的成功率。我建议至少满足三点：正脸、光照均匀、无遮挡。最好让员工在办公区现场用摄像头拍一张，而不是拿身份证照片扫描，因为它和现场环境光的色差很大，识别率会下降。

3.3 识别流程：摄像头实时比对到底应该怎么做

实时识别流程通常分成两段：检测和比对。检测负责找出画面里的人脸位置，比对负责把人脸特征和库里的特征做距离计算。face_recognition 库提供了便捷封装，完整代码如下：

import face_recognition import pickle import base64 import numpy as np from scipy.spatial import distance import cv2 def load_known_faces(cursor): """加载数据库中所有员工特征到内存""" cursor.execute("SELECT emp_no, name, face_encoding FROM employees") rows = cursor.fetchall() known_faces = [] for emp_no, name, enc_b64 in rows: encoding = pickle.loads(base64.b64decode(enc_b64)) known_faces.append((emp_no, name, encoding)) return known_faces def recognize(unknown_encoding, known_faces, threshold=0.4): """返回最佳匹配的员工信息，未匹配返回 None""" best_match = None min_distance = float("inf") for emp_no, name, encoding in known_faces: dist = distance.euclidean(unknown_encoding, encoding) if dist < min_distance: min_distance = dist best_match = (emp_no, name) if best_match and min_distance <= threshold: return best_match, min_distance return None, min_distance def main_loop(): # 数据库连接与已知人脸加载省略 video_capture = cv2.VideoCapture(0) while True: ret, frame = video_capture.read() if not ret: continue # 缩小画面加快检测速度 small_frame = cv2.resize(frame, (0, 0), fx=0.5, fy=0.5) # 把 BGR 转为 RGB，因为 face_recognition 默认使用 RGB rgb_frame = cv2.cvtColor(small_frame, cv2.COLOR_BGR2RGB) face_locations = face_recognition.face_locations(rgb_frame) face_encodings = face_recognition.face_encodings(rgb_frame, face_locations) for face_encoding, face_location in zip(face_encodings, face_locations): match, dist = recognize(face_encoding, known_faces) if match: emp_no, name = match # 此处联动考勤业务模块 handle_attendance(emp_no) print(f"识别成功: {name}, 距离: {dist:.3f}")

这里有几个细节值得展开。第一，使用face_recognition.face_locations先定位，再用face_recognition.face_encodings提取特征，这是目前最稳的调用姿势。很多初学者直接调face_recognition.face_encodings(frame)，如果图片里有多个人脸，它会返回多个特征，而你不一定知道谁是谁，反而容易出错。第二，scipy 的欧氏距离计算，也可以用 numpy 自己算，np.linalg.norm(unknown - known)效果一样。第三，帧率优化方面，我一般设置每 2 到 3 秒抽一帧做识别，既能保证识别结果及时，又能显著降低 CPU 占用。完整时间去跑每帧识别，CPU 会一直保持在 100% 附近，过一会儿就会发热降频，识别速度反而更慢。

3.4 阈值怎么定：识别率还是误识率，这是个平衡题

face_recognition 库官方文档给出的默认阈值是 0.4 的欧氏距离，距离越小表示两个人脸越相似。我在实际项目里测试过，0.4 对大部分场景偏严，可能导致少部分员工因为光线原因被拒识别；但如果放宽到 0.5，又容易出现两个人长得比较像的时候互相误认。

我的建议是先用一段时间的真实环境数据做校准。具体做法是：让 10 个员工分别在正常光线下采集图像，算他们自己的特征和库里特征的欧氏距离；再随机抽两台机器做跨人比对，记录最小距离和最大距离。如果同一人距离的中位数是 0.35，而不同人之间的最小距离是 0.48，那阈值取 0.40 到 0.43 之间就相对安全。距离分布越集中，阈值设定越有把握。

如果发现同一人的距离经常超过 0.5，说明注册照片和现场环境的差异太大，我不建议为了迁就它把全局阈值明显调低，更好的做法是补充注册多张照片：正面、侧脸、日常表情各一张，识别时只要任一张特征匹配就通过。这个办法在实际项目里把准确率从 91% 拉到了 96% 以上。

3.5 活体检测与防作弊：不能只靠一张脸

考勤场景下，照片攻击是最常见的作弊手段：别人拿张 A4 纸打印的照片对着摄像头晃一下。纯静态人脸识别完全防不住，必须要加活体检测。

最简单的做法是动作指令配合：识别成功后，屏幕随机提示“眨眨眼”或“摇摇头”，摄像头捕捉到对应动作才确认签到。这种方法实现成本低，但用户操作成本高，排长队时会让人烦躁。

进阶做法是用眨眼检测：调用 OpenCV 的人脸关键点检测，实时计算眼睛纵横比（EAR）。当一个人自然眨眼一次时，EAR 会先变小再恢复，这可以作为“活体”的判据。亲测这个方法识别稳定的员工问题不大，但戴眼镜员工在弱光环境下的眨眼参数波动比较大，误判率会上升。

从项目边界管理来说，我更建议先做简单活体，然后在部署层面加强：考勤设备固定安装，摄像头正对人员通道，管理员可复查照片留存。系统里每一条考勤记录，我还会保存一张识别时的现场截图，后续有人质疑时能追溯，这个细节往往比算法防作弊更有威慑力。

4. 考勤业务逻辑与联动实现

4.1 一天一条记录：第一次刷脸是签到，第二次是签退

先明确业务规则：员工早上第一次识别，记录为签到；当天再次识别，记录为签退；之后如果再识别，约定为重复签退或忽略，由业务决定。我采用一天一条记录 + 每次识别做判断的处理方式，因为这样统计月份考勤时最简单。

逻辑代码如下：

from datetime import datetime, time as dtime def handle_attendance(emp_no): now = datetime.now() today = now.date() conn = get_connection() cursor = conn.cursor() # 1. 查询当天是否已有记录 cursor.execute( "SELECT id, check_in_time FROM attendance WHERE emp_no = %s AND work_date = %s", (emp_no, today) ) row = cursor.fetchone() if row is None: # 2. 首次识别：插入签到记录，并根据上班时间判断是否迟到 check_in_limit = dtime(9, 0) # 9:00 上班 status = 1 if now.time() <= check_in_limit else 2 # 1正常 2迟到 cursor.execute( "INSERT INTO attendance (emp_no, work_date, check_in_time, status) " "VALUES (%s, %s, %s, %s)", (emp_no, today, now, status) ) conn.commit() print(f"{emp_no} 签到成功，状态: {status}") else: # 3. 已有签到记录，更新签退时间 cursor.execute( "UPDATE attendance SET check_out_time = %s WHERE id = %s", (now, row[0]) ) conn.commit() print(f"{emp_no} 签退成功")

如果你想支持上午、下午两次上下班的复杂规则，那就要考虑拆成四段记录，数据结构也会复杂不少。我的建议是：如果业务没有强制要求，优先做“一天一条 + 签入签出”的模式，统计简单，管理也方便。

4.2 跨天与时间边界：深夜加班的签退归属哪一天

考勤系统最容易出错的就是跨天问题。假设员工晚上 22:30 签到加班，次日凌晨 01:30 签退，签到日期是 12 月 1 日，签退日期是 12 月 2 日。如果用check_out_time直接更新到 12 月 1 日的记录里，会出现一个诡异现象：签退时间比签到时间还早。

最稳妥的方式是约定：签到日期的自然日即考勤归属日。如果签退发生在次日凌晨，仍然更新到签到那天的记录里，但需要在展示时做特殊处理。如果签退发生在 24 小时后，那就应该视为下一次签到记录的开头。我建议新增一个 sign_type 字段区分“上班签到”和“加班签到”，避免加班记录混在正常考勤里干扰月度统计。

我实际项目里遇到过最烦的情况是员工横跨两天：22:30 第一次刷脸进入公司，02:30 第二次刷脸离开。如果不做区分，系统会认为上班签到是 22:30，签退是 02:30，共 4 小时；但实际上他是来加班 4 小时。这里就需要“加班签到”的入口，员工选择“上班”或“加班”模式后再识别，或者用时段自动推断：18:00 之后首次识别视为加班。自动推断简单粗暴，但节假日排班时会有误差，所以我的最终方案还是人脸确认后弹出按钮让人选。

4.3 管理端统计：SQL 怎么写才高效

月度统计的核心需求是：某员工一个月内，正常出勤多少天、迟到多少次、早退多少次、缺勤多少天、请假多少天。基于前面的表结构，聚合 SQL 可以这么写：

SELECT emp_no, COUNT(*) AS total_days, SUM(CASE WHEN status = 1 THEN 1 ELSE 0 END) AS normal_days, SUM(CASE WHEN status = 2 THEN 1 ELSE 0 END) AS late_days, SUM(CASE WHEN status = 3 THEN 1 ELSE 0 END) AS early_leave_days, SUM(CASE WHEN status = 4 THEN 1 ELSE 0 END) AS absent_days, SUM(CASE WHEN status = 5 THEN 1 ELSE 0 END) AS leave_days FROM attendance WHERE work_date BETWEEN '2024-11-01' AND '2024-11-30' GROUP BY emp_no;

如果你还需要查询某个人的每日明细并导出 Excel，可以用 Python 的 openpyxl 生成 xlsx 文件，或者在管理端页面里用 DataTables 做前端表格，数据接口返回 JSON 即可。这个部分不是核心难点，但注意 SQL 里的索引使用：WHERE 条件命中 work_date 范围，再 GROUP BY emp_no，前面的辅助索引加上之后，百万行以下的数据量都没有问题。

4.4 请假和考勤怎么联动

处理请假后，当天的考勤不能直接缺失，否则会被统计成缺勤。我的做法是：请假审批通过后，管理端自动在 attendance 表插入一条记录，status 置为 5（请假），check_in_time 和 check_out_time 留空。这样月度 SQL 统计时，请假天数直接被 SUM(CASE WHEN status=5) 抓出来，不会混入缺勤。

你可能会问，为什么不在统计 SQL 里额外关联 leave_records，而是提前在 attendance 里造一条？因为考勤统计通常只以 attendance 表为准，逻辑越单一越不容易出错。离职后的补录、历史修改也不用处理 join 的时序问题。

5. 实操过程中踩过的坑与排查实录

5.1 识别失败：先查环境，再查阈值，最后查特征数据

我排查识别成功率低的问题有一套固定顺序，因为这样可以快速缩小范围。

第一步看现场图像质量。把摄像头抓到的原图保存下来，肉眼检查有没有严重过曝、逆光、侧脸过多。大部分识别失败都是图像质量造成的，而不是算法问题。某次项目里投诉率很高的工位附近，我过去一看，摄像头正对窗户，员工下午全逆光，换了个补光角度后，识别率立马上来了。

第二步检查数据库里的特征是否完好。之前发生过一次诡异现象：一部分员工始终识别成功，另一部分始终失败，而且失败的那些人换了新照片注册也还是失败。排查后发现，早期注册过程里，有一批员工的人脸特征被 pickle 序列化后，因为编码问题在写入时截断了，特征向量长度已经不是 128，导致距离计算混乱。后来我在注册代码里加了长度校验，识别时也做向量长度断言，问题不再出现。

第三步才是调阈值。如果大部分人都能识别，就个别距离在 0.42 到 0.48 之间被拒，你把阈值调到 0.46 通常就能解决。但如果一组人里面的互相距离都不稳定，说明注册库本身质量不行，调整阈值只是饮鸩止渴。

5.2 MySQL 连接问题：短连接风暴和编码坑

考勤设备是长时间运行的，如果你每识别一次就建一次数据库连接，连接建立的开销迟早会拖垮系统。因为识别频率高，高峰期可能每秒都有连接请求，MySQL 默认的一些连接限制会被打爆，报错“Too many connections”。

方案有两个。第一，使用连接池，比如 pymysql 搭配 DBUtils 的 PooledDB，环形复用连接。第二，识别主循环保持一个长连接，周期性 ping 保活，只有当连接断开时才重连。第二种方案更轻量，适合单台考勤机。我的生产程序里采用的是长连接 + 异常重连机制。

编码问题是另一个高频坑。MySQL 建库时使用 utf8mb4，建表时也指定 utf8mb4，Python 连接时再传charset="utf8mb4"，三处保持一致，中文字段名和人名才能正常读写。如果哪一处用了默认 latin1，写入的中文就会变成问号，而且这种数据一旦写入，很难恢复，只能删掉重建。

5.3 性能问题：摄像头卡顿、识别排队

如果跑识别的主循环只有单线程，在员工排队考勤的高峰期，画面会被前一个人的识别任务阻塞，导致屏幕卡顿。我采用的优化手段是设置一个简单的识别锁：新帧到来时，如果上一次识别还没结束，就直接跳过这一帧，只更新画面显示。这样实际识别频率可能从每秒 5 次降到每秒 2 次，但因为识别任务不阻塞画面线程，体验反而好很多。

更进一步，可以把识别放到生产者-消费者队列里：摄像头作为生产者，持续读帧放队列；识别线程作为消费者，从队列取帧识别。识别完成后，把结果放到结果队列，主线程从结果队列拿结果并触发考勤逻辑。这个方案在树莓派上也能流畅跑起来，只是内存和 CPU 占用会高一些。

另外，如果员工数量达到千人级别，每次比对都遍历全部特征会开始吃力。我建议在数据库里加一个部门字段作为过滤条件：考勤机固定部署在某个楼层或部门区域，识别前先只取该部门的特征子集，通常能把候选数量缩小到几十人，比对主体就瞬间完成了。或者直接用 numpy 矩阵化计算，一次算完所有距离，利用 numpy 底层向量化代替 Python 循环，速度提升明显。

5.4 一张速查表：常见问题、原因与对策

6. 写在最后的经验体会

做完这个考勤系统，我最深的体会是：人脸识别只是整个链路最亮眼的那个环节，真正决定系统好不好用的，是那些琐碎的业务规则和数据可靠性。你可以在识别准确率上花大量时间挠头，但如果你没有设计好一天一条记录的考勤表，或者没有处理跨天签退，上线第一天就会被行政同事叫去改需求。先把流程梳理清楚，再写代码，这条原则在这里体现得非常明显。

最后再分享一个小技巧：所有考勤记录写入数据库后，务必保留人脸识别时的现场摄像头截图。截图按“员工编号_日期_时间”命名，存到独立目录。这一步能给你省去很多不必要的争执——九成以上的“我没迟到”“这不是我”的争议，看一眼截图就结束了。从产品角度看，留痕能力甚至比识别精度更重要。

这个项目后续还能往不少方向扩展：把识别端和管理端都做成 Web 服务，在浏览器里看实时考勤；加一台备用识别设备做故障切换；把报警规则接入企业微信或钉钉，迟到自动提醒。底层的识别和存储架构已经立住，往哪个方向加功能都很顺手。做系统集成就是这样，基础打得稳，后面的事情自然顺。