★ FEATURED ARTICLE 手里那套用Excel维护的人力资源台账终于到了撑不住的时候——考勤要逐行核对工资算完要挨个解释合同到期全靠翻日历碰运气。于是我花了三周时间用 SpringBoot Java 做了套人力资源管理系统把考勤、工资、合同三条业务主线全部收了进去并且用事务把这几块的数据一致性绑死。这篇文章就把整套系统的设计思路、核心表结构、关键代码和踩过的坑一次讲清楚适合正在做类似管理系统的开发者也适合公司里负责数字化选型的人参考。先说明这套系统解决的三个核心问题考勤数据能不能自动汇总成工资依据工资调整能不能追溯到历史版本合同到期能不能提前被提醒。只要这三条线能跑通人事部门的日常事务基本就自动化了。我的做法是先梳理领域模型再定模块边界最后才动手写代码后面你会看到每一步选择都有具体原因。1. 这套系统要接住的人、钱、约三条主线1.1 考勤、工资、合同三者之间的真实业务关系很多初学SpringBoot的人拿到人力资源管理系统这个需求时第一反应就是把员工增删改查做出来。但真去问人事部的人你会发现他们日常最头疼的根本不是维护员工花名册而是三件事这个月考勤对不对得上工资条算出来有没有人质疑合同续签该不该提醒。这三件事在业务上是强关联的。考勤的最终产物是本月应出勤天数、实际出勤天数、请假时长、加班时长工资的输入是基本工资 考勤扣款 加班费 补贴 - 社保公积金合同则决定了员工的在职状态和薪资生效日期。如果这三个模块各自为政就会出现考勤改了工资没重算合同到期忘了续签工资还在按旧标准发这种事故。所以我的系统设计原则是考勤、工资、合同共享同一个员工主数据但各自由独立模块管理。员工主数据只负责唯一编号、姓名、部门、岗位、入职日期、离职日期这类基础信息考勤模块负责生成月度汇总工资模块引用考勤汇总并生成薪资单合同模块反向约束员工状态。三者通过员工编号和日期区间联动不搞一张大表塞所有字段。1.2 技术选型为什么是SpringBoot Java MyBatis这个组合在这个场景下是有明确理由的。人力资源系统最大的特点是表单多、流程多、报表多但并发量极低一般公司两三百人同时打卡已经是极限。SpringBoot最擅长的就是这种业务逻辑复杂但并发压力不大的中后台系统生态成熟招人容易出了问题网上一搜一堆解决方案。持久层我选了MyBatis而不是JPA原因很实际考勤和工资模块有大量动态SQL比如月度考勤汇总要根据请假类型、加班类型动态拼接查询条件JPA的实体映射在这种场景下反而绕。而MyBatis写SQL直来直去出问题时我能直接看到SQL在干什么。数据库用MySQL8.0版本以上事务隔离级别保持默认的REPEATABLE READ后面会讲为什么在这个项目里默认隔离级别反而安全。前端我用的是服务端渲染加Thymeleaf主要考虑是项目周期短不想再拆前后端工程。对内部管理系统来说页面简单够用就行把精力留给核心的考勤计算和工资事务。1.3 模块边界划分三个子系统,一套事务规则代码层面我按领域拆了三个子包attendance、salary、contract。每个子包内部有独立的Controller、Service、Mapper但Service之间允许受控调用。比如工资模块的月结Service会调用考勤模块的查询Service拿汇总数据但绝不能反向依赖。这种边界划分最大的好处是事务可以横向跨越多个领域。一次月结工资的操作涉及读取考勤汇总、生成工资明细、更新员工薪资档案、写入合同状态变更日志这四步必须在一个事务里完成。如果考勤和工资的Service相互耦合太深事务边界就会变成一团乱麻。后面专门有一节讲事务怎么画边界这里先记住结论模块独立、事务统一。2. 考勤模块从打卡记录到月度汇总的完整链路2.1 考勤落库表设计冗余字段换查询速度考勤模块的核心表我拆成三张打卡原始记录表、每日考勤结果表、月度考勤汇总表。原始记录表只干一件事——存打卡机或钉钉推送过来的每一条打卡时间每日结果表每天凌晨用定时任务把前一天的原始记录汇总成某员工某天考勤状态月度汇总表则在每月1号把上一月的每日结果聚合成一张总表。这里有个关键设计为什么不能直接在原始记录表上做月度汇总因为原始记录可能因为补卡、改签、系统重传而变化如果每次都全量计算性能差不说工资模块引用汇总数据时还可能发生读到一半数据被改的情况。每日结果表相当于做了一个中间缓存把计算逻辑和工资逻辑隔开。每日结果表的结构大致是这样CREATE TABLE daily_attendance_result ( id BIGINT PRIMARY KEY AUTO_INCREMENT, employee_id BIGINT NOT NULL, work_date DATE NOT NULL, first_punch_time DATETIME, last_punch_time DATETIME, status VARCHAR(20) NOT NULL COMMENT NORMAL/LATE/EARLY_LEAVE/ABSENT/LEAVE/BUSINESS_TRIP/OVERTIME, leave_hours DECIMAL(5,2) DEFAULT 0, overtime_hours DECIMAL(5,2) DEFAULT 0, UNIQUE KEY uk_employee_date (employee_id, work_date) );选择冗余员工编号和日期字段而不是只存打卡记录ID是为了让工资模块的关联查询少走一层JOIN。实际写下来这种冗余设计在报表多的时候非常省心SQL写起来简单索引命中率也高。2.2 迟到、早退、缺卡的状态判定逻辑每日考勤结果是怎么判定的这得分几步。首先从原始打卡记录里取第一笔和最后一笔时间分别作为上班卡和下班卡。然后跟排班表对比上班卡晚于排班时间标记LATE下班卡早于排班下班时间标记EARLY_LEAVE一天只有一笔打卡或者没有打卡标记ABSENT。这里最容易踩坑的是跨天班次。某天凌晨1点下班如果按自然日0点到24点去切分就会把凌晨的打卡算成第二天。我的办法是排班表里直接维护一个班次日期上夜班的班次归属到开工当天而不是收工当天。这看起来是个小逻辑实际开发里能让考勤准确率提高不少。状态判定代码的核心逻辑public DailyAttendanceResult buildResult(ListAttendanceRecord records, Shift shift) { DailyAttendanceResult result new DailyAttendanceResult(); if (records.isEmpty()) { result.setStatus(ABSENT); return result; } if (records.size() 1) { result.setStatus(ABSENT); // 只有一笔视为缺卡 return result; } LocalDateTime first records.get(0).getPunchTime(); LocalDateTime last records.get(records.size() - 1).getPunchTime(); result.setFirstPunchTime(first); result.setLastPunchTime(last); result.setStatus(determineStatus(first, last, shift)); result.setLeaveHours(0); result.setOvertimeHours(calcOvertime(last, shift)); return result; }注意只有一笔打卡也判为缺卡这是跟人事确认后的规则单次打卡不能证明员工确实在岗宁可判缺卡让员工走补卡审批也不能放任漏卡。2.3 月度考勤汇总的批处理实现每月1号凌晨2点系统跑批生成月度汇总。这个批处理我用的Spring自带的Scheduled没有引额外分布式任务框架因为单机跑足够。批处理逻辑要点先查上个月所有工作日的员工排班再查每日考勤结果然后逐员工汇总。汇总项包括应出勤天数、实际出勤天数、迟到次数、早退次数、事假小时数、病假小时数、加班小时数。这些字段最后会原封不动提供给工资模块。月度汇总生成必须保证是幂等的同一个月跑两次第二次要么跳过要么覆盖重算。我在汇总表上加了month和employeeId的唯一索引批处理前先清空上个月的汇总数据再重新插入避免脏数据累计。3. 工资模块工资条不是算出来的,是核对出来的3.1 工资构成拆解与薪酬档案快照工资模块的第一张关键表是薪酬档案表。每个员工当前生效的薪资构成基本工资、岗位工资、绩效基数、交通补贴、住房补贴。这里强烈建议不要只存一个工资总额因为考勤扣款和加班费是按基本工资算的不同项目的基数不一样。更关键的是薪酬档案必须做历史版本管理。员工调薪了新工资从某一天生效但上个月的工资单不能受影响。所以我在薪酬档案表里加了一个生效日期字段工资计算时只取生效日期晚于工资所属月第一天的那条记录。同时保留一个修改人日志表每次调薪都会放下一条快照记录出了问题能追溯是谁在什么时候改的。工资明细表按月存储每条明细包含员工号、月份、基础工资、奖金、补贴、考勤扣款、加班费、社保、公积金、实发金额。这张表是财务发工资的唯一数据源没有特殊情况不允许手动改改也必须走审批流程。3.2 工资计算规则的公式化设计工资计算我把规则拆成了可配置项不硬编码在代码里。配置表结构大致是规则名称 | 计算方式 | 优先级 固定薪资 | 基本工资 岗位工资 补贴 | 1 考勤扣款 | 迟到每次扣X元, 事假按日工资扣 | 2 加班费 | 平时1.5倍, 周末2倍, 法定节假日3倍 | 3 社保公积金 | 按基数比例, 个人缴纳部分代扣 | 4这个设计的核心逻辑是把计算规则和数据分开。以后调整加班倍率或者增加一项高温补贴直接改配置表不用重新发版。在SpringBoot里实现公式化也不复杂我用的方案是每一条规则对应一个实现类注册到一个规则引擎Map里计算工资时遍历所有规则按顺序执行。3.3 工资与考勤、合同的联动点月结事务工资月结是整个系统里事务最重的操作。流程是按员工循环查月度考勤汇总、算工资、插入工资明细、更新员工参与工资发放的标记、把工资状态改成已核算。这整个过程必须保证要么全部成功要么全部回滚。很多人在这一步栽跟头是因为他们把算工资和发工资混在一个事务里。我的设计是分两阶段阶段一只做核算生成工资明细并保存状态为待确认阶段二是财务确认后调用接口把工资状态改成已发放并更新员工薪资档案里的最后发放月份。这样即使某个月工资算错了只要还没确认发放重新核算不会产生重复数据。这里的事务边界是阶段一内部排他的阶段二独立事务。为什么不能把阶段二也放进同一个事务因为阶段二涉及的钱已经出了系统出纳那边可能已经转账了你再回滚只会造成线下线上不一致。事务管理的精髓就在于分清哪些操作可以回滚、哪些操作只能在业务层面补偿。4. 合同模块电子化签署与到期自动预警4.1 合同生命周期的状态流转合同模块我设计了四个状态草稿、生效中、到期、已解除。每份合同关联一个员工记录合同类型新签、续签、变更、起始日期、结束日期、试用期时长、薪资条款摘要。这里的核心逻辑是合同状态不能直接改必须通过动作流转。比如续签这个动作业务上并不是把旧合同的结束日期往后改而是新建一份合同然后把旧合同状态改成已到期。为什么要这么设计因为合同受法律约束任何修改都要留痕。如果你直接改日期审计的时候根本说不清什么时候改的。合同状态流转我基于状态机写了一套校验逻辑每个状态能到达哪些目标状态都在代码里配置好非法流转直接抛异常。这套逻辑代码不多但能防止很多手误操作。4.2 到期预警定时任务与提醒消息合同到期预警用的是定时任务加消息表。每天早上8点跑一次任务查询未来30天内到期且状态为生效中的合同往消息中心插一条提醒记录然后给对接负责人发站内信。这个功能实现起来不难但价值极高我一个朋友公司之前就是合同漏续签员工离职时索要双倍工资一笔就抵得上这套系统的开发成本。定时任务代码Scheduled(cron 0 0 8 * * ?) Transactional public void scanExpiringContracts() { ListEmployeeContract contracts contractMapper.findExpiringWithinDays(30); for (EmployeeContract contract : contracts) { if (contract.getStatus().equals(ACTIVE)) { contractReminderMapper.insert( new ContractReminder(contract.getEmployeeId(), contract.getId(), 合同即将到期, contract.getExpireDate()) ); } } }这里有个业务细节预警任务的执行不应该影响主流程事务。Transactional加在方法上确实把插入提醒做成事务但注意这个任务查询到的合同列表本身不能被锁住太久否则如果合同量大会影响日常合同查询。所以我在执行策略上做了调整查询只读不加锁插入提醒单独提交任务失败最多损失一次提醒第二天还能重跑。4.3 合同工资联动的审批枷锁合同模块里最容易和工资模块起冲突的地方是调薪。调薪通常伴随合同变更但合同变更审批没走完的时候工资模块要不要按新标准算钱我的设计答案是按当前生效合同的薪资条款算不按审批中的草稿算。具体实现是在工资计算时读取一条SQL查询员工在工资所属月当前生效的合同条款如果合同状态是生效中取合同薪资如果合同状态是草稿则忽略。这保证了一个原则工资永远跟着已经生效的合同走审批流程再慢也不会导致多发或少发。5. 事务管理让三套数据的账永远对得上5.1 考勤状态流转与工资快照的一致性处理现在回到标题里那个事务字眼。这个系统的首要事务场景是员工休假审批通过后考勤状态从正常变成休假同时工资模块的考勤扣款要自动重算。这个重算不能单独更新工资表必须和考勤状态更新放在同一个事务里否则就会出现考勤显示休假了工资还在扣款的割裂状态。我的做法是在请假审批通过接口上加Transactional方法内部做三件事更新请假申请状态更新每日考勤结果的状态和休假时长调工资重算Service更新当月工资明细的扣款项这三个操作任何一个失败事务整体回滚不会出现半截状态。但这里有个异常陷阱重算Service如果内部自己又加了不小心的catch吞掉异常事务会认为方法执行成功实际上工资没更新。所以我在代码规范里要求所有Service方法不允许吞异常要么抛出运行时异常要么返回Result对象并显式记录失败。5.2 事务边界到底画在哪结算场景拆解一个常见的反模式是在Controller层加Transactional把整个HTTP请求包在事务里。这样做的后果是数据库连接被占用时间过长并发稍微上来一点连接池就耗尽。我的经验是事务的粒度必须和业务操作的单位对齐。拿月结工资来说单个员工的计算循环里每算一个员工就提交一次事务比把所有员工包在一个大事务里好得多。后者一旦第200个员工计算失败前199个全部回滚数据库回滚日志巨大耗时也扛不住。改成每员工一个事务失败时只需要单独重算这个员工不影响其他人。还有更复杂的场景月结工资的过程中同事发起调薪申请恰好事务里读到的薪资档案是调薪前的版本。怎么避免MySQL默认的REPEATABLE READ隔离级别下事务内多次读取同一行数据会有一致性视图即使外部提交了调薪事务内看到的还是旧值。这在这个场景反而是正确的月末结算以结算开始时的薪资为准不会被中途调薪打断。5.3 事务失效的三个经典原因框架用久了就会发现Transactional不是加在哪都生效。我在这个项目里实际踩过三个坑写出来给大家避雷。第一个同类内部方法调用导致事务失效。同一个Service里A方法调用B方法B上标了Transactional是不生效的因为Spring事务是通过代理实现的内部调用不走代理。解决办法是拆成两个Service或者用注入自身代理的方式。我的习惯是拆Service结构更清晰。第二个事务方法里捕获了异常没有重新抛出。我亲眼见过有人写Transactional public void doSomething() { try { // 执行业务 } catch (Exception e) { log.error(error, e); // 没有继续抛出 } }这样事务一定会提交因为Spring只对RuntimeException和Error回滚checked exception默认不回滚被捕获后异常根本没传到代理层。这里必须改为捕获后继续抛出或者配置rollbackFor。第三个数据库引擎不是InnoDB。MySQL中MyISAM引擎根本不支持事务表的增删改不会回滚。排查方法很简单看建表语句里有没有ENGINEInnoDB没有就改。6. 部署上线与运行期QA遇到的实际问题排查记录6.1 时区与翻页两个隐藏的数据错位上线第一周就遇到一个诡异问题员工打卡时间是早上9点数据库里存的时间却是下午5点。排查后发现是服务器时区和数据库连接时区没对齐。SpringBoot连接MySQL的URL里没加serverTimezoneAsia/Shanghai而用默认的CST时区导致时间整体偏移。解决办法简单但不能忘jdbc:mysql://localhost:3306/hr_system?serverTimezoneAsia/ShanghaiuseUnicodetruecharacterEncodingutf8另一个隐藏问题是分页查询的深度翻页性能。考勤明细表一个月的数据量其实不大但如果你加了一个模糊查询条件快速翻到500页以后MySQL的LIMIT偏移量会越来越大查询越来越慢。我的做法是改成游标分页用WHERE id 上一页最后一条ID ORDER BY id LIMIT 20。这在内部系统里比传统分页稳得多。6.2 高并发考勤打卡的队列缓冲设计虽然总体并发不高但早上8点55到9点05这十分钟是打卡高峰。一百人的公司这十分钟可能集中打进来几千条记录。直接同步写库也行但人一多页面会卡顿考勤机的推送超时重试又可能造成重复数据。我的做法是引入一个简单的内存队列考勤接收接口先把原始记录放入队列后台线程批量消费后写入数据库。核心代码Component public class AttendanceQueue { private final BlockingQueueAttendanceRecord queue new LinkedBlockingQueue(10000); private final ExecutorService executor Executors.newSingleThreadExecutor(); PostConstruct public void start() { executor.submit(() - { while (true) { try { ListAttendanceRecord batch new ArrayList(); queue.drainTo(batch, 200); if (!batch.isEmpty()) { attendanceMapper.batchInsert(batch); } Thread.sleep(500); } catch (Exception e) { log.error(批处理打卡记录失败, e); } } }); } }批量插入的好处不只是性能更重要的是减轻数据库压力。队列满的时候接收接口直接返回打卡记录已提交稍后生效避免丢数据。6.3 薪资核算的精度控制与金额存储规范工资计算中最大的精度坑是金额字段用了FLOAT或DOUBLE。Java里float算0.10.2会得到0.30000000000000004工资差一分钱都会被员工发现。我在所有金额字段全部用DECIMAL(10,2)Java侧用BigDecimal计算。特别注意BigDecimal构造时不要用new BigDecimal(0.1)这样会得到0.1000000000000000055511151231257827021181583404541015625。必须用new BigDecimal(0.1)或BigDecimal.valueOf(0.1)。这个细节写错一次整个工资表就全偏了。月度工资的计算顺序也要固定先算应发项基本工资、绩效、补贴、加班费再算扣款项考勤扣款、社保、公积金最后算实发。每一步都用BigDecimal.add或subtract不要用乘法先合项再乘因为每一步的舍入规则不一样一次性算会跟Excel对不上。7. 这套系统还可以怎么扩展写到这核心模块和事务设计基本讲完了。回头看我自己的实践感受最值得说的不是用了什么高深技术而是把业务边界理清楚、把事务放在正确的位置上。如果后续要继续扩展我会优先做两件事。第一是报表可视化把考勤汇总和工资发放情况做成简单的图表管理层看得轻松第二是接入电子签章服务合同签署从走流程变成真正在线签字减少打印快递成本。这两个方向都不需要改动现有核心代码新模块加进去就行。最后分享一个压箱底的小技巧薪资月结跑批完成之后务必做一次对账——把工资表里的应发合计和考勤汇总里的出勤天数、请假小时、加班小时交叉验证任何异常数直接预警。这套对账逻辑本身也要写进系统里而不是靠人肉翻Excel。Trust me这个环节能帮你挡掉90%的劳资纠纷。
阅读完成 · 觉得有帮助？
