基于Java+SSM的人脸识别考勤系统设计与实现全解析

带毕业设计的同学里头，十个里面至少有四个会问同一个题目：基于Java的人脸识别考勤系统。为什么这个题这么火？因为用SSM框架做后端、加一个人脸识别模块、再配一套考勤管理页面，技术栈够典型，工作量适中，演示效果好，论文素材也容易凑齐。如果你正在为2026届毕业设计发愁，或者手里刚拿到一份“ssm+java人脸识别考勤系统源码”不知道怎么消化，这篇内容就是按实际开发顺序写的，从框架选型、数据库设计、核心代码到答辩常见问题，基本把我在这个项目里踩过的坑和验证过的方案讲透了。

这个系统解决的实际问题很简单：传统打卡依赖实体卡或指纹，代打、忘带卡、指纹磨损都是硬伤。换成“刷脸”之后，员工或学生走到摄像头前，系统自动识别身份、记录打卡时间，管理员在后台看得到每天的出勤明细和统计报表。做这个毕设，你需要掌握的不只是几个框架的增删改查，还包括人脸特征如何存取、图片怎么传、考勤时间怎么判、报表怎么聚合，这些才是论文里真正能写的技术点。

先看一下这个项目涉及的整体信息：

• 后端框架：SSM（Spring + SpringMVC + MyBatis）
• 编程语言：Java 8
• 人脸识别：人脸检测 + 特征提取 + 1:N检索比对
• 核心业务：注册人脸、刷脸打卡、考勤记录、异常标记、统计报表
• 交付形式：完整源码 + 毕业论文
• 适用对象：计算机、软件工程等专业的本科毕业设计

下面我从头到脚拆一遍，结合我自己实际搭建和调试的过程来讲，尽量少讲虚的，多给能直接用的内容。

1. 项目整体设计与思路拆解

1.1 为什么选SSM而不是Spring Boot

聊这个项目之前，先解决一个几乎绕不开的问题：现在新项目基本都是Spring Boot起步，为什么毕设还要选SSM？

核心原因是选题交付的要求。大部分学校对毕业论文的考核点在“三层架构”“Spring容器管理”“MyBatis持久层映射”，而SSM恰好是这种经典结构的标准样本。SpringMVC做表现层接收请求，Spring做业务层的Bean管理、事务控制，MyBatis做数据访问层的SQL映射，三层边界清楚，论文里的架构图、时序图都很好画。如果你用Spring Boot，很多配置自动完成，反而写不出多少“设计过程”。

我自己的体会是，SSM这套配置虽然比Spring Boot繁琐，但每一行配置都有对应的概念可以展开写。比如连接池的初始化、Mapper接口如何被扫描、事务管理器怎么接入，这些都是答辩时老师喜欢追问的点。用SSM答辩，你能讲的东西更多。

1.2 系统需求拆解与功能边界

人脸识别考勤系统从用户角度分两类角色：管理员和普通员工（或者学生）。我当时做的功能清单整理出来大概是这样的：

• 管理员端：员工信息增删改查、部门管理、人脸照片录入、考勤记录查看、异常打卡处理、考勤统计报表、上下班时间规则配置
• 员工端：注册/录入人脸、刷脸打卡、查看个人考勤记录、在线请假申请
• 核心流程：摄像头拍照 -> 人脸检测 -> 特征提取 -> 特征匹配 -> 匹配成功后写考勤记录
• 附加功能：迟到早退判断、缺卡提醒、月度汇总导出

这里要特别提醒一点：毕设评审老师对“抓贼式”监控功能通常没有兴趣，但对“考勤数据如何准确生成”非常在意。所以功能重点建议放在“打卡识别链路”和“考勤统计逻辑”上，别把精力耗在什么实时大屏、红外测温之类的花活上。

1.3 技术选型的取舍逻辑

人脸识别模块是整个项目的核心难点。做毕设的现实选择有两种：接入在线人脸识别API，或者集成离线人脸识别SDK。两种我都试过，各自的优缺点非常明显。

