毕业设计选"考勤系统"，这在很多人眼里可能不够高大上。但说实话，我见过太多选了"高难度系统"结果烂尾的同学，也见过不少用考勤系统这种经典题目稳扎稳打拿到优秀评级的例子。原因很简单：考勤系统的需求非常贴近真实业务，功能边界清晰，既能展示SpringBoot+Vue+MySQL这套主流技术栈的完整闭环，又能轻松拆出足够多的论文素材。你要是正愁选题，或者已经定了这个题目但不知道从哪里下手，这篇文章会把"公司日常考勤系统"从需求分析、数据库设计、后端接口、前端页面，一直聊到论文组织和部署文档怎么写，全程按可落地执行的标准来。
1. 为什么考勤系统是毕业设计的"稳妥型"选题：需求边界与工作量评估
1.1 需求清晰，但又不至于毫无挑战
考勤系统之所以被大量选作毕业设计，核心原因是它的需求足够贴近日常认知。你不用花太多时间向评委解释系统是干什么用的，签到、签退、请假、加班、统计，任何人都能听懂。但"懂"不代表"简单"，关键在于你怎么把这套看似普通的业务做深。
常见的学生版本是：用户能登录、能打卡、能看自己的记录，管理员能看到所有人的记录，完事。这种版本看起来功能齐全，但论文和工作量都薄得像纸片。真正能拿高分的版本，至少要纳入以下几个层次：
- 基础考勤闭环：上下班打卡、补卡申请、管理员审核。
- 请假与加班流程：员工提交申请，部门负责人审批，审批结果反写考勤状态。
- 考勤规则引擎：迟到、早退、缺卡、旷工的判定不应写死在代码里，而是由规则表驱动。
- 统计报表：月度汇总、部门维度对比、异常考勤列表、导出功能。
- 权限体系：至少分出管理员、部门主管、普通员工三种角色。
这样拆下来，功能量大概在10到14个模块左右。对于一个人完成的毕设来说，工作量刚好：不会轻松到没东西写，也不会复杂到三个月做不完。
1.2 一个小型团队的真实考勤场景建模
在设计时，我一直建议把系统想象成"一家30人左右的小型公司"在用的工具。公司有4到5个部门，每个部门有一位主管，公司设一位人事管理员。员工每天早晚各打卡一次，如果忘记打卡，可以在当天发起补卡申请。请假分事假和病假，三天以内主管审批，三天以上需要人事管理员复核。月底人事管理员导出考勤汇总表，用来核算工资。
把场景描述到这个颗粒度，系统的每一个功能都能对上具体的业务角色和业务动作。而且这个场景本身就是论文第一章"研究背景"和第三章"需求分析"的现成素材，你不用凭空编造业务故事，只需要把场景翻译成功能需求即可。
1.3 时间分配建议：别把三个月全砸在编码上
按我的经验，一个人完成这套系统，最合理的时间分配是：前两周做需求分析和数据库设计，中间五到六周做前后端编码，再留两周写论文和画图表，最后一周收拾部署文档和准备答辩。很多同学把时间全花在写代码上，结果论文只能用两个晚上通宵赶出来，这样的论文质量必然拖后腿。毕业设计的评分通常由系统演示和论文各占相当比例，答辩现场半个小时只能看你两三个功能，但论文评委是会拿着逐页翻的。
2. 技术栈选型的底层逻辑：为什么一定是SpringBoot+Vue+MySQL
2.1 这套组合解决了什么问题
在毕业设计层面，技术选型的第一原则不是"新"，而是"稳"。SpringBoot是当前企业级Java后端的事实标准，Vue是前端框架里最容易被初学者上手且文档最全的，MySQL是关系型数据库里在Windows和Linux上部署都毫无压力的。这三者组合起来，既有完整的行业代表性，又有足够多的参考代码和排错资料，哪怕你卡住三天，搜索到的解决方案数量也足以让你脱困。
- SpringBoot负责提供RESTful API，内置Tomcat，打包成JAR直接运行，省去单独配置服务器的麻烦。
- Vue负责前端页面渲染和交互，配合Element UI或者Element Plus组件库，能快速搭建出像模像样的管理界面。
- MySQL负责持久化所有考勤业务数据，用Navicat或MySQL Workbench都能很好地进行可视化管理。
2.2 为什么不建议改用其他方案
我知道有些同学会犹豫：要不要用Spring Cloud？要不要把前端换成React？要不要引入Redis？我的态度很明确：除非你已经对这套技术栈非常熟练，否则一律按"最主流、最简洁"的路线来做。
Spring Cloud对于单体毕设完全是过度设计，光服务注册发现和配置中心就能耗掉你一周的时间；React的学习曲线比Vue陡，而且针对于考勤这类管理系统，Vue的双向绑定和数据响应式特性开发效率更高；Redis在这个项目里只配做缓存，但考勤数据本身实时性要求不高，热点数据压力又小，引入Redis反而让部署文档多出不少篇幅。技术的价值在于解决问题，不在于看起来复杂。评委问"为什么不用XX"时，你回答"当前架构已满足业务要求，引入XX会增加部署和运维成本，且没有解决实际痛点"，这比硬撑着用一堆技术要加分得多。
2.3 前后端分离的项目结构规划
推荐的项目结构是标准的Maven多模块单体应用，实际操作中甚至不需要拆模块，一个SpringBoot工程加一个Vue工程即可：
attendance-system/ ├── backend/ # SpringBoot后端 │ ├── src/main/java/com/company/attendance │ │ ├── controller/ # 接口层 │ │ ├── service/ # 业务层 │ │ ├── mapper/ # MyBatis持久层 │ │ ├── entity/ # 实体类 │ │ ├── config/ # 配置类 │ │ └── common/ # 统一返回、异常处理、工具类 │ └── src/main/resources/ # application.yml, mapper XML ├── frontend/ # Vue前端 │ ├── src/ │ │ ├── api/ # axios请求封装 │ │ ├── views/ # 页面组件 │ │ ├── router/ # 路由配置 │ │ ├── store/ # 状态管理 │ │ └── components/ # 公共组件 └── database/ # SQL脚本前后端分离的好处是，你在论文"系统实现"一章可以自然地分两节来讲，每一节都能写出具体的页面截图和接口调用逻辑，论文篇幅和素材量都会充足很多。
3. 数据库设计：从业务场景到十张核心表的结构推演
3.1 数据库设计的第一性原则：让表结构能直接支撑业务规则
考勤系统的数据库设计，最忌讳的是把所有信息塞进一张大表。比如把用户信息、部门信息、打卡记录全部放在一起，后期统计会写得极其痛苦。我的建议是严格按照业务链路拆表，每条链路对应一个独立的业务对象。
以我自己的实践为例，设计了一共十张表：
| 表名 | 用途 | 核心字段 |
|---|---|---|
| sys_user | 员工账号信息 | id, username, password, real_name, department_id, role_id, phone, email, hire_date, status |
| sys_role | 角色表 | id, role_name, role_code |
| sys_user_role | 用户角色关联 | id, user_id, role_id |
| department | 部门表 | id, dept_name, dept_code, leader_id |
| attendance_rule | 考勤规则表 | id, rule_name, work_start_time, work_end_time, late_minutes, early_minutes, work_days |
| attendance_record | 打卡记录表 | id, user_id, work_date, check_in_time, check_out_time, status, source_type |
| leave_request | 请假申请表 | id, user_id, leave_type, start_time, end_time, reason, status, approver_id, apply_time |
| overtime_request | 加班申请表 | id, user_id, overtime_date, start_time, end_time, reason, status |
| reissue_request | 补卡申请表 | id, user_id, attendance_date, check_type, reason, status, approver_id |
| operation_log | 操作日志表 | id, user_id, operation, method, params, ip, create_time |
3.2 几张关键表的设计细节
先说attendance_record表，这是整个系统的核心。这里有三个容易踩坑的地方。
第一，不要用打卡时间直接存日期，而是拆出work_date和工作时间字段。这样方便按天查询，也方便索引。第二，status字段不要只存一个"正常"，我建议存一个可扩展的状态编码。比如NORMAL、LATE、EARLY_LEAVE、MISSING_CARD、ABSENT，至于具体判定规则由后端根据考勤规则表动态计算，而不是写死在签到接口里。第三，要加source_type字段，用来区分本次打卡记录是IC卡、指纹机还是Web端手动打卡。在企业管理类毕设里，虽然不会真正对接硬件设备，但论文里写"系统为后续接入设备预留了数据源字段"，立刻就显得设计有前瞻性。
再来说attendance_rule表。很多同学忽略这张表，把上下班时间写在代码配置里。这在毕设里是大忌，因为需求分析时你明明写了"不同部门、不同岗位可以有不同的考勤规则"，结果实现的时候写死了，论文前后对不上。规则表的存在，让考勤判定逻辑从"硬编码"变成了"查表计算"，这个设计决策在答辩时很容易被评委认可。
leave_request表则要注意审批状态流转。我推荐状态字段用PENDING、APPROVED、REJECTED、CANCELLED四个值，审批人字段approver_id在员工提交申请时由后端根据部门主管规则自动填充，不要在前端传。如果你想增加亮点，可以再加leave_type，把事假、病假、年假分开统计。
3.3 SQL脚本贡献一段完整的建表参考
这里给出考勤核心表的建表 SQL 片段，方便你直接在项目中复用。实际部署时把十张表全部建好，并插入默认管理员账号和测试部门数据。
CREATE TABLE `attendance_record` ( `id` bigint NOT NULL AUTO_INCREMENT COMMENT '主键', `user_id` bigint NOT NULL COMMENT '用户ID', `work_date` date NOT NULL COMMENT '工作日期', `check_in_time` datetime DEFAULT NULL COMMENT '签到时间', `check_out_time` datetime DEFAULT NULL COMMENT '签退时间', `status` varchar(20) NOT NULL DEFAULT 'NORMAL' COMMENT '考勤状态', `source_type` varchar(20) DEFAULT 'WEB' COMMENT '打卡来源', `remark` varchar(255) DEFAULT NULL COMMENT '备注', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_user_date` (`user_id`, `work_date`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='考勤打卡记录表';这里用user_id + work_date建联合索引非常关键，因为打卡查询和月度汇总几乎都是"谁在哪一天"，或者"谁在哪个月"这种维度的查询。没有这个索引，百万级数据量之后查询会明显变慢。虽然毕设数据量不大，但在论文的性能分析部分，你也可以借这个索引设计写上两句查询优化策略。
4. 后端核心接口实现：签到签退、请假审批与考勤规则计算
4.1 统一定义RESTful接口风格
后端接口建议全部采用/api前缀，返回统一的结果包装结构Result<T>。Result一般包含 code、message、data 三个字段。比如登录成功返回Result.success(token)，业务异常返回Result.error(500, "请假天数不能为负数")。为什么要这么做？因为前端使用 axios 拦截器时，可以统一处理错误码和异常提示，不需要每个页面都写一遍 try-catch，对提升代码整洁度意义很大。
接口清单按照业务模块划分，大致如下：
- 认证模块：POST /api/auth/login，POST /api/auth/logout，GET /api/auth/info
- 考勤打卡模块：POST /api/attendance/check-in，POST /api/attendance/check-out，GET /api/attendance/today，GET /api/attendance/my-records
- 请假模块：POST /api/leave/apply，GET /api/leave/my-list，GET /api/leave/pending，POST /api/leave/approve
- 补卡模块：POST /api/reissue/apply，GET /api/reissue/pending，POST /api/reissue/approve
- 考勤统计模块：GET /api/attendance/summary，GET /api/attendance/department-summary，GET /api/attendance/export
- 系统管理模块：GET /api/user/list，POST /api/user/add，PUT /api/user/update，DELETE /api/user/delete，GET /api/department/list
4.2 签到签退接口的业务逻辑
签到接口是整个系统最核心的代码，复杂度不在接口本身，而在判定规则。一个合格的签到接口逻辑顺序应该是：
- 从当前登录用户获取
userId。 - 查询该员工的考勤规则，也就是从
attendance_rule表取上下班时间。 - 查询当前日期是否已存在打卡记录。
- 如果 exists 且 checkInTime 为 null，则更新签到时间；如果 exists 且 checkInTime 非 null，则更新签退时间。
- 调用考勤状态计算逻辑，根据当前时间和规则重新计算状态。
这里有个细节值得注意：签到和签退建议合并为一个接口，通过"今天的记录状态"来自动判断是签到还是签退。前端页面上表现为同一个打卡按钮，点击后显示"上班打卡成功"或者"下班打卡成功"，用户感知是一致的，但后端逻辑却节省了一个接口。而且这样处理更容易保证同一天只有一个打卡记录。
考勤状态计算逻辑单独抽一个私有方法，比如calculateStatus(AttendanceRecord record, AttendanceRule rule)。它的判定优先级是：
- 如果签到时间为空，可能是缺卡或旷工，视当天是否请假而定。
- 如果签到时间晚于规则中的
work_start_time加late_minutes，判定为LATE。 - 如果签退时间早于
work_end_time减early_minutes，判定为EARLY_LEAVE。 - 如果两个时间都缺失，且无请假记录，判定为
ABSENT。
我把这段逻辑写成工具类而不是揉在Controller里，便于单元测试。毕设里能够提供几个简单的JUnit单元测试，也是论文测试章的加分项。
4.3 请假审批流程的状态机设计
请假审批我建议在LeaveRequestService中维护一个简单的状态机。员工创建请假单时状态为PENDING；主管接口通过approve操作传入PASS或REJECT，同时记录审批人和审批时间。这里需要特别注意：三天以上的请假需要两级审批，于是流程变成"主管审批通过后，如果请假日数大于三天，则状态保持PENDING并自动流转到人事管理员；如果小于等于三天，状态变为APPROVED"。
这个逻辑听起来很简单，但很多同学会把它写成硬编码的 if 嵌套。更好的做法是维护一个APPROVAL_LEVEL字段，在提交请假单时根据请假时长自动计算需要几级审批。这样后续调整审批规则时，不需要改代码，只改配置即可。我这样说可能比较抽象，举个具体的例子：请假日数>= 3时，approvalLevel设为 2，每通过一级审批currentLevel加1，当currentLevel >= approvalLevel时，请假状态最终变为APPROVED。这种设计在答辩时可以向评委展示你对状态流转的理解，而不是单纯地调增删改查接口。
4.4 考勤统计和报表导出
考勤统计是整个系统最容易在答辩时被深挖的部分，因为评委大概率会问："你如何计算一个员工这个月的出勤率？"很多人被问住，就是因为在实现在时候没有认真设计统计接口。
正确做法是编写一个月度汇总查询方法，输入参数是userId和yearMonth，输出结果包含应出勤天数、实际出勤天数、迟到次数、早退次数、旷工天数、请假天数、加班时长。查询逻辑分成两步：第一步查出该员工当月所有attendance_record；第二步依据考勤规则表生成"应出勤"的天数集合，再和实际记录逐一匹配。
导出的功能可以用EasyExcel或者POI实现，导出内容就是这张汇总表。如果时间不够，导出功能可以后置加入，前两天我在做类似项目时，发现导出的实现其实比想象中快，基本就是定义好表头实体类，一行EasyExcel.write(outputStream).sheet("考勤汇总").doWrite(dataList)就完事。但我建议把导出按钮只放在管理和人事管理员页面上，普通员工不开放，这样在论文的角色权限描述里又多一条可以写的细节。
4.5 登录鉴权与密码加密
登录鉴权方面，我不建议使用复杂的Spring Security配置，对于毕设项目来说，手写拦截器加JWT是性价比最高的方案。JWT生成和校验用io.jsonwebtoken库，登录成功后生成token返回前端，前端每次请求在Header里带Authorization: Bearer <token>。后端编写一个AuthInterceptor，使用HandlerInterceptor拦截所有/api/**请求（登录接口除外），解析token并存入ThreadLocal中，供Service层获取当前登录用户。
密码存储一定要用BCrypt加密，千万别明文存。很多同学为了省事直接在数据库里存明文密码，这在论文抽检或者答辩演示时一旦被追问，会显得非常不专业。Spring Security里的BCryptPasswordEncoder可以单拿出来用，不需要引入完整的安全框架，注意加盐和比对逻辑即可。
5. 前端页面与交互：Vue考勤看板的关键实现
5.1 前端工程的初始化与路由设计
前端选用Vue 3 + Vite构建，UI组件库用Element Plus。项目初始化用npm create vite@latest frontend，然后安装vue-router、pinia、axios和element-plus。路由根据自己的角色来控制：普通员工默认跳转到考勤看板页，主管额外看到审批中心，管理员能看到系统管理菜单。
路由设计建议按模块分组，而不是堆一个平铺的列表。这样做的实际好处是，你可以单独为每个路由配置meta，比如meta: { roles: ['admin', 'manager'] }，然后在全局路由守卫里判断当前用户的角色是否在允许列表里。这个设计在论文的"系统安全设计"小节里非常讨喜，评委看到有路由级别的权限控制，会认为你是考虑了细颗粒度权限的。
5.2 考勤打卡页面的交互细节
考勤看板页面是前端最重要的页面。页面主体分为三块：员工信息卡片、一个大号的打卡按钮、近7天的考勤记录列表。打卡按钮的状态根据今日打卡情况分为三种：未签到、已签到未签退、已完成。页面加载时调用/api/attendance/today拿到今日记录，按钮文案和颜色与后端返回的状态对应。
// 打卡提交逻辑 const handleCheck = async () => { const res = await checkAttendance(); if (res.code === 200) { ElMessage.success(res.data.message); todayRecord.value = res.data.record; } else { ElMessage.error(res.message); } };这里我在实际开发中的一个经验是，在打卡成功后不要马上刷新整页，而是只更新局部的打卡时间和状态字段，减少页面闪烁。同时，在页面顶部用一个警告条提示今日考勤异常，比如"今日已迟到，迟到时长12分钟"，让员工进入页面就能感知异常。这个交互细节能在演示时加分，因为评委看到的不是一个只会跳数据列表的系统，而是有业务流程体验的系统。
5.3 管理端页面的布局与权限菜单
管理端布局采用经典侧边栏加顶栏结构。侧边栏菜单根据角色动态渲染，管理员看到全部菜单，主管看到审批中心和部门考勤汇总，普通员工只看到考勤看板、我的考勤、请假申请。在实现上，后端登录接口返回用户信息时同时返回roleCode和一份menuList，前端根据menuList渲染菜单，不需要在本地硬编码角色与菜单的对应关系。这样后端可以随时调整权限配置，前端的改动成本极低。
其中一个页面的表格建议全部加上分页，后端接口返回PageResult结构，包含total、records、current、size。前端用el-pagination组件绑定current和size，每次翻页重新请求接口。分页看似基础，但很多毕设项目都不做，等演示数据积累到一定量级时，页面就会严重卡顿。在论文中，你也可以把分页作为"系统性能优化措施"的一部分来写。
5.4 前后端联调时的跨域与代理陷阱
前后端分离开发时，跨域是最容易碰到的坑。我建议在开发环境下，Vue 项目通过 Vite 的server.proxy配置代理，而不是在后端疯狂写@CrossOrigin。原因是代理的方式更接近生产环境的部署状态，也避免每次都把allowCredentials和allowedOrigins配置得焦头烂额。
// vite.config.js 片段 server: { port: 3000, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }这样前端请求/api/auth/login，开发服务器自动转发到后端地址。到了生产环境，则是用 Nginx 配置同样的转发规则。开发环境用的代理和生产环境用的 Nginx 转发，本质是同一套思路，面试或答辩被问"你懂不懂跨域"时，这个回答路径是比较完整的。
6. 论文结构与部署文档的组织思路：让评委快速看懂你的工作
6.1 论文各章节的写作重点与篇幅配比
论文的结构一般按学校模板来，但内容分配是有策略的。我见过很多人的论文把所有篇幅都堆在"功能编码"上，把需求分析和数据库设计写得像流水账。实际上，答辩评委最关注的是你"为什么这么设计"以及"系统是否满足了需求分析中的全部功能"。
一个稳妥的论文结构比例是：绪论和文献综述占两成，需求分析和可行性分析占两成，总体设计和数据库设计占三成，系统实现（含核心代码和截图）占两成，系统测试和总结占一成。也就是说，不要把核心篇幅放在"抄代码"上，而应放在设计思路的论证上。
在"需求分析"章节，把你选定的业务场景写清楚：有些什么角色、每类角色有哪些操作需求、考勤规则是怎么定义的。建议配一个功能模块图（用Visio或ProcessOn画），以及一张用例图。在"数据库设计"章节，至少画出ER图以及每张表的详细字段说明。这里不要只贴建表SQL，还要为每一张核心表写一段"为什么这么设计"的说明文字。
6.2 部署文档可以当作小型运维手册来写
部署文档不只是简单写"运行 npm run dev"和"运行 java -jar"。一份合格的部署文档应该包含环境准备、后端部署、前端部署、数据库初始化、常见问题排障五大部分。尤其要写清楚JDK版本（推荐JDK 1.8或11）、MySQL版本（推荐5.7或8.0）、Node版本，因为版本不匹配会导致各种奇怪的报错。
我在实际部署中经常遇到的是JDK版本过高导致JWT库和旧版依赖不兼容，或者MySQL 8.0的时区问题导致数据库连接报错。部署文档里把这些坑提前标注，能大幅减少用户提问。数据库初始化部分要写明：先创建数据库，再执行init.sql，同时提示字符集使用utf8mb4，否则中文会乱码。
后端部署有两种方式，方式一是直接java -jar target/attendance-backend.jar；方式二是用mvn package打包后在任意服务器运行。前端部署就简单一点，先npm run build生成dist目录，然后将目录下的文件放到Nginx的html根目录，同时配置反向代理转发/api到后端端口。
6.3 答辩演示的套路：准备一条主线和两条支线
答辩现场的时间有限，演示时建议走一条主线：以人事管理员身份登录，先展示员工管理功能，添加一个测试员工；再切换普通员工登录，演示打卡和提交请假；再切换主管登录，演示审批请假；最后回到管理员登录，查看考勤统计并导出报表。这条主线能把系统80%的功能覆盖到，而且故事连贯，评委看得明白。
准备的支线是"异常处理"和"权限控制"。当评委问到"如果员工忘记打卡怎么办"，你就顺势演示补卡申请流程；当评委问到"普通员工能不能看到别人的考勤数据"，你就顺势聊路由守卫和接口权限。答辩最怕的是评委问到你做过的功能之外的东西，所以把系统里已经实现的细节准备成回答弹药库，远比临场发挥更有把握。
7. 我实际踩过的坑：时区、事务、日期计算与权限泄漏
7.1 时区问题让打卡时间整整差了八个小时
我在第一次联调时，发现打卡记录里存的时间比本地时间快了8小时。排查了半天，发现是MySQL连接串里的serverTimezone=Asia/Shanghai没有配置，而JDBC驱动默认取了系统时区，导致时间偏移。解决办法是在application.yml里显式配置数据库连接的时区参数：
spring: datasource: url: jdbc:mysql://localhost:3306/attendance_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false同时，后端在返回打卡时间给前端时，建议统一在实体类的checkInTime字段上配置@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8")，不然Jackson默认序列化时区也可能出问题。这种问题在答辩前很容易被忽略，一旦现场演示时时间不对，观感会非常尴尬。
7.2 事务注解失效的典型场景
请假审批和补卡审批都涉及多表更新，需要加事务注解。但我踩过一个坑：在同一个类内部，一个方法调用另一个带有@Transactional的方法时，事务实际上是不生效的。因为Spring的事务是通过代理实现的，内部调用走的是原始对象而不是代理对象。解决方案是把这个更新逻辑拆到独立的Service类中，或者在外部调用入口方法上加事务。
我在请假审批接口中，需要同时更新请假单状态、写操作日志、并且可能改写考勤记录状态。这三步必须在一个事务里。如果事务失效，前面两步成功、第三步失败，数据就出现不一致。这个问题在答辩前不容易暴露，但一旦被问到"你如何保证数据一致性"，没有事务支撑的答案会很苍白。
7.3 日期计算里藏着很多边界条件
考勤系统的日期计算比想象中复杂。月度汇总时，要计算"应出勤天数"就得把周末和法定节假日排除。这里我没法引入完整节假日库，所以采用了一个折中方案：在attendance_rule表中维护work_days字段，默认值是"1,2,3,4,5"，代表周一到周五上班。遇到调休或者特殊安排，就在系统中配置一个holiday_config表，手动标记某一天是放假还是补班。
这种方案的逻辑简单，但非常稳。如果你天真地以为用第三方节假日API就能搞定，那在答辩演示当天如果遇到API不可用，整个系统就会陷入瘫痪。毕设系统最重要的是可控，宁可手动维护一份节假日配置，也不要依赖外部服务。我建议在月度汇总时遍历每一天，判断法定节假日的逻辑用配置文件驱动，这样论文里也可以把"节假日管理"作为系统中的一个独立模块来写。
7.4 权限泄漏的高频位置：统计接口和审批列表
权限问题是我最后想强调的。很多同学的考勤系统，做完了角色管理，但接口层的拦截并不严格。比如/api/attendance/summary这个统计接口，如果只是返回所有员工的数据，那么普通员工一旦知道接口地址，就能看到全公司考勤情况。正确的做法是在Service层先获取当前登录用户角色，如果是管理员或主管且有部门权限，才允许执行统计；如果是普通员工，则强制将查询条件限定为userId = 当前用户。
审批接口也有类似的问题：GET /api/leave/pending返回待办列表时，必须按当前审批人的身份过滤，而不是返回所有待审批记录。我见过一个项目，主管登录后能看到本部门所有请假，但也能看到别的部门待审批请假，就是因为查询语句里没有带上审批人条件。这个坑不一定要等系统上线才会发生，答辩现场评委很可能构造一个"越权访问"的测试用例来验证你的系统。提前把这些查询条件写好，是展示你理解权限控制的重要加分项。
从我个人的实践来看，考勤系统这类经典的毕设题目，从来都不是"简单"的代名词。它真正考察的是你对完整业务链路的认识：需求怎么转换为设计、设计怎么转换为代码、代码怎么保证数据的正确与安全。如果你能把这里提到的每一个环节都扎扎实实做出来，哪怕技术本身不是最前沿的，你在答辩时的底气也远高于做一个半吊子的"高复杂度"系统。最后再分享一个小经验：在项目交付前，至少完整地跑通一次从部署到使用的全过程，记录每一步的操作和可能遇到的问题，这些记录最后几乎原封不动就能变成你的部署文档，省下你很多写文档的时间。
