考勤管理系统毕设全攻略：从数据库设计到Spring Boot前后端分离实战

1. 这个毕设题目为什么年年有人选：考勤系统的真实定位

提起员工考勤管理系统，很多人的第一反应是：这不就是老掉牙的管理系统题目吗？确实，在毕设题库里，考勤系统几乎是常青树级别的存在。但换个角度想，正因为每年有大量学生选它，恰恰说明这类题目有足够成熟的参考路径、清晰的评分标准和明确的答辩逻辑，对多数本科阶段的学生来说，是性价比很高的选择。

选这个题目的核心逻辑在于，它具备一个合格毕设需要的三个要素：一是业务场景足够贴近真实，考勤是每个公司都有的场景，评委一听就懂，不需要过多解释业务背景；二是技术链条完整，从前端页面到后端接口、从数据库表设计到权限控制、从增删改查到报表导出，覆盖了Web开发的主流知识点；三是向上扩展空间大，想在答辩时加分，可以加入Redis缓存、Quartz定时任务、EasyExcel导出、WebSocket实时推送等进阶技术，完全取决于个人水平。

不过这里要先泼一盆冷水。考勤系统虽然上手简单，但想拿到高分并没有那么容易。很多人做完一个CRUD版本的考勤系统就去答辩，结果被评委几个问题问住：考勤状态是怎么判定的？迟到和早退的规则在哪里配置？加班工时如何计算？请假流程如何与考勤数据联动？这些问题其实都指向同一个核心——考勤系统的难点不在"增删改查"，而在业务规则的建模。看懂这句话，这篇毕设就已经成功了一半。

2. 需求范围的精准控制：做太多和做太少都是坑

拿到题目之后，最忌讳的事情就是直接打开IDE开始写代码。很多人在这一步就开始跑偏，有的想把考勤系统做成钉钉的简化版，人脸识别、GPS定位、排班管理全都要，结果做到一半发现工作量远超预期；有的则只做了签到签退和后台管理两个页面，答辩时评委随便问一个功能就说没有。这两种极端情况我都见过，前者往往是延期答辩的重灾区，后者则是分数上限被锁死在及格线附近。

2.1 核心功能清单：最小可行范围怎么划

一个能顺利毕业且拿到不错成绩的考勤系统，功能范围大致应该包含以下模块：

• 用户管理：员工账号的增删改查、密码重置、状态启停用
• 部门管理：部门的新增、编辑、删除，以及员工归属部门的维护
• 考勤打卡：员工上下班打卡签到，系统记录打卡时间
• 考勤查询：员工查看自己的考勤记录，管理员查看所有考勤记录
• 考勤统计：按日、月维度统计正常、迟到、早退、缺卡等状态
• 请假管理：员工提交请假申请，管理员或主管进行审批
• 公告管理：管理员发布考勤相关的通知公告
• 系统管理：角色管理、菜单权限、操作日志

这八个模块是我建议的最优范围，再多就会失控，再少就会显得单薄。如果你有多余的精力，或者想冲击优秀论文，可以在考勤统计里加入Excel导出、在打卡逻辑里加入上下班时间可配置、在页面展示上加入ECharts图表，这些都是加分项而不是必需项。

2.2 三种角色的权限边界

权限设计是评委必问的点，也是很多学生做得含糊的地方。一个合格的考勤系统，至少要区分三种角色：

权限这块不建议直接裸写Session判断，那样扩展性太差。我当时用的是Spring Boot + Shiro，也可以选Spring Security，两者都能满足需求。关键在于理解RBAC（基于角色的访问控制）模型：用户关联角色，角色关联权限，通过中间表维护关系。答辩时如果被问为什么要用RBAC，可以回答：直接给用户分配权限在用户量大的时候维护成本高，通过角色作为中间层可以实现权限的复用和动态调整。

3. 技术选型背后的具体考量：不选最火的，选最稳的

技术栈是答辩时评委最先关注的部分。被问到"为什么选这个技术"时，最怕听到的回答是"因为大家都在用"。选型必须有自己的思考逻辑，哪怕这个思考很简单，也比没有强。

3.1 后端和数据库的选择逻辑

网上关于考勤系统的源码，Java系占了绝大多数。这里面有历史原因，也有实际原因——Java生态成熟、招聘需求大、参考资料多。比较主流的组合是Spring Boot + MyBatis Plus + MySQL，我当年做的时候也是这一套。选Spring Boot的理由很直接：简化配置、内置Tomcat、快速启动，和传统SSM相比省掉了大量XML配置，更适合毕设周期。MyBatis Plus相比原生MyBatis，最大的优势是内置了通用的CRUD方法，单表操作基本不需要写SQL，能把时间省在业务逻辑上而不是重复的增删改查。

数据库选MySQL没什么悬念，行业主流、免费、资料多。有一点要特别注意，数据库编码一定要设置成utf8mb4而不是utf8，否则后期存emoji或者特殊符号会报错。虽然考勤系统里未必用得到emoji，但这种细节能体现你的工程素养。