在线API（比如百度AI人脸识别）接入速度快，有免费的额度，识别准确率高，还给你提供现成的文档和调试工具。缺点是必须联网，而且答辩现场如果网络不稳定，演示就会翻车。离线SDK（比如虹软ArcFace）可以本地跑，不依赖网络，稳定性好，但需要注册开发者账号、申请AppID和SDK Key，Windows环境下的动态链接库配置也有一些坑。

从稳妥角度讲，我最终采用的是“双方案兼容”的结构：核心接口定义成统一的FaceService，底层同时留着API实现和SDK实现的切换入口。这样论文里可以写两种方案的对比分析，答辩时即使一个方案出问题，切换另一个就能救场。如果你只想要省事，那直接用在线API即可，后面我会把具体接入步骤写清楚。

2. 环境准备与项目工程结构规划

2.1 开发环境清单

这部分写清楚，免得你装到一半发现版本不兼容。我自己用的稳定组合如下：

工具	版本	说明
JDK	1.8	不要用太高版本，SSM老项目依赖兼容性稳一些
Maven	3.6+	管理依赖
Tomcat	8.5	配合JDK8运行
MySQL	5.7	8.0也可以，但驱动和连接串要调整
IDEA	2023+	社区版足够
百度AI平台账号	人脸识别V3	每天有免费调用额度

Maven依赖上除了SSM三大框架，还需要阿里巴巴的fastjson或Jackson处理JSON，HttpClient组件用来调用人脸识别API，文件上传组件commons-fileupload，以及数据库连接池Druid。

提示：如果你在某宝或GitHub下载的源码自带lib目录的jar包，建议优先用Maven坐标替代，避免部署时出现ClassNotFoundException。

2.2 包结构设计

包结构直接影响论文里系统设计章节的书写逻辑，务必一开始就规划好。我的做法如下：

com.attendance ├── controller # SpringMVC控制层 ├── service # 业务层接口 ├── service.impl # 业务层实现 ├── mapper # MyBatis数据访问接口 ├── entity # 实体类 ├── common # 公共类（返回结果封装、常量、工具类） ├── config # 配置文件相关Java类 └── face # 人脸识别封装模块

这样的分包方式不仅代码层次清楚，写论文的时候直接引用每个包对应的职责说明即可。face包单独拆出来是方便后续换算法，这个细节在答辩时提到会加分。

2.3 SSM整合的核心配置

SSM整合的配置文件有四个：pom.xml、web.xml、spring-mvc.xml、spring-mybatis.xml。我贴一份spring-mybatis.xml的关键片段，重点看数据源和Mapper扫描：

