做企业考勤管理系统这个题目，很多Java学习者第一反应就是“无非一套CRUD”。但真正把考勤业务跑通之后，你会发现它跟普通的增删改查完全是两码事：考勤涉及排班规则、迟到早退判定、加班时长计算、请假调休抵扣，还有月底的统计报表，每个环节都有边界条件。这篇文章我以最近落地的这套基于javaweb+mysql的springboot企业考勤管理系统为例，把核心设计、数据库表结构、业务规则、前端交互和踩坑记录一次性讲清楚。项目核心栈是java+springboot+layui+jsp+bootstrap+mysql+maven，适合正在做课设、毕设，或者刚入职想拿真实业务练手的朋友参考。
这套系统解决了企业中一个很现实的问题：行政手工统计考勤不仅效率低，还容易漏算迟到和加班。系统上线后，员工自助打卡、主管在线审批请假、人事月底一键导出统计表，整个流程从一天压缩到十几分钟。下面我按实际开发顺序，从技术选型讲到部署碰壁，把能复用的经验都摊开说。
1. 项目总体设计与技术选型思路
1.1 为什么选springboot而不是传统SSH/SSM
如果是在五年前，这种系统可能还在用SSH（Struts+Spring+Hibernate）或者SSM（Spring+SpringMVC+MyBatis）手动配一堆XML。但现在做新的企业管理项目，springboot几乎是默认选项。核心原因是它把配置简化到了最低限度：内嵌tomcat、自动装配、starter依赖，一个main方法就能起服务。对于考勤系统这种业务逻辑复杂但技术栈常规的项目，springboot能把开发精力集中在考勤规则上，而不是浪费在环境搭建里。
用maven管理依赖也是一个顺势的选择。springboot父工程统一锁定了各依赖版本，引入group id和artifact id就能用，不需要自己操心版本冲突。我举例说明：一个基础web项目需要spring-boot-starter-web、mybatis-plus-boot-starter、mysql-connector-java、lombok，这些在pom里加起来不超过十行。相比以前SSM要手动引十几个jar包还担心版本不兼容，maven的依赖仲裁机制确实省心。第一次跑springboot项目时，我建议直接把spring-boot-maven-plugin加上，这样打jar包和本地启动都走同一套命令。
1.2 前端三层结构：jsp、layui、bootstrap各自扮演的角色
这套系统的前端结构容易被初学者弄混，jsp、layui、bootstrap同时出现，但它们的职责完全不同。jsp是服务端模板引擎，负责动态渲染页面骨架，有点像一个“带逻辑的html”，可以在里面写Java代码、EL表达式、JSTL标签，输出当前登录用户、下拉框数据等。layui是一套模块化前端框架，提供表格、表单、弹层、日期选择这些现成组件，我主要用它做后台管理界面的数据表格和操作按钮。bootstrap则负责响应式栅格布局和基础样式，让页面在不同分辨率下不至于乱掉。
这三种技术搭配起来有一个现实原因：jsp能直接在页面里使用session和request对象，做权限控制的isAdmin判断非常直接。layui的table组件渲染动态数据时支持url自动请求后端接口，配合springboot的restful接口，前后端数据交互非常顺畅。bootstrap补足了layui在某些布局场景下的不足，比如登录页、导航栏、卡片布局这些地方，bootstrap的栅格系统比layui自带布局更灵活。我实测下来的感受是，layui做后台表格效率很高，bootstrap做营销页和复杂布局更顺手，两者共存并不冲突，关键是约定好哪些模块用谁。
2. 数据库设计与核心表结构
2.1 考勤业务的数据模型拆解
数据库设计是这套系统的地基。我刚做第一版时直接建了一张打卡记录表，把员工id、打卡时间、打卡类型都塞进去，结果后来加请假、加班、调休时发现完全没法扩展。复盘之后重新梳理，考勤系统至少需要六类核心表：员工表、部门表、考勤记录表、请假申请表、加班申请表、考勤规则配置表。员工表关联部门，考勤记录表关联员工，请假和加班表又各自关联审批状态。这样才能支撑“员工打卡—比对规则—生成异常记录—主管审批—月底汇总”这条完整链路。
这里一个容易忽略的点是考勤规则配置表。很多demo项目把上下班时间写死在代码里，但真实企业会有不同班次：行政岗朝九晚六、生产岗两班倒、销售岗不用打卡。我把规则表设计成可配置项，包括上班时间、下班时间、最晚上班时间（超过就算迟到）、最早下班时间（提前就算早退）、是否弹性打卡等。这样不同部门绑定不同规则，月末统计时按规则逐条比对，而不是全公司套一个模板。
2.2 关键表设计细节与字段说明
员工表是基础，字段不需要太多，但有几个必须想清楚。employee_id作为主键，我建议用业务工号而不是自增id，因为考勤关联、导出报表时工号比自增id更有辨识度。department_id关联部门表，存储冗余的部门名称也可以，但需要确认部门改名时同步更新。入职时间、转正时间、离职状态这几个字段对考勤统计很重要，离职员工的历史考勤仍然要保留，所以要加del_flag逻辑删除标记，不能物理删除。
考勤记录表是核心业务表，字段设计直接影响统计效率。我采用的字段是：attendance_id、employee_id、attendance_date、on_duty_time、off_duty_time、status、work_duration。status字段用枚举值表示正常、迟到、早退、旷工、请假、加班等状态。这里有个经验：不要把打卡设备和业务表直接对接，打卡机上报的只是一个时间戳，是否迟到早退必须在服务端用规则计算得出，不要在插入时就算好，因为规则可能调整，历史数据的判定逻辑可能变化。
请假表和加班表结构类似，都包含申请人工号、开始时间、结束时间、时长（按小时或天）、事由、审批状态、审批人备注。审批状态常用枚举0待审批、1通过、2拒绝、3撤销。这里我建议把审批状态和审批完成时间分开，方便统计各审批环节耗时。考勤规则表则用rule_name标识班次名称，work_start_time和work_end_time存上下班时间，late_threshold存迟到宽容分钟数，flexible_flag存是否弹性打卡。
3. 认证授权与登录会话实现
3.1 登录拦截与角色权限控制
考勤系统必须有清晰的权限边界：员工能打卡、查看自己考勤、发起请假申请；部门主管能审批下属申请、查看本部门考勤；人事管理员能查看全员考勤、调整规则、导出表格。我落地时用了springboot的拦截器（HandlerInterceptor），自定义了LoginInterceptor和AuthInterceptor两层。LoginInterceptor拦截所有未被放行的路径，检查session里有没有currentUser，没有就重定向到登录页。AuthInterceptor在LoginInterceptor之后，匹配路径和角色集合，比如/api/attendance/approve/开头的路径只放行role=manager或role=admin。
实现时有个细节值得单独说：拦截器里判断权限不要用字符串拼接权限名，而是用角色编码加接口映射。我踩过的一个坑是某个审批接口没有加到拦截器放行列表里，导致主管点“通过”按钮永远返回401，排查了半天才发现是规则匹配顺序问题。我的做法是把所有接口路径在配置类里集中定义，用集合维护匿名接口和需管理权限接口，并加上注释，后续维护方便很多。
3.2 密码存储与会话管理
网上很多教学项目直接把密码明文存mysql，这在企业环境是绝对不允许的。我用的是bcrypt加密，spring-security-crypto包里有现成的BCryptPasswordEncoder，不需要引入整套spring security。注册用户时把明文密码编码后存入数据库，登录时用matches方法校验。BCrypt的好处是每次加密结果都不同，即使两个用户密码相同，密文也不一样，加上自带盐值，暴力破解成本高很多。bcrypt输出长度固定60字符，数据库字段长度一定要设为varchar(64)，别用默认的varchar(20)。
会话管理方面，我没有用spring session + redis，因为这是一个中小型系统，单机tomcat的session完全足够。登录成功后把用户id、工号、角色存进session，同时设置session超时时间为30分钟。这里要注意，用户如果用了“记住我”功能，不能只延长session超时，还要生成一个随机token存数据库，并在每次请求时校验。我的实现是在登录接口里判断rememberMe，如果是true就生成uuid作为token，存入user_token表，写入cookie，拦截器里优先从cookie取token查用户。这样浏览器关闭后cookie仍然有效，但token有过期时间，安全性和体验能兼顾。
4. 核心考勤功能实现与业务规则
4.1 打卡签到签退的完整流程
打卡功能看起来就是插入一条记录，但完整流程需要经过三个步骤。页面加载时先从考勤规则配置表读取当前员工的班次，判断当前时间是否在可打卡范围内；用户点击打卡按钮，请求后端接口，后端没有直接写记录，而是先做重复打卡校验，防止同一时间段重复提交；校验通过后，把打卡时间写入考勤记录表，并立即计算当前状态返回给前端显示。
签到和签退在逻辑上要区分开。我用的方式是，当天的考勤记录先查询是否存在，如果存在且on_duty_time为空，就写入上班时间；如果on_duty_time已有值且off_duty_time为空，就写入下班时间；两个都有值，则提示“今日打卡已完成”。这里不能用默认状态区分是否完成，因为可能存在忘签到直接签退、然后补签到的情况。我加了一个attendance_status字段，用2表示缺签到但已完成签退，这个状态在月底统计时需要特殊处理。
4.2 请假、加班与外勤等异常考勤处理
请假处理虽然说简单，但规则能绕到新手怀疑人生。员工提交请假申请后，我的实现是先查员工剩余年假和调休小时数，如果请假类型是年假，则从剩余天数中扣除并由主管审批；审批通过后，系统自动生成一条考勤记录，状态为请假，起止时间对应申请的日期，同时占用当天的工作时长统计。这里有一个容易踩的坑：跨天的请假必须拆分成两条记录，比如请假时间是前一天晚上到第二天早上，如果存成一条，考勤统计时会发现这一天既有上班打卡又有请假，冲突。
加班时长计算要结合打卡时间。标准规则是：未请假且下班时间晚于18点，以18点为基准，每满30分钟算0.5小时加班；超过22点需要向主管发送特殊审批提示。我实现时用工作时间整数分钟数除以30取整，不满30分钟的部分丢弃，这样避免人为拖延时间虚报。外勤情况我只记录外勤开始时间和结束时间，不参与电脑考勤判断，但月底会汇总成一张外勤明细表。
4.3 考勤统计报表的SQL编写思路
月底统计是所有功能的汇总之所，SQL写得好不好直接决定报表准不准。我这里分享一条统计每日出勤的经典SQL思路：以employee表为主表，left join考勤记录表，按日期过滤，然后利用case when表达式判断状态。比如统计迟到情况：当上班时间大于规则中的最晚上班时间且状态不是请假时，判定迟到。这条SQL如果写在一个mapper接口方法里，参数传月份起始日期和结束日期，就能查出该月每天的考勤明细。
再往下是月汇总，我的做法是先按员工id和月份分组，用count和sum函数汇总出勤天数、迟到次数、早退次数、请假天数、加班总时数。这里一个关键细节是：汇总SQL不应该把每个员工的所有状态当成独立行group by，而是先过滤状态再聚合。通常我会写一个子查询，先查出每个员工每天的“日汇总”，再在外层按月份聚合。原因是日汇总里可能需要多个字段做条件判断，直接在月汇总SQL里写case when会让SQL乱到无法维护。还有，人事导出报表时通常需要部门名称，所以SQL里要join部门表，而不是在Java代码里二次查询。
5. 前端页面组织与交互细节
5.1 layui表格组件在考勤明细中的使用
后台管理页面最核心的模块是考勤明细列表。我用layui的table.render方法，配置url指向后端接口，cols定义列，pagination开启分页。这个方法最大的优点是不用手动拼接html，表格加载、排序、分页都由layui封装好了。需要特别注意一个参数：parseData可以自定义返回格式，后端返回的数据如果不是layui默认的{code:0,msg:'',count:xxx,data:xxx}结构，服务端必须按这个格式封装，否则表格永远显示“加载数据失败”。我在这里吃过一次亏，因为同事把code返回为200，layui默认只有code为0才认为成功。
表格操作列里我放了“审批”“详情”“编辑”三个按钮。通过templet函数自定义列模板，按钮的data-id取当前行数据。点击按钮时用layer.open弹出iframe层，iframe内部加载标准化表单页面，提交之后调用父页面的table.reload刷新列表。这个模式在处理请假审批时非常顺手。layui的日期组件laydate也值得单独提一下，考勤查询页需要按日期范围过滤，用laydate的range:true就能一次性选起止日期，比手动填两个input再加校验靠谱得多。
5.2 基于bootstrap的响应式布局与弹窗交互
登录页、个人信息页、封装好的弹窗我用的bootstrap。登录页设计为左右两栏：左边是产品介绍和slogan，右边是登录表单。bootstrap的栅格系统让两栏在大屏幕下宽度比12：4，在小屏幕下自动堆叠，避免移动端看到一长串表单。登录按钮我用了bootstrap的btn-primary样式，配合自定义验证码功能，布局很稳。这里有一个细节：bootstrap默认的form-control样式跟layui的表单样式有细微冲突，主要是在边框颜色上，需要在全局css里统一覆盖，不然页面看起来会有些别扭。
弹窗交互上，bootstrap的modal组件在做“编辑考勤规则”时很实用。直接在当前页面弹窗修改，不需要跳转iframe。但modal内容里如果嵌入日期选择器，要手动调整z-index，不然日期弹层会被modal遮罩挡住。这也是我踩过的坑，最常见的现象就是点开日期控件，显示在弹窗背后，怎么也点不到。
6. 部署打包与常见问题排查
6.1 Maven多环境打包与配置分离
考勤系统最终要部署到服务器，全用开发环境配置跑生产肯定不行。我在项目中配置了多环境profile：application-dev.yml、application-prod.yml。dev环境连本地mysql，prod环境连云数据库。用spring-boot-maven-plugin打包时，通过命令行参数指定profile，例如mvn clean package -Pdev，就能把对应的yml打进jar包。这里有一个容易踩的坑：springboot的profile加载优先级，外部config目录里的application.yml优先级高于jar包内的，所以如果在服务器上放了一个外部配置文件，jar包里的配置会被覆盖，排查时要注意这个优先级规则。
数据库连接配置里，我强烈建议用druid连接池，不只是因为它有监控页面，更因为生产环境需要keepAlive配置，防止mysql八小时断开连接。时长设置上，druid的minEvictableIdleTimeMillis我设置的60000，validationQuery设置为SELECT 1，timeBetweenEvictionRunsMillis为300000。这一组参数能避免深夜无人访问后，第二天上班所有接口超时的情况。
6.2 高频踩坑：时区、中文乱码、路径404
第一个高频坑是时区问题。mysql连接串如果不加serverTimezone=Asia/Shanghai，默认使用服务器时区，一旦服务器时间跟北京时间不同，打卡记录就会整体偏移。我在jdbc url里面显式声明useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai，从源头解决时间错乱和中文乱码两个问题。
第二个坑是springboot内置tomcat对jsp的支持。springboot不是默认支持jsp，必须引入tomcat-embed-jasper依赖，并且要在pom的build节点配置resource把jsp目录包含进去。如果不配这个，打出来的jar包会缺了jsp页面，访问任意页面都是404。我的做法是把jsp放在src/main/webapp/WEB-INF/views下，同时在配置文件里设置spring.mvc.view.prefix和suffix。如果用war包部署到外部tomcat，还需要配置外部tomcat的jsp编译环境，这部分网上教程很多，但确实是最容易踩的地方。
第三个坑是文件上传乱码或中文文件名丢失。这个问题在考勤系统中不算高频，但导出excel报表时中文文件名就会乱。我统一用了org.apache.poi生成Excel，文件名用URLEncoder.encode再拼接，前端解析时再做decode，这样中文文件名不会再乱。另外sqlserver和mysql的关键字冲突也值得警惕，表名和字段名尽量避开desc、rank、level这些保留字，如果非要使用，mysql里要加反引号。
7. 个人实操心得与后续扩展方向
这个项目从需求分析到上线，前后用了三周左右。我最大的感受是，考勤系统最费时间的不是写代码，而是理清业务规则。在开发前跟行政人事聊一天，比写三天代码都有效。很多边界情况，比如重复打卡、跨天请假、补卡审批，都是在沟通中提前暴露的。如果拿着模糊需求直接撸代码，后面一定会返工。
还有一点值得分享：做这类系统时，不要把逻辑全堆在Controller和Service里。我的做法是抽了AttendanceRuleService专门处理考勤规则判断，请假、加班、调休规则也在其中，Controller层只做参数接收和结果封装。月末统计时，直接调用规则服务生成报表，不用重新串一遍逻辑。这样模块清晰，测试也好写。
后续如果你打算扩展，可以考虑接入企业微信或钉钉的打卡事件推送，把打卡源从网页按钮扩展为移动端自动定位打卡。再往后，可以增加补卡申请审批流，以及跟薪资系统对接，把请假、加班、迟到数据直接换算成薪资变动。不过这些都是锦上添花，核心的考勤闭环已经在本系统跑通了。做完这个项目，你会对springboot工程结构、复杂业务报表、角色权限控制都有更深的理解，也算是一套很完整的JavaWeb练手项目了。
