基于Spring Boot的公安院校晚自习考勤系统设计与实现解析

公安院校晚自习考勤系统，单看名字会觉得这又是一个“没什么技术含量”的课设题：建个表、写个接口、点个签到按钮，完事。但真正上手之后你会发现，晚自习考勤和公司打卡完全是两种逻辑——它面向的是“区队制”的学生管理场景，背后牵扯到晚自习计划、请假审批、公差报备、补签流程、查勤通报和综合测评汇总，业务链路比想象中长得多。这篇文章我就以这套基于 Java 的公安院校晚自习考勤系统为线索，把整个设计与实现过程拆开讲透：为什么做成 Web 端而不是小程序，表结构怎么设计才能撑起完整业务，签到时间窗口怎么判定不扯皮，以及源码拿到手里之后到底要改哪些地方才能顺利通过答辩。不管是准备做同类选题的计算机专业学生，还是想借鉴考勤业务设计的人，这篇都有参考价值。

1. 晚自习考勤和普通课堂考勤，根本不是一回事

很多人一听说“考勤系统”，第一反应就是参照钉钉打卡来做：用户签到、签退、后台拉个表格就完事。这套思路放到普通公司可以，放到公安院校的晚自习场景里会跑不通。原因是晚自习不是“上一节课”那么简单，它是一个时间固定、地点固定、人员必须整建制到位的管理时段。学生以区队为单位进入指定教室，按照固定时间开始、结束自习，中间还可能出现查勤和不定时点名。系统要处理的不仅是“来没来”，还要回答“什么时候来的”“待了多久”“中间有没有离开”“为什么没来”这些问题。每一步背后都是一类出勤状态，而每一种状态都涉及到学生管理评分，不是简单地打勾和打叉。

公安院校的管理方对于晚自习出勤率看得很重，考勤结果会跟日常量化管理挂钩。这就导致系统不能只记录“签到了”，还要能区分正常签到、迟到、早退、缺勤、请假、公差等不同情形。尤其是公差——学生被安排去搬物资、出板报、参加临时会议，这些都不属于缺勤，但必须有可追溯的审批依据，不然月底统计时辅导员会被学生反复找补。

所以做这套系统，第一步不是写代码，而是把使用场景里的角色和动作理清楚。我梳理下来，核心角色主要有四类：

• 学生：查看本周晚自习安排，执行签到、签退，提交请假、销假、补签申请。
• 区队长/班长：核对本区队到场情况，代辅导员确认考勤异常，处理学生补签申请。
• 辅导员/学管老师：维护晚自习计划，审批请假和公差申请，查看本区队或本年级的考勤汇总。
• 系统管理员：管理用户、班级、基础数据字典，维护系统参数。

从晚自习开始前到结束后，一条完整的数据流大概是这样：管理员提前把一周的晚自习计划生成好，分配到各教室和各区队；学生在开始时间前到达并进行签到；自习结束时签退；中间如果有查勤老师抽查，可以录入查到状态；如果有学生需要请假，走“学生申请 -> 区队长确认 -> 辅导审批”的流程；到了第二天，系统按状态码生成前一天的考勤明细和汇总。理完这条链路你就会发现，这根本不是一个 CRUD 就能解决的系统，它的核心难点在于状态管理、时间窗口判定和审批流怎么串起来。

2. 技术选型为什么不直接堆微服务，而是老老实实走 Spring Boot 单应用

这标题里带“基于 JAVA”，很多同学拿到后第一反应是问用 Spring Cloud 行不行、要不要加 Redis 做缓存。我劝你别这么干。毕设系统的评分点在于逻辑完整、能跑通、能讲清楚，不是看你的注册中心有几个节点。Spring Cloud、分布式事务这些东西放进一个单体教务考勤系统里，纯粹是给自己挖坑，面试官问起来你也很难自圆其说。正确做法是选择一个足够主流、能体现分层思想、且演示时不容易环境翻车的技术组合。

我最终采用的是这套非常经典的路子：

这里面我最想强调两个决定。

第一，页面端用了 Thymeleaf 而不是前后端分离。原因很简单，答辩现场最怕“前端页面能开，但接口挂了”这种尴尬。服务端渲染模式下，后端和页面部署在一起，只要工程能启动，页面基本就能打开，减少了各种跨域和接口联调问题。Thymeleaf 对自带权限控制的后台系统支持也很好，在页面里直接用 ${session.userName} 拿登录用户，比走 Token 再解析要直观得多。

