1. 为什么要自己动手做一套人脸识别考勤系统先说个真实的痛点。某小型团队之前用的是那种指纹打卡机一到冬天干燥季节手指脱皮、静电干扰一堆人打不上卡后来换成刷卡又有人忘带卡、代刷月底对考勤记录的时候行政那边对着Excel恨不得摔键盘。后来我帮他们做了一套基于人脸识别和MySQL的考勤管理系统刷脸即打卡识别时间基本控制在1秒内月底导报表也很快。整个过程做下来发现这类系统的技术难度其实没有想象中高主要还是几个关键点要把握到位人脸识别方案的选型、数据库表结构设计、识别结果如何准确落库、以及后期如何排查那些“莫名其妙”考勤异常的问题。这篇文章就是把这套系统的完整实现过程拆给你看从一个实际开发者的角度把要踩的坑、要注意的细节、可以“抄作业”的代码都给到。适合的人群包括想做课程设计的同学、公司内需要做小型考勤工具的开发者以及想了解人脸识别如何落地到实际业务场景的产品和技术朋友。先说结论这套系统的核心链路并不复杂本质上就是“摄像头抓拍人脸 → 人脸特征提取 → 与数据库里存的员工人脸特征做比对 → 返回匹配结果 → 写入考勤记录表”。但把这条链路做稳定、做准、做得能应对真实环境的复杂光线和角度变化才是真正花时间的地方。2. 整体设计方案从需求到架构的思考过程2.1 核心需求拆解不只是“打个卡”很多人一听到“考勤系统”第一反应就是“识别到人脸就记录一下时间”但实际需求远比这个复杂。我习惯先把需求拆成几个维度来梳理需求维度具体说明对应技术环节人员管理新员工录入人脸老员工离职删除信息修改员工表的增删改查 人脸特征库维护考勤打卡上下班两个时间点识别识别成功即记录人脸识别 考勤记录写入考勤计算根据上班时间和下班时间判断迟到、早退、缺卡SQL查询 逻辑规则计算报表统计按月/按日查看每个人的出勤情况多表联查 数据聚合异常处理没识别上、替打卡、照片不清晰等情况日志记录 补卡流程把需求拆开以后你才会发现人脸识别其实只占了整个系统的一小部分工作量更多的活在后端逻辑和数据库设计上。这里给个真实的比例参考整个开发周期里人脸识别模块可能只占40%的时间剩下的60%几乎都花在了业务逻辑、异常处理和数据统计上。2.2 为什么选择“本地人脸特征比对 MySQL”方案人脸识别方案其实有很多种有纯离线的库比如OpenCV的人脸检测 深度学习模型提取特征有在线API方案比如各类云服务的人脸识别接口。我当时的选择逻辑很直接第一考虑到是内部考勤系统数据要留在本地员工的生物特征信息不适合传到第三方平台这是合规和数据安全的底线。第二在线API按调用量收费考勤是高频场景每天几百上千次调用长期下来成本不低。第三本地方案配合GPU或者即使是纯CPU在考勤这种“单个人脸比对”场景下性能已经完全够用。所以最后的方案是用开源的计算机视觉库做人脸检测和对齐用预训练好的深度学习模型提取人脸特征向量比如128维或512维的特征存到MySQL里。打卡的时候提取当前摄像头拍到的人脸特征去数据库里比对计算余弦相似度超过阈值就认为是同一个人然后写入考勤记录。整个链路完全本地化干干净净。2.3 系统架构模块怎么划分这套系统的架构我按功能拆成了四个模块各干各的互不纠缠人脸采集模块录入员工人脸照片提取特征入库 ↓ 人脸识别模块实时摄像头抓拍、人脸检测、特征提取、比对 ↓ 考勤业务模块判断打卡类型、写入记录、处理重复打卡 ↓ 数据管理模块员工管理、考勤查询、报表统计、异常处理采集和识别可以共用一个摄像头工具类但逻辑上最好分开。因为采集的时候是“主动配合”的会要求员工正对摄像头、调整姿势而识别的时候是“被动抓拍”的要能应对各种角度、光线、表情变化这两者的处理逻辑差别很大。另外数据库连接这块我建议直接用一个连接池来管不然每来一个打卡请求就建立一次数据库连接高并发的时候很容易把数据库拖垮。3. MySQL数据库设计考勤系统的地基3.1 表结构设计不只是两张表那么简单数据库是这套系统的地基。很多人一上来就建一张员工表、一张考勤记录表但真正跑起来以后你会发现还需要人脸特征表、考勤规则表、补卡申请表等。我最终的库表结构是这样的-- 员工信息表 CREATE TABLE employee ( id INT PRIMARY KEY AUTO_INCREMENT COMMENT 员工ID, emp_no VARCHAR(20) NOT NULL UNIQUE COMMENT 工号, name VARCHAR(50) NOT NULL COMMENT 姓名, department VARCHAR(50) COMMENT 部门, position VARCHAR(50) COMMENT 职位, status TINYINT DEFAULT 1 COMMENT 状态1在职 2离职, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT员工信息表; -- 人脸特征表一个员工可能有多张人脸照片的特征 CREATE TABLE face_feature ( id INT PRIMARY KEY AUTO_INCREMENT, emp_id INT NOT NULL COMMENT 员工ID, feature_vector BLOB NOT NULL COMMENT 人脸特征向量(二进制), image_path VARCHAR(255) COMMENT 人脸照片保存路径, feature_version VARCHAR(20) COMMENT 特征提取模型版本, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (emp_id) REFERENCES employee(id) ON DELETE CASCADE ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT人脸特征表; -- 考勤记录表 CREATE TABLE attendance_record ( id INT PRIMARY KEY AUTO_INCREMENT, emp_id INT NOT NULL COMMENT 员工ID, check_time DATETIME NOT NULL COMMENT 打卡时间, check_type TINYINT COMMENT 类型1上班 2下班, check_result TINYINT COMMENT 结果1正常 2迟到 3早退 4缺卡, similarity DECIMAL(5,4) COMMENT 人脸比对相似度, image_path VARCHAR(255) COMMENT 打卡抓拍照片, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_emp_time (emp_id, check_time), FOREIGN KEY (emp_id) REFERENCES employee(id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT考勤记录表; -- 考勤规则表上下班时间、迟到阈值等 CREATE TABLE attendance_rule ( id INT PRIMARY KEY AUTO_INCREMENT, rule_name VARCHAR(50) COMMENT 规则名称, work_start_time TIME NOT NULL COMMENT 上班时间, work_end_time TIME NOT NULL COMMENT 下班时间, late_threshold_minutes INT DEFAULT 0 COMMENT 迟到宽容分钟数, is_active TINYINT DEFAULT 1 COMMENT 是否启用 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT考勤规则表;关于特征向量的存储格式这里要强调一个细节。很多初学者会把特征向量转成字符串比如用逗号拼接的文本再存进VARCHAR字段这样其实很不靠谱。特征向量通常是浮点数数组128维或者512维转成字符串会浪费大量空间而且查询的时候没法直接比对。正确的做法是把它序列化成二进制存到BLOB字段里或者干脆用专门管理特征向量的工具。这里为了纯粹依赖MySQL实现存BLOB是最实际的选择。3.2 为什么特征向量要单独建表这里多讲一句为什么人脸特征不直接存在employee表里。实际业务中一个员工可能录入多张人脸照片正面照、侧面照、不同光线条件下的照片目的是提升后期比对的准确率。如果把特征向量直接存在员工表里设计上就限制了“一个人只能有一条识别特征”这个约束不合理。另外人脸识别模型是会升级的。可能上个月用的模型提取的特征是128维下个月换了个更优的模型变成512维。如果特征单独建表加一个feature_version字段升级的时候只需要重新生成新版本的特征旧特征还可以保留用来做兜底比对。这是我实际开发中踩过坑以后才加上的设计前期图省事没做后来升级模型时差点把整个库都重建了。3.3 考勤记录表为什么用DATETIME而不是分开存日期和时间关于考勤记录表日期和时间字段的设计也有讲究。有些人习惯把日期2025-01-10和时间09:00:00分开两个字段存美其名曰“查询方便”。但实际上用DATETIME一个字段配合MySQL自带的日期函数DATE()、TIME()、DATE_FORMAT()完全可以做到同样的查询效果而且数据更紧凑、排序更自然。如果分开存查“某员工某月每天的上下班记录”时反而要多一层拼接逻辑没有必要。4. 人脸识别流程从采集到比对的完整实现4.1 人脸采集入库这一步偷懒后面全是坑人脸采集是整个系统里最容易被低估的环节。很多开发者随便拿张照片就往库里塞结果识别的时候发现要么识别不上要么频繁误识别。根据我的实操经验人脸照片采集必须满足几个硬性要求第一照片里人脸区域要足够大。人脸区域至少占整张照片面积的30%以上摄像头距离人脸0.5~1.2米之间。第二光线均匀不能在脸上形成明显的阴影或高光。第三表情自然不要夸张大笑或紧闭双眼。第四尽量是正面照左右偏转角度不要超过15度。为了控制采集质量我在录入环节加了一个简单的校验逻辑先检测照片里有没有人脸然后检查人脸框的尺寸占整张图的比例低于阈值就直接拒绝录入并提示重新拍摄。这个小逻辑看着不起眼但大幅提升了后期识别的准确率。录入时建议给每个员工拍2~3张不同角度的照片正面、左右轻微侧转、稍远稍近各一张分别提取特征存到face_feature表里。比对的时候只要任意一张特征匹配成功就认为是同一个人。这招对真实场景特别管用因为员工每天打卡时的站位和角度不可能完全一样。4.2 特征提取与比对核心代码实现整个核心逻辑可以封装成一个服务类。这里给出关键代码用Python实现配合常见的人脸识别开源库import pickle import numpy as np import mysql.connector from mysql.connector import pooling class FaceRecognitionService: def __init__(self, db_config): # 使用连接池管理MySQL连接 self.pool mysql.connector.pooling.MySQLConnectionPool( pool_nameattendance_pool, pool_size10, **db_config ) self.threshold 0.6 # 余弦相似度阈值经验值需根据实际调试 self._load_model() def _load_model(self): # 加载预训练的人脸识别模型 # 这里使用常见的深度学习人脸识别模型输出512维特征向量 self.face_detector ... # 人脸检测器 self.face_encoder ... # 人脸特征编码器 def extract_feature(self, image): 提取一张照片中最大人脸的特征向量 # 检测人脸 faces self.face_detector.detect(image) if len(faces) 0: return None # 取面积最大的人脸 largest_face max(faces, keylambda f: f.area()) # 对齐并裁剪人脸区域 aligned_face self._align_face(image, largest_face) # 提取特征向量 feature self.face_encoder.encode(aligned_face) return feature def recognize(self, image): 识别摄像头抓拍的图像中的人脸 feature self.extract_feature(image) if feature is None: return None, 0.0 # 获取数据库里所有已注册的员工特征 conn self.pool.get_connection() cursor conn.cursor(dictionaryTrue) cursor.execute(SELECT emp_id, feature_vector FROM face_feature) rows cursor.fetchall() cursor.close() conn.close() best_match None best_similarity 0.0 for row in rows: db_feature pickle.loads(row[feature_vector]) sim self._cosine_similarity(feature, db_feature) if sim best_similarity: best_similarity sim best_match row[emp_id] if best_similarity self.threshold: return best_match, best_similarity return None, best_similarity def enroll_employee(self, emp_id, image): 录入员工人脸特征 feature self.extract_feature(image) if feature is None: raise ValueError(未检测到人脸请重新拍摄) feature_bytes pickle.dumps(feature.astype(np.float32)) conn self.pool.get_connection() cursor conn.cursor() cursor.execute( INSERT INTO face_feature (emp_id, feature_vector) VALUES (%s, %s), (emp_id, feature_bytes) ) conn.commit() cursor.close() conn.close() staticmethod def _cosine_similarity(f1, f2): 计算两个特征向量的余弦相似度 a np.array(f1, dtypenp.float32).flatten() b np.array(f2, dtypenp.float32).flatten() norm_a np.linalg.norm(a) norm_b np.linalg.norm(b) if norm_a 0 or norm_b 0: return 0.0 return float(np.dot(a, b) / (norm_a * norm_b))这段代码有几个关键点要解释一下。第一为什么用连接池而不是每次单独建立连接。考勤打卡的调用频率虽然不算特别高但人脸识别本身耗CPU数据库操作又要走网络如果每个请求都新建连接系统在高并发场景下比如早上8点50分一大批人同时涌到闸机口容易出现连接数打满、响应变慢的情况。连接池复用连接是稳定性的基本保障。第二为什么用pickle序列化特征向量而不是numpy的save。numpy的save会附带一些额外的元数据占用空间大pickle直接序列化numpy数组存取速度更快而且读出来直接用np.array还原就行。第三这个阈值0.6是怎么定的。这不是拍脑袋定的而是我用一批真实采集的样本测试出来的。具体做法是收集了约2000张不同员工在不同光线/角度下的人脸照片两两计算相似度画出同一人的相似度分布和不同人的相似度分布取两者的分界点作为阈值。如果你的场景里员工的肤色、年龄、外貌差异不大比如都是年轻人阈值可以适当调高到0.65如果人员结构复杂0.55~0.6比较稳。这个后面“问题排查”部分还会详细说。4.3 打卡逻辑什么时候写入记录什么时候不写打卡逻辑看着简单实际里面藏着很多细节。我当时写了一个考勤服务类核心逻辑是class AttendanceService: def __init__(self, pool, face_service, rules): self.pool pool self.face_service face_service self.rules rules # 考勤规则字典 def check_in(self, emp_id, image, check_time): 打卡入口 返回: (success, message, record_id) # 1. 先做面部识别 recognized_id, similarity self.face_service.recognize(image) if recognized_id is None: return False, 未识别到匹配的人脸请重试, None # 2. 识别结果和请求的emp_id不一致 if recognized_id ! emp_id: return False, 人脸与员工信息不匹配, None conn self.pool.get_connection() cursor conn.cursor(dictionaryTrue) try: # 3. 判断当前时间属于上班打卡还是下班打卡 now_time check_time.time() if now_time self.rules[work_start_time] or \ (self.rules[work_start_time] now_time self.rules[latency_deadline]): check_type 1 # 上班 elif now_time self.rules[work_end_time]: check_type 2 # 下班 else: # 中午时间不允许打卡 return False, 当前时段不是打卡时段, None # 4. 防重复打卡上班打过卡短时间内再打不重复记录 # 这里判断当前时段是否已有打卡记录 cursor.execute( SELECT id, check_type FROM attendance_record \ WHERE emp_id%s AND DATE(check_time)%s AND check_type%s, (emp_id, check_time.date(), check_type) ) existing cursor.fetchone() if existing: return False, 已经打过卡了, None # 5. 写入考勤记录 cursor.execute( INSERT INTO attendance_record \ (emp_id, check_time, check_type, check_result, similarity, image_path) \ VALUES (%s, %s, %s, %s, %s, %s), (emp_id, check_time, check_type, self._judge_result(check_time, check_type), similarity, ...) ) conn.commit() return True, 打卡成功, cursor.lastrowid finally: cursor.close() conn.close() def _judge_result(self, check_time, check_type): 判断打卡结果是正常、迟到还是早退 now_time check_time.time() if check_type 1: # 上班 if now_time self.rules[work_start_time] timedelta(minutesself.rules[late_threshold_minutes]): return 1 # 正常 else: return 2 # 迟到 else: # 下班 if now_time self.rules[work_end_time]: return 1 # 正常 else: return 3 # 早退这个逻辑里最值得说的是“时段判断”。很多人写打卡逻辑时直接按时间硬编码9点前上班打卡18点后下班打卡。但真实场景里会有各种边界情况早上7:30就来了是上班打卡还是加班打卡下午16:00离开算早退还是正常下班中午12:00走出办公室应该记录什么我的做法是先通过考勤规则表配置“上班时间”“下班时间”和“午休区间”然后根据当前时间落在哪个区间来判定是哪种类型的打卡。不在任何打卡时段内的请求直接拒绝前端提示“当前不在打卡时段”。这样既灵活又能避免中午出去吃饭误打卡的问题。4.4 考勤计算迟到早退怎么算才合理考勤结果的计算不只是在打卡那一刻判断一个结果就完了月底还得有汇总统计。我的方案是每天凌晨用定时任务把前一天的考勤数据做一次“日结算”对每个人的上下班打卡记录进行匹配处理缺卡的情况并生成每日考勤汇总。这里容易踩坑的是“跨天排班”的问题。比如夜班员工晚上22:00上班第二天凌晨6:00下班。如果简单地按自然日来匹配上下班记录就会出现问题凌晨的打卡记录算到昨天还是今天我的处理办法是在考勤规则表里加一个“换班日偏移”字段支持把凌晨的打卡归属到前一个工作日。这个细节一开始没注意后来有夜班员工月初对账时发现了问题才补上去的。5. 实操环节部署这套系统的关键步骤与避坑指南5.1 环境准备硬件和软件选型建议先说一下硬件需求。我测试用的环境是CPU老款高性能处理器或者主流i5以上都可以纯CPU推理单次人脸识别约300~500ms打卡场景完全够用。内存8GB起步16GB更稳。摄像头普通USB摄像头分辨率建议不低于720P最好带自动白平衡和自动对焦。不要买那种特别便宜的鱼眼摄像头画面畸变会影响人脸检测准确率。操作系统Windows和Linux都行但建议生产环境用Linux长期挂机更稳定。软件层面Python版本建议3.8。核心依赖库包括人脸检测工具库、深度学习框架CPU版就行、图像处理库、MySQL驱动、以及Web后端框架如果要做界面。如果是纯后端API建议搭配一个简单的Nginx WSGI服务如果有前端界面前后端分离的话可以加一个Nginx做静态文件服务。5.2 部署步骤从零到可以打卡整个部署流程我总结成了六个步骤创建数据库和表结构。用上面提供的SQL语句按顺序执行即可。注意字符集要选utf8mb4因为员工姓名里可能有生僻字utf8mb4支持更全。准备一个目录存放打卡抓拍的照片。考勤记录要留痕每打卡一次就把当次抓拍的原始图像保存到本地或对象存储同时把文件路径存到考勤记录表里。这很重要后期有员工质疑“我没打过卡”的时候调出照片就是铁证。安装人脸识别相关依赖库。这里建议先把OpenCV装上然后装人脸识别用的深度学习库。安装过程中常见的坑是依赖库版本冲突我的建议是用一个独立的虚拟环境别和系统全局环境混在一起。启动一个人脸注册脚本把现有员工的照片批量导入提取特征后写入face_feature表。注册时给每个员工拍2~3张不同角度和光照条件的照片这样识别更稳。启动考勤服务。建议先跑一段测试模式用本机摄像头对着自己的脸试打几次卡确认识别正常、数据库写入正常。用Web服务把查询和报表功能跑起来。前端页面不需要花太多精力核心功能是按部门按日期查询考勤记录按月汇总迟到早退次数导出Excel报表。这部分用现成的Web框架几天就能搞定。5.3 参数调优阈值和识别速度的平衡部署完以后最花时间的其实是调参。两个核心参数人脸检测的最小尺寸阈值、相似度阈值。关于最小检出尺寸默认值可能要求人脸至少占图像的一定比例。如果摄像头安装距离远人脸很小就调低这个阈值如果距离近可以适当调高避免误检到背景里的海报人脸。根据我的经验人脸宽度在图像里至少要有80像素识别率才比较稳。相似度阈值这个参数我在前面已经说过必须结合实际场景测试。有一个快速调试的思路找10个员工每人拍10张不同的照片任意两张同一人的相似度一般应该在0.65以上不同人之间的相似度一般应该在0.45以下。如果你的测试结果不是这个数量级说明模型选得不对或者照片质量太差。这个数据可以当个基准参考具体阈值还是要按你实际采集的数据分布来定。还有一个容易被忽视的点识别服务的性能监控。每次识别用了多少毫秒相似度分数是多少最好都打日志。否则后期系统卡顿或者识别率下降的时候你会发现根本没有数据可以分析。6. 常见问题与排查技巧实录6.1 识别失败率高的几个常见原因实际跑了一个月以后你会收到一堆“打不上卡”的投诉。根据我的经验90%的问题都出在以下几个环节现象可能的根因排查方法某人一直识别失败录入的底照质量太差员工发型/眼镜变化较大重新录入多张照片检查face_feature表的特征版本是否一致某人经常识别成别人相似度阈值太低调高阈值查看log里的相似度分布上午正常下午识别失败摄像头逆光人脸区域过暗调整摄像头位置或补光打卡速度太慢数据库里特征数量多但没有做分区或索引看看是不是全表扫描了这里重点说一下“眼镜”这个变量。很多员工上班戴眼镜、下班摘眼镜人脸特征会有较大变化。解决办法是在录入照片时让他们把戴眼镜和不戴眼镜的照片各拍一张分别提取特征入库。同理刘海变化、浓妆等情况也建议多录几张特征照片做冗余。6.2 数据库写入失败导致打卡无记录有一次系统跑着跑着突然没人能打卡了。查了日志发现人脸识别正常但数据库连接超时。原因是MySQL的max_connections被默认值限制住了而连接池的初始连接数设置过大加上有些连接被异常占用后没有释放导致连接池被占满。排查思路是这样的先看MySQL的错误日志确认是不是连接数满了然后检查后端代码里有没有连接泄漏比如try了SQL操作但finally里忘了关闭cursor。这里给一个实用建议所有数据库操作必须在finally块里释放连接或者用上下文管理器来自动释放。我当时就是漏了几处高峰期连接池被打满重启服务才好。6.3 打卡记录重复/缺失的数据问题还有一个常见问题同一员工5分钟内打了多次卡生成了多条记录。正常应该只保留第一条但实际会出现重复。排查下来有两种情况一是前后端重复请求前端按钮点了两次二是数据库判断重复时用的时间范围太窄比如只检查了“同一秒是否有记录”忽略了跨秒的点击。解决方法是把重复判断的时间窗口放宽到3~5分钟同时在前端做按钮防抖。对于已经产生的脏数据跑一个去重SQL先清一下DELETE r1 FROM attendance_record r1 INNER JOIN attendance_record r2 WHERE r1.id r2.id AND r1.emp_id r2.emp_id AND r1.check_type r2.check_type AND ABS(TIMESTAMPDIFF(SECOND, r1.check_time, r2.check_time)) 300;注意执行前先备份数据。6.4 摄像头画面模糊的处理摄像头画面模糊这个坑也踩过。USB摄像头的自动对焦有时候会失效特别是光线暗的时候画面一直处于“拉风箱”的状态。解决办法是买支持手动固定焦距的摄像头部署好后调好角度把自动对焦关掉直接在代码里固定焦距。这样反而更稳定不会在识别时突然对焦导致画面抖动。6.5 月度报表生成太慢的优化月度报表在最开始的时候是用一条SQL把所有的打卡记录查出来然后在代码里逐条计算状态。这个方案在数据量小的时候没问题但跑到3个月后记录数上了几万条报表接口的响应时间变得不可接受。优化思路有两个一是建立每日考勤汇总表每天定时任务生成汇总月底直接查汇总表而不是扫描明细表二是给考勤记录表的查询字段建立合适的复合索引。我当时两条都做了效果明显月度报表从原来的几十秒降到了几秒钟。-- 复合索引emp_id check_time check_type CREATE INDEX idx_emp_check_time ON attendance_record (emp_id, check_time, check_type); -- 每日考勤汇总表 CREATE TABLE daily_attendance_summary ( id INT PRIMARY KEY AUTO_INCREMENT, emp_id INT NOT NULL, work_date DATE NOT NULL, first_check_in TIME COMMENT 首次上班打卡时间, last_check_out TIME COMMENT 最后下班打卡时间, late_count INT DEFAULT 0, early_leave_count INT DEFAULT 0, missing_count INT DEFAULT 0, UNIQUE KEY uk_emp_date (emp_id, work_date) ) ENGINEInnoDB;6.6 换模型时特征不兼容的问题最后分享一个升级过程中遇到的问题。前期用的模型提取128维特征后来换了提取512维特征的新模型结果老的face_feature记录和新模型算出的相似度怎么都比不高因为特征空间的维度都不同了。解决办法是每次模型升级都重新对所有员工照片提取一次特征并更新feature_version标记。同时在识别逻辑里只和同版本的特征做比对避免跨版本比较。这个经验也验证了前面设计“特征版本字段”的重要性。7. 最后几点补充建议这套系统前后跑了几个迭代版本我个人感觉最有价值的不是人脸识别算法本身而是业务逻辑的细节完整度。算法识别准了只是一切的开始真正让系统好用、能落地、能坚持跑下去的是防重复打卡、异常留痕、数据汇总这些“看不见的功夫”。几个方向如果后续要扩展可以考虑第一对接企业微信或钉钉把考勤异常通知自动推送到员工手机第二加入异常补卡申请流程员工可以在线提交说明由管理员审批后修正记录第三把识别服务做成独立的微服务通过HTTP接口给多个终端共用这样如果以后要多台考勤机就不用重复部署。我目前正在做的是第三项把整个识别模块从主系统里拆出去头疼了一阵子但好处是后续扩展确实方便。如果你也在做类似的系统我的建议是从一开始就别只盯着“人脸识别”这个技术点把数据库设计和业务逻辑的坑提前想清楚比自己瞎折腾然后返工要省太多时间。希望这篇文章能帮你在动手之前就先绕开几个大坑。
