简介：这是一套面向计算机专业本科生及Java全栈初学者的毕业设计级公司日常考勤系统，基于Spring Boot + Vue前后端分离架构，聚焦企业人力资源管理中的考勤数据采集、统计与异常处理等核心场景。资源包共含项目源码、MySQL 5.7数据库脚本、功能说明文档等关键内容，涵盖员工信息管理、打卡记录、考勤报表、缺勤审批等完整业务模块；所有代码经严格调试，支持JDK 1.8、Tomcat 7+及Vue CLI本地运行，开箱即用。压缩包大小为10.2MB，结构清晰，便于理解分层设计与接口对接逻辑。目前已有85人学习下载，适合毕设开发、课程设计或Spring Boot与Vue协同实践参考——读者可直接部署运行、查阅完整业务流程实现、复用数据库建模与RESTful接口设计思路，并基于源码快速扩展请假、排班等进阶功能。
1. 项目缘起：为什么还要自己折腾一个考勤系统？
在IT行业摸爬滚打了十几年，经手过不少内部管理系统，考勤系统算是其中“最不起眼”但又“最要命”的一个。说它不起眼，是因为功能看起来就那么几样：打卡、请假、统计报表。说它要命，是因为一旦出问题，直接影响员工薪资和公司管理秩序，业务部门、财务部门、HR部门能把你电话打爆。市面上的SaaS考勤工具很多，但要么功能臃肿、价格不菲，要么定制化程度低，无法满足一些特定流程（比如复杂的多部门审批、与现有OA的深度集成）。所以，当公司规模发展到一两百人，业务线开始复杂时，很多技术负责人都会考虑：是不是该自己搞一个？
基于SpringBoot和Vue来搭建，就成了一个非常务实的选择。SpringBoot的“约定大于配置”和快速启动能力，能让我们把精力集中在业务逻辑，而不是繁琐的XML配置上。Vue的渐进式框架特性和清晰的组件化思想，则让前端开发变得高效且易于维护，前后端分离的架构也符合现代Web开发的主流。这个“【springboot9132】基于Springboot+vue的公司日常考勤系统”项目，本质上就是一个为解决上述痛点而生的、可落地的全栈解决方案。它不是一个玩具Demo，而是包含了从权限控制、打卡逻辑、复杂审批流到数据可视化的完整生产级应用骨架。接下来，我就结合自己踩过的坑和最佳实践，把这个系统的里里外外拆解清楚。
2. 技术栈选型背后的“生存智慧”
选型不是堆砌时髦技术，而是在满足需求、团队技能和长期维护成本之间找平衡。这个项目选SpringBoot和Vue，背后有很实际的考量。
2.1 后端：为什么是SpringBoot 而不是 Spring Cloud 或更轻量的框架？
首先看版本，项目代号“9132”，我推测是基于SpringBoot 2.x的某个稳定版本（例如2.7.x）。为什么不用最新的SpringBoot 3.x？对于企业内部管理系统，稳定性压倒一切。SpringBoot 2.x经过多年迭代，生态极其成熟，遇到任何问题基本都能在Stack Overflow或中文社区找到答案。而SpringBoot 3.x需要Java 17+，并且一些依赖库的适配可能还不完善，贸然升级可能会在部署时引入不必要的风险。
为什么不直接用更轻量的Netty或Vert.x？考勤系统虽然并发不一定极高（除非上下班瞬间万人同时打卡），但业务逻辑复杂，涉及大量的CRUD、事务管理、规则引擎和集成需求。SpringBoot提供的Spring Data JPA/MyBatis-Plus（持久层）、Spring Security（安全）、Spring Transaction（事务）、Spring Cache（缓存）以及丰富的Starter，能像“瑞士军刀”一样，开箱即用地解决这些问题。自己用轻量框架从头搭建这些轮子，开发周期会成倍增加。
关于SpringBoot的配置，这里有个关键点：配置文件的多环境隔离。很多新手会把application.properties写死，这是大忌。生产环境的数据库密码、Redis地址、文件上传路径怎么能和开发环境一样？标准做法是：
application.yml # 主配置，放通用设置 application-dev.yml # 开发环境配置 application-test.yml # 测试环境配置 application-prod.yml # 生产环境配置（敏感信息可用环境变量或配置中心替换）通过spring.profiles.active=dev来激活特定环境。这才是企业级项目该有的样子。
2.2 前端：为什么是Vue 而不是 React 或 Angular？
Vue对于大多数国内团队来说，学习曲线更平缓，文档和中文社区支持更好。对于像考勤系统这样以表单、表格、操作为主的后台管理系统，Vue的模板语法和响应式系统非常直观，开发效率高。而且，基于Vue的成熟UI库如Element Plus或Ant Design Vue，提供了大量现成的、符合后台管理审美的组件，能节省大量前端开发时间。
这里必须提一下路由（Vue Router）和状态管理（Vuex/Pinia）。考勤系统涉及多个模块（打卡页、审批页、报表页），必须用Vue Router来管理。而像用户登录信息、全局的部门树等数据，就需要用状态管理工具来共享。现在更推荐使用Pinia，它比Vuex更简洁，TypeScript支持更好。一个常见的坑是：在路由切换时，如果使用了<keep-alive>缓存组件，像el-table这类组件内部的状态（如滚动条位置）可能会被错误保留。需要在组件内利用activated和deactivated生命周期钩子，或者在<router-view>上使用include/exclude属性进行精细控制。
2.3 前后端分离架构的关键连接点
前后端分离后，沟通的桥梁就是API。这里有几个核心实践：
- 统一的API响应格式：所有后端接口返回的数据应该包裹在一个标准结构里，例如
{code: 200, data: {...}, message: "success"}。这样前端可以统一拦截处理成功和错误。 - 权限认证与状态保持：考勤系统必须登录。通常采用JWT（JSON Web Token）方案。用户登录后，后端生成一个Token返回给前端，前端将其存储在
localStorage或sessionStorage中，并在后续每次请求的HTTP Header（如Authorization: Bearer <token>）中携带。后端通过一个拦截器（Spring的HandlerInterceptor或Filter）来验证Token的有效性。 - 跨域问题（CORS）：开发时，前端运行在
localhost:8080，后端在localhost:9090，浏览器会因同源策略阻止请求。后端需要在配置中允许前端源的跨域请求。在生产环境，通常通过Nginx反向代理将前后端请求统一到一个域名下，从而避免CORS。
3. 核心业务模块的深度设计与“避坑指南”
一个考勤系统，核心就三大块：人员与权限、考勤规则与打卡、请假审批流程。每一块都有不少细节。
3.1 人员与权限设计：RBAC模型是基础，但远远不够
大多数系统会用基于角色的访问控制（RBAC）。设计用户表、角色表、权限表（或菜单表）、以及它们的关联表。一个用户可以拥有多个角色，一个角色可以拥有多个权限。
但考勤系统的权限特殊在数据权限。例如，部门经理只能查看和审批本部门员工的考勤，HR可以看全公司。这光靠菜单权限控制不了。需要在查询数据时，动态拼接数据过滤条件。比如，在查询打卡记录的SQL或JPA Specification中，自动加上AND department_id IN (用户所属部门及子部门列表)。这个“部门及子部门列表”需要提前计算好，可以缓存在Redis中，避免每次查询都递归查询数据库。
踩坑记录：权限缓存的失效我们曾将用户的权限列表缓存在Redis，设置1小时过期。但当管理员在后台修改了用户角色后，该用户可能在一小时内仍然拥有旧权限。解决方案是：在修改用户-角色关系后，主动清除对应用户的权限缓存。更精细的做法是，将权限缓存Key设计为user:perms:{userId}，修改后直接DEL掉这个Key。
3.2 考勤规则与打卡逻辑：远比“记录时间”复杂
这是业务逻辑最重的地方。
3.2.1 规则配置化千万不要把上下班时间、迟到早退分钟数、是否弹性打卡等规则硬编码在代码里。应该设计一套规则配置表，允许HR在后台进行配置。例如：
考勤组表：将具有相同考勤规则的员工归类（如“技术部-标准工时”、“销售部-弹性工时”）。班次表：定义一天的工作时段，如“9:00-18:00”（中间可能包含午休时间）。特殊日期表：定义节假日、调休日等。
3.2.2 打卡事件的生成与计算打卡动作产生一条原始的打卡记录，包含用户ID、打卡设备/位置（可选）、打卡时间戳。核心难点在于，如何将一堆离散的打卡点，计算成每天的考勤结果（是否正常、迟到、早退、缺卡等）。
- 配对上下班打卡：对于标准班次，需要从一个人一天的所有打卡记录中，找出最可能的一次“上班打卡”和一次“下班打卡”。算法不能简单取最早和最晚，因为可能有多次进出。一个稳健的策略是：在班次规定的上班时间前后一段时间窗口内（如前后1小时），取最早的一次作为上班打卡；在下班时间窗口内，取最晚的一次作为下班打卡。
- 状态判定：对比配对后的实际上班打卡时间与规定上班时间，得出是否迟到及迟到时长。下班同理。如果缺少上班或下班打卡，则标记为“缺卡”。
- 处理异常：如何处理外勤打卡？如何处理补卡申请？这些都需要有对应的流程和状态字段来标识。例如，一条打卡记录可能关联一个“补卡审批单”，只有当审批通过后，这条记录才参与考勤计算。
一个真实踩过的坑：时区与夏令时我们的服务器部署在UTC时区，而员工在中国。如果直接存储new Date()生成的Timestamp，就会是UTC时间。前端显示时需要转换，计算当天考勤时，更需要将打卡时间转换为当地的日期。必须在存储打卡时间时，就明确时区信息，或者统一存储为UTC时间，在所有业务计算和显示时，都显式地指定时区进行转换。否则，在跨时区部署或遇到夏令时切换时，会出现日期错乱的灵异事件。建议在数据库中使用TIMESTAMP WITH TIME ZONE类型（如果数据库支持），或者在Java代码中使用Instant或ZonedDateTime。
3.3 请假审批流程：状态机与消息通知
请假、加班、出差、补卡，都需要审批。这是一个典型的工作流场景。对于中小型系统，不需要引入复杂的Activiti、Flowable等引擎，用一个状态机就能搞定。
设计一张审批单表，核心字段包括：申请人、审批类型（请假）、审批状态（草稿、审批中、已通过、已拒绝、已取消）、当前审批人、审批流定义（例如，[“部门经理”, “HR”]）。
状态流转设计：
- 提交申请：状态从“草稿”变为“审批中”，根据审批流，将“当前审批人”设为第一个审批人（如部门经理）。
- 审批人操作：审批人通过或拒绝。如果通过，且后面还有审批人，则“当前审批人”指向下一个；如果是最后一个审批人通过，则状态变为“已通过”。如果任何一人拒绝，状态直接变为“已拒绝”。
- 消息通知：每一个状态变更，都需要通知相关人员。可以通过集成企业微信、钉钉的API发送工作通知，或者系统内站内信。这里的关键是异步和解耦。不要在主业务逻辑里同步调用消息发送API，万一第三方服务超时或失败，会影响主流程。应该将“发送通知”作为一个事件发布出去，由专门的异步任务监听并处理。Spring的
ApplicationEventPublisher就很好用。
关于SpringBoot整合ActiveMQ：如果公司内部有消息队列，可以用它来做这种异步通知的中间件，可靠性更高。但对于大部分场景，用Spring自带的@Async注解配合线程池，或者使用内存事件总线，就足够了。引入ActiveMQ会增加运维复杂度，需要权衡。
4. 前后端具体实现与性能优化要点
4.1 后端API设计：Restful风格与分页查询
考勤系统的API主要是对各类“单”和“记录”的增删改查。遵循Restful风格能让API更清晰：
GET /api/attendance-records：获取打卡记录列表（带分页、筛选）GET /api/attendance-records/{id}：获取单条记录POST /api/leave-requests：提交请假申请PUT /api/leave-requests/{id}/approve：审批请假单（这是一种RPC风格的端点，在纯Restful里可能有争议，但实践中很直观）
分页查询是标配。使用Spring Data JPA，可以非常方便地实现：
@GetMapping("/api/attendance-records") public Page<AttendanceRecordDTO> getRecords( @RequestParam int page, @RequestParam int size, @RequestParam(required = false) Long userId, @RequestParam(required = false) @DateTimeFormat(iso = DateTimeFormat.ISO.DATE) LocalDate startDate, @RequestParam(required = false) @DateTimeFormat(iso = DateTimeFormat.ISO.DATE) LocalDate endDate) { // 构建查询条件 Specification<AttendanceRecord> spec = ...; // 分页查询 Page<AttendanceRecord> pageResult = attendanceRecordRepository.findAll(spec, PageRequest.of(page-1, size)); // 转换为DTO并返回 return pageResult.map(converter::toDTO); }注意：Page对象通常从0开始，但前端传参习惯从1开始，需要做减1转换。
4.2 前端页面组件化：以打卡日历和统计报表为例
前端使用Vue + Element Plus，核心在于组件化。
打卡日历：可以使用像el-calendar这样的组件，但需要自定义内容。思路是：获取一个月的考勤结果数据，然后遍历日历的每一天，根据该天的考勤状态（正常、迟到、缺勤、休假）渲染不同的颜色或图标。这里涉及到Vue组件的数据传递和计算属性灵活运用。
统计报表：这是前端比较耗性能的地方。当HR查看部门月度考勤汇总时，后端可能返回成千上万条数据。前端渲染表格和图表时，必须做虚拟滚动或分页加载。对于ECharts图表，如果数据点过多，可以考虑让后端先做聚合（如按日统计迟到人数），前端只渲染聚合后的结果。
关于Vue播放M3U8：这个需求可能出现在一些扩展场景，比如打卡时同步上传抓拍图片或短视频（用于验证）。如果确实需要在前端播放视频，可以使用video.js配合videojs-contrib-hls插件来播放M3U8格式的流。不过，这通常涉及更复杂的视频服务器架构，对于纯考勤系统不是必须的。
4.3 文件上传与下载：SpringBoot的资源处理
考勤系统可能需要上传附件，如病假证明、出差凭证等。
上传：SpringBoot通过MultipartFile接口处理上传。需要注意：
- 限制文件大小：
spring.servlet.multipart.max-file-size和max-request-size。 - 防止恶意文件：检查文件后缀和MIME类型。
- 存储路径：不要存储在应用服务器内部（如
/tmp），一旦重启可能丢失。应该存储到专用的文件服务器或对象存储（如阿里云OSS、MinIO），或者至少是一个稳定的网络挂载盘。在数据库中只存储文件的访问路径或URL。
下载与大文件处理：对于下载考勤报表（如导出的Excel），如果数据量巨大，生成文件可能很慢。不能让用户请求一直等待。应该采用异步导出模式：用户点击导出后，后端生成一个导出任务放入队列，立即返回一个任务ID。前端轮询任务状态，当任务完成（文件生成好）后，再返回一个可下载的链接。对于文件下载本身，SpringBoot可以通过ResourceHttpMessageHandler自动处理静态资源映射，也可以通过ResponseEntity<Resource>手动控制输出流，对于大文件，务必使用StreamingResponseBody进行流式输出，避免将整个文件加载到内存。
5. 安全、部署与监控：让系统稳定运行
5.1 安全防护：不止于登录
- SQL注入与XSS：使用MyBatis-Plus或JPA等ORM框架，基本可以避免手写SQL导致的注入。对于XSS，前端框架如Vue默认会对渲染的数据进行转义。但对于富文本内容（如审批意见），需要在后端入库前进行HTML标签过滤或使用安全的HTML解析库。提到的“springboot解决pdf xss攻击”，可能是指处理用户上传的PDF文件中的恶意脚本，这需要专门的PDF解析和安全沙箱技术，一般考勤系统不涉及。
- CSRF：如果使用JWT且API是无状态的，CSRF风险较低，因为攻击者无法轻易伪造请求头中的Authorization Token。但如果使用Cookie-Session模式，则必须配置CSRF保护。
- 数据脱敏：在日志或某些查询接口中，员工的身份证号、手机号等敏感信息需要脱敏显示。
- 权限验证：每个API接口必须在进入业务逻辑前，验证当前用户是否有权访问该资源。可以使用Spring Security的
@PreAuthorize注解或在拦截器中实现。
5.2 部署实践：从IDE到服务器
开发环境：用IDEA或Eclipse直接运行SpringBoot应用没问题。但注意，如果Eclipse创建SpringBoot项目时没有3.4.3选项，可能是STS插件版本问题，手动修改pom.xml里的版本号即可。
生产环境：
- 打包：使用
mvn clean package生成可执行的JAR文件（内嵌Tomcat）。对于更复杂的部署，可以考虑打WAR包部署到外置Tomcat。 - Docker部署：这是目前的主流。编写一个简单的Dockerfile，基于OpenJDK镜像，将JAR包复制进去，以
java -jar命令启动。配合Docker Compose可以轻松管理应用、MySQL、Redis等服务。 - Linux服务器：在Linux上运行SpringBoot应用，建议使用
systemd或supervisord来管理进程，实现开机自启、故障重启。记得配置好JVM内存参数（-Xms,-Xmx）。 - 控制台乱码：如果发现Linux服务器上运行日志乱码，通常是服务器终端编码与JVM默认编码不一致导致。可以在启动脚本中指定
-Dfile.encoding=UTF-8。
5.3 日志、监控与排查
没有监控的系统就是在裸奔。
- 日志：使用SLF4J + Logback，合理配置日志级别（INFO, ERROR），将日志输出到文件，并按日期或大小滚动。关键业务操作（如打卡、审批通过）必须记录操作日志。
- 健康检查：SpringBoot Actuator提供了
/health,/metrics等端点，可以集成到公司的监控平台。 - APM工具：对于性能问题，可以接入SkyWalking、Pinpoint等工具，追踪慢SQL、慢API，快速定位瓶颈。
6. 从项目骨架到业务深化：可能的扩展方向
一个基础的考勤系统跑起来后，还可以根据业务需要深化：
- 集成第三方身份认证：与企业微信、钉钉打通，实现扫码登录、接收审批通知、甚至直接从组织架构同步部门和员工信息。
- 智能化考勤：结合IP地址、Wi-Fi定位或GPS（移动端）进行打卡位置校验，防止代打卡。
- 复杂的排班与调休：支持按周、按月、按年的循环排班，处理调休、年假自动计算等。
- 薪资计算集成：将考勤结果（迟到、缺勤、加班）数据对接给薪资计算模块。
- 数据可视化大屏：为管理层提供实时在岗人数、部门出勤率等数据可视化图表。
这个基于SpringBoot和Vue的考勤系统项目，提供了一个坚实且灵活的基础。它最大的价值不在于代码本身，而在于展示了一套如何用主流、稳健的技术栈，去解决一个真实、复杂的业务问题的完整方法论。从数据库设计到API契约，从权限模型到状态流转，每一个环节的思考与权衡，才是真正值得借鉴的地方。在实际开发中，最花时间的往往不是编码，而是和产品经理、HR反复确认那些隐藏在“打卡”两个字背后的、千奇百怪的业务规则。把这些规则设计成可配置、可扩展的模型，是系统能否长期存活的关键。
本文还有配套的精品资源，点击获取