第二，权限控制选择了 Shiro，而不是直接硬编码 session 判断。这个系统虽然小，但角色之间有明确隔离。普通学生不能看到全校区队汇总，辅导员不能修改系统字典。Shiro 的框架思路简单，就是把“登录用户是谁、他有哪些角色、某个请求需要什么权限”这三点串起来。拦截器配置写起来花费的时间很少，但答辩时可以很自然地讲出认证和授权的整体流程，这是老师的常态提问点，也是拉开档次的地方。

至于为什么不用小程序或者 App，理由同样现实。小程序需要额外的微信审核和 HTTPS 证书配置，App 还要考虑安卓签名和模拟器问题。毕设阶段把 Java Web 这套主链路做深做透，已经足够覆盖考勤管理的全部核心需求了。如果你确实想让系统有点移动味，可以在页面里加一个基于 Bootstrap 的移动端视图，而不是另起炉灶做多端。

3. 表结构设计：用一个周六晚自习周期推到出所有核心表

动手写代码之前，我先做了一件很笨但很有效的事：把一个完整的晚自习周期从头到尾演了一遍。从周一早上管理员发布“本周 19:00-21:00 在教室 C101 上晚自习”开始，到周日统计出上周综合考勤，一遍演完，哪些表要建、表里哪些字段必须有，基本就清楚了。

3.1 核心表之间的关系：学生、计划、记录三张主表缺一不可

很多课设版本的考勤系统只做两张表：学生表 + 考勤记录表，然后记录表里直接用字符串存“2025-06-02 19:00 在 C101”，这种做法非常偷懒，因为它丢失了“考勤计划”这个中间维度。没有考勤计划，系统没法在后台自动生成当天的考勤任务，也没有办法校验学生是不是签错了教室。我的设计里把链路拆成了五张基础表加三张扩展表：

• sys_user：用户登录账号，包含用户名、密码（MD5 加盐）、角色类型、状态。
• student_info：学生扩展信息，字段包括学号、姓名、区队编号、手机号、宿舍楼栋、关联 sys_user_id。
• class_info：区队/班级表，比如“侦查学 2101 区队”，关联辅导员用户 ID。
• schedule_info：晚自习计划表，核心字段是计划日期、开始时间、结束时间、所在教学楼与教室、区队 ID、发布状态。
• attendance_record：考勤记录表，关联学生和计划，记录签到时间、签退时间、签到状态、签退状态、查勤状态。
• leave_request：请假/公差申请单，包含请假类型、开始时间、结束时间、原因说明、证明材料地址、审批状态。
• attendance_modify_log：补签/修正记录表，谁在什么时间把哪条考勤记录从什么状态改成了什么状态。
• dict_data：数据字典表，存放“0 未签到 / 1 已签到 / 2 正常 / 3 迟到 / 4 早退 / 5 缺勤 / 6 请假 / 7 公差”这类映射。

这里面最容易被忽略的是 attendance_modify_log。学生漏签后辅导员要进行补签操作，如果没有操作日志，后面统计有争议时根本说不清楚是谁改的。实际管理场景里，考勤数据是要作为评分依据的，修改痕迹必须留底。这一张表平时看着没用，但到了答辩问“系统如何保证数据可信度”的时候，它就是很好的一个回答点。

3.2 关键字段设计：不能只有状态，还得有可计算的时间

设计 attendance_record 表时，我特意把“状态”和“时间”分开处理。比如一名学生到教室的时间是 18:52，签到接口写入的是签到时间字段；而 daily_status 字段是在后台定时任务里统一计算出来的。为什么不直接在前端判断迟到后把状态存成“迟到”呢？因为系统规则可能调整，比如原定宽限时间 10 分钟，后来改成 20 分钟，但已经存进数据库的“迟到”状态不会自动更新。如果每次只记录原始时间，状态统一用视图或定时任务计算，规则变化后重新刷一遍就能得到新结果。

晚自习考勤有两个特殊时间点需要设计成系统参数：一个是 start_time，代表计划开始时间；另一个是 signin_deadline，也就是最晚签到时间。它通常跟 start_time 不一样，方便设置宽限期。具体判断逻辑是这样一把标尺：

• 在 start_time 前签到的：正常。
• 在 start_time 后、signin_deadline 前签到的：仍算正常，但系统可以给个提示，客观记录为“踩点签到”。
• 超过 signin_deadline 仍未签到且没有请假的：当天状态自动落为迟到或缺勤，具体看策略设置。
• 签退时间同理，早于规定结束时间算早退，结束时间后未操作签退的，通过定时任务自动补为正常签退时间。

