SpringBoot小型企业员工考勤管理系统这个题目很多计算机专业的同学应该不陌生。每年毕设季考勤、请假、排班这类系统都是热门选题原因很简单业务逻辑清晰、功能边界明确、技术栈覆盖全面而且就算以后不写毕设把它改一改拿到小公司做内部工具也完全拿得出手。这篇博文我打算从项目设计的角度完整拆解这套系统的核心思路包括表结构怎么设计、打卡逻辑怎么实现、统计报表怎么处理再把从环境搭建到部署运行的实操过程捋一遍。最后会分享一些我在开发和排查过程中遇到的典型问题特别是SpringBoot版本、依赖冲突、循环依赖这类容易卡住新手的坑。适合正在做毕设、想快速上手SpringBoot完整项目的同学也适合需要给小型团队搭建内部考勤工具的朋友参考。1. 项目定位与核心需求拆解1.1 小型企业考勤管理的真实痛点先说清楚为什么要做这样一个系统。小型企业的考勤管理和大型企业完全不是一回事。大企业有成熟的OA系统有专门的HR部门维护规则有考勤机、钉钉、企业微信这类现成产品。但小型企业情况很特殊——人员规模通常在几十人到一两百人之间既没有预算上昂贵的人力资源系统又觉得用钉钉打卡这种通用方案不够贴合自身管理需求。小型企业的考勤痛点集中在几个方面。第一个痛点是排班灵活。很多小公司不是标准朝九晚六。生产型企业的工人有三班倒餐饮零售行业的门店有早晚班研发型小团队可能实行弹性工作制。这些个性化的排班需求通用考勤软件要么不支持要么配置起来非常繁琐。第二个痛点是审批流程随意。小公司的请假、调休、加班申请经常是口头说一声或者微信发个消息时间一长就说不清了。月底统计考勤的时候人事要在微信聊天记录里翻半天效率极低。第三个痛点是数据统计困难。老板想看这个月谁迟到最多、哪个部门请假天数超标、员工的加班时长怎么计算用Excel表格人工统计一两百人的数据量能把人事累到崩溃。正是这些痛点决定了这套系统的核心定位一个轻量、可定制、能覆盖排班打卡请假统计全流程的Web应用。它不需要像钉钉那样服务几亿用户只需要把一个企业内部的流程走通把数据管好。1.2 毕设项目与企业项目的差异点这个标题里有两个关键词值得注意一是“毕设源码”二是“小型企业员工考勤管理”。这两个词放在一起决定了系统的复杂度定位——它必须比课程作业有深度但又不能做成一个需要多团队协作的超大型系统。毕设场景下评审老师关注的核心点和技术能力展示直接相关。他们不会真的去验证你的系统能不能扛住10万并发但一定会看你的技术栈是否合理、表结构设计是否规范、核心业务逻辑是否严谨、有没有考虑异常情况。从企业实际使用的角度来看这套系统需要覆盖的核心业务链路是管理员配置基础信息部门、员工、考勤规则→ 员工每日打卡 → 系统自动判断考勤状态 → 员工发起请假/加班申请 → 审批人处理 → 月末生成统计报表。这条链路环环相扣把每个环节实现到位整个项目的完整度就很可观了。正因为目标是“既能过毕设又能真实落地”系统在技术选型和功能设计上都不需要追求大而全而是把每一块做扎实。这也符合实际开发的基本原则先解决核心问题再谈锦上添花。1.3 技术选型为什么是SpringBoot现在的Java后端开发说SpringBoot是事实标准一点也不夸张。很多同学刚接触时可能会有疑问Spring MVC用的好好的为什么非要SpringBoot答案在于“约定优于配置”这个设计理念。传统Spring项目光配置文件就要写好几份web.xml、spring-mvc.xml、applicationContext.xml、数据库连接配置……每个配置文件的标签和属性都够背一阵子的。SpringBoot把大量默认配置内嵌进了框架本身开发者只需要关注自定义的业务配置。举一个非常直观的例子。要搭建一个Web项目传统Spring需要配置DispatcherServlet配置包扫描配置视图解析器配置数据库连接池配置事务管理器配置MyBatis SqlSessionFactorySpringBoot只需要引入spring-boot-starter-web依赖然后写一个main方法启动即可。原因是SpringBoot提供了自动装配机制——它在spring.factories配置文件中注册了大量自动配置类启动时会根据classpath下的依赖和配置文件中的属性智能地创建所需的Bean。这套机制对小型企业考勤系统来说特别合适。系统本身模块清晰、业务量不大SpringBoot的轻量特性让开发效率大幅提升同时它内置的Tomcat让部署变得极其简单打成一个jar包就能跑不需要单独安装应用服务器。2. 系统架构与核心功能设计2.1 整体架构分层这套考勤系统的整体架构采用经典的三层结构Controller层负责接收和响应HTTP请求Service层承载业务逻辑Mapper层DAO层与数据库交互。在实际编码时我的建议是再多加一层清晰的实体划分。很多新手项目会把Controller写得很重一堆业务逻辑堆在里面这其实是维护性灾难。更合理的做法是controller包只做参数接收、调用Service、封装返回值service包处理业务规则、事务管理mapper包数据访问配合MyBatis的XML文件或注解entity包数据库表对应的实体类dto包接口传输对象用于接收前端参数或返回前端数据vo包视图对象按需组合数据返回给前端config包配置类如跨域配置、拦截器配置common包通用工具类、统一返回结果、异常处理关于前端和后端是否分离这一点在热搜词里也出现了“springboot vue前后端分离”。我的看法是毕设场景下前后端分离是加分项能让系统架构清晰度更高如果时间紧张用服务端渲染的模板引擎比如Thymeleaf也能达到同样的功能效果。前后端分离的架构下SpringBoot只负责提供RESTful API前端用Vue或React独立开发。这样做的好处是开发职责清晰API接口设计规范后续扩展新功能比如接入小程序非常方便。项目目录结构上会多出一个前端文件夹后端只专注接口。2.2 数据库表结构设计数据库设计是这套系统的地基。我在做这类项目时第一件事不是写代码而是花半天时间把表结构理清楚。表设计不好后面写Service层代码会极度痛苦。考勤系统的核心表结构大致如下员工表employee字段名类型说明idbigint主键emp_novarchar(20)工号唯一namevarchar(50)姓名dept_idbigint所属部门positionvarchar(50)职位phonevarchar(20)手机号hire_datedate入职日期statustinyint状态1在职 0离职员工是考勤的主体一切数据都围绕员工产生。工号建议唯一因为日常打卡、查询都会使用工号作为检索条件。部门表department字段名类型说明idbigint主键namevarchar(50)部门名称manager_idbigint负责人考勤记录表attendance_record字段名类型说明idbigint主键emp_idbigint员工IDwork_datedate工作日期check_in_timedatetime上班打卡时间check_out_timedatetime下班打卡时间statustinyint考勤状态1正常 2迟到 3早退 4缺卡 5请假 6加班这张表是整个系统的数据核心每月数据量随人数线性增长。一百人的企业一个月的记录就是三千条左右完全在MySQL的舒适区内。请假申请表leave_request字段名类型说明idbigint主键emp_idbigint申请人leave_typetinyint请假类型1年假 2事假 3病假 4调休start_timedatetime开始时间end_timedatetime结束时间reasonvarchar(255)请假事由statustinyint审批状态0待审批 1通过 2驳回approver_idbigint审批人排班表schedule字段名类型说明idbigint主键emp_idbigint员工IDwork_datedate排班日期start_timetime上班时间end_timetime下班时间排班表解决的是不同岗位上下班时间不同的问题。如果没有排班表所有员工共享一套考勤规则那弹性工时和三班倒就无从谈起。系统用户表sys_user字段名类型说明idbigint主键usernamevarchar(50)登录名passwordvarchar(100)密码BCrypt加密emp_idbigint关联员工roletinyint角色1管理员 2员工 3审批人用户表独立于员工表是为了避免把登录凭证和员工基础信息混在一起。密码必须加密存储千万不能明文入库。2.3 考勤规则的配置化设计考勤系统里最容易被低估、实际最复杂的模块是考勤规则。很多同学以为考勤规则不就是“9点上班18点下班迟到算迟到”嘛真做起来会发现现实情况远比这复杂。以小型企业为例常见的考勤规则至少包括不同岗位不同班次研发岗10点上班销售岗9点上班弹性打卡早上8:30到9:30之间打卡都不算迟到迟到容忍时间迟到5分钟内不扣款外勤打卡不在公司GPS范围内时允许提交外勤说明加班规则工作日加班、周末加班、节假日加班的计算方式不同好的考勤系统应该把这些规则做成可配置的而不是硬编码在Java代码里。我的做法是设计一张attendance_rule表保存规则名称、规则值和生效状态。比如# 考勤规则配置示例 rule_key: work_start_time, rule_value: 09:00 rule_key: work_end_time, rule_value: 18:00 rule_key: late_tolerance_minutes, rule_value: 5 rule_key: enable_flexible_time, rule_value: true rule_key: flexible_start_time, rule_value: 08:30 rule_key: flexible_end_time, rule_value: 09:30ServiceImpl读取规则配置时用MapString, String集中加载避免每次判断都查一次数据库。规则变化时只需要更新数据库不需要重新发布代码。3. 核心功能实现与实操要点3.1 打卡功能的实现逻辑打卡是整个考勤系统的入口也是逻辑上最容易出bug的地方。一个健壮的打卡接口需要处理好几个边界场景。重复打卡问题。员工可能一天内多次点击打卡按钮。如果第一次打卡记录已经存在第二次打卡应该更新打卡时间还是提示已打卡我的处理方式是区分上班卡和下班卡。上班卡已经打过的再打就走下班卡更新逻辑下班卡也打过的提示“今日打卡已完成”。打卡时间校验。这个校验不能放在前端前端的时间是可以随意修改的必须以后端服务器时间为准。后端接口里获取LocalDateTime.now()作为打卡时间。定位校验。如果要求必须在公司范围内打卡还需要接收前端传来的经纬度计算与公司坐标的距离超过阈值则拒绝打卡或转为外勤待审状态。计算距离可以用Haversine公式核心代码实现起来并不复杂private static final double EARTH_RADIUS 6371.0; public static double getDistance(double lat1, double lng1, double lat2, double lng2) { double radLat1 Math.toRadians(lat1); double radLat2 Math.toRadians(lat2); double a radLat1 - radLat2; double b Math.toRadians(lng1) - Math.toRadians(lng2); double s 2 * Math.asin(Math.sqrt( Math.pow(Math.sin(a / 2), 2) Math.cos(radLat1) * Math.cos(radLat2) * Math.pow(Math.sin(b / 2), 2) )); return s * EARTH_RADIUS * 1000; // 返回米 }打卡成功后系统需要根据排班表中的上班时间自动判断考勤状态。这里有一个值得注意的细节状态判断不能放在打卡时做一旦判断完写死到记录里管理员后续手动修正考勤状态就麻烦了。正确的做法是打卡时只记录打卡时间考勤状态的最终判定在统计时动态计算。3.2 考勤统计与异常处理考勤统计是系统最有价值的功能模块。管理者最关心的问题都集中在这里谁迟到了、谁早退了、谁旷工了、这个月每个人的出勤天数是多少。统计的核心算法是遍历指定时间段内的每一天对每个员工根据排班表和打卡记录判断当天的考勤状态。伪代码如下for each employee in employeeList: for each date in dateRange: schedule getSchedule(employee, date) record getAttendanceRecord(employee, date) if schedule is null: continue // 当天未排班跳过 if record is null and not onLeave(employee, date): markAsAbsent(employee, date) continue if record.checkInTime schedule.startTime tolerance: markAsLate(employee, date) if record.checkOutTime schedule.endTime: markAsEarlyLeave(employee, date) if record.checkInTime ! null and record.checkOutTime ! null: markAsNormal(employee, date)这里涉及一个选择状态判断是写SQL还是写Java。我建议在Java里做。一方面逻辑分支较多SQL难维护另一方面状态判定规则可能会变写在Java里改起来更直接。统计结果需要落到一张单独的attendance_summary表中避免每次查询都重新计算。月末最后一天生成当月汇总记录每个员工的出勤天数、迟到次数、早退次数、请假天数、加班时长。这样管理端的月度报表查询只需要一条简单SQL性能完全没问题。3.3 请假审批流程请假审批是考勤系统里第二个核心业务模块。这里的关键是状态机的设计。一张请假单的状态流转为待审批 → 通过/驳回。撤销操作也要考虑待审批状态下允许申请人撤销已审批的不能撤销。后端实现上审批操作需要注意并发问题。如果申请人和审批人同时操作同一张请假单可能导致状态覆盖错误。解决办法是更新SQL中带上状态条件UPDATE leave_request SET status #{targetStatus}, approver_id #{approverId}, approve_time NOW() WHERE id #{id} AND status 0通过WHERE status 0这个条件只有待审批状态的单子才能被更新影响行数为0时说明已经被处理直接提示用户即可。这种方式比先查再改的编程式事务更高效也避免了分布式锁的复杂度。假期额度控制也是实际业务中需要的。比如年假每人每年有固定天数请假时需要校验剩余额度。这个在Service层处理查询该员工当年的请假记录计算已用天数判断是否超过总额度。额度不足时直接抛出业务异常。4. 项目搭建与运行指南4.1 环境准备版本兼容是关键这套系统推荐的技术环境如下组件推荐版本说明JDK1.8 或 11稳定优先避免用太新的版本SpringBoot2.7.x与JDK 1.8高度兼容Maven3.6依赖管理MySQL5.7 或 8.0推荐8.0性能更好Redis5.0可选用于缓存和持久化会话关于SpringBoot版本最近网上关于“springboot版本太高”的讨论很多。很多同学用SpringBoot 3.x结果发现JDK必须用17以上很多旧版本的第三方依赖兼容不了卡得欲哭无泪。对毕设和中小型项目来说SpringBoot 2.7.18是当前最稳妥的选择支持JDK 1.8生态成熟网上查资料最容易。Maven的镜像配置建议用阿里云镜像否则首次拉取依赖会非常慢。打开settings.xml在mirrors节点加入mirror idaliyunmaven/id mirrorOfcentral/mirrorOf name阿里云公共仓库/name urlhttps://maven.aliyun.com/repository/public/url /mirror4.2 核心配置application.yml 关键配置项目的核心配置文件如下这里面有几个配置项特别容易出错。server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/attendance_system?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue username: root password: 123456 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8 mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.attendance.entity configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImplserverTimezoneAsia/Shanghai这个参数必须要加。MySQL 8.0的驱动和服务器默认时区是美国时区不加这个参数启动项目时大概率报The server time zone value ... is unrecognized的错。map-underscore-to-camel-case设置为true后数据库字段emp_no可以自动映射到实体类的empNo属性不用手写一堆resultMap能省不少事。4.3 从源码到运行完整启动步骤从拿到源码到系统跑起来完整的步骤如下。第一步创建数据库。我用Navicat或命令行执行SQL脚本mysql -u root -p attendance.sqlSQL脚本里包含建库语句、建表语句和基础数据插入语句。建议脚本开头包含DROP DATABASE IF EXISTS防止重复执行时冲突。第二步导入项目到IDE。我习惯用IntelliJ IDEA直接用IDEA打开pom.xml让它自动识别为Maven项目。首次导入会下载大量依赖需要耐心等几分钟。第三步修改配置文件。把application.yml中的数据库账号密码改成自己本地的配置。第四步启动项目。直接运行主类中带SpringBootApplication的main方法。看到控制台出现SpringBoot的启动Banner并且打印出Tomcat started on port(s): 8080说明启动成功。第五步验证接口是否正常。浏览器访问http://localhost:8080/api/health或登录接口返回JSON数据即OK。如果是前后端分离项目还需要启动前端工程。进入前端目录执行npm install npm run serve然后浏览器访问前端地址。4.4 打包部署开发完成后需要把系统打成可执行的jar包。在项目根目录执行mvn clean package -DskipTests打包完成后target目录下会生成attendance-system-0.0.1-SNAPSHOT.jar。这是SpringBoot内嵌Tomcat的可执行jar包部署非常方便java -jar attendance-system-0.0.1-SNAPSHOT.jar --spring.profiles.activeprod生产环境部署时推荐用nohup方式后台运行nohup java -jar attendance-system-0.0.1-SNAPSHOT.jar logs/app.log 21 这样即使关闭终端服务也能持续运行。关于Docker部署热搜词里提到“springboot jdk1.8打包到docker desktop”。这个实践我试过很值得推荐。Dockerfile配置如下FROM openjdk:8-jdk-alpine VOLUME /tmp COPY target/attendance-system-0.0.1-SNAPSHOT.jar app.jar ENV JAVA_OPTS ENTRYPOINT [java,-Djava.security.egdfile:/dev/./urandom,-jar,/app.jar]构建镜像并运行docker build -t attendance-system . docker run -d -p 8080:8080 --name attendance attendance-system使用容器部署的好处是环境一致性避免“在我电脑上能跑在服务器上跑不了”的问题。5. 常见问题与排查技巧实录5.1 SpringBoot版本与依赖冲突这是我遇到最多的一个问题也是热搜词里“springboot版本太高”讨论的核心。一个典型的报错场景是项目用了SpringBoot 3.0以上版本JDK却还是1.8启动时直接报UnsupportedClassVersionError。或者SpringBoot升级后SpringCloud组件不兼容各种NoSuchBeanDefinitionException层出不穷。我的建议非常明确不要做第一个吃螃蟹的人。毕设和中小型项目用成熟稳定的版本组合远比追求新版本重要。SpringBoot 2.7.x配JDK 1.8或11是目前最稳的组合。如果你确实要用SpringBoot 3.x那必须用JDK 17以上并且所有第三方依赖的版本都要相应升级。依赖冲突的排查思路是项目启动报NoSuchMethodError、ClassNotFoundException这类错误时优先怀疑是依赖版本冲突用IDEA的Maven Helper插件查看依赖树找出相互冲突的依赖在pom.xml中用exclusion排除掉多余的版本。5.2 循环依赖问题使用SpringBoot 2.7及以上版本启动时如果出现这样的报错The dependencies of some of the beans in the application context form a cycle说明项目里存在循环依赖A依赖BB又依赖A。比如常见的场景是AttendanceServiceImpl里注入了LeaveServiceImpl而LeaveServiceImpl又注入了AttendanceServiceImpl。SpringBoot 2.6版本之后默认禁止循环依赖这是好事——它逼着你从设计上解决问题。可行的改法有三种重构把公共逻辑抽取到第三个Service中使用Lazy在其中一个注入点加Lazy注解延迟代理的创建通过ApplicationContext获取在真正需要的地方再获取Bean而不是初始化时就注入最推荐的是重构方式。循环依赖本身是设计不够清晰的信号绕开它会让代码更健康。5.3 数据库时区与时间格式问题考勤系统对时间的依赖度极高时区问题处理不好会让整个系统错乱。常见报错是java.sql.SQLException: The server time zone value й׼ʱ is unrecognized or represents more than one time zone.这是MySQL连接URL缺少serverTimezone参数导致的。按照上面4.2中的配置加上serverTimezoneAsia/Shanghai即可。还有个更隐蔽的问题SpringBoot默认的Jackson序列化会把LocalDateTime转成数组格式前端拿到数据后无法直接显示。解决办法有两种在application.yml中加入spring.jackson.date-format配置或者统一在实体类的日期字段上加JsonFormat(pattern yyyy-MM-dd HH:mm:ss)注解。5.4 MyBatis动态SQL与批量操作当需要按条件查询员工打卡记录时动态SQL是MyBatis里最常用的功能。select idselectRecordList parameterTypemap resultTypecom.example.attendance.entity.AttendanceRecord SELECT * FROM attendance_record where if testempId ! null and empId ! AND emp_id #{empId} /if if teststartDate ! null and startDate ! AND work_date gt; #{startDate} /if if testendDate ! null and endDate ! AND work_date lt; #{endDate} /if /where ORDER BY work_date DESC /select这里的where标签会自动处理第一个条件前的AND不用手动拼接。注意和在XML中需要转义为gt;和lt;否则XML解析报错。批量插入打卡记录时用foreach标签效率更高避免N条数据执行N次SQLinsert idbatchInsert parameterTypelist INSERT INTO attendance_record (emp_id, work_date, check_in_time, check_out_time, status) VALUES foreach collectionlist itemitem separator, (#{item.empId}, #{item.workDate}, #{item.checkInTime}, #{item.checkOutTime}, #{item.status}) /foreach /insert5.5 热词联动SpringBoot自动装配原理热搜词里有“springboot自动装配原理”面试官也经常问这个问题在项目答辩时很容易被问到。这块理解到位答辩时能加分不少。SpringBoot自动装配的核心是EnableAutoConfiguration注解。它通过Import(AutoConfigurationImportSelector.class)导入一个选择器这个选择器会读取META-INF/spring.factories文件中配置的所有EnableAutoConfiguration类然后通过ConditionalOnClass、ConditionalOnMissingBean等一系列条件注解按需装配。举个例子当你引入spring-boot-starter-web依赖classpath下有了DispatcherServlet和WebMvcConfigurerSpringBoot就会自动创建DispatcherServletAutoConfiguration相关的Bean。你可以通过配置spring.mvc.*或server.*来自定义行为但完全不用手写配置文件。理解了这个原理你就能明白为什么引入新依赖后通常不需要额外配置也明白了为什么要使用SpringBoot官方推荐的starter因为它们和自动装配机制的配合最成熟。6. 项目扩展与后续优化方向6.1 权限框架的引入当前系统如果直接使用自定义的拦截器做权限控制虽然能满足基本功能但当系统需要更细粒度的权限管理时就会力不从心。引入Spring Security或Apache Shiro可以让权限控制更规范。以Spring Security为例核心配置包括用户认证Authentication、授权Authorization、密码加密推荐使用BCrypt、会话管理。Spring Security的过滤器链机制让它在安全性上非常可靠CSRF防护、Session固定攻击防护都是默认开启的。不过要注意Spring Security的学习曲线较陡如果项目时间紧张保持现有的拦截器方案也完全可以。判断标准是系统是否需要多角色细粒度权限控制。如果只是管理员和普通员工两种角色拦截器也够用。6.2 缓存与性能优化当考勤系统的数据量增长到一定规模后或需要频繁查询部门统计数据时缓存是提升性能的有效手段。可以使用Redis缓存热点数据。比如部门列表、员工列表、考勤规则配置这些数据变化频率极低但查询频率极高非常适合做缓存。一个简单的做法Cacheable(value department, key #id) public Department getById(Long id) { return departmentMapper.selectById(id); }加上EnableCaching注解启用缓存。查询时先查Redis命中直接返回未命中才查MySQL并回填缓存。这能把接口响应时间从几十毫秒降到几毫秒。需要注意的是缓存一致性处理要谨慎。数据更新时要将相关缓存主动失效否则可能造成数据不一致的问题。6.3 小技巧如何把项目讲清楚最后分享一个偏个人经验的小技巧关于项目答辩或展示时如何把系统讲清楚。很多同学做项目很投入但表达时容易陷入细节被问到“系统有什么特色”时反而说不出所以然。我见过太多人答辩时说我们用了SpringBoot、MySQL、Vue然后就没有然后了。这些只是技术名词体现不出你的思考深度。更好的做法是围绕业务亮点来讲。比如可以说“这个系统的核心思考是考勤规则的可配置化。我们团队有多个岗位研发岗和销售岗的上下班时间不同。我通过设计一张排班表和一张规则表把考勤规则从代码中抽离出来管理员可以在页面上灵活配置不用改代码。打卡判断和月末统计都从这两张表读取规则。”这段话既展示了数据库设计能力又体现了业务分析能力和架构思维。比单纯罗列技术栈有用得多。7. 写在最后这套SpringBoot小型企业员工考勤管理系统不只是一个毕设题目更是一个能够真实运行的业务系统。从需求分析、表结构设计到功能实现、部署上线整个链路都走一遍对SpringBoot和Web开发的理解会有质的提升。我在给很多同学和开发者参考这套系统的过程中感受最深的一点是考勤系统的核心难点不在技术而在业务规则的建模。你只有理解了迟到、早退、请假、加班这些概念之间的逻辑关系才能设计出合理的表结构和状态机。技术选型和编码反而是相对简单的部分。如果你正在做类似的系统我的建议是拿到源码后不要急于运行先花几天时间读懂表结构和核心业务流程再动手改起来。把别人的代码变成自己的理解这个学习效果远好于直接复制粘贴跑通一个项目。实际开发、调试和部署过程中遇到什么问题欢迎评论区交流。如果你已经跑通了这套系统可以把它扩展成带加班审批、出差管理的完整企业考勤平台这又是一个很好的进阶方向。