<context:property-placeholder location="classpath:jdbc.properties"/> <bean id="dataSource" class="com.alibaba.druid.pool.DruidDataSource"> <property name="driverClassName" value="${jdbc.driver}"/> <property name="url" value="${jdbc.url}"/> <property name="username" value="${jdbc.username}"/> <property name="password" value="${jdbc.password}"/> </bean> <bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean"> <property name="dataSource" ref="dataSource"/> <property name="typeAliasesPackage" value="com.attendance.entity"/> <property name="mapperLocations" value="classpath:mapper/*.xml"/> </bean> <bean class="org.mybatis.spring.mapper.MapperScannerConfigurer"> <property name="basePackage" value="com.attendance.mapper"/> </bean> <bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> <property name="dataSource" ref="dataSource"/> </bean> <tx:annotation-driven transaction-manager="transactionManager"/>

有一类高频报错是启动时Mapper接口和XML文件绑不上，十有八九是mapperLocations路径写错，或者XML文件的namespace没对应接口全限定名。另一个常见毛病是多数据源场景下事务管理器没有指定，导致事务不生效。SSM项目虽然老，但这些基本功未来进公司做Spring Boot项目照样用得上。

3. 数据库设计与核心表结构

3.1 数据模型整体规划

考勤系统的表结构谈不上复杂，但表之间的关系和字段设计会直接影响后续统计逻辑。我在设计时把表分成三类：基础信息表、考勤业务表、人脸特征表。基础信息表存员工、部门；考勤业务表存打卡记录、请假申请；人脸特征表单独存放图片和特征值，避免把大字段塞进员工表导致查询变慢。

3.2 各表字段详解

员工表（employee）：

CREATE TABLE `employee` ( `id` int(11) NOT NULL AUTO_INCREMENT, `employee_no` varchar(32) NOT NULL COMMENT '工号', `name` varchar(32) NOT NULL, `department_id` int(11) DEFAULT NULL, `position` varchar(64) DEFAULT NULL, `phone` varchar(20) DEFAULT NULL, `face_image` varchar(255) DEFAULT NULL COMMENT '人脸照片URL', `face_feature` text COMMENT '人脸特征值JSON', `status` tinyint(1) DEFAULT '1' COMMENT '1在职 0离职', `create_time` datetime DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_employee_no` (`employee_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

人脸特征我存的是text类型，内容是API返回的JSON数组。为什么不直接存成二进制或者单独建特征表？因为毕设级别的人脸比对量很小，一张表完全够用，论文里写“特征随员工信息同步加载，减少多表关联查询开销”也是一句合理的解释。

考勤记录表（attendance_record）：

CREATE TABLE `attendance_record` ( `id` int(11) NOT NULL AUTO_INCREMENT, `employee_id` int(11) NOT NULL, `attendance_date` date NOT NULL COMMENT '出勤日期', `clock_in_time` datetime DEFAULT NULL COMMENT '上班打卡时间', `clock_out_time` datetime DEFAULT NULL COMMENT '下班打卡时间', `status` varchar(16) DEFAULT 'NORMAL' COMMENT 'NORMAL正常 LATE迟到 EARLY早退 ABSENT缺卡', `create_time` datetime DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_employee_date` (`employee_id`, `attendance_date`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这张表的核心设计点是：一天一条记录，上班打卡时插入，下班打卡时更新。好处是月度统计直接按attendance_date范围做GROUP BY即可，不需要去重。坏处是并发情况下可能出现同一人重复打卡，解决方案是uniqueKey加上employee_id和attendance_date唯一约束，打卡时先查后插。

请假申请表（leave_apply）和其他几张基础表不单独贴SQL了，结构都很常规，核心字段就是employee_id、leave_type、start_time、end_time、reason、status。

3.3 字段设计的避坑说明

两个实际踩过的坑有必要单独说。第一个是时间字段类型：打卡时间一定用datetime，日期用date，不要图省事存字符串。否则做日期格式校验、按月份统计的时候，到处都要CAST转换，MySQL的隐式转换还可能让索引失效。第二个是员工表里的face_feature字段不要用blob，虽然看起来“省空间”，但查列表时会把所有特征一次性加载进内存，页面会明显变卡，按需加载很麻烦。text类型加上JSON序列化损失的性能在这个量级下完全可以忽略。

4. 人脸识别接入与核心流程实现

4.1 人脸识别方案选择与统一接口设计

人脸识别在毕设项目里最好做成一整个独立模块，而不是散落在Service层里。我设计了一个简单接口：

public interface FaceService { // 传入图片Base64，返回人脸特征值 String detectFace(String base64Image); // 图片与已有特征比对，返回匹配的员工ID Employee matchFace(String base64Image, List<Employee> candidates); }

接口定了之后，实现类可以随时替换。用百度AI实现时，detectFace调的是人脸检测接口，matchFace调的是人脸搜索接口。用离线SDK实现时，detectFace是本地提取特征字节数组，matchFace是本地特征比对。业务层代码完全不用关心脸是怎么识别的，只关心输入一张图、输出一个人。这也是论文里能吹“面向接口编程”的实例。

4.2 基于百度AI的接入流程

注册百度AI开放平台，创建人脸识别应用，拿到API Key和Secret Key。然后获取access_token，后续接口调用都需要它。这一步有一个容易忽略的坑：access_token有效期是30天，调试时每次重启项目都重新获取一次，但上线部署需要做缓存刷新逻辑。毕设里你就老实写一个定时刷新任务，防止答辩演示的时候token过期。

核心调用代码我用HttpClient实现：

String url = "https://aip.baidubce.com/rest/2.0/face/v3/search" + "?access_token=" + token; HttpPost post = new HttpPost(url); StringEntity entity = new StringEntity( "{\"image\":\"" + base64Image + "\",\"image_type\":\"BASE64\"," + "\"group_id_list\":\"attendance_group\",\"liveness_control\":\"NONE\"}", ContentType.APPLICATION_JSON ); post.setEntity(entity); CloseableHttpResponse response = httpClient.execute(post); String result = EntityUtils.toString(response.getEntity());

返回结果里的score就是相似度分数，一般80分以上能判定为同一个人。我实测下来光线正常、正对摄像头的情况下，百度API的匹配准确率非常稳定。要注意的是传图片Base64时不要带“data:image/jpeg;base64,”这个前缀，必须纯数据，否则报错“image format error”。

4.3 人脸注册流程实现

人脸注册流程是指：员工先上传一张清晰的正脸照，后端调用人脸检测接口提取特征值，存到employee表的face_feature字段。这个流程放在管理员端“录入人脸”功能里。

整个处理链路是这样的：

1. 前端上传图片，后端接收MultipartFile
2. 图片转Base64字符串，压缩到2MB以内
3. 调用FaceService.detectFace提取特征
4. 成功后把图片保存到服务器本地（用于页面展示和论文截图）
5. 特征值JSON写入员工记录
6. 失败则提示“未检测到人脸”，请用户重拍

图片这块有一个坑：后端保存路径一定要用绝对路径加UUID重命名，不要用原文件名，否则中文文件名会带来乱码和路径问题。我就是吃过这个亏，后来统一改成UUID.jpg，干净利落。

4.4 刷脸打卡业务闭环

刷脸打卡是系统的核心场景，流程比注册长一些，但也不复杂：

1. 员工点击页面上的“开始打卡”，浏览器调起摄像头
2. 用户拍照，前端压缩后转Base64字符串，POST到后端接口
3. 后端从employee表查出所有在职员工（特征值非空），作为候选集
4. 调用matchFace做1:N比对
5. 匹配分数达到阈值，获取员工ID，查询当天是否已有记录
6. 无记录则新增，有记录则视为重复打卡直接忽略
7. 根据当前时间判断迟到或正常，写入status字段

有人会问，为什么不用人脸检索的group_id功能，反而要把所有员工拉出来自己比对？原因很简单：考勤系统的数据量级很小，一个公司撑死几百人，直接内存比对毫秒级就能完成。自己做比对，你在论文里还能多写一段“JPEG图像转灰度图、对齐、特征向量相似度计算”的分析，比直接调API的“搜索接口”看上去更有技术含量。

打卡核心的Controller方法大致长这样：

@PostMapping("/attendance/clock") @ResponseBody public Result clockIn(@RequestBody ClockRequest request) { // request中包含base64Image字段 Employee employee = faceService.matchFace(request.getBase64Image()); if (employee == null) { return Result.error("未识别到有效人脸，请正对摄像头重试"); } return attendanceService.handleClock(employee); }

AttendanceService里处理迟到早退逻辑时，要用的时间规则（上下班时间）我放在了配置表里，而不是写死在代码中。老师如果要演示不同规则的效果，管理员页面改一下配置即可，体验感完全不同。

4.5 考勤统计逻辑实现

考勤统计是论文里比较好写的一块，因为涉及到的SQL优化点很多。月度考勤报表的SQL大致是：

SELECT DATE_FORMAT(a.attendance_date, '%Y-%m') AS month, e.name, e.employee_no, d.name AS department_name, COUNT(DISTINCT a.attendance_date) AS work_days, SUM(CASE WHEN a.status = 'LATE' THEN 1 ELSE 0 END) AS late_count, SUM(CASE WHEN a.status = 'EARLY' THEN 1 ELSE 0 END) AS early_count, SUM(CASE WHEN a.status = 'ABSENT' THEN 1 ELSE 0 END) AS absent_count FROM attendance_record a JOIN employee e ON a.employee_id = e.id JOIN department d ON e.department_id = d.id WHERE a.attendance_date BETWEEN #{startDate} AND #{endDate} GROUP BY e.id, DATE_FORMAT(a.attendance_date, '%Y-%m')

这种SQL核心注意点是覆盖索引。attendance_record表上加了employee_id和attendance_date的联合索引，查询和分组都没有发生全表扫描。如果数据量只有几千条，你感觉不到差别，但写论文时Explain分析是加分项，这个场景值得专门截个图放进文档。

5. 前端页面与交互实现要点

5.1 页面架构与模板选择

SSM项目的前端通常用JSP。虽然现在看起来老土，但毕设场景里JSP配合JSTL标签做后端渲染，写起来确实快，而且老师一般只关心功能是否完整、交互是否顺畅，不会要求你用Vue重构。勤系统需要做的主要页面如下：

页面	功能
员工列表页	分页展示员工信息、搜索、编辑
人脸录入页	上传照片，调用后端API完成特征提取
打卡页	调起摄像头，拍照后上传识别
考勤记录页	按日期检索，展示打卡明细和状态
月度报表页	汇总统计，支持导出Excel
请假申请页	员工提交请假信息，管理员审批
个人中心	查看个人当月出勤汇总

5.2 摄像头的调起与图片处理

前端摄像头这部分是最容易出问题的地方。PC端浏览器调起摄像头用getUserMedia接口即可，但有一个极具迷惑性的坑：如果你不是HTTPS环境，浏览器会禁止非安全域名的摄像头权限。本地部署用localhost访问就没问题，一旦部署到远程服务器，必须配HTTPS才能正常调起摄像头。

我实现打卡页的关键代码：

navigator.mediaDevices.getUserMedia({ video: { width: 480, height: 640 } }) .then(function (stream) { video.srcObject = stream; }) .catch(function (err) { alert("摄像头无法启用，请检查权限或使用HTTPS访问"); });

拍到照片后的处理方式是截取视频帧到canvas，然后调用canvas.toDataURL("image/jpeg", 0.7)压缩成Base64字符串，再通过AJAX发给后端。压缩这一步很关键，不压缩的话手机照片动辄几MB，Base64字符串巨大，后端接收和识别都会变慢。

5.3 后端接收Base64图片的配置问题

前端发过来的Base64字符串，后端接收时要设置SpringMVC的请求大小限制。默认的2MB限制很容易让人脸图片上传时直接抛异常。在spring-mvc.xml里配置：

<bean id="multipartResolver" class="org.springframework.web.multipart.commons.CommonsMultipartResolver"> <property name="maxUploadSize" value="10485760"/> <property name="maxInMemorySize" value="1048576"/> <property name="defaultEncoding" value="UTF-8"/> </bean>

这里maxUploadSize用字节表示，10MB是10 * 1024 * 1024。建议先压缩图片到合理大小，再把限制设置为10MB，两层保险，避免Tomcat的请求体大小限制（默认也是2MB左右，需要改server.xml里的maxPostSize）导致二次翻车。这里实测时的教训是：改完Spring的multipartResolver后，如果Tomcat还报413，多半要顺手把server.xml里Connector的maxPostSize改成0（不限制）或10MB。

6. 常见问题排查与避坑实录

6.1 摄像头黑屏或权限拒绝

这个问题的原因排除起来有顺序：先看浏览器控制台报什么错，再检查是否是HTTP非安全域导致，接着看Windows的摄像头隐私设置里有没有允许浏览器访问摄像头。有些公用电脑会被安全软件强制屏蔽摄像头，这类属于系统环境原因，代码本身没问题。

一个比较实用的调试技巧：打卡页在调用getUserMedia之前先写一个“测试摄像头”按钮，只调起视频流，不拍照不上传。这样能快速定位是采集问题还是后端识别问题。

6.2 中文乱码问题

SSM项目中文乱码有两个典型场景。第一个是前端通过AJAXPOST的JSON里包含中文姓名时乱码，解决办法是统一在web.xml里加CharacterEncodingFilter，强制请求和响应都是UTF-8。第二个是MySQL存储乱码，建表时用utf8mb4字符集，JDBC连接串后面加上characterEncoding=utf8，两层保证。

6.3 人脸识别匹配不准或失败

识别率低的常见原因：

• 摄像头分辨率太低，人脸区域过小
• 光线太暗或逆光，特征提取失败
• 录入照片和打卡照片角度相差过大
• 相似度阈值设置太高

我实测调试时，把阈值从90逐步降到75，才能找到一个适合实验室场景、又能容忍一定角度变化的平衡点。这个调参过程也值得写进论文的实验章节，老师会比较认可这种细节。

6.4 考勤记录重复打卡问题

重复打卡的根源是前端用户快速点了两次按钮，两个请求同时到达后端，出现了典型的并发插入问题。除了数据库加唯一索引兜底之外，业务层也要做一次前置查询。更稳妥的方案是加Redis分布式锁，但毕设里引入Redis又增加一个中间件，有点过度设计了。我的做法是唯一索引做兜底，Service层加synchronized方法锁，简单有效，也能在论文里提一句“线程安全设计”。

6.5 数据库连接池报错排查

SSM项目启动时最常见的报错是“Cannot create PoolableConnectionFactory”，可能的原因包括：数据库没启动、用户名密码错误、MySQL驱动缺失、防火墙拦截3306端口。排查顺序：先用Navicat或命令行连接一下同一套账号密码，确认数据库层没问题再检查代码配置。这里有一个很蠢但常见的错误：复制别人项目的jdbc.properties时，把driverClass写成了com.mysql.cj.jdbc.Driver，但项目里的MySQL驱动是5.x版本，运行时ClassNotFound，调整驱动版本和连接串的兼容性即可。

7. 论文撰写思路与答辩准备

7.1 论文结构怎么搭

论文请按“绪论 -> 相关技术介绍 -> 需求分析 -> 系统设计 -> 系统实现 -> 系统测试 -> 总结”的常规顺序推进。这里重点说几个容易拿分和踩坑的位置：

相关技术介绍，不要写成名词解释大合集。人脸识别部分的重点要讲清楚特征提取和比对的基本原理，最好举一个检索过程的例子，别只贴百度AI的接口文档。需求分析部分必须画用例图，系统设计部分必须有架构图、功能结构图、数据库ER图，这些图在答辩时就是你的讲解地图。系统测试部分要设计测试用例，把正常打卡、迟到打卡、重复打卡、未注册用户打卡这几个场景都覆盖到。

7.2 答辩高频追问整理

根据我带过的学生反馈以及我自己被问到的经验，老师翻来覆去问的其实就是这几个问题：

• 人脸识别调的是第三方API吗？如果断网了怎么办？（如实回答就行，再补充说明离线SDK方案可以替换）
• 相似度分数是怎么算出来的？阈值为什么设为这个值？（把调参过程说清楚）
• 数据库为什么这么设计？如果员工多，一张特征字段表会有什么影响？（引出分表或缓存方案）
• 系统有哪些安全性设计？（可以从密码MD5加盐、SQL注入防护、登录拦截器三方面回答）
• 事务在哪里控制的？（点名ServiceImpl类里的@Transactional注解）

打印论文前记得调整图表的分辨率，截图不要模糊，表格不要跨页断开。答辩PPT控制在12页左右，重点放架构图和核心流程图，演示环节一定要提前录一段备用视频，现场翻车又恢复不了的时候，视频能救你一命。

7.3 最终检查清单

• [ ] 数据库脚本完整，包含初始化数据
• [ ] 项目导入后Maven依赖能正常下载
• [ ] 本地启动Tomcat，管理员账号可登录
• [ ] 人脸录入功能完成特征提取
• [ ] 打卡全流程可跑通，考勤记录正确生成
• [ ] 访问方式使用localhost + HTTPS（远程部署需配置证书）
• [ ] 论文图表清晰，代码片段格式统一
• [ ] 答辩PPT和录像备份已就绪

最后说点实际的

这个项目我从零开始搭，前后花了两个多星期的晚上，最费时间的不是写代码，而是调人脸识别那套环境以及处理各种奇葩的浏览器权限问题。如果你拿到了一套源码，不建议直接启动然后哪里报错问哪里，那样很容易被问题牵着走。先把数据库脚本建好，把项目跑起来看到登录页，再顺着“录入人脸 -> 刷脸打卡 -> 查看报表”这条主线走通一遍，你自然就明白每个模块是怎么回事了。

我最后再分享一个小建议：把FaceService接口从业务层解耦出来，是整个项目里最值得的一步设计。等答辩时老师问你“如果换一个人脸识别SDK怎么做”，你可以直接现场演示只改一个实现类的过程，这种操作比背一百页PPT都有说服力。