区队和教室之间的关系也建议做进计划表。我遇到过不少设计，教室信息写死在页面标题里，这会导致后续统计“某日各教室出勤率”时没有数据的支撑点。只要在 schedule_info 里维护好 building、room_no 两个字段，后期做一个按楼栋教室的透视表，就是一条 SQL 的事。

3.3 MySQL 建表的几个小细节：字符集、唯一索引和软删除

数据库这层在实际操作里最容易踩坑的是三件事。一是字符集，表结构创建时最好统一指定 utf8mb4，不然在 MySQL 5.7 环境里容易遇到中文乱码或者表情符号报错。二是唯一索引，考勤记录表里一定对 student_id + schedule_id 加唯一约束，这能从数据库层面挡住同一个学生同一次晚自习被重复插入记录，防止前端多次点击导致数据翻倍。三是是否做软删除。考虑到这套系统后期要保留历史数据用于学年评比，我建议加一个 deleted 字段，删除操作统一改成 UPDATE，而不是物理 DELETE，这样可以避免误操作把整个月的考勤清掉。

在建表完成后，还需要把一部分统计工作放到初始化数据里。比如每个学期开始前，可以把每周的晚自习计划模板做成配置，通过一个计划生成器批量生成。界面上的操作是“选择开始日期和结束日期 + 选择周几 + 选择区队”，代码后台循环生成 schedule_info。这套代码不复杂，但直接决定了系统能不能真正做到“信息化排计划”而不是每天手工添加。

4. 核心功能实现：签到、请假、统计这三个模块写好了，系统就完成一半

考勤系统的代码量并不大，真正需要用心写的地方集中在签到时间判定、请假审批流和统计查询三个模块。下面我按实际开发顺序把核心逻辑和实现要点完整展开。

4.1 签到接口的判定不能只写“更新 status = 1”

签到接口是整条考勤链路的入口。如果这里不做充分防呆，后面的定时统计大概率会出脏数据。签到接口接收学生 ID、计划 ID 和可选的位置信息。后端代码里我写了这样一段逻辑：

java复制@Override
@Transactional(rollbackFor = Exception.class)
public Result signIn(SignInDTO dto) {
    // 1. 判断计划是否存在并且处于已发布状态
    ScheduleInfo schedule = scheduleInfoMapper.selectById(dto.getScheduleId());
    if (schedule == null || !schedule.getPublishStatus().equals(1)) {
        return Result.error("考勤计划不存在或未发布");
    }

    // 2. 判断该学生是否真的属于这个计划关联的区队
    StudentInfo student = studentInfoMapper.selectById(dto.getStudentId());
    if (!schedule.getClassId().equals(student.getClassId())) {
        return Result.error("当前学生不属于该区队，无法签到");
    }

    // 3. 判断是否已经签过到，防止重复提交
    LambdaQueryWrapper<AttendanceRecord> wrapper = Wrappers.lambdaQuery();
    wrapper.eq(AttendanceRecord::getStudentId, dto.getStudentId());
    wrapper.eq(AttendanceRecord::getScheduleId, schedule.getId());
    AttendanceRecord existRecord = attendanceRecordMapper.selectOne(wrapper);
    if (existRecord != null && existRecord.getSignTime() != null) {
        return Result.error("请勿重复签到");
    }

    // 4. 生成签到时间和业务日期
    LocalDateTime now = LocalDateTime.now();
    LocalDate businessDate = schedule.getScheduleDate();

    if (existRecord == null) {
        existRecord = new AttendanceRecord();
        existRecord.setStudentId(student.getId());
        existRecord.setScheduleId(schedule.getId());
        existRecord.setClassId(student.getClassId());
        existRecord.setBusinessDate(businessDate);
        existRecord.setSignTime(now);
        attendanceRecordMapper.insert(existRecord);
    } else {
        existRecord.setSignTime(now);
        attendanceRecordMapper.updateById(existRecord);
    }
    return Result.success("签到成功", buildSignStatus(schedule, existRecord));
}

走到第 4 步之后，才轮到时间判定。我单独抽了一个方法 buildSignStatus，它只负责根据 startTime 和 signinDeadline 判断当前时间落在哪个区间，并把结果返回给前端展示。这里有个设计原则——接口绝对不要把“迟到”“早退”这些最终状态写死到 sign_time 字段里，只记录客观时间，具体状态由后台统一计算，才能保证规则的灵活性不受历史数据限制。

