学生考勤管理系统的设计与实现这个题目，在毕业设计和课程设计里几乎算得上“常青树”了。很多人第一反应是“老套”“没新意”，但真把它做好、做扎实，却不那么容易。我当年拿到这个题目的时候，项目正文几乎是一片空白，只有“学生考勤管理系统”七个字，所有细节全靠自己推演。做完之后回头看，这个系统其实特别适合用来检验SSM和Vue的理解程度：它包含了典型的CRUD操作、状态流转、角色权限、统计报表、甚至还能扩展出扫码签到和实时推送，麻雀虽小，五脏俱全。
这篇文章就围绕“基于SSM+Vue的学生考勤管理系统”展开，把我当时的完整设计思路、表结构、核心接口、权限方案以及开发中踩过的坑整理出来。不管你是正在选毕设题目、准备课程设计，还是想找一套足够典型的前后端分离项目练手，这份记录都能直接当参考。
1. 为什么选SSM+Vue做考勤系统：一个“传统”组合的取舍逻辑
1.1 考勤管理到底在管理什么
动笔写代码之前，得先想清楚这个系统要解决什么问题。传统的人工点名流程是这样的：老师带纸质花名册进教室，逐个念名字，学生答到，老师在纸上打勾画叉；课后统计出勤名单，期末再汇总计算平时分。整个过程耗时、易错，代签和口头请假的情况也难以追溯。
换成系统之后，核心需求就变成了几个明确的小模块：学生和班级信息的维护、课程表管理、每次课的签到记录、请假的提交与审批、出勤情况的统计与导出。看起来都是常规管理功能，但考勤本身有自己特殊的地方——状态的判断不是非黑即白的。一节课学生踩点进教室算正常，上课后十分钟内进教室算迟到，中途离开可能算早退，这几种状态对最终成绩的影响不一样，所以状态字段的设计比普通增删改查复杂一个层次。
1.2 SSM依然是这个场景的稳妥选择
很多人在技术选型的时候纠结：为什么不用Spring Boot？实际上，SSM（Spring、Spring MVC、MyBatis）和Spring Boot的核心思想完全一致，只是Boot把自动配置和起步依赖做得好，让开发者少写大量XML。而SSM把底层原理暴露得更清楚，对学习和写论文来说反而更能展开讲。我选SSM还有一个非常实际的原因：很多学校的软工、Java方向的课程设计题目文档里，明确写了“基于SSM”作为技术要求，跟老师沟通的时候较少被质疑技术路线有问题。
SSM三件套在考勤系统里的分工是这样的：Spring负责统一管理Service层和Mapper层的对象依赖；Spring MVC负责接收前端来的HTTP请求，做参数绑定和视图返回；MyBatis负责SQL的编写和结果集的映射。三者各司其职，配合得很顺。
1.3 Vue负责的是“体验”这部分
后端把数据接口写好还不够，教室里的老师不可能对着JSON操作。Vue在这里的价值是做单页应用，页面上有课程列表、签到按钮、统计图表、班级花名册这些交互组件。如果再细致一点，签到现场还能出一个“实时到课人数”的统计面板，这必须借助前端轮询或WebSocket推送来刷新，用传统JSP+jQuery做起来会很别扭，Vue生态下有成熟方案可以直接集成。
我最终确定的系统拓扑结构大致长这样：
- 前端：Vue 2 + Vue Router + Vuex + Element UI
- 后端：Spring + Spring MVC + MyBatis，部署在Tomcat
- 数据库：MySQL 5.7，使用Navicat做日常管理
前后端通过JSON交互，接口路径以/api开头，前端用Axios发请求。
2. 数据库设计是地基：表结构定了，业务就跑了一半
考勤系统逻辑上不算复杂，但数据库设计如果偷懒，后面统计查询的时候会非常难受。我把数据表分成“基础资料”和“考勤流水”两类：基础资料包括学生、课程、教师、班级；考勤流水包括考勤记录、请假记录、选课关系。
2.1 核心表的字段设计
2.1.1 学生表、教师表、课程表
学生表和教师表本质上是“用户”信息的两类扩展，但我没有贪图省事合并成一张user表，而是分开建。原因很简单：学生有学号、班级、年级这些教学属性，教师有工号、职称和归属教研室属性，强行合并会让字段有一堆空值，后期维护反而麻烦。
学生表关键字段：
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | BIGINT自增 | 主键 |
| student_no | VARCHAR(20) | 学号，唯一索引 |
| name | VARCHAR(32) | 姓名 |
| class_id | BIGINT | 关联班级表 |
| phone | VARCHAR(11) | 联系电话 |
| status | TINYINT | 1在读 0离校 |
课程表是另一个核心，字段包括课程名、授课教师ID、上课时间、上课地点、学期。要注意的是，课程并不直接和学生关联，中间必须有一张course_student选课关系表。这是第三个容易踩坑的地方——很多新手直接把学生ID塞进课程表的一个字段里，用逗号分隔，这是非常糟糕的设计，后面统计考勤的时候根本无法用SQL关联查询。
2.1.2 考勤记录表是全局最重要的一张表
考勤记录表记录的是“某学生在某课程的某一次课上，出勤状态是什么”，因此最少需要四个维度：学生ID、课程ID、上课日期、状态。实际设计中我加了一个“签到时间”字段用来判断迟到，加了一个“来源”字段区分是老师手动登记还是学生扫码签到。
CREATE TABLE attendance_record ( id BIGINT AUTO_INCREMENT PRIMARY KEY, student_id BIGINT NOT NULL, course_id BIGINT NOT NULL, attendance_date DATE NOT NULL, status TINYINT NOT NULL COMMENT '0缺勤 1正常 2迟到 3早退 4请假', sign_in_time DATETIME DEFAULT NULL, source TINYINT DEFAULT 1 COMMENT '1老师登记 2学生签到', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_student_course_date (student_id, course_id, attendance_date) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;唯一索引写在建表语句里，这是防止重复签到最关键的一道防线。
2.2 考勤状态机：一条记录的五种命运
考勤状态的流转大概是这样的：学生走进教室扫码签到，系统先看当前时间和上课时间之间的差值，如果差值小于等于0，标记为“正常”；如果晚于上课时间但不超过15分钟，系统不会直接改成“迟到”，而是把签到时间存进sign_in_time字段，先标记为“正常-待确认”。老师在课程结束后统一复核，把超过阈值的记录批量改成“迟到”。请假审批通过时，状态直接设为“请假”，如果老师事后补录考勤，需要跳过该学生的请假状态。
这种“先记录事实、再判定状态”的做法，比在签到瞬间就敲定状态更合理。现场网络抖动、学生手机时间不准、老师口头推迟上课等因素都存在，过早判定容易产生不可逆的错误记录。
2.3 统计口径不提前定义，报表会变成扯皮大会
出勤率的计算方式直接影响成绩，所以我提前和需求方（其实就是老师）确认了口径：出勤率 = （正常次数 + 迟到次数×0.5 + 早退次数×0.5 + 请假次数×1） / 总应到次数。这个口径表示“请假不扣分，迟到早退扣一半，缺勤零分”。有些老师觉得迟到一次不该扣这么狠，也有的认为请假必须算缺勤，每个人标准不同。把规则设计成系统参数而不是写死在代码里，就能以适应不同老师的习惯。
统计SQL是这套系统里最值钱的部分。比如按月统计每个学生的出勤率，核心SQL可以写成这样：
SELECT student_id, DATE_FORMAT(attendance_date, '%Y-%m') AS month, COUNT(*) AS total, SUM(status = 1) AS normal_count, SUM(status = 2) AS late_count, SUM(status = 3) AS early_count, SUM(status = 0) AS absent_count, SUM(status = 4) AS leave_count FROM attendance_record GROUP BY student_id, DATE_FORMAT(attendance_date, '%Y-%m');MySQL中SUM(status = 1)这种写法利用了布尔值转数字的特性，比SUM(CASE WHEN status = 1 THEN 1 ELSE 0 END)简洁不少，初学者看两遍就能掌握。
2.4 被很多人忽略的“请假审批”表
请假看起来属于“流程性”功能，但在考勤系统里它的数据价值极高。请假表需要四个关键字段：学生ID、课程ID（或日期范围）、请假类型（事假/病假）、审批状态（待审核/通过/驳回）。审批通过后，系统自动往考勤记录表里插入一条“请假”状态的记录，而不是等到考勤时才去判断“今天是否有有效请假”。这个做法把“请假”从查询条件变成了事实数据，统计的时候直接面向考勤记录表，逻辑极简。
3. 后端SSM的落地链路：从接口定义到SQL实现
3.1 分层：Controller只做翻译，业务逻辑在Service
很多初学者写后端喜欢把所有东西塞进Controller，一个方法里既校验参数又访问数据库又拼返回结果，看起来代码量少，但考试管理系统这种项目后期会不断改需求，高耦合代码改一处崩三处。
我的项目保持了标准三层结构：
- Controller层：接收前端参数，做基本的非空校验，调用Service，把结果包装成统一格式
- Service层：处理业务规则，比如签到去重校验、请假审批状态流转、出勤率计算
- Mapper层：只写SQL和参数映射
统一返回格式是另一个值得坚持的设计。我用一个Result<T>包装类，固定包含code、message、data三个字段，前端Axios拦截器统一判断code是否为200，不需要每个接口单独处理错误分支。
3.2 签到接口的幂等处理：并发问题是考勤系统的隐藏考点
教室里的情况是几十个学生同时扫码，信号好的瞬间可能同时发出几十个请求。如果接口不做并发处理，同一个学生可以在一秒内提交多次签到，产生多条记录，虽然数据库唯一索引挡得住最后一条，但应用层面会出现异常和性能损耗。
我采用的处理方式是“先查后插”加数据库兜底：
- Service层根据
studentId + courseId + attendanceDate查询已有记录 - 如果存在直接返回“今日已签到”结果，不重复插入
- 如果不存在，执行insert
- insert触发唯一索引冲突异常时捕获异常，同样返回“今日已签到”
这种方式不需要引入Redisson这种重组件，利用数据库自带的唯一约束就能解决重复插入问题。真要追求极致性能，还可以用Synchronized加锁或分布式锁，但考勤系统的并发量远没到那个程度，杀鸡不必用牛刀。
3.3 Excel批量导入导出：老师最依赖的功能
学生花名册如果一个个手工录入，系统落地阻力会很大。老师在教务系统导出全校学生名单Excel，直接上传到考勤系统，系统解析后批量插入。导出功能也类似，学期末一键导出某门课的考勤汇总表，老师直接用来计算平时分。
我用的是Apache POI的简单封装EasyExcel，核心代码量很小：
- 学生导入：根据Excel表头映射到
StudentDTO，逐行校验学号是否已存在，存在则跳过，不存在则插入，收集错误行号返回给前端 - 考勤导出：先查汇总数据，再写入Excel响应流，文件名带日期防止浏览器缓存
这里有个细节：导入时不要一条条调insert，而是每500条批量提交一次，MySQL的批量插入和单条插入的性能差距非常明显，数据量在几千行的时候就能感知到差异。
3.4 删除学生时的级联保护
管理员要删除一个学生，但该学生在考勤记录表里已经有好几条记录。如果直接执行DELETE FROM student，会破坏外键约束关系，即便数据库没有设置外键，也会留下大量孤立考勤记录。我的做法是“逻辑删除”：学生表的status字段置为0（离校），保留历史数据。查询时默认过滤status=0的学生，但考勤统计时仍然沿用历史记录。这个设计虽然多了一个字段的判断，却保住了数据的完整性和可追溯性。
4. Vue前端：不只是把页面写出来
4.1 前端页面结构和状态管理
页面层按角色拆分：登录页、管理员端、教师端、学生端。管理员端负责班级、学生、教师、课程的基础信息维护；教师端负责创建课程、发起签到、复核记录、查看统计；学生端负责查看自己的课程表、签到、提交请假申请。
在Vuex中我管理的全局状态不多，主要是当前登录用户的信息和token。每个页面通过调用后端接口获取业务数据，不把大量数据塞进Vuex。理由很简单——考试管理系统的数据是“查询型”的，缓存在前端意义不大，反而徒增状态管理复杂度。
4.2 动态路由和导航守卫
三个角色的功能差异很大，如果路由表对所有角色全量开放，学生能看到管理员的页面入口，安全性和体验都会出问题。我在前端做了两层防护：
第一层，动态路由。用户登录成功后根据角色id动态加载对应的路由表，未授权角色访问不到路由定义；第二层，全局导航守卫。每次路由跳转前检查本地是否存在token，没有就跳登录页。
但这只是前端防护，真正要紧的是后端拦截器。前端路由隐藏菜单是装饰，后端接口做好鉴权才是真相。
4.3 扫码签到的完整流程
这个功能是整个系统最出彩的部分。老师端页面展示一个动态生成的二维码，学生拿手机扫码完成签到。二维码内容不是普通的课程ID，而是一个带随机数的会话凭证，例如courseId=101&random=abc123&expire=300。前端每次点击“发起签到”就向后端申请一个新凭证，后端把凭证放在Redis缓存，过期时间5分钟。
学生扫到二维码，微信内置浏览器打开一个H5迷你页面，页面读取学生登录态的token，调签到接口，传入会话凭证。后端拿到后先去Redis查凭证是否有效，再查studentId对应的token，接着走“先查后插”的去重逻辑，完成签到。用随机数凭证的好处是，过期二维码无法反复使用，而且无法通过抓包伪造，因为每次发起签到都会刷新凭证。
4.4 实时出勤情况：用WebSocket给大屏喂数据
项目中期老师提了一个需求：教室的投影大屏上要实时显示“本节课已签到人数 / 应到人数”，学生一扫完码数字就跳一下。用轮询接口当然也能实现，但刷新间隔太短会增加后端压力，太长又不够“实时”，WebSocket是更正确的解法。
实现不算复杂：前端在进入课程详情页时建立WebSocket连接，连接地址带上courseId和用户token，后端用一个ConcurrentHashMap维护courseId 到 一组WebSocket Session的映射。学生签到成功插入考勤记录后，Service层调用一个消息推送组件，向该courseId对应的所有WebSocket会话群发一条“新签到”事件，前端大屏收到后自增计数。
这个功能我用了大约半天时间就调通了，但对系统的完整度和答辩演示效果提升非常明显。
4.5 前端容易忽略的几个细节
- Axios拦截器统一处理401状态码，token过期自动跳到登录页，避免每个页面都写重复的错误处理
- 时间格式化统一在前端工具函数里处理，不要直接展示后端传的时间戳字符串
- 表单校验规则定义在独立的
validate.js里，多页面复用 - 签到的倒计时按钮加防重复点击的
disabled状态，防止用户手抖连发请求
5. 权限控制与安全设计：考勤系统也要讲究门禁
5.1 RBAC模型的落地
前端动态路由、后端接口鉴权、菜单显示控制，这三者背后的模型统一是RBAC：用户关联角色，角色关联权限。我建了三张表：sys_user、sys_role、sys_user_role，权限点通过角色编码来判断（ADMIN、TEACHER、STUDENT），后端拦截器校验用户角色是否在接口允许的角色列表中。
这种角色直接绑定接口的粗粒度控制在考勤系统里够用了。不需要细化到“老师A只能管理课程B”这种权限分离，那属于数据级权限的范畴，会让系统复杂一个量级。
5.2 登录认证：JWT和拦截器配合
因为前后端是分离部署的两个服务，用传统Session做登录态会碰到跨域Cookie的问题，所以认证方案选了JWT。用户登录成功后：
- 后端生成Token，包含userId和role两个核心声明
- 把Token返回给前端，前端存在localStorage
- 后续请求统一在Authorization请求头携带Token
- 后置拦截器解析Token，把userId放入ThreadLocal供Service层使用
无状态Token的优点是服务器不用保存会话，缺点是注销和踢人比较难实现。考勤系统对这两个需求不强，所以方案是合适的。如果以后要支持“管理员强制下线某学生”，把Token换成Redis存储的会话方案即可。
5.3 防止越权签到：不能替别人打卡
这里有一个非常典型的安全漏洞：学生扫码签到的接口，如果不做处理，调用方可以传任意学生ID，只要有人发起签到，其他不在教室的人也可以通过程序模拟请求代签。防御手段很简单——签到接口不允许前端传入studentId，后端必须从token里解析当前登录用户是谁，然后用这个身份来查选课关系并写入考勤记录。学生ID只能来自服务端信任的登录态，永远不信任前端原始参数。
同样的道理也用在请假审批上：学生只能查询和修改自己的请假申请，教师只能审批自己课程的请假，所有这些约束都在Service层做身份比较，而不依赖前端隐藏按钮。
6. 开发过程中我踩过的六个坑，每个都写出来
6.1 时区问题：返回的时间总是少了8小时
后端返还给前端的考勤时间，在页面上显示比真实时间慢了8个小时。排查发现是Jackson序列化时间时，使用了默认UTC时区，而数据库连接串里的serverTimezone=Asia/Shanghai只对JDBC层生效，JSON序列化时又回到了UTC。解决办法是在applicationContext.xml里显式配置Jackson的timeZone为GMT+8，并且在Java实体类的时间字段上使用@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8")。
6.2 MyBatis查询返回Map时字段名变了
一次查询考勤汇总数据，前端一直拿不到studentName字段，接口返回的是studentname。原因是我用List<Map<String, Object>>接收查询结果，MyBatis默认列名直接作为Map的key，下划线没有转驼峰。解决方式是开启map-underscore-to-camel-case: true配置，并为聚合查询里的字段显式加别名，保持命名一致。
6.3 跨域配置导致前端调不到接口
前端跑在Vue开发服务器端口8080，后端Tomcat端口8081，浏览器因为同源策略直接拦截。CORS配置本身不复杂，真正容易踩坑的是“允许携带凭证”的选项。因为前端要携带Authorization头，后端CorsFilter里必须调用setAllowCredentials(true)，同时允许的域名不能写成*，必须明确列出前端的访问地址，否则浏览器会拒绝请求。
6.4 Vue Router使用history模式刷新404
前端用history模式路由时，开发环境一切正常，部署到Nginx后，访问某个子路径刷新页面会报404。原因是Nginx找不到对应的静态资源路径。解决方法是加一条location匹配规则，把所有非静态资源的请求都rewrite到index.html：
location / { try_files $uri $uri/ /index.html; }如果不加这行，每次用户在“签到页面”按F5，就会看到白屏。
6.5 Lombok和JDK版本导致编译失败
项目使用Lombok做实体类的getter/setter，某天升级JDK后编译直接报错，提示找不到getSignInTime方法。原因是Lombok版本太老，不支持新JDK的编译特性。当时解决的方案是把Lombok升级到适配新JDK的版本，同时清掉Maven的本地仓库缓存重新下载依赖。
6.6 二维码跨平台兼容问题
学生用微信扫老师屏幕上的二维码签到，但二维码里存的是localhost地址，学生手机上访问的却是他自己手机里的localhost，直接打不开。这个问题提醒我，二维码内容里的链接必须是局域网内可访问的IP地址或已完成部署的公网域名，开发调试时我一直用电脑的局域网IP来生成二维码，才能让手机和电脑在同一个网络下完成联调。
7. 如果让我再做一遍，我会在这些地方直接优化
做完整个系统，如果让我回头重新来一次，有几件事我会从第一天就开始做。第一，先写好数据库设计文档再动手写代码，这次我是在开发中途才意识到统计口径需要字段支撑，前面两张表返工了一次；第二，考勤状态的处理我会从最开始就用枚举类加字典表，而不是先写魔法数字再回头重构；第三，签到和请假的数据我都会加上操作日志记录，谁在什么时候改了什么状态，出了问题能溯源。
还有一个我建议大家尝试的方向：把考勤数据做一个简单的异常预警，比如某学生连续三节课缺勤，系统自动给辅导员或班主任发提醒。学校里辅导员最关心的就是学生出勤连续异常，这种功能加上去，整个系统就不再是单纯记录出勤的仓库，而是一个能主动发现问题的小工具。虽然当时因为时间原因没有实现，但如果你在做这个题目，这块功能无论从实用价值还是答辩亮点来说，都很值得投入时间。
考勤管理系统看着简单，真正做完才知道，任何一个不起眼的业务规则背后都是数据结构和接口设计的选择。希望这篇记录能给正在做类似项目的你一些参考，少走几个我已经走过的弯路。
