做了几年JavaWeb方向的项目，我越来越觉得很多校园管理系统的问题不在功能少，而在“流程对不上现场”。就拿考勤来说，传统刷卡、点名、钉钉打卡都绕不开一个尴尬场景：学生完全可以“代打”，老师课后还要花时间核对表格。所以当我接到这个“基于人脸识别的学生考勤请假选课软件系统”时，第一反应就是：这题的核心不是把三个功能堆在一起，而是怎么用人脸识别这个强身份凭证，把考勤、请假、选课三条业务线串成一个可信闭环。整个项目做下来，踩了不少坑，也总结出一些很实用的经验，这里完整记录下来。
这个系统适合两类人看：一是正在做毕业设计或课程设计的学生，需要一个能讲清楚业务逻辑、能演示的技术骨架；二是想在校内信息化场景落地人脸识别的开发者，需要一份避开弯路、能直接上手的设计思路。文章不会只贴代码，更多会讲清楚每个关键决策背后的为什么。
1. 系统从哪来：三条业务线的痛点与整体设计
1.1 旧流程的麻烦在哪儿
先拆业务。学生考勤、请假、选课，看起来是三件事，实际上都围绕同一个主体——学生的身份和时间轴。
考勤的旧办法是点名、刷卡或扫码。点名慢，而且老师记不住所有人；刷卡能解决“代刷”问题吗？不能，把卡给别人就行了。扫码本质也一样，一个二维码截图能传遍全班。
请假的旧办法是纸质假条或云文档。纸质假条需要找辅导员签字、找任课老师签字，转一圈下来半天没了；云文档又容易漏审批，老师根本不知道学生到底请没请到假。
选课的旧办法是抢课。每学期选课系统一开，全校学生同时点，服务器直接卡死。更麻烦的是，如果学生考勤有问题、请假没审批，他还照样选课，业务上其实是脱节的。
这三条线的共同点，是需要一个不可伪造、不可转交的身份凭证。人脸是唯一一个“人在现场才能通过”的凭证，这比任何卡和码都硬。基于这个判断，系统选定人脸识别作为考勤和请假流程的身份入口，同时把选课结果和学生的考勤状态做联动。
1.2 功能边界与角色权限怎么划分
系统一共设计了四种角色：学生、教师、辅导员、系统管理员。每个角色能做什么，直接决定了后端接口和页面路由的划分。
- 学生端：人脸信息注册、扫码式考勤打卡（实际是摄像头人脸比对）、请假申请、个人课表查询、选课/退课。
- 教师端：发起课堂考勤、查看考勤统计、审批所授课程的请假申请、查看选课名单。
- 辅导员端：审批学生请假、查看所带班级的考勤异常数据。
- 管理员端：维护学生/教师基础信息、配置考勤时间窗口、配置课程和选课开放时间、查看全系统日志。
这里有个容易被忽略的点：请假审批不是单级的。我的设计是“任课教师初审 + 辅导员终审”，因为有些请假理由（比如病假）确实需要辅导员确认，而课程层面教师要先判断是否影响考核。两级审批会让流程引擎稍微复杂一点，但贴近真实校园业务。
1.3 为什么继续用JavaWeb而不是换架构
很多人问，人脸识别都上来了，后端怎么还选JavaWeb？原因有三：
第一，校园信息化系统往往要跑在机房老服务器上，技术栈越主流越稳。JavaWeb生态里的Spring Boot + MyBatis + MySQL组合，运维成本低，出了问题找资料也容易。
第二，人脸识别SDK普遍提供Java版SDK，服务端集成很顺。整个识别过程的内存管理、特征值比对都在SDK内部完成，Java层只需要处理图片输入和结果回调。
第三，学生选课这种短时高并发场景，Java生态里的成熟处理方案一堆（Redis预扣库存、MQ削峰、数据库乐观锁），比从零设计的脚本方案靠谱得多。
2. 人脸识别引擎选型与接入细节
2.1 离线SDK vs 云端API，我为什么选离线方案
人脸识别的能力来源有两种主流选择。
一种是云端API，比如各云厂商的人脸识别接口，上传照片返回比对分数。优点是算法最先进，识别率极高；缺点也很明显：学生人脸属于隐私数据，每次打卡都要把采集的照片传到云端，数据合规上很麻烦，而且一旦断网，整个考勤系统就瘫了。
另一种是离线人脸SDK，在本地服务器上做特征值提取和比对，不依赖外网。我最终选了离线方案，核心理由是“考勤场景不能断网”。教学楼、阶梯教室里网络质量很不稳定，如果每次打卡都走云端，大课间一到，几百人同时发起请求，延迟和失败率根本压不住。
离线方案的具体做法是：在服务端引入一个商用级离线人脸SDK（也有开源库可选），启动时加载人脸模型，对外通过本地接口暴露“人脸检测、特征提取、1:1比对、1:N检索”四个能力。学生的人脸照片只在本机存储和计算，合规问题也简单一些。
2.2 人脸注册、检测、比对的完整流程
系统里的人脸流程分两个阶段。
注册阶段，学生在指定页面用摄像头拍一张正面照。后端拿到照片后的处理顺序是：先做人脸检测，确认图里确实有且只有一张脸；然后提取特征值，转成一组浮点向量；最后把特征值存到数据库的人脸表里。这里要注意，注册时的照片质量决定了后续所有识别效果，所以前端必须做动作活体检测，不能让学生随便传一张相册照片，我后面会详细说。
考勤阶段，学生在考勤终端前看一眼摄像头，系统实时抽帧，对人脸框做质量评估（模糊度、遮挡、角度），合格的帧才送去提取特征值，然后与库里该学生的注册特征做1:1比对，分数超过阈值就记为出勤。
1:N检索也可以做，就是拿当前脸和整个班的人脸库做匹配，自动识别“你是谁”。但我在实际项目里不推荐考勤用1:N，因为班级人数多的时候检索耗时会明显上升，而且误识别率比1:1高一个量级。更稳的流程是：学生先通过学号或校园卡定位到自己的记录，再做人脸1:1验证，也就是“身份定位 + 生物特征确认”的双因子思路。
2.3 阈值怎么定：识别通过率与误识率的平衡
人脸比对的结果是一个相似度分数，系统要在“太松”和“太严”之间找平衡。
如果阈值设得太低，长得像的同学可能互相通过，或者照片翻拍也能蒙混过关；设得太高，光线稍微暗一点、人稍微侧个脸就被拒，学生排队堵在考勤机前，体验很差。
我实测下来，对于离线SDK提取的特征值，相似度阈值在0.78到0.82之间是相对安全的区间。具体怎么定，可以做一个简单实验：取100个学生的注册照片，让每个学生现场拍10次打卡照，统计同一人的比对分数分布和不同人之间的分数分布，找两个分布之间重叠最小的点。项目里我用0.80作为默认阈值，然后在管理后台留一个可调参数，因为不同教室的光线条件会有差异。
这里还有一个务必处理的细节：活体检测。静态照片打印出来对着摄像头是能骗过普通比对的，所以系统里加了摇头、眨眼、张嘴的动作指令，随机抽一个动作让用户完成，视频流里的多帧变化能有效挡住照片攻击。防作弊这块不能省，否则人脸识别就只是个贵一点的截图工具。
3. 数据库设计与核心业务逻辑
3.1 表结构设计：用几张表把流程串起来
数据库我设计了11张核心表，按功能分成三组：
- 基础信息组：学生表、教师表、课程表、专业班级表。
- 考勤与请假组：人脸特征表、考勤记录表、请假申请表、请假审批记录表。
- 选课组：选课计划表、学生选课表、课程考勤状态快照表。
重点说人脸特征表。它不存图片本身，存的是特征值向量和一个指向物理照片文件的路径。特征值在代码里是float数组，MySQL里可以存成blob，也可以拆成多个float字段。我更推荐存blob，因为更新和比对时只需要整体读出来交给SDK，不需要在SQL层解析。
请假表里要有一个当前状态字段，用数字表示：0待教师审批、1教师已通过待辅导员审批、2已通过、3已驳回、4已撤销。不要小看这个状态机，请假流程和多级审批最怕的就是状态混乱，宁愿字段多点也不要逻辑上二义。
3.2 考勤模块：考勤时间窗口与补卡逻辑
考勤记录表的核心字段是：学生ID、课程ID、计划上课时间、实际打卡时间、考勤状态、识别方式。
关键设计点是“时间窗口”。不能学生随便什么时候打卡都算考勤，否则课前十分钟和课后十五分钟都能打，考勤就没意义了。我的规则是：上课前10分钟至上课后5分钟内打卡记为“正常”；上课后5分钟至20分钟内记为“迟到”；超过20分钟按“缺勤”，但允许提交补卡申请。补卡申请会走一个类似请假的审批流程，需要任课教师确认当时学生确实在课堂现场。
这个时间窗口不是写死的，而是课程表里每个“上课时间段”自带的一个参数。管理员可以在课程配置里单独调整某节课的宽限期，方便处理机房课、实验课这类需要提前入场的课程。
3.3 请假模块：状态机与数据联动
请假流程很容易做成一堆没人看的记录，所以我把请假和考勤做了关联：学生请假审批通过后，系统在考勤表中自动插入一条“请假”状态的记录，并且该时间段不会被算进缺勤统计。
具体状态流转是这样的：学生提交请假申请，填写课程ID、请假开始时间、结束时间、请假类型（病假/事假/其他）、证明材料附件。任课教师看到后先判断是否影响平时成绩，通过后转给辅导员；辅导员最后核实确认。任何一级驳回，状态回到驳回，学生可以编辑重新提交。
这里值得提醒的是：请假时间一旦跨多节课，涉及的不只是某一张考勤表，而是一个时间段内的所有课程。比如一个学生请假一上午，上午有两节课，就需要自动把两条考勤记录都标记为请假。实现上我会把“请假时间区间”和“该学生当天的课程时间表”做一次碰撞检测，凡是有重叠的课程时段都批量生成请假考勤记录。
3.4 选课模块：用考勤数据做选课约束
选课业务最容易做砸的是并发和规则。
并发问题放在后面说，先讲规则。很多学校的选课系统就是个纯抢课平台，但在这个系统里，我加了一句业务规则：上一学期考勤异常次数超过一定阈值的学生，在选课开放的前48小时内不能抢热门课程，只能选剩余名额充足的课程；正常出勤的学生优先选课。这个规则有争议，但确实能激励学生按时上课，也让考勤数据有了业务价值。
选课表的唯一约束是“学生ID + 课程ID”，技术上用联合唯一索引兜底，保证任何情况下一个学生同一门课只能有一条选课记录。名额扣减必须使用带条件的UPDATE语句：UPDATE course SET selected_count = selected_count + 1 WHERE id = ? AND selected_count < max_student，影响行数为1才代表抢课成功。
4. 从环境搭建到功能联调：核心实操记录
4.1 环境选型与项目骨架搭建
系统的后端技术栈锁定为：JDK 8 + Spring Boot 2.7 + MyBatis-Plus + MySQL 8 + Redis 5 + 前端Vue 2（管理端用Element-UI）。人脸识别SDK单独封装成一个本地服务模块，通过HTTP接口给业务后端调用，这样如果以后要换SDK，不需要动业务代码。
这里解释一下为什么用Redis。选课场景的瞬间并发可能非常高，直接用数据库扣减名额，行锁竞争会让请求堆积。Redis解决这个问题的思路是：把每门课的剩余名额预存到Redis里，抢课时先走Redis的原子DECR操作，成功再把数据异步落库。数据库是最终依据，Redis是流量闸门。
项目骨架我是这么组织的：
face-service：人脸SDK封装服务，独立端口。system-server：Spring Boot主服务，提供考勤、请假、选课、管理后台的全部接口。admin-web：管理端前端。web-app：学生/教师H5应用端，兼容手机和教室平板。
4.2 人脸注册与考勤打卡的核心逻辑
人脸注册接口的伪代码逻辑如下：
- 前端做动作活体检测，采集到一组带动作序列的照片，挑一张质量分最高的传后端。
- 后端先做基础校验：文件大小不超过2MB、图片分辨率不低于640x480。
- 调用face-service的检测接口，确认人脸框数量等于1，人脸角度（偏航、俯仰、侧倾）在正负15度以内。
- 存原图到OSS或本地磁盘，再提取特征值、存人脸特征表。
- 返回注册成功，并附带一张“检测质量得分”，方便前端提示用户是否要重新拍。
考勤打卡的流程要多一步身份定位：学生在考勤终端输入学号后4位，后端查到候选学生记录，返回一个随机动作指令；前端展示动作指令并开始录制短视频，实时检测动作是否完成；然后取最后一帧做1:1比对，通过则记录考勤时间。整个流程控制在3秒内完成，这个时间可以用动作序列的大小来调节，动作越多越安全但越慢，我最终选了2个随机动作，兼顾速度和可信度。
4.3 请假审批的状态流转实现
请假审批我用了状态机模式，不是简单的if-else。状态机的实现思路是：定义当前状态、事件、目标状态、执行动作的映射表，每次状态变更都走统一入口，先校验事件是否合法，再执行动作，最后落库。
比如事件是“教师通过”，映射规则是：当前状态必须为待教师审批，目标状态为待辅导员审批，执行动作为记录审批意见、给辅导员发一条站内待办通知。如果学生想撤销，只有当前状态在待教师审批和待辅导员审批时才能执行撤销。
这样做最大的好处是，后续想加“教务处长终审”之类的环节，只需要在映射表里增加一条规则，不用改动核心业务代码。我在项目里还加了一个全局监听器，任何状态变更都会写入审批流水表，作为审计凭据，出了问题可以回溯到底是谁在哪个时间节点批的。
4.4 选课并发场景的处理
选课是系统里唯一需要处理高并发的场景，核心设计是“前端限流 + Redis校验 + 异步落库”。
开放选课前，先把所有课程的剩余名额初始化到Redis。学生提交选课请求后，先校验该学生是否在限制名单里（查上一学期考勤异常次数），再执行Redis DECR。DECR结果小于0说明没名额了，直接返回“课程已满”。名额扣减成功后，发一条MQ消息，由消费者异步写入选课表并更新MySQL里的selected_count。
这个方案避免了数据库锁竞争，接口响应基本都在百毫秒级。但要注意一个坑：Redis里的名额和数据库里的记录之间会有短暂不一致，所以我在后台管理页面展示的“剩余名额”以数据库为准，每秒同步一次Redis的修正值。
5. 部署上线后最常踩的坑：问题排查实录
5.1 服务器端SDK部署的三个注意点
人脸SDK对服务器的依赖比普通Java应用更敏感，部署时我踩过的坑主要是这几个：
第一是必须确认CPU指令集支持。很多离线人脸SDK依赖特定的CPU指令集优化性能，部署前用官方检测工具跑一遍，否则会出现不明原因的启动失败。
第二是模型文件路径不能带中文和空格。这个坑非常隐蔽，本地Windows开发环境没出问题，一旦上了Linux服务器，模型加载直接找不到文件，日志只报一个底层链接错误。
第三是内存配置要预留足。人脸模型加载进内存后占用很高，启动参数-Xmx不能给得太紧。我这边生产环境是8G内存的服务器，JVM堆给了4G，剩下的留给SDK动态库，运行才平稳。
5.2 光照、角度、口罩问题怎么调
人脸识别上线后最现实的挑战不是算法，而是光线。阶梯教室逆光环境下，人脸框检测没问题，但特征值提取质量很差，比对分数普遍偏低。我的解决思路是三层：
第一层，考勤终端尽量安装在面向窗户的侧面，避免正对强光；第二层，终端摄像头选带宽动态功能的型号，对逆光有硬件级改善；第三层，在代码里对图片做直方图均衡化预处理，人脸区域亮度均一化后再送SDK比对。
口罩问题是近两年所有考勤系统都绕不开的。纯靠人脸算法，戴口罩时特征值缺失严重，没有办法做高精度识别。我的务实做法是：允许学生选择“戴口罩模式”，该模式下系统只做人脸检测和身份定位，远程手动确认，兼容考勤效率和安全性的平衡。这种兜底机制是必要且合理的。
5.3 选课高峰期的数据库与日志调优
选课高峰期的问题不只是并发，还有日志。
最初上线时，我把所有请求日志都打到了Tomcat默认目录，流量一上来，磁盘IO被打满，数据库连接池也出现等待。后来做了三件事：
第一，接口日志分级，核心业务接口打业务日志，其余接口只记录异常场景，把正常请求的日志级别从INFO调到WARN，压测下来吞吐量提升了近20%。
第二，数据库连接池从默认的20调到了60，同时给MySQL的wait_timeout做了合理化配置，避免大量Sleep连接占满单机限制。
第三，抢课当天提前30分钟做一次缓存预热，课程名单、学生基本信息全部加载到Redis，避免冷启动时数据库承受瞬时高压。
这三项做完，选课当天没有再出现服务不可用的情况。
5.4 一个容易忽略的隐私合规细节
人脸数据属于个人信息中的敏感信息，哪怕在校园内部系统里，也要做起码的合规设计。我在系统里做了几件务实的事：
- 人脸照片不直接放在业务数据库，而是单独存放，并设置访问权限，普通后台管理员默认不可查看原图；
- 特征值表与业务表分离，即便业务表被拖库，攻击者也拿不到可还原成人脸的数据；
- 用户协议里明确告知人脸数据的用途、存储期限和删除方式，学生毕业时提供“注销人脸信息”功能，一键删除特征表和照片文件。
这些不一定满足所有行业标准，但在校园项目里是性价比最高、最能体现专业度的处理方式。
最后再说一个我特别有感触的细节：整个项目里最花时间的不是人脸SDK对接，而是考勤时间窗口与请假流程之间的数据联动。业务规则里总是藏着无数个“如果……那么……”的边缘情况，把这些边界条件想清楚，系统才会真正像一个给校园用的系统。最开始我以为最难的是摄像头识别，踩着坑走完才发现，最难的一直都是业务流程本身。这也是做这类系统最有意思、也最磨人的地方。