关于位置信息，很多类似的毕设系统喜欢在上课考勤里做 GPS 定位，但我没把它作为强校验条件。原因是晚自习场景下有相当一部分学生在教室外勤或参加临时任务，一旦定位范围设得太死，反而会产生大量误判。与其在定位问题上跟真实使用场景较劲，不如把定位做成一个可选项，通过页面提示“不在常用范围，记录已标注”，把最终裁决权保留给辅导员。

4.2 请假审批为什么需要双人复核，还要跟计划日期对齐

请假模块如果只做成一个申请表就非常单薄。我这边把流程定义成了“学生提交 -> 区队长确认 -> 辅导员审批”，因为区队长最了解本区队同学的实时动态，能够先筛掉一批不合理的病假、公假申请，减轻辅导员负担。真实业务里，区队长确认往往是在教室当场做的，所以这个环节在移动端体验里应该尽量轻，一个列表页面加两个按钮就够了。

请假申请的数据结构有一个关键点：请假时间是多天范围还是单次晚自习？大多数情况下请病假会覆盖一个整天或连续几天，而一个整天可能包含“第几节晚自习”这种细分时段。为了让统计不产生歧义，我建议请假表存储的是开始时间和结束时间，然后用 SQL 判断重叠区间：

sql复制SELECT COUNT(*) FROM leave_request
WHERE student_id = ?
AND approval_status = 2
AND leave_start_time <= ?  -- 当前考勤计划的结束时间
AND leave_end_time >= ?    -- 当前考勤计划的开始时间

只要满足这个重叠条件，就说明该学生当天在考勤计划覆盖的时间段里存在有效请假，后台在生成考勤状态时就会把该计划对应的 attendance_record 标记为“请假”，而不是“缺勤”。

请假状态我用一个整数 field 去维护：0 待区队长确认、1 区队长已确认待辅导员审批、2 审批通过、3 已驳回。每到新的状态变更，都写一条 leave_log，方便回溯。还有一个小细节：当审批状态变成 2 之后，系统不应该直接改考勤记录，而是把 status 置为待计算，等定时任务统一重新跑一遍该学生的当日考勤。这样做的好处是，如果某学生同时提交了病假，但实际下午又到教室自习且签了到，系统还能以“实际到场为准”给他覆盖成正常考勤。

4.3 统计报表不是简单 count，而是一套自下而上的汇总逻辑

考勤统计这个模块决定月底公示时会不会被学生投诉。我的做法不是直接从考勤记录 count 状态，而是采用分层统计：先按学生、按计划算明细，再按区队、按日期汇总，最后再加权成周报和月报。每层都有专门的方法，SQL 尽量不揉成一团。

举一个最典型的例子：计算某区队某天的出勤率。先要拿到这个区队当天应有的总人数（这里用 class_info 的成员数，去掉那些处于休学等特殊状态的学生），再把当天所有计划下实际缺勤人数和迟到人数筛出，最终从 class_info 维度更新汇总表。如果直接在 attendance_record 表里 count，很容易忽略那些当天根本没有考勤计划的学生，或者漏掉数据未生成的学生，导致出勤率算出来超过 100%。

周报统计出来后，我用 EasyExcel 做了导出功能。导出字段包括业务日期、学号、姓名、区队、应到状态、实到状态、签到时间、签退时间、异常原因、操作人。这里有一个别人没注意到的经验：要在导出方法里配置好列宽和样式，不然 Excel 打开后日期列显示成一串科学计数法数字，观感非常差。

统计展示页面我放了两类图：一类是折线图，展示一个月内每日出勤率变化趋势；另一类是柱状图，按周对比各区队缺勤人次。ECharts 引入方式很简单，把后端返回的 JSON 适配成 xAxis 和 series 需要的数组就可以。后端返回的数据结构不要直接返回嵌套实体，而是 DTO 一层层传出来，例如 AttendanceStatDTO 里面有 bizDate、className、totalCount、actualCount、leaveCount、lateCount 等扁平字段，前端页面直接使用，不容易写错。

5. 代码跑通不等于答辩能过：测试数据和演示脚本要像“故事”一样设计

很多同学把系统开发完，启动成功，截了两张图就觉得稳了。实际上答辩现场的演示环节才是最容易翻车的。最典型的情况是：数据库里一片空白，点开“月度统计”，图表区一根柱子都没有，你只能在台上反复解释“因为还没录测试数据”。老师最不想看到的就是这种空壳演示。所以我在交付前专门花半天时间整理了一批演示数据，并设计了一套演示脚本。