3.2 前端是JSP还是Vue？我的建议

前端选择上，很多毕设题目说明里写的是JSP。JSP的优势是直接与Spring Boot集成，不需要额外构建前端项目，部署起来省事。但JSP在答辨时容易被问"为什么不用前后端分离"，与其被动解释，不如一开始就考虑清楚。

如果你对前端有一定基础，我的建议是采用Vue + Element UI + Axios的轻量级前后端分离架构。这样做有三个好处：一是页面效果明显比JSP好看，评委第一印象好；二是在答辩时可以讲"前后端通过RESTful API交互，后端不关心页面渲染，前端通过Axios请求动态绑定数据"，这段话本身就是亮点；三是这套技术栈在后续找工作时是常态化的技能，做毕设等于提前练手。不过代价是需要额外处理跨域问题，需要在后端写一个CorsConfig配置类，并且打包时需要把前端dist目录放到后端resources下统一部署，这中间的坑我在后面会详细说。

如果前端基础薄弱，JSP也不是不行，但尽量用JSTL + EL表达式渲染数据，避免在JSP里混写大量Java脚本片段。答辩老师看到JSP里一堆<% %>写逻辑的代码，印象分会打折扣。

4. 数据库设计的核心细节：五张核心表的关系与字段

数据库设计是考勤系统的地基，也是答辩时最容易暴露问题的地方。设计得好不好，评委通过看ER图就能判断你的水平。我按当时表结构给大家逐张拆解，直接照着改就能用。

4.1 用户表、部门表、角色表的拆分逻辑

第一张表是用户表（sys_user），核心字段包括id、username（用户名）、password（加密存储）、real_name（真实姓名）、dept_id（所属部门外键）、status（1启用/0禁用）、create_time。这里的关键是password字段永远不要存明文，必须用MD5或者BCrypt加密，答辩时评委大概率会问"密码为什么不能明文存储"，要能把"数据库泄露也无法还原用户密码"这层逻辑讲清楚。

第二张是部门表（sys_dept），字段相对简单：id、name、create_time。需要注意的是，部门表和用户表之间是一对多关系，用户在创建时必须绑定一个部门，考试系统里用户打卡后统计考勤，都依赖部门维度做数据聚合。

第三张是角色表，还要搭配用户-角色关联表。角色表里存admin、manager、employee三种角色编码，关联表里存user_id和role_id的映射关系。这种"多对多通过中间表拆解"的设计思路，也是答辩时的常见问题点。

4.2 考勤记录表和请假表的字段设计

考勤记录表（attendance_record）是整个系统的核心，每一条记录代表员工某一天某个时间点的打卡情况。字段设计如下：

• id：主键自增
• user_id：用户id，外键关联
• attendance_date：考勤日期，格式为yyyy-MM-dd
• sign_in_time：上班打卡时间，datetime
• sign_out_time：下班打卡时间，datetime
• status：考勤状态，用数字枚举存储（0-正常、1-迟到、2-早退、3-缺卡、4-请假、5-出差）

这里有个很多新手会踩的坑：status字段到底怎么算？如果你的设计是打卡时手动选择状态，那这个系统就没有任何价值。正确的做法是，status根据签到时间和系统配置的上下班时间自动判定，比如上午9点上班，员工9点半打卡，系统自动判定为迟到，而不需要人去修改状态。

请假表（leave_request）字段：id、user_id、leave_type（事假/病假/年假/调休）、start_date、end_date、reason、status（0-待审批、1-已通过、2-已驳回）、approve_user_id（审批人）、create_time。请假审批通过后，需要能在考勤查询里看到该员工对应日期的考勤状态为"请假"，这一块涉及两个表的联动，是加分点。

5. 考勤核心逻辑的代码级拆解：打卡、判定、报表

数据库设计好了，接下来最硬核的部分就是核心逻辑的实现。建议先写一个独立的接口，专门负责"判定一条考勤记录的状态"，其他模块都调用这个接口，避免逻辑散落各处。

5.1 签到与退签的接口设计思路

打卡接口不复杂，但有一个细节值得注意。一个员工一天内可能多次打卡，你怎么处理？我的做法是：如果当天没有记录则创建一条，如果再打卡则更新对应的sign_in_time或sign_out_time字段。判定"第二次打卡属于签到还是签退"，可以通过时间来判断，上午12点之前算签到，之后算签退。这个规则虽然简单，但对绝大多数公司场景是够用的。下面是简化版的打卡接口示例：

