很多人第一次接到签到功能的需求时第一反应是“这不就是个打卡记录吗有什么难的”。等真正动手做才发现里面藏着不少门道跨天时间怎么算、连续天数怎么定义、补签之后连续天数要不要恢复、用户手机时间不准怎么处理。这篇文章我就把自己做签到、补签、连续签到天数的完整思路整理出来从表结构设计到核心接口实现再到容易踩的坑一次性讲清楚。先说下这套方案的适用场景。我做的是运动类APP里的签到模块用户每天打开APP完成一次签到可以领取积分奖励如果某天忘了签到可以通过补签卡补上首页要展示用户连续签到了多少天。这套设计在电商、内容社区、工具类APP里都能直接复用核心逻辑不依赖具体业务。1. 功能拆解与整体设计思路签到功能看起来就三个动作签到、补签、查看连续天数。但把这三个动作掰开揉碎了看涉及的问题比想象中多。先梳理一下用户侧的完整路径。用户打开APP首页日历上显示本月每天的签到状态已签到的日子是实心的没签的是空心今天会有醒目的“签到”按钮。用户点一下按钮按钮变成“已签到”积分到账连续签到天数加一。如果昨天漏签了系统会提示“您有1次补签机会”用户使用补签卡后昨天变成已签状态连续签到天数可能因此恢复。这个路径背后需要支撑的能力有签到记录的存储与幂等防止用户疯狂点击重复签到、签到状态的批量查询日历展示需要查一个月的数据、连续签到天数的实时计算、补签的资格校验与次数控制。我在刚接到这个需求时第一版方案只建了一张签到记录表每次查连续天数就count一下结果用户量一上来首页接口响应时间直接飙到十几秒。后来才明白签到功能虽然业务简单但对性能的要求一点不低尤其是连续天数查询这个动作会被首页、个人中心、签到页多处调用必须做缓存或者空间换时间的预处理。整体设计上我采用了“数据库记录事实 缓存承载查询 定时任务兜底”三层结构。数据库只负责记录每天的签到事实和补签事实保证数据的绝对可靠Redis缓存负责连续天数、今日签到状态这类高频查询定时任务每天凌晨计算一次所有用户的连续签到天数并落表作为缓存失效后的兜底数据源。这个方案有个很关键的好处无论用户怎么折腾补签、换设备、清缓存最终以数据库里的事实记录为准缓存和中间表都可以重建不会出现数据不一致的问题。2. 数据层设计一张记录表还是两张表签到数据模型的设计决定了后续所有接口的复杂度。我见过有人把签到记录和补签记录混在一张表里用一个sign_type字段区分结果查连续天数时逻辑绕来绕去维护起来非常痛苦。也有人给每天建一张表这种设计基本是给自己挖坑后面做统计报表的时候恨不得把表合并回去。我的做法是拆成两张表user_sign_record记录用户每天的签到事实user_sign_repair_record记录补签操作。两张表通过用户ID和签到日期关联。先看第一张表的结构CREATE TABLE user_sign_record ( id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 主键ID, user_id bigint(20) NOT NULL COMMENT 用户ID, sign_date date NOT NULL COMMENT 签到日期, sign_source tinyint(4) NOT NULL DEFAULT 1 COMMENT 签到渠道1-APP签到页2-活动弹窗3-任务中心, sign_type tinyint(4) NOT NULL DEFAULT 1 COMMENT 签到类型1-正常签到2-补签, repair_record_id bigint(20) DEFAULT NULL COMMENT 补签记录ID正常签到时为空, reward_points int(11) NOT NULL DEFAULT 0 COMMENT 本次签到获得的积分, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, update_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, PRIMARY KEY (id), UNIQUE KEY uk_user_date (user_id, sign_date), KEY idx_user_id (user_id), KEY idx_sign_date (sign_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户签到记录表;这个表里最核心的是uk_user_date这个唯一索引它从数据库层面保证了同一个用户同一天只能有一条有效记录这是幂等的第一道防线。用户就算在1毫秒内连点10次签到按钮也只有一条记录能插入成功。第二张补签记录表CREATE TABLE user_sign_repair_record ( id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 主键ID, user_id bigint(20) NOT NULL COMMENT 用户ID, repair_date date NOT NULL COMMENT 补签的日期, repair_card_cost int(11) NOT NULL DEFAULT 1 COMMENT 消耗补签卡数量, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, PRIMARY KEY (id), UNIQUE KEY uk_user_date (user_id, repair_date), KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户补签记录表;补签表也做了唯一约束防止用户重复提交补签请求导致同一天被补签两次。这里有个细节补签操作本身也会往user_sign_record里插入一条sign_type2的记录相当于补签是一个“先扣卡、再写签到记录”的组合操作两张表通过repair_record_id关联起来。关于用户手中的补签卡数量我单独建了user_asset表维护这个表不是签到模块专属的积分、优惠券之类的资产也放在里面。签到模块只用它的repair_card_count字段。为什么不在用户表里直接加一个字段因为用户资产表的更新频率很高单独拆表可以避免行锁竞争影响用户核心数据的读写。接下来是连续签到天数。我建了一张user_sign_continuous表专门存每个用户当前的连续签到天数CREATE TABLE user_sign_continuous ( id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 主键ID, user_id bigint(20) NOT NULL COMMENT 用户ID, continuous_days int(11) NOT NULL DEFAULT 0 COMMENT 当前连续签到天数, last_sign_date date NOT NULL COMMENT 最后一次签到日期, max_continuous_days int(11) NOT NULL DEFAULT 0 COMMENT 历史最高连续签到天数, update_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, PRIMARY KEY (id), UNIQUE KEY uk_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户连续签到统计表;这张表的设计思路是空间换时间。连续签到天数是一个被高频读取但低频更新的数据每次用户签到才更新一次但可能被查询几十次甚至上百次。单独用一张表存查询走主键索引性能非常稳定。max_continuous_days字段用来给运营做排行和勋章发放属于附带需求一起存了免得以后加字段。3. 核心接口实现签到、补签、连续天数计算3.1 签到接口的完整流程签到接口是整套系统的核心入口我直接把Spring Boot的代码贴出来配合注释说明每一步的作用。RestController RequestMapping(/api/sign) public class SignController { Autowired private SignService signService; /** * 用户签到 */ PostMapping(/doSign) public ResultSignResultVO doSign(RequestParam Long userId) { return Result.success(signService.doSign(userId)); } }签到服务层的核心逻辑Service public class SignServiceImpl implements SignService { Autowired private UserSignRecordMapper signRecordMapper; Autowired private UserSignRepairRecordMapper repairRecordMapper; Autowired private UserSignContinuousMapper continuousMapper; Autowired private UserAssetMapper assetMapper; Autowired private RedisTemplateString, String redisTemplate; Transactional(rollbackFor Exception.class) Override public SignResultVO doSign(Long userId) { LocalDate today LocalDate.now(); // 第一步尝试插入签到记录利用唯一索引保证幂等 UserSignRecord record new UserSignRecord(); record.setUserId(userId); record.setSignDate(today); record.setSignSource(1); record.setSignType(1); record.setRewardPoints(calculateReward(userId, today)); try { signRecordMapper.insert(record); } catch (DuplicateKeyException e) { // 说明今天已经签到了直接返回已签到状态 return SignResultVO.alreadySigned(); } // 第二步扣减补签卡如果有的话正常签到不扣 // 注实际流程这里不需要扣卡扣卡在补签接口里做 // 第三步更新连续签到天数 UserSignContinuous continuous continuousMapper.selectByUserIdForUpdate(userId); int newContinuousDays 1; if (continuous ! null) { LocalDate lastSignDate continuous.getLastSignDate(); if (lastSignDate.equals(today)) { // 理论上不会走到这里因为第一步已经做了幂等 newContinuousDays continuous.getContinuousDays(); } else if (lastSignDate.equals(today.minusDays(1))) { // 昨天签到了连续天数1 newContinuousDays continuous.getContinuousDays() 1; } else { // 昨天没签到连续天数重置为1 newContinuousDays 1; } continuous.setContinuousDays(newContinuousDays); continuous.setLastSignDate(today); continuous.setMaxContinuousDays( Math.max(continuous.getMaxContinuousDays(), newContinuousDays) ); continuousMapper.updateById(continuous); } else { // 第一次签到直接初始化 UserSignContinuous newRecord new UserSignContinuous(); newRecord.setUserId(userId); newRecord.setContinuousDays(1); newRecord.setLastSignDate(today); newRecord.setMaxContinuousDays(1); continuousMapper.insert(newRecord); } // 第四步刷新缓存中的连续签到天数 String cacheKey sign:continuous: userId; redisTemplate.opsForValue().set(cacheKey, String.valueOf(newContinuousDays), 7, TimeUnit.DAYS); // 第五步同步积分到用户资产可以走消息队列异步这里为了演示直接调用 assetMapper.addPoints(userId, record.getRewardPoints()); SignResultVO vo new SignResultVO(); vo.setSigned(true); vo.setContinuousDays(newContinuousDays); vo.setRewardPoints(record.getRewardPoints()); return vo; } private int calculateReward(Long userId, LocalDate date) { // 连续签到7天给高额积分平时给基础积分 UserSignContinuous continuous continuousMapper.selectByUserId(userId); int days continuous ! null ? continuous.getContinuousDays() : 0; if ((days 1) % 7 0) { return 100; } return 5; } }这段代码有几个值得细说的点。第一步的幂等处理是整个接口的根基。我见过很多人在代码里先select再insert用代码判断是否已经签到这在并发场景下是有问题的。两个请求同时查到“未签到”然后同时执行插入就会产生重复数据。利用数据库唯一索引加DuplicateKeyException捕获是最稳妥的幂等方案不管多少并发打过来保证只有一条记录落库。第三步更新连续天数的时候用了selectByUserIdForUpdate也就是SELECT ... FOR UPDATE把用户对应的连续签到记录行锁住。这个锁的意义在于如果一个用户正好在跨天的时候并发请求23:59:59和00:00:00各来一次两次请求可能拿到不同的today进而计算出错误的连续天数。加锁之后两次请求串行执行后执行的那个会基于前一个的结果重新判断逻辑就对了。这里我不建议用Redis分布式锁来代替数据库行锁。原因很简单分布式锁需要考虑锁的粒度、过期时间、释放时机稍微处理不当就会出现死锁或者重复执行而数据库行锁在这个场景下性能足够用户量再大同一时刻对同一个用户签到记录的并发也极低还能和事务保持一致事务回滚时锁自动释放省心很多。3.2 补签接口扣卡、补记录、恢复连续补签的逻辑比正常签到复杂在两点一是要校验补签资格有没有卡、补签日期是否在允许范围内、补签日期是否真的没签到二是补签之后连续天数怎么变。先看代码Transactional(rollbackFor Exception.class) Override public SignResultVO doRepair(Long userId, LocalDate repairDate) { LocalDate today LocalDate.now(); // 第一步校验补签日期是否在允许范围内只能补签近7天 if (repairDate.isAfter(today.minusDays(1)) || repairDate.isBefore(today.minusDays(7))) { throw new BizException(只能补签昨天起前7天内的签到记录); } // 第二步校验目标日期是否已有签到记录 UserSignRecord existRecord signRecordMapper.selectByUserAndDate(userId, repairDate); if (existRecord ! null) { throw new BizException(该日期已签到无需补签); } // 第三步校验补签卡数量 UserAsset asset assetMapper.selectByUserIdForUpdate(userId); if (asset.getRepairCardCount() 0) { throw new BizException(补签卡不足); } // 第四步扣减补签卡 assetMapper.decreaseRepairCard(userId, 1); // 第五步插入补签记录 UserSignRepairRecord repairRecord new UserSignRepairRecord(); repairRecord.setUserId(userId); repairRecord.setRepairDate(repairDate); repairRecord.setRepairCardCost(1); repairRecordMapper.insert(repairRecord); // 第六步插入签到记录标记为补签 UserSignRecord signRecord new UserSignRecord(); signRecord.setUserId(userId); signRecord.setSignDate(repairDate); signRecord.setSignSource(1); signRecord.setSignType(2); signRecord.setRepairRecordId(repairRecord.getId()); signRecord.setRewardPoints(0); // 补签不再发基础积分 signRecordMapper.insert(signRecord); // 第七步重新计算连续签到天数 recalculateContinuousDays(userId, repairDate); SignResultVO vo new SignResultVO(); vo.setSigned(true); vo.setRepairDate(repairDate); return vo; }补签日期范围限制这个逻辑不同产品的定义不一样。有些产品允许任意补签有些只允许补签最近3天我这里写的是7天具体按运营策略调。重点是范围校验一定放在最前面避免后面查询和扣卡操作白做。第七步的重新计算连续天数是补签功能里最容易出问题的地方。假设一个用户的历史签到记录是1号签、2号签、4号签、5号签3号漏了所以4号签到时候连续天数重置为1因为2号和4号不连续。现在用户补签了3号那么1号到5号变成了连续的5天连续签到天数应该从1恢复为5。实现方式是把该用户最近一段时间比如从最早补签日期往前推30天的签到记录全查出来从最早的日期开始逐天遍历算出一个最新的连续值private void recalculateContinuousDays(Long userId, LocalDate repairDate) { // 查从补签日期往前推30天到今天的签到记录 LocalDate startDate repairDate.minusDays(30); ListUserSignRecord records signRecordMapper.selectByUserAndDateRange( userId, startDate, LocalDate.now() ); SetLocalDate signDateSet records.stream() .map(UserSignRecord::getSignDate) .collect(Collectors.toSet()); int continuousDays 0; LocalDate cursor LocalDate.now(); // 如果今天没签到从昨天开始往前数 if (!signDateSet.contains(cursor)) { cursor cursor.minusDays(1); } while (signDateSet.contains(cursor)) { continuousDays; cursor cursor.minusDays(1); } UserSignContinuous continuous continuousMapper.selectByUserIdForUpdate(userId); if (continuous null) { continuous new UserSignContinuous(); continuous.setUserId(userId); continuous.setLastSignDate(LocalDate.now()); continuous.setMaxContinuousDays(continuousDays); continuousMapper.insert(continuous); } else { continuous.setContinuousDays(continuousDays); continuous.setLastSignDate(LocalDate.now()); continuous.setMaxContinuousDays( Math.max(continuous.getMaxContinuousDays(), continuousDays) ); continuousMapper.updateById(continuous); } // 同步更新Redis缓存 String cacheKey sign:continuous: userId; redisTemplate.opsForValue().set(cacheKey, String.valueOf(continuousDays), 7, TimeUnit.DAYS); }这里有个细节差点坑了我如果用户今天已经签到了lastSignDate就是今天遍历从今天开始往前数如果用户今天还没签到今天的签到状态不能算进连续天数的“中断判断”里。举个例子用户昨天签了、今天还没签连续签到天数应该是“昨天之前的连续值”而不是0。如果遍历逻辑从今天开始判断发现今天没签名就会直接返回0这是错的。所以上面代码里先判断今天是否签到没签到就从昨天开始往前数这个顺序很关键。补签不发积分这个也是产品策略不是技术必须。我见过有些产品的补签会发一半积分这样设置的话把rewardPoints改成对应值就行。但有一点要注意补签记录的积分不能参与连续签到7天的阶梯奖励计算否则用户可以用补签卡无限刷积分。3.3 查询连续签到天数的两种方式连续签到天数的读取路径有两条一条是用户打开签到页时实时查另一条是其他业务模块比如做活动、发勋章需要批量获取用户连续签到数据时读取。两条路径我用了不同的实现。实时查询路径走Redis缓存Override public int getContinuousDays(Long userId) { String cacheKey sign:continuous: userId; String cachedValue redisTemplate.opsForValue().get(cacheKey); if (cachedValue ! null) { return Integer.parseInt(cachedValue); } // 缓存未命中查数据库 UserSignContinuous continuous continuousMapper.selectByUserId(userId); int days continuous ! null ? continuous.getContinuousDays() : 0; // 回填缓存 redisTemplate.opsForValue().set(cacheKey, String.valueOf(days), 7, TimeUnit.DAYS); return days; }缓存过期时间设置成7天是因为如果用户连续7天没有做任何签到操作缓存中存的连续天数大概率已经失效了值可能已经被重置重新从数据库读一次更保险。这个过期时间其实不敏感因为每次签到都会主动刷新缓存即使缓存过期后回源数据库拿到的也是最新的值。批量查询场景就没这么简单了。运营催了一个“连续打卡7天用户发勋章”的活动运营同学直接扔给我一个几万人的用户ID列表让我算出每个用户的连续天数。这种场景如果还是一条一条查接口得跑几个小时。我的做法是写一个批量刷新的定时任务直接走MySQL查询用一次IN查询把目标用户的连续签到记录全取出来代码里批量计算后批量更新。如果数据量更大几十万用户就得考虑用LIMIT分批处理避免一次加载太多数据把内存打爆。4. 签到日历与状态展示的实现细节日历展示这块是前端工作量大、后端容易被低估的部分。用户在签到页看到的不是一个简单的“今天是否已签”而是整个月每一天的状态签到、补签、漏签、未来日期。后端要提供一个能一次返回整月状态的接口。接口设计如下GetMapping(/monthStatus) public ResultMonthSignStatusVO getMonthStatus( RequestParam Long userId, RequestParam(required false) String yearMonth) { // yearMonth格式2025-06默认当前月份 YearMonth ym yearMonth ! null ? YearMonth.parse(yearMonth) : YearMonth.now(); LocalDate startDate ym.atDay(1); LocalDate endDate ym.atEndOfMonth(); ListUserSignRecord records signRecordMapper.selectByUserAndDateRange( userId, startDate, endDate ); // 按日期分组方便前端按天渲染 MapLocalDate, UserSignRecord recordMap records.stream() .collect(Collectors.toMap(UserSignRecord::getSignDate, Function.identity())); MonthSignStatusVO vo new MonthSignStatusVO(); vo.setYearMonth(ym.toString()); vo.setToday(LocalDate.now()); ListDaySignStatus dayList new ArrayList(); for (int day 1; day ym.lengthOfMonth(); day) { LocalDate date ym.atDay(day); UserSignRecord record recordMap.get(date); DaySignStatus status new DaySignStatus(); status.setDate(date); status.setDayOfMonth(day); if (date.isAfter(LocalDate.now())) { status.setStatus(0); // 未来日期不可签到 } else if (record ! null record.getSignType() 2) { status.setStatus(3); // 补签 } else if (record ! null) { status.setStatus(1); // 已签到 } else { status.setStatus(2); // 漏签 } dayList.add(status); } vo.setDayList(dayList); return Result.success(vo); }这个接口把状态判断的逻辑全部放在后端前端只需要拿到状态数字然后渲染对应的样式即可避免前端重复实现日期判断逻辑导致不一致。状态码设计为0、1、2、3四个值对应未来、已签、漏签、补签每个值对应一种UI样式。补签单独一个状态是为了让用户快速看出哪几天是补签的配合补签记录详情做展示。日历接口要注意的一个优化点列表查询只查当月记录不需要把历史数据全查出来。selectByUserAndDateRange的SQL要走到idx_user_id和idx_sign_date这两个索引联合索引或者分别用两个索引都行避免全表扫描。5. 踩坑实录与排查技巧做签到功能这一路下来踩过的坑不少挑几个有代表性的分享出来这些都是在联调测试和线上运维中真实遇到的问题。第一个坑是Android和iOS设备时间不一致导致签到日期错乱。用户把手机时间改成未来某天提前把明天的签到做了到了真正那天再签到就提示“今日已签到”连续天数计算也跟着乱套。这个问题的处理思路是前端上报设备时间和时区后端以服务器时间为准并且对时间偏移超过一定阈值比如5分钟的请求直接拒绝。实现上很简单签到接口加一个参数clientTime后端校验Math.abs(now - clientTime)是否超过阈值超过就返回“设备时间异常”的提示。第二个坑是补签和正常签到并发时连续天数可能计算错误。场景是这样的用户当天签到请求还在处理中同时发起了昨天的补签请求两个事务互不知道对方的存在各自计算连续天数然后更新后提交的覆盖先提交的导致结果不准。解法是统一加同一把行锁补签接口里selectByUserIdForUpdate和签到接口里selectByUserIdForUpdate拿的是同一行记录上的锁任何一个事务先拿到锁另一个就必须等它提交或回滚才能继续。这个锁机制天然保证了串行化不需要额外处理。第三个坑是Redis缓存与数据库不一致。签到成功后先更新数据库再更新缓存如果Redis操作失败网络抖动、内存满了触发淘汰策略数据库已经加了连续天数缓存还是旧值。我在代码里用了“先更新数据库再删除缓存”的模式而不是“先更新数据库再更新缓存”。删除缓存后下一次查询会回源数据库然后重新填充缓存这样即使删除缓存失败也没有太大问题最多是缓存里的旧值多存活一会等下一次签到或缓存过期时自动修复。这个模式和缓存雪崩、缓存穿透那些问题一样属于Redis使用中必须掌握的基础规范。第四个坑是定时任务重算连续天数时如果刚好有用户在签到会互相覆盖。比如凌晨00:00:10的任务开始重算用户A的数据00:00:15用户A签到了任务算完的结果是旧的没包含今天签到直接把用户A的连续天数覆盖回去了。解决办法是在定时任务里查询用户数据时跳过最近5分钟内有签到操作的用户或者在定时任务执行时也使用SELECT FOR UPDATE锁住该用户记录。我在做签到功能的过程中最深的感触是越是看起来简单的业务越要在数据一致性和并发控制上下足功夫。签到本身只是一个状态变更但当它承载了积分、勋章、排行榜这些运营价值时任何数据错误都会被放大到用户投诉甚至客诉的层面。贴一个我总结的常见问题速查表都是实际开发中高频出现的问题和对应的排查思路问题现象可能原因排查与处理用户反复点击签到积分发放多次缺少幂等控制检查user_sign_record表是否加了uk_user_date唯一索引检查签到接口是否捕获DuplicateKeyException连续签到天数莫名重置为1时区问题导致日期判断错误昨天签到但今天没签被误判为断签确认服务器时区为Asia/Shanghai检查连续天数计算逻辑中“今天未签不从今天开始判断”的分支补签后连续天数没恢复补签记录未写入重算逻辑遍历范围不够确认补签后recalculateContinuousDays被调用检查重算时startDate是否覆盖到需要的前置日期凌晨签到数据被定时任务覆盖定时任务和签到请求并发定时任务改为跳过近5分钟活跃用户或对用户记录使用SELECT FOR UPDATE日历状态和实际签到记录不一致状态判断逻辑重复且不统一统一由后端接口返回状态码前端只做渲染不判断业务逻辑缓存中的连续天数和数据库不一致缓存更新失败或缓存删除失败使用“先更新数据库、再删除缓存”模式确认删除缓存的finally块有兜底处理还有一个关于前端联调的细节日历组件在渲染“今天”的时候如果用户已经签到按钮要置灰并显示“已签到”如果没签到按钮要高亮显示。这个判断最好也用后端返回的todaySigned字段不要依赖前端本地时间原因还是设备时间可能不准。最后再分享一个链路追踪的小技巧。签到接口涉及数据库、Redis、可能还有消息队列排查问题时如果每一步没有日志出问题根本不知道卡在哪里。我在doSign和doRepair的每个关键步骤都打了带用户ID追踪ID的日志格式统一为[sign][userId123] step: xxx, result: xxx线上排查问题的时候直接grep用户ID就能看到这个用户从请求进入数据库到缓存更新的完整时间线定位问题非常快。签到功能做完到现在运营又陆续提了补签卡赠送、连续签到翻倍积分、签到提醒推送这些需求但底层的数据模型和核心逻辑都没怎么动过只是在新需求上做增量扩展。这也验证了我当时的判断把签到事实、补签事实、连续统计分开建模虽然前期多写了几张表但后续扩展非常轻松。如果你也正在做类似功能我建议你在一开始就按照这个思路把数据层设计好不要在“先凑合能用”和“一步到位”之间犹豫签到功能的数据模型一旦上线后期改造成本远高于前期设计成本。 
长河君 · 2026/9/15 9:54:22 · 阅读 1.2k 签到系统设计：补签、连续天数与并发控制的完整实践
很多人第一次接到签到功能的需求时第一反应是“这不就是个打卡记录吗有什么难的”。等真正动手做才发现里面藏着不少门道跨天时间怎么算、连续天数怎么定义、补签之后连续天数要不要恢复、用户手机时间不准怎么处理。这篇文章我就把自己做签到、补签、连续签到天数的完整思路整理出来从表结构设计到核心接口实现再到容易踩的坑一次性讲清楚。先说下这套方案的适用场景。我做的是运动类APP里的签到模块用户每天打开APP完成一次签到可以领取积分奖励如果某天忘了签到可以通过补签卡补上首页要展示用户连续签到了多少天。这套设计在电商、内容社区、工具类APP里都能直接复用核心逻辑不依赖具体业务。1. 功能拆解与整体设计思路签到功能看起来就三个动作签到、补签、查看连续天数。但把这三个动作掰开揉碎了看涉及的问题比想象中多。先梳理一下用户侧的完整路径。用户打开APP首页日历上显示本月每天的签到状态已签到的日子是实心的没签的是空心今天会有醒目的“签到”按钮。用户点一下按钮按钮变成“已签到”积分到账连续签到天数加一。如果昨天漏签了系统会提示“您有1次补签机会”用户使用补签卡后昨天变成已签状态连续签到天数可能因此恢复。这个路径背后需要支撑的能力有签到记录的存储与幂等防止用户疯狂点击重复签到、签到状态的批量查询日历展示需要查一个月的数据、连续签到天数的实时计算、补签的资格校验与次数控制。我在刚接到这个需求时第一版方案只建了一张签到记录表每次查连续天数就count一下结果用户量一上来首页接口响应时间直接飙到十几秒。后来才明白签到功能虽然业务简单但对性能的要求一点不低尤其是连续天数查询这个动作会被首页、个人中心、签到页多处调用必须做缓存或者空间换时间的预处理。整体设计上我采用了“数据库记录事实 缓存承载查询 定时任务兜底”三层结构。数据库只负责记录每天的签到事实和补签事实保证数据的绝对可靠Redis缓存负责连续天数、今日签到状态这类高频查询定时任务每天凌晨计算一次所有用户的连续签到天数并落表作为缓存失效后的兜底数据源。这个方案有个很关键的好处无论用户怎么折腾补签、换设备、清缓存最终以数据库里的事实记录为准缓存和中间表都可以重建不会出现数据不一致的问题。2. 数据层设计一张记录表还是两张表签到数据模型的设计决定了后续所有接口的复杂度。我见过有人把签到记录和补签记录混在一张表里用一个sign_type字段区分结果查连续天数时逻辑绕来绕去维护起来非常痛苦。也有人给每天建一张表这种设计基本是给自己挖坑后面做统计报表的时候恨不得把表合并回去。我的做法是拆成两张表user_sign_record记录用户每天的签到事实user_sign_repair_record记录补签操作。两张表通过用户ID和签到日期关联。先看第一张表的结构CREATE TABLE user_sign_record ( id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 主键ID, user_id bigint(20) NOT NULL COMMENT 用户ID, sign_date date NOT NULL COMMENT 签到日期, sign_source tinyint(4) NOT NULL DEFAULT 1 COMMENT 签到渠道1-APP签到页2-活动弹窗3-任务中心, sign_type tinyint(4) NOT NULL DEFAULT 1 COMMENT 签到类型1-正常签到2-补签, repair_record_id bigint(20) DEFAULT NULL COMMENT 补签记录ID正常签到时为空, reward_points int(11) NOT NULL DEFAULT 0 COMMENT 本次签到获得的积分, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, update_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, PRIMARY KEY (id), UNIQUE KEY uk_user_date (user_id, sign_date), KEY idx_user_id (user_id), KEY idx_sign_date (sign_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户签到记录表;这个表里最核心的是uk_user_date这个唯一索引它从数据库层面保证了同一个用户同一天只能有一条有效记录这是幂等的第一道防线。用户就算在1毫秒内连点10次签到按钮也只有一条记录能插入成功。第二张补签记录表CREATE TABLE user_sign_repair_record ( id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 主键ID, user_id bigint(20) NOT NULL COMMENT 用户ID, repair_date date NOT NULL COMMENT 补签的日期, repair_card_cost int(11) NOT NULL DEFAULT 1 COMMENT 消耗补签卡数量, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, PRIMARY KEY (id), UNIQUE KEY uk_user_date (user_id, repair_date), KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户补签记录表;补签表也做了唯一约束防止用户重复提交补签请求导致同一天被补签两次。这里有个细节补签操作本身也会往user_sign_record里插入一条sign_type2的记录相当于补签是一个“先扣卡、再写签到记录”的组合操作两张表通过repair_record_id关联起来。关于用户手中的补签卡数量我单独建了user_asset表维护这个表不是签到模块专属的积分、优惠券之类的资产也放在里面。签到模块只用它的repair_card_count字段。为什么不在用户表里直接加一个字段因为用户资产表的更新频率很高单独拆表可以避免行锁竞争影响用户核心数据的读写。接下来是连续签到天数。我建了一张user_sign_continuous表专门存每个用户当前的连续签到天数CREATE TABLE user_sign_continuous ( id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 主键ID, user_id bigint(20) NOT NULL COMMENT 用户ID, continuous_days int(11) NOT NULL DEFAULT 0 COMMENT 当前连续签到天数, last_sign_date date NOT NULL COMMENT 最后一次签到日期, max_continuous_days int(11) NOT NULL DEFAULT 0 COMMENT 历史最高连续签到天数, update_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, PRIMARY KEY (id), UNIQUE KEY uk_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户连续签到统计表;这张表的设计思路是空间换时间。连续签到天数是一个被高频读取但低频更新的数据每次用户签到才更新一次但可能被查询几十次甚至上百次。单独用一张表存查询走主键索引性能非常稳定。max_continuous_days字段用来给运营做排行和勋章发放属于附带需求一起存了免得以后加字段。3. 核心接口实现签到、补签、连续天数计算3.1 签到接口的完整流程签到接口是整套系统的核心入口我直接把Spring Boot的代码贴出来配合注释说明每一步的作用。RestController RequestMapping(/api/sign) public class SignController { Autowired private SignService signService; /** * 用户签到 */ PostMapping(/doSign) public ResultSignResultVO doSign(RequestParam Long userId) { return Result.success(signService.doSign(userId)); } }签到服务层的核心逻辑Service public class SignServiceImpl implements SignService { Autowired private UserSignRecordMapper signRecordMapper; Autowired private UserSignRepairRecordMapper repairRecordMapper; Autowired private UserSignContinuousMapper continuousMapper; Autowired private UserAssetMapper assetMapper; Autowired private RedisTemplateString, String redisTemplate; Transactional(rollbackFor Exception.class) Override public SignResultVO doSign(Long userId) { LocalDate today LocalDate.now(); // 第一步尝试插入签到记录利用唯一索引保证幂等 UserSignRecord record new UserSignRecord(); record.setUserId(userId); record.setSignDate(today); record.setSignSource(1); record.setSignType(1); record.setRewardPoints(calculateReward(userId, today)); try { signRecordMapper.insert(record); } catch (DuplicateKeyException e) { // 说明今天已经签到了直接返回已签到状态 return SignResultVO.alreadySigned(); } // 第二步扣减补签卡如果有的话正常签到不扣 // 注实际流程这里不需要扣卡扣卡在补签接口里做 // 第三步更新连续签到天数 UserSignContinuous continuous continuousMapper.selectByUserIdForUpdate(userId); int newContinuousDays 1; if (continuous ! null) { LocalDate lastSignDate continuous.getLastSignDate(); if (lastSignDate.equals(today)) { // 理论上不会走到这里因为第一步已经做了幂等 newContinuousDays continuous.getContinuousDays(); } else if (lastSignDate.equals(today.minusDays(1))) { // 昨天签到了连续天数1 newContinuousDays continuous.getContinuousDays() 1; } else { // 昨天没签到连续天数重置为1 newContinuousDays 1; } continuous.setContinuousDays(newContinuousDays); continuous.setLastSignDate(today); continuous.setMaxContinuousDays( Math.max(continuous.getMaxContinuousDays(), newContinuousDays) ); continuousMapper.updateById(continuous); } else { // 第一次签到直接初始化 UserSignContinuous newRecord new UserSignContinuous(); newRecord.setUserId(userId); newRecord.setContinuousDays(1); newRecord.setLastSignDate(today); newRecord.setMaxContinuousDays(1); continuousMapper.insert(newRecord); } // 第四步刷新缓存中的连续签到天数 String cacheKey sign:continuous: userId; redisTemplate.opsForValue().set(cacheKey, String.valueOf(newContinuousDays), 7, TimeUnit.DAYS); // 第五步同步积分到用户资产可以走消息队列异步这里为了演示直接调用 assetMapper.addPoints(userId, record.getRewardPoints()); SignResultVO vo new SignResultVO(); vo.setSigned(true); vo.setContinuousDays(newContinuousDays); vo.setRewardPoints(record.getRewardPoints()); return vo; } private int calculateReward(Long userId, LocalDate date) { // 连续签到7天给高额积分平时给基础积分 UserSignContinuous continuous continuousMapper.selectByUserId(userId); int days continuous ! null ? continuous.getContinuousDays() : 0; if ((days 1) % 7 0) { return 100; } return 5; } }这段代码有几个值得细说的点。第一步的幂等处理是整个接口的根基。我见过很多人在代码里先select再insert用代码判断是否已经签到这在并发场景下是有问题的。两个请求同时查到“未签到”然后同时执行插入就会产生重复数据。利用数据库唯一索引加DuplicateKeyException捕获是最稳妥的幂等方案不管多少并发打过来保证只有一条记录落库。第三步更新连续天数的时候用了selectByUserIdForUpdate也就是SELECT ... FOR UPDATE把用户对应的连续签到记录行锁住。这个锁的意义在于如果一个用户正好在跨天的时候并发请求23:59:59和00:00:00各来一次两次请求可能拿到不同的today进而计算出错误的连续天数。加锁之后两次请求串行执行后执行的那个会基于前一个的结果重新判断逻辑就对了。这里我不建议用Redis分布式锁来代替数据库行锁。原因很简单分布式锁需要考虑锁的粒度、过期时间、释放时机稍微处理不当就会出现死锁或者重复执行而数据库行锁在这个场景下性能足够用户量再大同一时刻对同一个用户签到记录的并发也极低还能和事务保持一致事务回滚时锁自动释放省心很多。3.2 补签接口扣卡、补记录、恢复连续补签的逻辑比正常签到复杂在两点一是要校验补签资格有没有卡、补签日期是否在允许范围内、补签日期是否真的没签到二是补签之后连续天数怎么变。先看代码Transactional(rollbackFor Exception.class) Override public SignResultVO doRepair(Long userId, LocalDate repairDate) { LocalDate today LocalDate.now(); // 第一步校验补签日期是否在允许范围内只能补签近7天 if (repairDate.isAfter(today.minusDays(1)) || repairDate.isBefore(today.minusDays(7))) { throw new BizException(只能补签昨天起前7天内的签到记录); } // 第二步校验目标日期是否已有签到记录 UserSignRecord existRecord signRecordMapper.selectByUserAndDate(userId, repairDate); if (existRecord ! null) { throw new BizException(该日期已签到无需补签); } // 第三步校验补签卡数量 UserAsset asset assetMapper.selectByUserIdForUpdate(userId); if (asset.getRepairCardCount() 0) { throw new BizException(补签卡不足); } // 第四步扣减补签卡 assetMapper.decreaseRepairCard(userId, 1); // 第五步插入补签记录 UserSignRepairRecord repairRecord new UserSignRepairRecord(); repairRecord.setUserId(userId); repairRecord.setRepairDate(repairDate); repairRecord.setRepairCardCost(1); repairRecordMapper.insert(repairRecord); // 第六步插入签到记录标记为补签 UserSignRecord signRecord new UserSignRecord(); signRecord.setUserId(userId); signRecord.setSignDate(repairDate); signRecord.setSignSource(1); signRecord.setSignType(2); signRecord.setRepairRecordId(repairRecord.getId()); signRecord.setRewardPoints(0); // 补签不再发基础积分 signRecordMapper.insert(signRecord); // 第七步重新计算连续签到天数 recalculateContinuousDays(userId, repairDate); SignResultVO vo new SignResultVO(); vo.setSigned(true); vo.setRepairDate(repairDate); return vo; }补签日期范围限制这个逻辑不同产品的定义不一样。有些产品允许任意补签有些只允许补签最近3天我这里写的是7天具体按运营策略调。重点是范围校验一定放在最前面避免后面查询和扣卡操作白做。第七步的重新计算连续天数是补签功能里最容易出问题的地方。假设一个用户的历史签到记录是1号签、2号签、4号签、5号签3号漏了所以4号签到时候连续天数重置为1因为2号和4号不连续。现在用户补签了3号那么1号到5号变成了连续的5天连续签到天数应该从1恢复为5。实现方式是把该用户最近一段时间比如从最早补签日期往前推30天的签到记录全查出来从最早的日期开始逐天遍历算出一个最新的连续值private void recalculateContinuousDays(Long userId, LocalDate repairDate) { // 查从补签日期往前推30天到今天的签到记录 LocalDate startDate repairDate.minusDays(30); ListUserSignRecord records signRecordMapper.selectByUserAndDateRange( userId, startDate, LocalDate.now() ); SetLocalDate signDateSet records.stream() .map(UserSignRecord::getSignDate) .collect(Collectors.toSet()); int continuousDays 0; LocalDate cursor LocalDate.now(); // 如果今天没签到从昨天开始往前数 if (!signDateSet.contains(cursor)) { cursor cursor.minusDays(1); } while (signDateSet.contains(cursor)) { continuousDays; cursor cursor.minusDays(1); } UserSignContinuous continuous continuousMapper.selectByUserIdForUpdate(userId); if (continuous null) { continuous new UserSignContinuous(); continuous.setUserId(userId); continuous.setLastSignDate(LocalDate.now()); continuous.setMaxContinuousDays(continuousDays); continuousMapper.insert(continuous); } else { continuous.setContinuousDays(continuousDays); continuous.setLastSignDate(LocalDate.now()); continuous.setMaxContinuousDays( Math.max(continuous.getMaxContinuousDays(), continuousDays) ); continuousMapper.updateById(continuous); } // 同步更新Redis缓存 String cacheKey sign:continuous: userId; redisTemplate.opsForValue().set(cacheKey, String.valueOf(continuousDays), 7, TimeUnit.DAYS); }这里有个细节差点坑了我如果用户今天已经签到了lastSignDate就是今天遍历从今天开始往前数如果用户今天还没签到今天的签到状态不能算进连续天数的“中断判断”里。举个例子用户昨天签了、今天还没签连续签到天数应该是“昨天之前的连续值”而不是0。如果遍历逻辑从今天开始判断发现今天没签名就会直接返回0这是错的。所以上面代码里先判断今天是否签到没签到就从昨天开始往前数这个顺序很关键。补签不发积分这个也是产品策略不是技术必须。我见过有些产品的补签会发一半积分这样设置的话把rewardPoints改成对应值就行。但有一点要注意补签记录的积分不能参与连续签到7天的阶梯奖励计算否则用户可以用补签卡无限刷积分。3.3 查询连续签到天数的两种方式连续签到天数的读取路径有两条一条是用户打开签到页时实时查另一条是其他业务模块比如做活动、发勋章需要批量获取用户连续签到数据时读取。两条路径我用了不同的实现。实时查询路径走Redis缓存Override public int getContinuousDays(Long userId) { String cacheKey sign:continuous: userId; String cachedValue redisTemplate.opsForValue().get(cacheKey); if (cachedValue ! null) { return Integer.parseInt(cachedValue); } // 缓存未命中查数据库 UserSignContinuous continuous continuousMapper.selectByUserId(userId); int days continuous ! null ? continuous.getContinuousDays() : 0; // 回填缓存 redisTemplate.opsForValue().set(cacheKey, String.valueOf(days), 7, TimeUnit.DAYS); return days; }缓存过期时间设置成7天是因为如果用户连续7天没有做任何签到操作缓存中存的连续天数大概率已经失效了值可能已经被重置重新从数据库读一次更保险。这个过期时间其实不敏感因为每次签到都会主动刷新缓存即使缓存过期后回源数据库拿到的也是最新的值。批量查询场景就没这么简单了。运营催了一个“连续打卡7天用户发勋章”的活动运营同学直接扔给我一个几万人的用户ID列表让我算出每个用户的连续天数。这种场景如果还是一条一条查接口得跑几个小时。我的做法是写一个批量刷新的定时任务直接走MySQL查询用一次IN查询把目标用户的连续签到记录全取出来代码里批量计算后批量更新。如果数据量更大几十万用户就得考虑用LIMIT分批处理避免一次加载太多数据把内存打爆。4. 签到日历与状态展示的实现细节日历展示这块是前端工作量大、后端容易被低估的部分。用户在签到页看到的不是一个简单的“今天是否已签”而是整个月每一天的状态签到、补签、漏签、未来日期。后端要提供一个能一次返回整月状态的接口。接口设计如下GetMapping(/monthStatus) public ResultMonthSignStatusVO getMonthStatus( RequestParam Long userId, RequestParam(required false) String yearMonth) { // yearMonth格式2025-06默认当前月份 YearMonth ym yearMonth ! null ? YearMonth.parse(yearMonth) : YearMonth.now(); LocalDate startDate ym.atDay(1); LocalDate endDate ym.atEndOfMonth(); ListUserSignRecord records signRecordMapper.selectByUserAndDateRange( userId, startDate, endDate ); // 按日期分组方便前端按天渲染 MapLocalDate, UserSignRecord recordMap records.stream() .collect(Collectors.toMap(UserSignRecord::getSignDate, Function.identity())); MonthSignStatusVO vo new MonthSignStatusVO(); vo.setYearMonth(ym.toString()); vo.setToday(LocalDate.now()); ListDaySignStatus dayList new ArrayList(); for (int day 1; day ym.lengthOfMonth(); day) { LocalDate date ym.atDay(day); UserSignRecord record recordMap.get(date); DaySignStatus status new DaySignStatus(); status.setDate(date); status.setDayOfMonth(day); if (date.isAfter(LocalDate.now())) { status.setStatus(0); // 未来日期不可签到 } else if (record ! null record.getSignType() 2) { status.setStatus(3); // 补签 } else if (record ! null) { status.setStatus(1); // 已签到 } else { status.setStatus(2); // 漏签 } dayList.add(status); } vo.setDayList(dayList); return Result.success(vo); }这个接口把状态判断的逻辑全部放在后端前端只需要拿到状态数字然后渲染对应的样式即可避免前端重复实现日期判断逻辑导致不一致。状态码设计为0、1、2、3四个值对应未来、已签、漏签、补签每个值对应一种UI样式。补签单独一个状态是为了让用户快速看出哪几天是补签的配合补签记录详情做展示。日历接口要注意的一个优化点列表查询只查当月记录不需要把历史数据全查出来。selectByUserAndDateRange的SQL要走到idx_user_id和idx_sign_date这两个索引联合索引或者分别用两个索引都行避免全表扫描。5. 踩坑实录与排查技巧做签到功能这一路下来踩过的坑不少挑几个有代表性的分享出来这些都是在联调测试和线上运维中真实遇到的问题。第一个坑是Android和iOS设备时间不一致导致签到日期错乱。用户把手机时间改成未来某天提前把明天的签到做了到了真正那天再签到就提示“今日已签到”连续天数计算也跟着乱套。这个问题的处理思路是前端上报设备时间和时区后端以服务器时间为准并且对时间偏移超过一定阈值比如5分钟的请求直接拒绝。实现上很简单签到接口加一个参数clientTime后端校验Math.abs(now - clientTime)是否超过阈值超过就返回“设备时间异常”的提示。第二个坑是补签和正常签到并发时连续天数可能计算错误。场景是这样的用户当天签到请求还在处理中同时发起了昨天的补签请求两个事务互不知道对方的存在各自计算连续天数然后更新后提交的覆盖先提交的导致结果不准。解法是统一加同一把行锁补签接口里selectByUserIdForUpdate和签到接口里selectByUserIdForUpdate拿的是同一行记录上的锁任何一个事务先拿到锁另一个就必须等它提交或回滚才能继续。这个锁机制天然保证了串行化不需要额外处理。第三个坑是Redis缓存与数据库不一致。签到成功后先更新数据库再更新缓存如果Redis操作失败网络抖动、内存满了触发淘汰策略数据库已经加了连续天数缓存还是旧值。我在代码里用了“先更新数据库再删除缓存”的模式而不是“先更新数据库再更新缓存”。删除缓存后下一次查询会回源数据库然后重新填充缓存这样即使删除缓存失败也没有太大问题最多是缓存里的旧值多存活一会等下一次签到或缓存过期时自动修复。这个模式和缓存雪崩、缓存穿透那些问题一样属于Redis使用中必须掌握的基础规范。第四个坑是定时任务重算连续天数时如果刚好有用户在签到会互相覆盖。比如凌晨00:00:10的任务开始重算用户A的数据00:00:15用户A签到了任务算完的结果是旧的没包含今天签到直接把用户A的连续天数覆盖回去了。解决办法是在定时任务里查询用户数据时跳过最近5分钟内有签到操作的用户或者在定时任务执行时也使用SELECT FOR UPDATE锁住该用户记录。我在做签到功能的过程中最深的感触是越是看起来简单的业务越要在数据一致性和并发控制上下足功夫。签到本身只是一个状态变更但当它承载了积分、勋章、排行榜这些运营价值时任何数据错误都会被放大到用户投诉甚至客诉的层面。贴一个我总结的常见问题速查表都是实际开发中高频出现的问题和对应的排查思路问题现象可能原因排查与处理用户反复点击签到积分发放多次缺少幂等控制检查user_sign_record表是否加了uk_user_date唯一索引检查签到接口是否捕获DuplicateKeyException连续签到天数莫名重置为1时区问题导致日期判断错误昨天签到但今天没签被误判为断签确认服务器时区为Asia/Shanghai检查连续天数计算逻辑中“今天未签不从今天开始判断”的分支补签后连续天数没恢复补签记录未写入重算逻辑遍历范围不够确认补签后recalculateContinuousDays被调用检查重算时startDate是否覆盖到需要的前置日期凌晨签到数据被定时任务覆盖定时任务和签到请求并发定时任务改为跳过近5分钟活跃用户或对用户记录使用SELECT FOR UPDATE日历状态和实际签到记录不一致状态判断逻辑重复且不统一统一由后端接口返回状态码前端只做渲染不判断业务逻辑缓存中的连续天数和数据库不一致缓存更新失败或缓存删除失败使用“先更新数据库、再删除缓存”模式确认删除缓存的finally块有兜底处理还有一个关于前端联调的细节日历组件在渲染“今天”的时候如果用户已经签到按钮要置灰并显示“已签到”如果没签到按钮要高亮显示。这个判断最好也用后端返回的todaySigned字段不要依赖前端本地时间原因还是设备时间可能不准。最后再分享一个链路追踪的小技巧。签到接口涉及数据库、Redis、可能还有消息队列排查问题时如果每一步没有日志出问题根本不知道卡在哪里。我在doSign和doRepair的每个关键步骤都打了带用户ID追踪ID的日志格式统一为[sign][userId123] step: xxx, result: xxx线上排查问题的时候直接grep用户ID就能看到这个用户从请求进入数据库到缓存更新的完整时间线定位问题非常快。签到功能做完到现在运营又陆续提了补签卡赠送、连续签到翻倍积分、签到提醒推送这些需求但底层的数据模型和核心逻辑都没怎么动过只是在新需求上做增量扩展。这也验证了我当时的判断把签到事实、补签事实、连续统计分开建模虽然前期多写了几张表但后续扩展非常轻松。如果你也正在做类似功能我建议你在一开始就按照这个思路把数据层设计好不要在“先凑合能用”和“一步到位”之间犹豫签到功能的数据模型一旦上线后期改造成本远高于前期设计成本。