员工考勤管理办法源码解析：3个坑让打卡数据不丢
盯着屏幕上的 StackTrace 报错，红色的字一行接一行，心跳直接飙到一百八。这场景太熟了，HR 拿着考勤表找上开发，说“上个月王五的迟到记录怎么没了？”，你心里咯噔一下。别慌，这时候光看业务逻辑代码是没用的，必须往下钻，看底层数据是怎么存的。这就是我们要聊的【员工考勤管理办法】在系统里的实现，特别是它的【源码解析】。
很多团队把考勤系统做得很轻，觉得不就是个时间戳加个状态吗？错。考勤是法律风险的雷区，也是数据一致性的深水区。今天不聊虚的，直接拆解一个生产级考勤系统的核心代码，看看那些让你头秃的 Bug 是怎么产生的，又是怎么被源码设计规避的。
入口定位：为什么你的打卡接口慢如蜗牛
很多开发者在写考勤打卡接口时，第一反应是直接插入数据库。比如用户点击“打卡”，后端接收时间，INSERT INTO attendance (user_id, clock_in_time) VALUES (...)。看起来很干净，对吧？
但在高并发场景下，比如早上 9:00 到 9:15，全公司几百人同时打卡，这种简单写法会瞬间压垮数据库连接池。更糟糕的是，如果这时候网络抖动，用户点了两次，或者前端重试机制触发，你数据库里就会多出两条一模一样的记录。HR 月底算工资时，看到两条 9:01 的打卡记录，是算迟到还是正常？这就是典型的“最终一致性”缺失。
我们来看一个典型的错误入口设计：
// 错误的入口设计：缺乏幂等性检查
@PostMapping(/clock)
public ResultString clockIn(@RequestBody ClockRequest req) {
// 1. 直接获取当前时间
LocalDateTime now = LocalDateTime.now();
// 2. 构建实体对象
Attendance record = new Attendance();
record.setUserId(req.getUserId());
record.setClockTime(now);
record.setType(req.getType()); // IN or OUT
// 3. 直接保存，没有检查是否已存在
attendanceService.save(record);
return Result.success(打卡成功);
}
这段代码的问题在于它完全依赖数据库的唯一索引来兜底，而不是在应用层做防御。如果数据库锁等待超时，整个请求就会挂起，用户体验极差。真正的【员工考勤管理办法】落地代码，必须在入口层就做好“拦截”和“去重”。
核心片段：幂等性锁与状态机的博弈
解决并发打卡和重复请求的核心，不是简单的 if exists 判断，因为查询和插入之间有时间窗口（Race Condition）。我们需要引入分布式锁，或者利用数据库的行级锁特性。
下面这段代码展示了一个更稳健的核心处理逻辑，它结合了 Redis 分布式锁和数据库的状态机校验：
@Service
public class AttendanceCoreService {
private final RedisTemplateString, String redisTemplate;
private final JdbcTemplate jdbcTemplate;
/**
* 核心打卡逻辑：带幂等性保护
*/
public ClockResult processClock(ClockRequest req) {
// 1. 生成唯一业务键：用户ID + 日期 + 打卡类型
// 这样同一天同类型打卡，Key 是固定的
String idempotentKey = String.format(att:lock:%d:%s:%s,
req.getUserId(),
LocalDate.now().toString(),
req.getType());
// 2. 尝试获取分布式锁，超时时间设为 3 秒
// 如果获取失败，说明有重复请求正在处理中，直接返回“处理中”
Boolean isLocked = redisTemplate.opsForValue()
.setIfAbsent(idempotentKey, 1, 3, TimeUnit.SECONDS);
if (Boolean.FALSE.equals(isLocked)) {
// 快速失败，避免线程堆积
return ClockResult.duplicated(请求正在处理中，请勿重复提交);
}
try {
// 3. 查询当日该用户该类型的打卡记录
// 注意：这里使用 SELECT FOR UPDATE 防止并发写入
ListMapString, Object existingRecords = jdbcTemplate.queryForList(
SELECT id, status FROM attendance WHERE user_id = ? AND date = ? AND type = ? FOR UPDATE,
req.getUserId(), LocalDate.now(), req.getType()
);
if (!existingRecords.isEmpty()) {
// 4. 状态机校验：如果已经是“已确认”状态，拒绝修改
// 如果状态是“待确认”或“异常”，允许覆盖更新
String currentStatus = (String) existingRecords.get(0).get(status);
if (CONFIRMED.equals(currentStatus)) {
return ClockResult.error(该班次已确认，不可再次打卡);
}
// 5. 执行更新操作（而非插入），保证数据唯一性
jdbcTemplate.update(
UPDATE attendance SET clock_time = NOW(), status = 'PENDING' WHERE id = ?,
existingRecords.get(0).get(id)
);
return ClockResult.success(打卡时间已更新);
} else {
// 6. 如果不存在，则插入新记录
jdbcTemplate.update(
INSERT INTO attendance (user_id, date, type, clock_time, status) VALUES (?, ?, ?, NOW(), 'PENDING'),
req.getUserId(), LocalDate.now(), req.getType()
);
return ClockResult.success(打卡成功);
}
} finally {
// 7. 无论成功失败，务必释放锁
redisTemplate.delete(idempotentKey);
}
}
}
逐行拆解关键点：
idempotentKey 的构造：这是幂等性的灵魂。把用户、日期、类型组合成唯一键，确保同一业务动作只执行一次。
setIfAbsent (SETNX)：利用 Redis 的原子操作实现分布式锁。这里设置了 3 秒超时，防止服务宕机导致死锁。
SELECT ... FOR UPDATE：这是数据库层面的悲观锁。在 MySQL InnoDB 引擎下，这会锁定查询到的行，防止其他事务同时修改这条数据。
状态机校验：注意代码中没有直接删除重插，而是根据 status 判断。如果考勤记录已经被 HR 确认（CONFIRMED），后端直接拒绝修改。这符合【员工考勤管理办法】中“事后不可逆”的合规要求。
finally 释放锁：这是最容易被新手忽略的地方。如果不在 finally 块中释放锁，一旦中间抛异常，锁就会一直存在直到超时，导致用户短时间内无法再次打卡。
设计思想：为什么要把逻辑下沉到数据层？
很多初学者喜欢把逻辑写在 Service 层，用 Java 对象去对比时间。但在考勤这种对精确度要求极高的场景下，时间源必须统一。
在上述源码中，我们特意让数据库执行 NOW() 或 SYSDATE()，而不是使用 Java 的 LocalDateTime.now()。为什么？
因为 Java 服务可能部署在多个节点上，如果服务器 A 和服务器 B 的时钟不同步（哪怕只差几毫秒），会导致同一秒内打卡的用户被判定为不同状态。更严重的是，如果 Java 应用服务器时间比数据库慢，用户明明 8:59:59 打卡，数据库记录却是 9:00:01，这就产生了“假迟到”。
根据 ISO 8601 标准以及大多数云服务商的 NTP（网络时间协议） 官方文档建议，分布式系统中的时间同步误差应控制在毫秒级以内。但在代码层面，最稳妥的做法是以存储层的时间为准，应用层只负责传递“事件发生”的信号，而不负责定义“事件发生的时间”。
此外，这里的设计还隐含了一个思想：分离“打卡事实”与“考勤结果”。
clock_time 是事实，不可变（除了异常修正）。
status 是状态，随业务流转。
final_attendance 是结果，由定时任务计算。
这种分层设计，使得当公司调整考勤规则（比如从“迟到5分钟算旷工”改为“迟到1分钟算迟到”）时，只需要修改计算定时任务的逻辑，而无需清洗历史打卡数据。
手写简化版：如何在本地模拟测试？
为了让大家能跑通这段逻辑，这里提供一个简化的本地测试版本。我们假设不使用 Redis，而是使用 Java 内置的 ConcurrentHashMap 模拟锁，方便在 IDE 中直接调试。
import java.time.LocalDate;
import java.time.LocalDateTime;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.atomic.AtomicInteger;
public class SimpleAttendanceSimulator {
// 模拟 Redis 锁
private static final ConcurrentHashMapString, AtomicInteger lockMap = new ConcurrentHashMap();
// 模拟数据库表
private static final ConcurrentHashMapString, AttendanceRecord dbMap = new ConcurrentHashMap();
public static class AttendanceRecord {
public String userId;
public LocalDate date;
public String type;
public LocalDateTime time;
public String status;
public AttendanceRecord(String userId, LocalDate date, String type) {
this.userId = userId;
this.date = date;
this.type = type;
this.status = PENDING;
}
}
/**
* 简化版打卡逻辑
*/
public static String simulateClock(String userId, String type) {
LocalDate today = LocalDate.now();
String key = userId + _ + today + _ + type;
// 模拟获取锁：putIfAbsent 返回 null 表示获取成功
AtomicInteger counter = lockMap.putIfAbsent(key, new AtomicInteger(0));
if (counter != null) {
// 模拟锁被占用
return FAIL: Duplicate request detected;
}
try {
// 模拟数据库查询与更新
AttendanceRecord record = dbMap.computeIfAbsent(key, k - {
return new AttendanceRecord(userId, today, type);
});
// 模拟业务校验
if (CONFIRMED.equals(record.status)) {
return FAIL: Already confirmed;
}
// 更新时间和状态
record.time = LocalDateTime.now();
record.status = PENDING;
System.out.println(SUCCESS: + userId + + type + at + record.time);
return SUCCESS;
} finally {
// 释放锁
lockMap.remove(key);
}
}
public static void main(String[] args) {
// 测试1：正常打卡
simulateClock(User1001, IN);
// 测试2：重复打卡（模拟快速点击）
simulateClock(User1001, IN);
// 测试3：另一个用户
simulateClock(User1002, IN);
}
}
这段代码虽然简化了，但保留了核心的原子性操作思想。在实际项目中，请务必将 ConcurrentHashMap 替换为真正的分布式锁组件（如 Redisson），并将 dbMap 替换为真实的 JPA/MyBatis 操作。
应用场景：跨省转介与特殊班次处理
在实际落地【员工考勤管理办法】时，你会发现标准代码永远覆盖不了所有业务场景。比如，很多大厂有“多地办公”需求，员工在北京上班，但偶尔去上海出差。这时候，简单的 LocalDate.now() 就会失效，因为时区不同。
痛点场景：
员工在上海出差，当地时间是 9:00，北京时间是 9:00（假设无时差，但若有跨国则有时差）。如果系统只记录 UTC 时间，而不记录用户所在时区，月底统计时就会出错。
源码应对策略：
在 AttendanceRecord 中增加 timezone 字段。
public class AttendanceRecord {
// ... 其他字段
public String timezone; // 例如 Asia/Shanghai 或 America/New_York
public LocalDateTime localTime; // 用户当地感知的时间
public LocalDateTime utcTime; // 统一存储的 UTC 时间
}
在打卡接口中，强制要求前端传递 timezone 参数，并在后端进行校验：
// 后端校验时区合法性
if (!ZoneId.getAvailableZoneIds().contains(req.getTimezone())) {
throw new InvalidTimezoneException(Invalid timezone: + req.getTimezone());
}
// 转换时间
ZonedDateTime localZoned = ZonedDateTime.of(req.getLocalTime(), ZoneId.of(req.getTimezone()));
LocalDateTime utcTime = localZoned.withZoneSameInstant(ZoneOffset.UTC).toLocalDateTime();
这种处理在跨省转介办理或跨国协作场景中尤为关键。根据人社部关于流动人员人事档案管理服务的相关指引，虽然考勤本身不属于档案，但涉及薪资结算和社保缴纳地认定时，准确的时间与地点元数据是合规的基础。
另外，对于“特殊班次”（如轮班制、夜班），不要硬编码 if type == NIGHT。应该引入策略模式（Strategy Pattern），定义一个 AttendanceStrategy 接口，针对不同班次实现不同的校验逻辑。例如，夜班的“迟到”定义可能是“23:50 之后”，而白班是“09:00 之后”。将规则外置到配置文件或数据库中，代码才能保持简洁和可扩展。
总结与互动
写考勤系统，表面是写代码，底层是写规则，核心是防风险。从入口的幂等性设计，到数据层的时间统一，再到业务层的状态机流转，每一个环节都藏着坑。
源码解析的意义，不在于让你背下这几行代码，而是让你明白：为什么要加锁？为什么要用数据库时间？为什么要分状态？当你理解了这些“为什么”，下次面对 HR 提出的奇葩需求（比如“允许补卡但必须审批”）时，你就知道该在哪里扩展逻辑，而不是推翻重来。
最后，抛出一个问题给大家讨论：你公司项目里是怎么处理的？特别是遇到“跨天打卡”（比如 23:50 下班，00:10 才刷脸）这种边界情况，你们是算前一天的下班，还是后一天的上班？欢迎在评论区分享你的踩坑经验。 
长河君 · 2026/9/22 4:19:07 · 阅读 1.2k 员工考勤管理办法源码解析：3个坑让打卡数据不丢
员工考勤管理办法源码解析：3个坑让打卡数据不丢
盯着屏幕上的 StackTrace 报错，红色的字一行接一行，心跳直接飙到一百八。这场景太熟了，HR 拿着考勤表找上开发，说“上个月王五的迟到记录怎么没了？”，你心里咯噔一下。别慌，这时候光看业务逻辑代码是没用的，必须往下钻，看底层数据是怎么存的。这就是我们要聊的【员工考勤管理办法】在系统里的实现，特别是它的【源码解析】。
很多团队把考勤系统做得很轻，觉得不就是个时间戳加个状态吗？错。考勤是法律风险的雷区，也是数据一致性的深水区。今天不聊虚的，直接拆解一个生产级考勤系统的核心代码，看看那些让你头秃的 Bug 是怎么产生的，又是怎么被源码设计规避的。
入口定位：为什么你的打卡接口慢如蜗牛
很多开发者在写考勤打卡接口时，第一反应是直接插入数据库。比如用户点击“打卡”，后端接收时间，INSERT INTO attendance (user_id, clock_in_time) VALUES (...)。看起来很干净，对吧？
但在高并发场景下，比如早上 9:00 到 9:15，全公司几百人同时打卡，这种简单写法会瞬间压垮数据库连接池。更糟糕的是，如果这时候网络抖动，用户点了两次，或者前端重试机制触发，你数据库里就会多出两条一模一样的记录。HR 月底算工资时，看到两条 9:01 的打卡记录，是算迟到还是正常？这就是典型的“最终一致性”缺失。
我们来看一个典型的错误入口设计：
// 错误的入口设计：缺乏幂等性检查
@PostMapping(/clock)
public ResultString clockIn(@RequestBody ClockRequest req) {
// 1. 直接获取当前时间
LocalDateTime now = LocalDateTime.now();
// 2. 构建实体对象
Attendance record = new Attendance();
record.setUserId(req.getUserId());
record.setClockTime(now);
record.setType(req.getType()); // IN or OUT
// 3. 直接保存，没有检查是否已存在
attendanceService.save(record);
return Result.success(打卡成功);
}
这段代码的问题在于它完全依赖数据库的唯一索引来兜底，而不是在应用层做防御。如果数据库锁等待超时，整个请求就会挂起，用户体验极差。真正的【员工考勤管理办法】落地代码，必须在入口层就做好“拦截”和“去重”。
核心片段：幂等性锁与状态机的博弈
解决并发打卡和重复请求的核心，不是简单的 if exists 判断，因为查询和插入之间有时间窗口（Race Condition）。我们需要引入分布式锁，或者利用数据库的行级锁特性。
下面这段代码展示了一个更稳健的核心处理逻辑，它结合了 Redis 分布式锁和数据库的状态机校验：
@Service
public class AttendanceCoreService {
private final RedisTemplateString, String redisTemplate;
private final JdbcTemplate jdbcTemplate;
/**
* 核心打卡逻辑：带幂等性保护
*/
public ClockResult processClock(ClockRequest req) {
// 1. 生成唯一业务键：用户ID + 日期 + 打卡类型
// 这样同一天同类型打卡，Key 是固定的
String idempotentKey = String.format(att:lock:%d:%s:%s,
req.getUserId(),
LocalDate.now().toString(),
req.getType());
// 2. 尝试获取分布式锁，超时时间设为 3 秒
// 如果获取失败，说明有重复请求正在处理中，直接返回“处理中”
Boolean isLocked = redisTemplate.opsForValue()
.setIfAbsent(idempotentKey, 1, 3, TimeUnit.SECONDS);
if (Boolean.FALSE.equals(isLocked)) {
// 快速失败，避免线程堆积
return ClockResult.duplicated(请求正在处理中，请勿重复提交);
}
try {
// 3. 查询当日该用户该类型的打卡记录
// 注意：这里使用 SELECT FOR UPDATE 防止并发写入
ListMapString, Object existingRecords = jdbcTemplate.queryForList(
SELECT id, status FROM attendance WHERE user_id = ? AND date = ? AND type = ? FOR UPDATE,
req.getUserId(), LocalDate.now(), req.getType()
);
if (!existingRecords.isEmpty()) {
// 4. 状态机校验：如果已经是“已确认”状态，拒绝修改
// 如果状态是“待确认”或“异常”，允许覆盖更新
String currentStatus = (String) existingRecords.get(0).get(status);
if (CONFIRMED.equals(currentStatus)) {
return ClockResult.error(该班次已确认，不可再次打卡);
}
// 5. 执行更新操作（而非插入），保证数据唯一性
jdbcTemplate.update(
UPDATE attendance SET clock_time = NOW(), status = 'PENDING' WHERE id = ?,
existingRecords.get(0).get(id)
);
return ClockResult.success(打卡时间已更新);
} else {
// 6. 如果不存在，则插入新记录
jdbcTemplate.update(
INSERT INTO attendance (user_id, date, type, clock_time, status) VALUES (?, ?, ?, NOW(), 'PENDING'),
req.getUserId(), LocalDate.now(), req.getType()
);
return ClockResult.success(打卡成功);
}
} finally {
// 7. 无论成功失败，务必释放锁
redisTemplate.delete(idempotentKey);
}
}
}
逐行拆解关键点：
idempotentKey 的构造：这是幂等性的灵魂。把用户、日期、类型组合成唯一键，确保同一业务动作只执行一次。
setIfAbsent (SETNX)：利用 Redis 的原子操作实现分布式锁。这里设置了 3 秒超时，防止服务宕机导致死锁。
SELECT ... FOR UPDATE：这是数据库层面的悲观锁。在 MySQL InnoDB 引擎下，这会锁定查询到的行，防止其他事务同时修改这条数据。
状态机校验：注意代码中没有直接删除重插，而是根据 status 判断。如果考勤记录已经被 HR 确认（CONFIRMED），后端直接拒绝修改。这符合【员工考勤管理办法】中“事后不可逆”的合规要求。
finally 释放锁：这是最容易被新手忽略的地方。如果不在 finally 块中释放锁，一旦中间抛异常，锁就会一直存在直到超时，导致用户短时间内无法再次打卡。
设计思想：为什么要把逻辑下沉到数据层？
很多初学者喜欢把逻辑写在 Service 层，用 Java 对象去对比时间。但在考勤这种对精确度要求极高的场景下，时间源必须统一。
在上述源码中，我们特意让数据库执行 NOW() 或 SYSDATE()，而不是使用 Java 的 LocalDateTime.now()。为什么？
因为 Java 服务可能部署在多个节点上，如果服务器 A 和服务器 B 的时钟不同步（哪怕只差几毫秒），会导致同一秒内打卡的用户被判定为不同状态。更严重的是，如果 Java 应用服务器时间比数据库慢，用户明明 8:59:59 打卡，数据库记录却是 9:00:01，这就产生了“假迟到”。
根据 ISO 8601 标准以及大多数云服务商的 NTP（网络时间协议） 官方文档建议，分布式系统中的时间同步误差应控制在毫秒级以内。但在代码层面，最稳妥的做法是以存储层的时间为准，应用层只负责传递“事件发生”的信号，而不负责定义“事件发生的时间”。
此外，这里的设计还隐含了一个思想：分离“打卡事实”与“考勤结果”。
clock_time 是事实，不可变（除了异常修正）。
status 是状态，随业务流转。
final_attendance 是结果，由定时任务计算。
这种分层设计，使得当公司调整考勤规则（比如从“迟到5分钟算旷工”改为“迟到1分钟算迟到”）时，只需要修改计算定时任务的逻辑，而无需清洗历史打卡数据。
手写简化版：如何在本地模拟测试？
为了让大家能跑通这段逻辑，这里提供一个简化的本地测试版本。我们假设不使用 Redis，而是使用 Java 内置的 ConcurrentHashMap 模拟锁，方便在 IDE 中直接调试。
import java.time.LocalDate;
import java.time.LocalDateTime;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.atomic.AtomicInteger;
public class SimpleAttendanceSimulator {
// 模拟 Redis 锁
private static final ConcurrentHashMapString, AtomicInteger lockMap = new ConcurrentHashMap();
// 模拟数据库表
private static final ConcurrentHashMapString, AttendanceRecord dbMap = new ConcurrentHashMap();
public static class AttendanceRecord {
public String userId;
public LocalDate date;
public String type;
public LocalDateTime time;
public String status;
public AttendanceRecord(String userId, LocalDate date, String type) {
this.userId = userId;
this.date = date;
this.type = type;
this.status = PENDING;
}
}
/**
* 简化版打卡逻辑
*/
public static String simulateClock(String userId, String type) {
LocalDate today = LocalDate.now();
String key = userId + _ + today + _ + type;
// 模拟获取锁：putIfAbsent 返回 null 表示获取成功
AtomicInteger counter = lockMap.putIfAbsent(key, new AtomicInteger(0));
if (counter != null) {
// 模拟锁被占用
return FAIL: Duplicate request detected;
}
try {
// 模拟数据库查询与更新
AttendanceRecord record = dbMap.computeIfAbsent(key, k - {
return new AttendanceRecord(userId, today, type);
});
// 模拟业务校验
if (CONFIRMED.equals(record.status)) {
return FAIL: Already confirmed;
}
// 更新时间和状态
record.time = LocalDateTime.now();
record.status = PENDING;
System.out.println(SUCCESS: + userId + + type + at + record.time);
return SUCCESS;
} finally {
// 释放锁
lockMap.remove(key);
}
}
public static void main(String[] args) {
// 测试1：正常打卡
simulateClock(User1001, IN);
// 测试2：重复打卡（模拟快速点击）
simulateClock(User1001, IN);
// 测试3：另一个用户
simulateClock(User1002, IN);
}
}
这段代码虽然简化了，但保留了核心的原子性操作思想。在实际项目中，请务必将 ConcurrentHashMap 替换为真正的分布式锁组件（如 Redisson），并将 dbMap 替换为真实的 JPA/MyBatis 操作。
应用场景：跨省转介与特殊班次处理
在实际落地【员工考勤管理办法】时，你会发现标准代码永远覆盖不了所有业务场景。比如，很多大厂有“多地办公”需求，员工在北京上班，但偶尔去上海出差。这时候，简单的 LocalDate.now() 就会失效，因为时区不同。
痛点场景：
员工在上海出差，当地时间是 9:00，北京时间是 9:00（假设无时差，但若有跨国则有时差）。如果系统只记录 UTC 时间，而不记录用户所在时区，月底统计时就会出错。
源码应对策略：
在 AttendanceRecord 中增加 timezone 字段。
public class AttendanceRecord {
// ... 其他字段
public String timezone; // 例如 Asia/Shanghai 或 America/New_York
public LocalDateTime localTime; // 用户当地感知的时间
public LocalDateTime utcTime; // 统一存储的 UTC 时间
}
在打卡接口中，强制要求前端传递 timezone 参数，并在后端进行校验：
// 后端校验时区合法性
if (!ZoneId.getAvailableZoneIds().contains(req.getTimezone())) {
throw new InvalidTimezoneException(Invalid timezone: + req.getTimezone());
}
// 转换时间
ZonedDateTime localZoned = ZonedDateTime.of(req.getLocalTime(), ZoneId.of(req.getTimezone()));
LocalDateTime utcTime = localZoned.withZoneSameInstant(ZoneOffset.UTC).toLocalDateTime();
这种处理在跨省转介办理或跨国协作场景中尤为关键。根据人社部关于流动人员人事档案管理服务的相关指引，虽然考勤本身不属于档案，但涉及薪资结算和社保缴纳地认定时，准确的时间与地点元数据是合规的基础。
另外，对于“特殊班次”（如轮班制、夜班），不要硬编码 if type == NIGHT。应该引入策略模式（Strategy Pattern），定义一个 AttendanceStrategy 接口，针对不同班次实现不同的校验逻辑。例如，夜班的“迟到”定义可能是“23:50 之后”，而白班是“09:00 之后”。将规则外置到配置文件或数据库中，代码才能保持简洁和可扩展。
总结与互动
写考勤系统，表面是写代码，底层是写规则，核心是防风险。从入口的幂等性设计，到数据层的时间统一，再到业务层的状态机流转，每一个环节都藏着坑。
源码解析的意义，不在于让你背下这几行代码，而是让你明白：为什么要加锁？为什么要用数据库时间？为什么要分状态？当你理解了这些“为什么”，下次面对 HR 提出的奇葩需求（比如“允许补卡但必须审批”）时，你就知道该在哪里扩展逻辑，而不是推翻重来。
最后，抛出一个问题给大家讨论：你公司项目里是怎么处理的？特别是遇到“跨天打卡”（比如 23:50 下班，00:10 才刷脸）这种边界情况，你们是算前一天的下班，还是后一天的上班？欢迎在评论区分享你的踩坑经验。