简介：在Java后端开发中，权限控制与数据一致性是构建可靠系统的核心要素。无论是企业级应用还是课程设计项目，都需要通过合理的数据库设计与事务管理来保证业务数据的准确性。基于Spring Boot和MyBatis的主流技术栈，开发者可以高效实现用户认证、角色授权及考勤记录的唯一性约束。学生考勤系统作为经典课设题目，涵盖了角色权限、状态流转、聚合报表等典型场景，是理解Java Web开发全流程的绝佳载体。从技术选型、数据库表设计、签到防重复到统计SQL优化，系统拆解了一个完整考勤系统的实现要点，为课设答辩和Java面试提供实战参考。 每年到了毕设季和课设季，总有一批人抱着"学生考勤系统"这个题来找我，理由都差不多：Java学的还行，感觉考勤系统比较简单，想稳妥拿个高分。结果真正动手做的时候，登录权限、打卡去重、请假审批、统计报表、首页数据可视化……一个模块一个坑。这篇文章我就以自己这些年做Java项目的经验，把这个题目从技术选型到数据库设计、核心功能实现、再到联调排错和面试延伸，完整拆开讲一遍。准备用Java做课设或者正在复习Java面试基础的，都可以拿这篇文章当参考。
1. 为什么"学生考勤系统"每年都是课设常青树
之前帮人排查过一个Java毕设项目的线上问题，项目就是学生考勤，结果期末统计的时候管理员页面直接卡死，查了一下是统计SQL没有按日期走索引，几千条记录就把查询拖垮了。这不是个别现象，而是这类系统最常见的问题之一。考勤系统看起来只是"记录谁来了谁没来"，但往细了做，角色权限、业务单据、统计报表、异常数据兜底，每一层都有值得展开的设计空间。
从题目本身来分析，"基于Java的学生考勤系统"这个命题有四个天然的好处：
角色清晰，天然具备权限控制的讨论空间。管理员、教师、学生三种角色的菜单和数据权限都不同，这比随便写一个CRUD项目更容易讲清楚访问控制逻辑。
核心业务有明确的"状态变化"。学生签到，一条记录产生，状态从"未考勤"变成"正常/迟到/早退/旷课"，请假审批也有"待审批/已通过/已驳回"，这些状态机非常适合用Java枚举和策略模式来表达。
自带统计报表需求。按课程、按班级、按周、按月统计出勤率，需要写聚合SQL，这正好回应了面试里"你对SQL掌握得怎么样"的问题。
从开发量来看，规模适中。用Spring Boot + MyBatis + Thymeleaf这套主流组合，一个人两三周能完成全功能，有足够时间打磨细节，不像商城系统那样容易陷入无限迭代。
如果正在准备Java面试，这个项目的价值就更高了。面试官基本都会围绕项目问：登录是怎么做的、权限怎么控制的、有哪些表、为什么这样设计、并发打卡怎么防重复、统计的SQL怎么优化。这些问题都能在考勤系统的真实场景里找到落脚点，比背八股文生动得多。
2. 技术栈选型的取舍逻辑
2.1 课设项目到底该用哪套技术
我一贯的选型建议是：如果时间够用，优先选Spring Boot + MyBatis + Thymeleaf + MySQL。理由不是这样最"高级"，而是这套组合覆盖了Java后端开发最核心的能力点：Spring IoC/AOP、数据库操作、模板渲染、Restful接口设计。很多学校还在教Servlet+JSP，能理解，那是为了讲清楚HTTP和Web底层的运转逻辑，但课设阶段我更推荐直接把Spring Boot用起来。
也有同学上来就选Spring Cloud微服务加Vue前后端分离，我见过不少这样的项目，最后都是花了一半时间在搭环境和调跨域上，核心业务反而没做扎实。不是说微服务不好，而是考勤系统这规模，微服务的复杂度是纯负担。如果导师要求必须有前端框架，那选Vue + Element Plus做管理端，后端提供JSON接口，也可以，但工作量会明显上浮，需要提前评估时间。
技术选型还有一个很现实的原因：这套技术栈毕业后进公司还能直接用。学生考勤里的用户登录、权限拦截、事务管理、SQL聚合，和真实企业项目里做的事情没有本质区别，做完之后拿得出手。
2.2 开发环境的安装与配置
环境这块是每次帮人远程看项目时出现问题最多的环节，常见的有这么几类：
- JDK版本混乱。有的电脑装了多个JDK，IDEA里项目JDK、Modules的Language Level、Maven的JDK设置三者不一致，编译的时候报各种诡异错误。
- Lombok不生效。明明依赖加了，注解也写了，运行时报找不到getter/setter，多半是IDEA没启用Annotation Processing。控制面板Settings -> Build, Execution, Deployment -> Compiler -> Annotation Processors，勾选Enable annotation processing，基本就能解决。
- Maven依赖下载慢。国内使用默认中央仓库很容易卡住，解决方案是在Maven的settings.xml里配置阿里云镜像。
- MySQL 8的驱动和时区问题。驱动选择com.mysql.cj.jdbc.Driver，连接串建议追加serverTimezone=Asia/Shanghai，否则会出现时间差8小时的问题。
JDK版本的选择上，如果你的机器是纯学习用途，装JDK 8或JDK 11都比较稳妥，资料多、兼容性好。现在新项目用JDK 17的也越来越多，但要注意Spring Boot版本需要2.5以上才完整支持17。没必要追求最新，稳定压倒一切。
2.3 前端渲染方案怎么定
如果采用前后端不分离的方案，Thymeleaf是Spring Boot的天然拍档，页面直接写HTML，通过th:each、th:if这些属性渲染数据，后端返回视图名，路由跳转也比较直观。这种方案对不熟悉前端工程化的同学最友好，不用配Node、不用学Vue CLI，一条命令就能把项目跑起来。
如果选前后端分离，那么后端只需要返回JSON，前端负责所有页面交互。这样做的优势是接口复用性强，同一个登录接口可以给Web端和移动端共用，劣势是需要额外搭一套前端工程，跨域和Token管理也会增加复杂度。
我在课设指导时，一般建议学生先想清楚一个问题：我的目标是快速、稳定地交付一个完整系统，还是想额外展示前后端分离的能力？如果对Vue不熟，硬上分离式开发，踩坑成本其实挺高的。
3. 数据库设计：考勤系统的地基
数据库设计是课设评分的大头，也是面试必问的部分。考勤系统不要一上来就建十几张表，那样看起来很丰富，但关联性差，自圆其说都难。我更推荐从核心流程出发，按"用户-班级-课程-考勤-请假"这个主链路设计，保证每张表都有存在理由。
3.1 核心表清单与字段设计
这里给出一套常见的表结构设计，适用于大多数考勤系统：
用户表（user）：用户ID、用户名、密码（推荐BCrypt加密存储）、姓名、角色（管理员/教师/学生）、所属班级ID、联系电话、创建时间。学生和教师不需要分开建表，用一个角色字段区分即可，这样登录逻辑会简单很多。但要注意：如果角色以后要扩展（比如加一个辅导员），需要评估字段冗余会不会成为问题。
班级表（class_info）：班级ID、班级名称、专业、入学年份、辅导员/班主任ID。班级独立成表的目的是方便后续按班级维度做统计筛选。
课程表（course）：课程ID、课程名称、课程编号、授课教师ID、上课时间（如周一第1-2节）、上课地点。课程表是考勤的业务载体，教师需要知道这节课上哪些学生来签到。
考勤记录表（attendance_record）：记录ID、课程ID、学生ID、教师ID、考勤日期、签到时间、考勤状态（正常/迟到/早退/旷课/请假）、备注、创建时间。这张表是整个系统的核心，字段设计直接决定统计SQL的复杂度。
请假申请表（leave_request）：申请ID、学生ID、课程ID、请假开始时间、结束时间、请假事由、附件、审批状态（待审批/已通过/已驳回）、审批人ID、审批时间、审批意见。
选课关系表（student_course）：学生ID、课程ID。学生和课程是多对多关系，必须通过中间表维护，否则考勤时无法知道一个学生应该出现在哪些课程中。
3.2 表设计里容易被忽视的几个关键点
有人为了省事，把考勤状态设计成一个字符串字段，直接填"正常"或"迟到"。这样看起来简单，但统计时必须写一堆字符串匹配，如果前后端手误写成了"迟到 "多了个空格，整个统计结果就错了。更推荐的做法是存整数代码，比如1正常、2迟到、3早退、4旷课、5请假，Java侧用枚举常量维护，展示层再做翻译。
考勤记录表必须有唯一约束，至少要保证同一学生在同一天同一门课程只有一条记录。这个约束的预防作用比应用层判断更硬。如果先查后插，在高并发或重复提交的场景下容易脏数据，一旦数据库层面加了唯一索引，即便应用层逻辑有漏洞，数据也进不去。索引建议这样建：UNIQUE KEY uk_stu_course_date(student_id, course_id, attendance_date)。
每次考勤日期建议用DATE类型，签到时间建议用DATETIME类型。时间区域配置错误会导致数据库时间与本地时间相差8小时，后面排查起来很闹心。连接串里serverTimezone=Asia/Shanghai和数据库初始化时设置时区，两者都要注意。
3.3 一套可直接参考的建表SQL示例
下面给出核心表的简化版本，便于快速搭建演示：
CREATE TABLE `user` ( `id` INT NOT NULL AUTO_INCREMENT, `username` VARCHAR(50) NOT NULL, `password` VARCHAR(100) NOT NULL, `real_name` VARCHAR(50) DEFAULT NULL, `role` TINYINT NOT NULL DEFAULT 3 COMMENT '1-管理员 2-教师 3-学生', `class_id` INT DEFAULT NULL, `phone` VARCHAR(20) DEFAULT NULL, `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ); CREATE TABLE `class_info` ( `id` INT NOT NULL AUTO_INCREMENT, `class_name` VARCHAR(100) NOT NULL, `major` VARCHAR(100) DEFAULT NULL, `enroll_year` VARCHAR(10) DEFAULT NULL, `head_teacher_id` INT DEFAULT NULL, PRIMARY KEY (`id`) ); CREATE TABLE `course` ( `id` INT NOT NULL AUTO_INCREMENT, `course_name` VARCHAR(100) NOT NULL, `course_no` VARCHAR(50) DEFAULT NULL, `teacher_id` INT NOT NULL, `class_time` VARCHAR(100) DEFAULT NULL COMMENT '如:周一第1-2节', `location` VARCHAR(100) DEFAULT NULL, PRIMARY KEY (`id`) ); CREATE TABLE `student_course` ( `id` INT NOT NULL AUTO_INCREMENT, `student_id` INT NOT NULL, `course_id` INT NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_student_course` (`student_id`, `course_id`) ); CREATE TABLE `attendance_record` ( `id` INT NOT NULL AUTO_INCREMENT, `course_id` INT NOT NULL, `student_id` INT NOT NULL, `teacher_id` INT NOT NULL, `attendance_date` DATE NOT NULL, `sign_in_time` DATETIME DEFAULT NULL, `status` TINYINT NOT NULL DEFAULT 1 COMMENT '1-正常 2-迟到 3-早退 4-旷课 5-请假', `remark` VARCHAR(200) DEFAULT NULL, `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_stu_course_date` (`student_id`, `course_id`, `attendance_date`), KEY `idx_course_date` (`course_id`, `attendance_date`) );生产环境可以把ID改为雪花ID或UUID，但课设阶段用自增主键就够了，好理解也好用。
4. Java后端核心功能实现思路
4.1 登录与权限拦截的两种主流实现
登录是最能体现基本功的模块。我推荐用Session + 拦截器的方案，原因很简单：在学习阶段，Session方案能让人更清楚地理解"会话"这个概念，代码量少，出问题容易排查。具体做法是：登录成功后，把用户对象放入Session；自定义一个HandlerInterceptor，在preHandle方法里判断Session中是否有用户，没有就重定向到登录页；同时按角色控制菜单渲染。
很多课程设计项目死在这一步，因为Controller里每个方法都去判断Session，代码重复，漏判一个接口就绕过登录了。正确做法是注册拦截器：
public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); User user = (User) session.getAttribute("loginUser"); if (user == null) { response.sendRedirect("/login"); return false; } return true; } }然后在配置类里注册这个拦截器，并排除登录接口和静态资源路径。如果想在登录后返回JSON给前端，可以用POST方式提交用户名密码，Controller里验证成功后把用户对象塞进Session，前端拿到成功标志后跳转首页。
如果有余力，也可以了解JWT方案。JWT把用户ID和角色签名进一个Token字符串，前端在Header里携带，后端用过滤器解析。它的优点是无状态，适合前后端分离；缺点是Token过期处理、注销下架这些逻辑比Session麻烦。面试常问两者的区别，做一遍感受会很深。
4.2 考勤签到与状态判定逻辑
考勤的经典需求是：教师选定一门课程、日期、课程节次，然后选择班级，逐个或批量把学生标记为"出勤/迟到/早退/缺勤"，或者由学生在规定时间内自助打卡。自助打卡更贴近校园场景，也更容易引起面试官兴趣。
我在实现打卡时，把规则封装在一个核心Service方法里，关键逻辑是这样：
- 根据当前登录学生ID和传入的课程ID，查询选课关系是否有效；
- 判断当前时间是否在该课程允许的签到时间窗口内。比如课程是8:00开始，允许课前10分钟到课后15分钟内打卡，超过这个窗口直接抛"超出签到时间"；
- 检查当前日期当天此学生此课程是否已有考勤记录，有则禁止重复打卡；
- 计算考勤状态：如果签到时间在课程开始时间之前，状态为正常；如果签到时间在课程开始之后、但在宽限期（如15分钟）内，状态为迟到；超过宽限期的，需要教师手工判定，或者直接标记为旷课；
- 插入考勤记录，统一提交事务。
核心代码大概是这样：
public AttendanceResult signIn(Integer courseId, Integer studentId) { StudentCourse sc = studentCourseMapper.selectByStudentAndCourse(studentId, courseId); if (sc == null) { return AttendanceResult.failure("未选该课程，无法考勤"); } LocalDate today = LocalDate.now(); if (attendanceRecordMapper.exists(studentId, courseId, today)) { return AttendanceResult.failure("今天已考勤，请勿重复打卡"); } Course course = courseMapper.selectById(courseId); LocalTime now = LocalTime.now(); // 签到窗口判断 if (now.isBefore(course.getStartTime().minusMinutes(10)) || now.isAfter(course.getStartTime().plusMinutes(15))) { return AttendanceResult.failure("当前不在签到时间范围内"); } Integer status = now.isBefore(course.getStartTime()) ? STATUS_NORMAL : STATUS_LATE; attendanceRecordMapper.insert(courseId, studentId, course.getTeacherId(), today, now, status); return AttendanceResult.success(status); }这里最值得扩展的点是"如果多人同时打卡，怎么保证不重复"：数据库唯一索引兜底，事务结合，锁是必要的。面试官如果问并发场景，可以顺着这个思路展开。
4.3 请假审批流程的状态流转
请假不需要一上来就设计成复杂工作流引擎。考勤系统的请假，核心状态只有三个：待审批、已通过、已驳回。学生提交请假申请后，指定审批人（一般是授课教师或辅导员）登录系统看到待办列表，点击通过或驳回，审批意见写入记录。
状态字段我建议用Integer类型，配合常量类或枚举类统一管理。用枚举的好处是：状态名称集中、可以在枚举里添加"是否允许取消申请"之类的业务规则，代码更内聚。
需要注意一个业务联动：请假审批通过之后，这条学生当天该课程的考勤记录应该自动标记为"请假"状态，而不是在统计时把请假单独排除。这么做能够避免统计口径不一致的问题：有的地方用了请假表，有的地方用了考勤表，最后两边数据对不上。
4.4 统计报表：用聚合SQL说话
统计是考勤系统最容易出彩的部分，也最容易翻车。常见的统计维度有这么几个：
- 按学生统计：某学生在某段时间内出勤、迟到、早退、旷课、请假次数；
- 按班级统计：某班级某门课的平均出勤率；
- 按课程统计：某课程的出勤情况，便于教师掌握学生整体状态；
- 按日期统计：某天各班级的出勤对比。
以"统计某学生某门课程的各状态次数"为例：
SELECT SUM(CASE WHEN status = 1 THEN 1 ELSE 0 END) AS normal_count, SUM(CASE WHEN status = 2 THEN 1 ELSE 0 END) AS late_count, SUM(CASE WHEN status = 3 THEN 1 ELSE 0 END) AS early_leave_count, SUM(CASE WHEN status = 4 THEN 1 ELSE 0 END) AS absent_count, SUM(CASE WHEN status = 5 THEN 1 ELSE 0 END) AS leave_count, COUNT(*) AS total_count FROM attendance_record WHERE student_id = #{studentId} AND course_id = #{courseId}这里用COUNT加CASE WHEN，只需要一次表扫描，避免多次查表。统计报表如果数据量大，性能瓶颈往往在attendance_date范围查询，所以前面建索引时特别建议加上(course_id, attendance_date)联合索引。
4.5 多角色首页：同一张表，三种视角
管理员首页显示：班级总数、学生总数、今日出勤率、本周缺勤TOP5班级。教师首页显示：我的课程数、今日有课课程、最近一次课程的出勤统计。学生首页显示：我的出勤率、最近缺勤课程提醒、待审批的请假申请。
三种视角对应同一条考勤数据，只是筛选条件不同。如果在前端分开写死三套页面，后端三个Controller各查各的，代码量会膨胀。更优雅的做法是在后端的统计Service里抽出公共统计方法，参数包含用户角色和用户ID，Service内部根据角色决定按什么维度过滤。这也是一个典型的场景可以讲给面试官听。
5. 全流程联调与典型问题排查清单
系统开发完成后，从"能跑"到"真正可以答辩演示"之间，还有一段联调路要走。这里把遇到的高频问题和排查思路整理成清单，每条都是真实踩过的坑。
5.1 VSCode/IDEA控制台乱码
现象：启动Spring Boot后，控制台输出的中文变成乱码。排查链路：先确认代码文件本身的编码是不是UTF-8，再确认IDE控制台编码是否设置为UTF-8，最后确认浏览器页面有没有显式指定UTF-8。VSCode里出现乱码，通常是终端编码和文件编码不匹配，可以在设置里把files.encoding改为utf8，并在启动配置的VM options里加-Dfile.encoding=UTF-8。
5.2 Lombok注解突然失效
现象：项目之前编译正常，某次更新后报"cannot find symbol"或者直接提示"you aren't using a compiler supported by lombok, so lombok will not work"。排查链路：先看Maven依赖是否还在，再看IDEA里Annotation Processing是否被关闭，最后检查JDK版本是否被切换过。JAVA_HOME指向的JDK版本，与IDEA内配置的Project SDK版本不一致时，Lombok经常出问题。
5.3 OutOfMemoryError: insufficient memory
现象：项目启动几分钟后内存暴涨，控制台报堆内存不足。排查链路：先用JVM参数让系统启动时打印GC日志，然后通过VisualVM或JProfiler查看堆内存占用情况。考勤系统这种场景，常见原因是统计功能把大量考勤记录一次性加载到内存再在Java代码里过滤。解决思路是：把所有统计都改成SQL聚合完成，避免全表加载；如果必须加载，用分页或分批查询。
5.4 编译时报"源发行版 17 需要目标发行版 17"
现象：代码里用了比较新的语法，但本地JDK是8，IDEA却把Language Level设置为17，编译会报错。排查链路：检查Project Structure里的Project SDK和Language Level，检查Maven的pom.xml里maven.compiler.source和target设置，再检查IDEA的Settings -> Build Tools -> Maven -> Runner -> JRE。多处必须保持一致，这是多版本JDK环境下方方面面的老问题。
5.5 数据库时间与本地时间差8小时
现象：页面上显示的签到时间比实际时间慢了或快了8小时。排查链路：先确认数据库服务器的时区，再检查连接串是否配置了serverTimezone，最后检查MySQL的全局时区设置。建议连接串统一使用jdbc:mysql://localhost:3306/attendance?useUnicode=true&characterEncoding=UTF-8&serverTimezone=Asia/Shanghai，数据库初始化时也设置好时区，避免在应用层做时间偏移的脏操作。
6. 把课设项目讲出面试价值
很多Java求职者手里有项目，面试时讲得却很平，基本就是说"我做了个考勤系统，有登录、有增删改查"，然后等面试官问。这个状态太被动了。考勤系统虽然小，但完全可以在面试时展现出个人的设计思考。
面试官在我朋友展示考勤系统时问过一个问题："同一个学生同一节课，如果重复提交考勤怎么办？"他答了"先查后插"，面试官又问"如果两个人同时提交呢"——这就涉及并发安全。其实考勤系统的解锁点非常多：登录校验方案对比、密码加密方式、事务边界怎么定、唯一索引的作用、聚合SQL优化、枚举代替魔法值、拦截器的使用。每一个都能映射到对应的八股文知识点，而且是从真实场景里长出来的，比空背理论自然得多。
如果想在项目上加几个亮点，可以考虑：
- 给签到接口加上Redis分布式锁，保证幂等，并讲解为什么数据库唯一索引还不够。
- 用策略模式将"正常/迟到/早退/旷课/请假"的状态判定拆成独立的策略类，配合工厂模式获取策略，展示设计模式的实际运用。
- 增加定时任务：每天晚上自动把未签到的学生标记为旷课，用Spring的@Scheduled实现。
- 导出考勤报表Excel，用EasyExcel或POI封装工具类，既实用又能讲清楚内存控制相关知识点。
做课设的最终目标不只是交一个系统，而是在这个过程中把Java后端常见知识串起来。考勤系统朴素但五脏俱全，遇到的每一个问题，都有机会变成面试回答里的加分项。
如果最后让我总结一点个人经验，那就是：宁可把一张考勤记录表的唯一索引和事务边界想清楚，也不要急着把页面写得花团锦簇。系统核心数据的可靠性和可解释性，才是这个项目拿到高分的关键。数据库设计做完之后，先花半小时把所有表的关系画出来、自问一下"如果我是使用这个系统的人，我最关心哪些数据"，往往比直接写代码效果更好。把这套流程走完，这个考勤系统在答辩和面试里都不会拖你的后腿。
本文还有配套的精品资源，点击获取
