简介：Java后端开发中，权限管理与数据库设计是构建企业级应用的核心基础。Spring Boot作为当前主流的Java开发框架，通过自动配置与starter机制大幅简化了项目搭建；MyBatis则凭借灵活的SQL控制能力，在复杂业务报表查询中优势明显。以学生考勤系统为例，这类多角色业务系统天然适合实践RBAC权限模型，同时涵盖课表生成、签到逻辑、请假审批、统计报表等典型场景。本文从概念到原理，系统拆解考勤系统的数据表设计、核心业务实现与常见踩坑点，帮助你掌握从零构建一个可扩展、可维护的Java Web项目的完整思路，为课程设计或简历项目积累实战经验。 每次接到这类题目，我都觉得特别亲切。基于Java的学生考勤系统，基本上算是Java学习者从语法走向工程的一个标志性项目。不管是课程设计、毕业设计，还是单纯想攒一个能写进简历的完整项目，这个题目都逃不掉。它的好处在于：业务足够贴近现实、技术栈覆盖面广、规模适中，既不会像图书管理那样太简单显得没含金量，也不会像电商系统那样复杂到一个人做不完。
这篇博文我就按我实际做这个项目的思路来梳理一遍，从设计到实现、从踩坑到优化，尽量把每个环节的“为什么”都说清楚。项目不是特别高深，但里面藏着不少值得注意的细节，值得好好拆一拆。
1. 项目整体设计与思路拆解
1.1 先想清楚：学生考勤系统到底在解决什么
做任何系统之前，第一件事不是急着写代码，而是把业务问题定义清楚。学生考勤说白了就是回答三个问题：某节课谁来了、谁没来、没来是什么原因。
但落到实际场景里，事情就没那么简单了。一个真实的考勤需求里，至少要区分三类人：管理员要管全局，维护所有基础数据；老师要发起考勤、看统计结果、批假；学生要签到、请假、查自己的出勤记录。这三类角色的操作权限、数据范围、页面功能都不一样，这就是RBAC（基于角色的访问控制）最典型的使用场景。
项目设计阶段我把核心需求拆成了四个模块：
- 基础信息管理：学生、班级、教师、课程信息的增删改查，这是系统的地基；
- 考勤业务：老师发起考勤、学生签到、跨天/跨周课程处理；
- 异常处理：请假申请、审批、补签、特殊情况备注；
- 统计报表：按课程、班级、时间范围汇总出勤率、缺勤次数，导出明细。
很多人一上来就写代码，其实漏掉了一个东西：数据流的走向。从“老师发起考勤”到“学生收到签到任务”，再到“学生签到后数据回写”，这条链路就是整个系统的生命线。设计阶段把这条链路画清楚，后面写代码就是顺着走一遍的事。
1.2 技术栈选型：为什么我推荐Spring Boot + MyBatis
这个题目历史悠久，网上能找到很多JSP + Servlet + JDBC的老方案，也有SSH（Struts2 + Spring + Hibernate）时代的古董版本。我个人的建议是：别再用那些了，直接上Spring Boot + MyBatis + MySQL。原因很简单。
第一，Spring Boot已经是Java后端的事实标准。现在的课程设计和毕业设计，用Spring Boot不仅写起来快，答辩的时候技术亮点也更好讲。内嵌Tomcat、自动配置、starter机制，每一项都能解释半天。
第二，MyBatis胜在灵活，SQL自己控制得住。考勤统计这类业务报表，可能会有各种复杂的查询条件组合，MyBatis的动态SQL写起来非常顺手。相比JPA那种全自动ORM，MyBatis对新手来说心智负担小得多——你不需要理解懒加载、一级二级缓存、n+1查询这类进阶概念，只要SQL功底扎实就能玩转。
前端方面我选的是Layui + Thymeleaf。Layui是一个类库式的UI框架，组件丰富、上手快，二次封装程度高，非常适合后台管理系统。不选前后端分离，是因为这个项目规模不需要上Vue，服务端渲染一套下来反而更省事，面试也更容易自圆其说。
提示：如果你所在学校有明确要求用什么技术栈，比如必须JSP或者必须SSM，那以上建议可以忽略，以验收要求为准。
1.3 权限控制：三句话理清角色边界
权限设计是这个项目里很容易被忽视、但真心值得展开的一块。我见过很多学生做的系统，登录进去一个页面通吃所有功能，老师能把自己开除，学生能改自己成绩，这肯定是说不通的。
我的设计思路是三句话：
- 管理员：基础数据维护 + 系统配置，不进考勤操作；
- 教师：发起考勤、查看所授课程统计、审批学生请假；
- 学生：签到、请假、查看个人出勤情况。
技术实现上用了Spring Boot的拦截器（HandlerInterceptor）配合自定义注解来做接口细粒度校验。核心逻辑就是拦截器里解析session/Redis里的登录用户，判断请求路径和角色是否匹配。这里有个小技巧：把需要认证的路径藏在拦截器配置里，比在代码里到处写if (role == xxx)要干净得多。
权限这块做得好还有一个隐藏好处：答辩的时候，评委问“你怎么处理越权访问的”，你可以直接甩出拦截器架构图和几行核心代码，这个加分项基本就锁定了。
2. 数据库设计与核心业务逻辑
2.1 表结构设计：从业务场景反推数据模型
数据库设计是整个考勤系统的根基。表结构设计得好，写SQL的时候就顺手；设计得烂，后面每个功能都会别扭。我最终的表结构核心是六张表：用户表、学生表、教师表、课程表、课程安排表（课表）、考勤记录表，外加一张请假表。
这里我重点说一下考勤记录表的设计，因为这是最容易出问题的地方。
CREATE TABLE attendance_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '主键ID', course_schedule_id BIGINT NOT NULL COMMENT '课程安排ID，标识是哪一次课', student_id BIGINT NOT NULL COMMENT '学生ID', status TINYINT NOT NULL DEFAULT 0 COMMENT '考勤状态：0未签到 1正常 2迟到 3早退 4请假 5缺勤', sign_time DATETIME DEFAULT NULL COMMENT '签到时间', sign_type TINYINT DEFAULT 0 COMMENT '签到方式：0无 1手工签到 2扫码签到', remark VARCHAR(255) DEFAULT NULL COMMENT '备注', create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', UNIQUE KEY uk_schedule_student (course_schedule_id, student_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='考勤记录表';为什么不直接存“哪门课”，而是多绕一层存course_schedule_id（课程安排ID）？这就是为了应对“同一门课在不同时间、不同地点上课”的场景。Java程序设计这门课，周一在A302上的是1班，周三在B201上的是2班，如果考勤只关联课程ID，那“这一次”课的数据就没法区分了。
课程安排表正好把“时间 + 地点 + 教师 + 课程”组合起来，每周的每一堂课都是一条独立记录，考勤记录挂在它下面，整个业务链条就通了。这个设计我当时也是踩了一个星期的坑才想明白的，最初用的就是“考勤直接关联课程ID”，结果连“统计某节课的出勤率”都写不出来。
2.2 考勤状态判断：迟到和早退的标准到底怎么定
这是项目里业务逻辑最繁琐的部分，没有之一。
考勤状态我分成了六种：未签到、正常、迟到、早退、请假、缺勤。其中判断正常、迟到、早退都需要和课时安排时间做比对，这就有几个细节要抠。
一节课的时间段怎么存？我用了两个字段start_time和end_time，格式是TIME类型，只存时间不存日期。对应的日期存在course_date字段里。这样设计的好处是，老师排课的时候不需要关心具体哪一天，只需要设置“周一第二大节”这种周期性规则。
产生考勤记录的逻辑是这样的：当管理员或老师导入课表时，系统根据学期开始日期自动生成所有课次对应的考勤占位数据，每个学生的初始状态就是0（未签到）。从这个角度看，考勤记录其实是预生成的。
学生发起签到的时候，服务器时间跟课时段的比对逻辑如下：
// 上课开始时间前15分钟至上课开始时间后45分钟，算正常签到区间 LocalTime signTime = LocalTime.now(); if (signTime.isBefore(courseStartTime.plusMinutes(45)) && signTime.isAfter(courseStartTime.minusMinutes(15))) { status = 1; // 正常 } else if (signTime.isAfter(courseStartTime.plusMinutes(45))) { status = 2; // 迟到 }这个15分钟、45分钟的窗口就是我们口头上说的“宽限期”。真实课堂里，学生踩点到、迟到半分钟、老师拖堂十分钟都是常见情况。把窗口设置成死板的一刀切，学生肯定有意见。我建议在项目里把这两个参数做成系统配置项，放到配置表里，以后调节方便，也方便在答辩时向评委展示“需求分析做得细”。
早退的判断逻辑其实更简单，因为签到是单次动作，早退需要做“签退”才能记录。如果系统里要做签退功能，就是在课时段结束前允许学生再点一次签退按钮，记录leave_time，然后数据落库之前再判断是不是早退了。
2.3 请假与补签：异常流程的兜底设计
真正的考勤系统，学生问的第一句话往往是：“老师我睡过头了/生病了/有事，能不能补签？”所以，请假和补签流程必须提前设计好，否则系统跑起来你就知道什么叫天天被学生私聊。
我做的方案是：学生提交请假单（选择课程、日期、事由类型、上传证明图片），提交后状态为“待审批”。教师端看到待审批列表，通过后，系统自动把该学生对应课次的考勤状态从“缺勤”改成“请假”。
这里有一个不小的业务问题：学生是在课前请假，但考勤记录是课前就预生成的。所以请假审批通过后，必须有一个“回写事件”——把考勤记录更新为4（请假）状态。这个用一条UPDATE就搞定了：
UPDATE attendance_record SET status = 4, remark = CONCAT(remark, '；请假审批通过') WHERE course_schedule_id = #{scheduleId} AND student_id = #{studentId}补签逻辑就更有意思了。补签谁说了算？肯定不能学生自己点，那就等于签到没意义了。我设置的是教师端补签，老师看到某学生异常记录，如果觉得理由充分，可以手动点击“补签”，把状态改成正常并记录备注。
这个功能不复杂，但很体现“系统设计要考虑真实场景”的思路。很多初学者会把考勤系统做成“机器判定一切”的刻板逻辑，实际上人文关怀也好、漏洞兜底也好，都需要灵活处理机制。你把这个讲给评委听，他们会觉得你真的在思考业务，而不仅仅是写代码。
3. 核心功能实现与实操细节
3.1 环境准备与项目初始化
工欲善其事，必先利其器。环境配置这个环节，我见过太多人在这上面折腾一整天没出结果。统一说下我用的版本组合：
- JDK 1.8（稳定、兼容性最好，很多学校机房默认就是这个）；
- Maven 3.6.x；
- Spring Boot 2.7.x；
- MySQL 5.7 或 8.0；
- Redis 5.x/6.x（用来存验证码和登录状态，可选）；
- IDE：IntelliJ IDEA（社区版够用）。
用Spring Initializr（start.spring.io）初始化项目，依赖只需要选四个：Spring Web、MyBatis Framework、MySQL Driver、Lombok。至于Thymeleaf和Spring Validation，后面加到pom.xml里也行。
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-thymeleaf</artifactId> </dependency>这里有一个很值得注意的坑：Lombok和JDK版本的兼容问题。如果你用的是JDK 17以上，Lombok需要1.18.30以上版本，否则会出现“you aren't using a compiler supported by lombok”的报错。所以，图省事的话就用JDK 8，别一上来就上JDK 21给自己找不痛快。
3.2 签到接口的实现思路与代码细节
签到功能是系统最核心的操作，同时也是并发压力最大的一瞬间——全班几十个人同时点签到，如果在循环里逐条更新数据库，很容易出性能问题。
我这里的思路是：学生端签到请求只传两个参数——scheduleId（课次ID）和studentId（学生ID），由后端统一计算当前时间并判状态，避免客户端时间作弊。同时使用数据库的UNIQUE KEY uk_schedule_student做唯一约束，防止学生重复签到。
@PostMapping("/student/sign") @ResponseBody public Result sign(@RequestParam Long scheduleId, @RequestParam(required = false) String code) { // 获取当前登录学生ID，不从参数取，防止越权 Long studentId = CurrentUserHolder.get(); // 查询课程安排信息 CourseSchedule schedule = scheduleMapper.selectById(scheduleId); // 计算当前状态 Integer status = calculateSignStatus(schedule); // 插入或更新考勤记录 attendanceMapper.insertOrUpdate(scheduleId, studentId, status); return Result.ok(status); }这里有两个容易被忽略的设计要点：
第一，学生ID从哪里来？不要相信前端传的studentId。因为一个学生完全可以改前端参数，把别人的ID传进来帮别人签到——这就是“代签漏洞”。正确做法是学号在登录后存进Session或Redis，接口里直接从登录态获取。这是安全问题，不是代码风格问题。
第二，同一课程重复签到怎么办？我在插入的时候用了insertOrUpdate，配合唯一索引；同时在判断逻辑里加了状态判断——如果已存在正常考勤记录，直接返回“已签到”，不再重复更新。防止学生刷接口把状态从“迟到”刷成“正常”。
3.3 考勤统计模块的查询优化
统计报表这个模块，最容易出现的问题是“查得慢”和“数据对不上”。
慢的根因往往是没有按需查询。比如老师要看“Java程序设计”这门课的出勤汇总，最笨的写法是查出所有考勤记录，然后在内存里循环统计。数据量小的时候没事，一旦记录到几千条，页面就卡了。
更推荐的做法是直接用SQL做聚合，让数据库把结果集压缩好了再返回给应用层：
SELECT DATE_FORMAT(cs.course_date, '%Y-%m-%d') AS course_date, SUM(CASE WHEN ar.status = 1 THEN 1 ELSE 0 END) AS normal_count, SUM(CASE WHEN ar.status = 2 THEN 1 ELSE 0 END) AS late_count, SUM(CASE WHEN ar.status = 4 THEN 1 ELSE 0 END) AS leave_count, SUM(CASE WHEN ar.status = 5 THEN 1 ELSE 0 END) AS absent_count, COUNT(*) AS total_count FROM course_schedule cs LEFT JOIN attendance_record ar ON cs.id = ar.course_schedule_id WHERE cs.course_id = #{courseId} GROUP BY cs.course_date ORDER BY cs.course_date用SUM(CASE WHEN ...)这种写法比多次COUNT扫描快得多，一条SQL就解决了所有状态的数量统计。这个写法笔试面试也都考过，写在这里也算学以致用。
“数据对不上”的问题通常出在JOIN的边界上。比如某节课还没人生成考勤记录，如果用INNER JOIN，这节课就不会出现在统计结果里，但老师觉得“明明是一节课，为什么统计里没有”。这就是应该用LEFT JOIN保护主表行数的地方。
3.4 界面交互方式与体验
前端这块，说几句不那么代码向但很重要的话。
这个项目如果做成纯后台管理界面，学生用起来会非常痛苦——每次上课要打开电脑、登录、找到课程、点签到，步骤太多了。我做了一个改进：在教师发起考勤时，生成一个六位数的签到码。学生端首页只要输入这个签到码，系统自动匹配当前时间最近的待签到课程，一键完成签到。输入验证码的方式还能防止学生不在教室远程签到。
另外，页面统计数据尽量用图表。Layui自带的echarts适配层可以做折线图和柱状图，把出勤率趋势展示出来。答辩时演示图表部分，评委第一印象就会觉得“这系统完整度高”，这个印象分很值钱。
4. 常见问题与排查技巧实录
4.1 环境配置类问题
说实话，这个项目我帮不少同学排过错，翻车重灾区就是环境配置，这里把高频问题集中整理一下。
问题1：Maven依赖下载慢或者卡死。这是因为默认走了中央仓库。方案是配置阿里云镜像，在settings.xml里的mirrors节点加一段镜像配置。配置完再刷新Maven，速度能快很多。
问题2：端口被占用。启动Spring Boot时报“Port 8080 was already in use”。用netstat -ano | findstr 8080查PID，然后任务管理器结束进程就行。有些人选择改端口，其实治标不治本，因为你可能改了8080又撞上8081。
问题3：IDEA运行代码报中文乱码。这个基本上是控制台编码不对。修改IDEA的Help -> Edit Custom VM Options，加上-Dfile.encoding=UTF-8，然后重启。也可以检查项目编码设置，全部统一成UTF-8。
这些环境问题看着琐碎，但实际占用了做项目的三分之一时间。我通常建议：装好环境先跑一个最简单的Hello World项目，确认链路通了再开始写业务代码。这个步骤省不了，花五分钟能避免后面两小时的折腾。
4.2 业务逻辑类问题
问题4：学生重复签到没有提示。原因可能就是唯一索引没建，或者插入前没查状态。这两个手段都要上，接口测试的时候先发两次重复请求验证一下。
问题5：请假审批后考勤记录没变化。这是因为审批只更新了请假表，忘了回写考勤记录。解决方法是把业务逻辑做成一个事务：更新请假单状态然后更新考勤状态，必须同时成功或同时失败，加上@Transactional注解。事务这个东西理论上都懂，但实际用起来才是真学会。
问题6：统计出勤率超过100%。多半是统计口径不一致。出勤率的分子分母到底怎么定义，必须在需求阶段就定好：正常 + 迟到算出席，请假和早退算不算？比如某学校规定请假不影响出勤率，那分子就是正常 + 迟到，分母就要看是应到人数还是实到人数。这些口径要在代码里写成常量，并在注释里写清楚规则，而不是散落在SQL里。
4.3 数据库与时区问题
问题7：时间差8小时。这是项目里最容易出现、也最莫名其妙的问题。JVM默认时区跟MySQL连接串的时区不一致，查出来的时间就漂了。最稳妥的方案是连接串显式指定时区：
jdbc:mysql://localhost:3306/attendance?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai然后在MySQL侧也确认一下time_zone变量：
SHOW VARIABLES LIKE '%time_zone%';问题8：MySQL 8.0的密码加密方式导致连接失败。MySQL 8默认用caching_sha2_password，老版本的驱动不认。要么用8.x对应版本的驱动（mysql-connector-java8.0.x），要么在创建用户时指定mysql_native_password，二选一即可。
4.4 还有一个容易忽略的坑：Lombok的编译问题
前面提到过JDK和Lombok的版本兼容问题，这里再展开一下。如果你用的是新版IDEA + 新版JDK，编译报错提示“you aren't using a compiler supported by lombok”，一般就是Lombok版本太旧。去Maven中央仓库看看最新版，把lombok.version改成最新的就行。
另外一个相关的坑：IDEA需要安装Lombok插件，否则@Data注解的getter/setter代码无法识别，但Maven编译又能通过，这种“IDE报错但项目能跑”的诡异状态最容易让人懵圈。确认一下插件装了没有。
5. 做得多了以后的一点实际心得
这个项目前前后后我见过完整版本也有十来个了，有一个体会特别深：真正拉开档次差距的，往往不是技术，而是细节和完成度。
有的人的考勤系统，就是一个CRUD的堆砌，页面难看、逻辑松散、字段名乱起。而有的人的考勤系统，会有完整的异常处理、操作日志、数据校验、周期性任务、前端防重复提交、后端参数校验，甚至还能生成Excel导出报表。同一个题目，投入的时间相近，最后呈现的效果天差地别。
我建议你拿到这个题目后，优先做三件事：
第一，先把权限体系做扎实。这是系统架构的骨架，也是最容易出彩的部分。它能隔离职责，也能保护数据，同时也是面试官最爱深挖的地方。
第二，把考勤状态的判定逻辑设计成可配置的。哪些状态算迟到、宽限期多长，都做成配置项。这不仅方便业务调整，也能体现你的需求分析能力。
第三，统计报表别用循环写法。一条SQL能聚合的就别多查几次，这既是性能问题，也是代码质量问题。
最后再分享一个小技巧。如果你打算把这个项目写进简历，记得把项目描述写得有数据支撑。别写“实现了考勤功能”，而是写“设计并实现了多角色考勤系统，支持千人级并发签到、课表周期自动生成考勤任务、考勤数据通过SQL聚合统计将报表查询耗时控制在百毫秒级”。同样是亮点，“可量化”和“不可量化”在面试官眼里是两种东西。
这个系统后续还可以扩展的方向也很多：比如接入企业微信或者钉钉的消息提醒、用二维码扫码签到、基于Redis做签到排行榜、用WebSocket做实时出勤大屏。这些都可以作为你继续深入的方向。先把基础版本做扎实了，再谈扩展，一步一个脚印搞定它。
本文还有配套的精品资源，点击获取