演示数据的原则是要“有故事”。比如一个 40 人的区队，要保证大部分人正常签到，有两三个人迟到，一个人缺勤，一个人请了病假，还有一个人公差。这样从异常明细到统计图表都有内容可看。为了让折线图看起来有起伏，可以生成连续 30 天的数据，其中偶尔几天缺勤率明显偏高，和系统里某一条通报记录形成对应关系。

我通常会准备三个角色账号用于现场演示。第一步用管理员账号登录，进入晚自习计划管理页，点一次“一键生成下周计划”，让页面出现新的考勤安排；第二步切换成学生账号，选择当天计划进行签到，顺手提交一条请假申请；第三步切换到辅导员账号，处理补签申请和请假审批，然后点开这个月的统计页，展示人数、出勤率、异常趋势。这三步串下来，从计划到记录到汇总到审批走了一个完整的闭环，老师在台下看得清晰，也不会中途打断你问“这个功能在哪里”。

除了数据，还要把“全套文案”对应起来。设计文档里至少要包含需求分析、用例图、数据库设计说明、核心流程图、系统测试这几个部分。测试部分不要写“系统运行正常”这种废话，要按模块列测试用例。比如签到模块至少要有“未发布计划时签到”“正常时间签到”“重复签到”“请假后签到”四条用例，每条用例说明输入数据和预期输出，证明你真的知道自己在测什么。把答辩文案和代码结构一一对应，即使代码是不熟悉的源码包，也能在短时间内做到心里有数。

6. 免费领到的源码：从下载到跑通到敢于答辩的完整改造清单

标题里提到“免费领源码”，这确实是毕设圈最常见的获取路径。但可以坦白讲，网上大量同类系统的源码是不带文档说明的，有的数据库脚本是用 5.7 语法写的，有的是基于旧版 JDK 编译的。我领到第一批源码后，也经历过一整晚的报错。这里把最容易被卡住的点列一下，重点看 JDK、MySQL、Maven 这三座大山。

先从 JDK 版本查起。如果源码引入了较新的 Lombok 版本，运行环境要求 JDK8 以上，但很多机器只装了 JRE，或者系统变量 JAVA_HOME 指到老版本。最稳的做法是统一装 JDK8，并在 IDEA 的 Project Structure 里确认 SDK 和 Language Level 都调到 8。其次是 MySQL。脚本导入时如果默认字符集不是 utf8mb4，中文表注释可能出乱码，建议用 Navicat 或命令行执行 source 导入之前，先检查数据库编码。再用 Maven 时，如果长时间卡在下载依赖，基本是仓库源的问题，要么加阿里云镜像，要么检查 Nexus 配置。

把这些环境问题磨过去之后，我强烈建议你改包名——不要小看这一步。网上领来的源码，很多包名都叫 com.example 或者直接是别人机构的缩写，老师一打开 IDEA 就会看到，非常减印象分。改成自己定义的 groupId，比如 com.你的姓名字母考勤编号，重新 Reimport 一次，然后把主启动类上的扫描路径同步改掉。改包名后注意 MyBatis 的 mapper xml 里的 namespace 也要逐文件更新，IDE 的全局替换能解决大部分。

接下来是做“代码审计式阅读”。你有没有真正理解这套源码，最直接的标志是能不能回答这几个问题：登录之后的用户身份存在 session 里还是 token 里？没有数据库文件系统的保存路径配置在哪里？考勤准时判定的时间是服务端系统时间还是前端传过来的？这些信息不一定能在一遍通读里找全，但通过全局搜索 sign_time、schedule、permission 这几个关键词，基本能把主链路串起来。

最后一个环节是改造。我会习惯性给源码加一个新模块，不一定是大功能，哪怕只是在统计页面加一个“导出上月出勤汇总”的按钮，也能让系统跟原始版本拉开差距。这么做一方面防止被老师看出是直接下载的源码，另一方面也让自己真正拥有一段能讲透的代码。答辩现场老师通常会选你代码里某个自认为熟悉的很细的点去问，你如果在原有代码里认真改过两三百行，底气会比对着源码背稿强太多。

就这套公安院校晚自习考勤系统而言，我最后的建议只有一句话：不要满足于“能跑”，试着把整个业务从头串到尾讲一遍。从晚自习计划生成、学生签到、请假审批到月度统计，每一步的数据是怎么变过来的，字段在哪个表里发生变化，都串顺了，哪怕源码是领来的，答辩时也会变成你自己的“设计思路”。毕竟，老师看重的从来不是代码是谁写的，而是这方案放在真实场景里能不能讲出道理。