企业官网建设流程全解析

手里那套用Excel维护的人力资源台账终于到了撑不住的时候——考勤要逐行核对，工资算完要挨个解释，合同到期全靠翻日历碰运气。于是我花了三周时间用 SpringBoot + Java 做了套人力资源管理系统，把考勤、工资、合同三条业务主线全部收了进去，并且用事务把这几块的数据一致性绑死。这篇文章就把整套系统的设计思路、核心表结构、关键代码和踩过的坑一次讲清楚，适合正在做类似管理系统的开发者，也适合公司里负责数字化选型的人参考。

先说明这套系统解决的三个核心问题：考勤数据能不能自动汇总成工资依据，工资调整能不能追溯到历史版本，合同到期能不能提前被提醒。只要这三条线能跑通，人事部门的日常事务基本就自动化了。我的做法是先梳理领域模型，再定模块边界，最后才动手写代码，后面你会看到每一步选择都有具体原因。

1. 这套系统要接住的"人、钱、约"三条主线

1.1 考勤、工资、合同三者之间的真实业务关系

很多初学SpringBoot的人拿到人力资源管理系统这个需求时，第一反应就是把员工增删改查做出来。但真去问人事部的人，你会发现他们日常最头疼的根本不是维护员工花名册，而是三件事：这个月考勤对不对得上，工资条算出来有没有人质疑，合同续签该不该提醒。

这三件事在业务上是强关联的。考勤的最终产物是"本月应出勤天数、实际出勤天数、请假时长、加班时长"；工资的输入是"基本工资 + 考勤扣款 + 加班费 + 补贴 - 社保公积金"；合同则决定了员工的在职状态和薪资生效日期。如果这三个模块各自为政，就会出现"考勤改了，工资没重算""合同到期忘了续签，工资还在按旧标准发"这种事故。

所以我的系统设计原则是：考勤、工资、合同共享同一个员工主数据，但各自由独立模块管理。员工主数据只负责唯一编号、姓名、部门、岗位、入职日期、离职日期这类基础信息；考勤模块负责生成月度汇总；工资模块引用考勤汇总并生成薪资单；合同模块反向约束员工状态。三者通过员工编号和日期区间联动，不搞一张大表塞所有字段。

1.2 技术选型为什么是SpringBoot + Java + MyBatis

这个组合在这个场景下是有明确理由的。人力资源系统最大的特点是表单多、流程多、报表多，但并发量极低，一般公司两三百人同时打卡已经是极限。SpringBoot最擅长的就是这种"业务逻辑复杂但并发压力不大"的中后台系统，生态成熟，招人容易，出了问题网上一搜一堆解决方案。

持久层我选了MyBatis而不是JPA，原因很实际：考勤和工资模块有大量动态SQL，比如月度考勤汇总要根据请假类型、加班类型动态拼接查询条件，JPA的实体映射在这种场景下反而绕。而MyBatis写SQL直来直去，出问题时我能直接看到SQL在干什么。数据库用MySQL，8.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(List<AttendanceRecord> 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() { List<EmployeeContract> 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，方法内部做三件事：

1. 更新请假申请状态
2. 更新每日考勤结果的状态和休假时长
3. 调工资重算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引擎根本不支持事务，表的增删改不会回滚。排查方法很简单：看建表语句里有没有ENGINE=InnoDB，没有就改。

6. 部署上线与运行期QA：遇到的实际问题排查记录

6.1 时区与翻页：两个隐藏的"数据错位"

上线第一周就遇到一个诡异问题：员工打卡时间是早上9点，数据库里存的时间却是下午5点。排查后发现是服务器时区和数据库连接时区没对齐。SpringBoot连接MySQL的URL里没加serverTimezone=Asia/Shanghai，而用默认的CST时区导致时间整体偏移。

解决办法简单但不能忘：

jdbc:mysql://localhost:3306/hr_system?serverTimezone=Asia/Shanghai&useUnicode=true&characterEncoding=utf8

另一个隐藏问题是分页查询的深度翻页性能。考勤明细表一个月的数据量其实不大，但如果你加了一个模糊查询条件，快速翻到500页以后，MySQL的LIMIT偏移量会越来越大，查询越来越慢。我的做法是改成游标分页：用WHERE id > 上一页最后一条ID ORDER BY id LIMIT 20。这在内部系统里比传统分页稳得多。

6.2 高并发考勤打卡的队列缓冲设计

虽然总体并发不高，但早上8点55到9点05这十分钟是打卡高峰。一百人的公司，这十分钟可能集中打进来几千条记录。直接同步写库也行，但人一多页面会卡顿，考勤机的推送超时重试又可能造成重复数据。

我的做法是引入一个简单的内存队列，考勤接收接口先把原始记录放入队列，后台线程批量消费后写入数据库。核心代码：

@Component public class AttendanceQueue { private final BlockingQueue<AttendanceRecord> queue = new LinkedBlockingQueue<>(10000); private final ExecutorService executor = Executors.newSingleThreadExecutor(); @PostConstruct public void start() { executor.submit(() -> { while (true) { try { List<AttendanceRecord> 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.1+0.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%的劳资纠纷。