java复制@PostMapping("/sign")
public Result sign(@RequestParam Long userId) {
    String today = LocalDate.now().toString();
    AttendanceRecord record = attendanceMapper.selectByUserIdAndDate(userId, today);
    LocalTime now = LocalTime.now();
    
    if (record == null) {
        record = new AttendanceRecord();
        record.setUserId(userId);
        record.setAttendanceDate(today);
        // 默认设置上午9点上班、下午6点下班，可在系统配置中修改
        if (now.isBefore(LocalTime.of(12, 0))) {
            record.setSignInTime(LocalDateTime.now());
        } else {
            record.setSignOutTime(LocalDateTime.now());
        }
        attendanceMapper.insert(record);
    } else {
        if (now.isBefore(LocalTime.of(12, 0))) {
            record.setSignInTime(LocalDateTime.now());
        } else {
            record.setSignOutTime(LocalDateTime.now());
        }
        attendanceMapper.updateById(record);
    }
    return Result.success("打卡成功");
}

实际开发中还要考虑重复提交、接口幂等性、异常处理等问题，但对毕设来说，把核心流程跑通是第一位的。

5.2 迟到、早退、缺卡的自动判定策略

考勤状态的判定逻辑可以用一个方法统一处理，输入是考勤记录和系统配置的上下班时间，输出是状态枚举。判定规则如下：

• 签到时间为空且当前时间晚于上班时间：缺卡
• 签到时间晚于上班时间超过设定宽限分钟数：迟到
• 签退时间早于下班时间：早退
• 签到签退均有且不满足迟到早退条件：正常

宽限分钟数这个设计很容易被忽略，但对答辩来说是加分项。现实场景里，员工晚1分钟打卡就判定迟到，显然不合理。所以系统里应该有一个考勤规则的配置表，存上班时间、下班时间、宽限分钟数这几个参数。这样"考勤规则可配置"本身就体现了系统的灵活性和业务思考深度。

5.3 月统计报表与Excel导出实现

月统计是考勤系统里功能量比重比较大的模块，通常要提供一个报表页，展示某员工某个月的应出勤天数、实际出勤天数、迟到次数、早退次数、请假天数。最简单的实现方式是利用SQL的聚合查询：

sql复制SELECT 
    user_id,
    COUNT(*) AS total_days,
    SUM(CASE WHEN status = 0 THEN 1 ELSE 0 END) AS normal_days,
    SUM(CASE WHEN status = 1 THEN 1 ELSE 0 END) AS late_count,
    SUM(CASE WHEN status = 2 THEN 1 ELSE 0 END) AS early_leave_count,
    SUM(CASE WHEN status = 3 THEN 1 ELSE 0 END) AS miss_count
FROM attendance_record
WHERE attendance_date BETWEEN #{startDate} AND #{endDate}
GROUP BY user_id

Excel导出用EasyExcel实现，这是阿里巴巴开源的库，相比POI来说API设计更友好，内存占用也更小。注意一个坑：EasyExcel导出时要注册一个自定义的样式处理器，否则表头字体和列宽会很难看。同时导出操作建议放到一个异步线程里执行，因为数据量大的时候同步导出会卡住页面。

6. 踩坑实录：从前端联调到部署的完整排错链路

这部分内容，是我最想分享给各位的。前面讲的都是"应该怎么做"，但实际开发中"为什么做不出来"往往更让人崩溃。我按时间顺序还原几个印象比较深的坑，以及完整的排查过程。

6.1 前后端分离部署的跨域问题

我用的Vue前端跑在8080端口，Spring Boot后端跑在8081端口，联调时第一个遇到的就是跨域报错。浏览器控制台提示"CORS policy"，怎么解决？

排查思路是：跨域的根源是浏览器同源策略，前后端域名不同，浏览器在发送复杂请求（如POST+JSON）时会先发送一个OPTIONS预检请求，后端必须返回允许跨域的响应头。所以解决方式就是在后端加一个CORS配置类，我当时的做法是：

java复制@Configuration
public class CorsConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOriginPatterns("*")
                .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
                .allowedHeaders("*")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

allowCredentials(true) 意味着允许携带Cookie，但此时allowedOriginPatterns不能写成""，必须使用allowedOriginPatterns("")，这是个很隐蔽的坑，写成allowedOrigins("*")会报错。

6.2 打卡重复提交导致的数据错乱

测试时发现一个诡异的问题：连续快速点击两次打卡按钮，数据库里出现了两条考勤记录。查了半天，发现是前端按钮没有禁用，点击后接口请求还在等待，用户又点了一次，后端并发处理导致两个请求都通过了userId和date的查询，都判断为"当天暂无记录"，于是各自insert了一条。

这个问题的完整链路是：前端防抖缺失 -> 后端查询判断非原子 -> 并发插入产生脏数据。解决方案是双管齐下，前端在请求发出后dis置按钮，后端在查询前加Redis锁，在分布式环境下可以用SETNX命令实现简单的互斥。虽然是毕设，但这个问题解决的过程特别能体现工程思维，后面如果评委问"如何防止重复提交"，这是现成的素材。

6.3 导出Excel内存溢出的排查过程

导出一个月的数据时，导出接口直接报OutOfMemoryError。一开始我以为是Excel数据量太大的问题，后来才发现是数据一次性load到内存导致的。完整链路是这样的：查询所有记录 -> 封装成List