Redis位图适合存高频布尔打卡记录，MongoDB只存业务语义强的字段；位图offset须从0开始；连续天数需Lua原子更新；月份键必须设TTL并冷热分离。
用 u:sign:{userId}:{yyyyMM} 做 Redis 位图键，别存 MongoDB
MongoDB 不适合存高频、低价值、布尔型的打卡记录——它没原生位图支持，强行用文档存每天一个 {date: "2026-03-14", status: true}，一个月就是 31 条文档，100 万用户就产生 3100 万文档，索引膨胀、写放大、查询慢，纯属自找麻烦。
正确做法是：把考勤打卡这个「签到/未签到」二值问题交给 Redis 的 BITMAP，MongoDB 只存需要关联查询、带业务语义、需原子更新或要长期归档的字段，比如：
-
last_sign_date（最后签到日期，用于判断是否断签） -
continuous_days（当前连续签到天数，每次签到后用 Lua 脚本原子更新） -
total_points（累计积分，避免每次查 bitmap 再算） -
sign_history_summary（按月统计的签到次数，如{"202601": 28, "202602": 25}，可异步从 Redis 同步）
SETBIT 和 BITCOUNT 是核心，但偏移量别从 1 开始算
常见错误是把“3 月 1 日”对应 offset=1、“3 月 2 日”对应 offset=2……这会导致位图浪费空间，且和 BITPOS、BITFIELD 行为不一致。Redis 位图下标从 0 开始，必须严格对齐：
- 2026 年 3 月共 31 天 → offset 范围是
0到30 - 3 月 1 日 →
SETBIT u:sign:123:202603 0 1 - 3 月 15 日 →
SETBIT u:sign:123:202603 14 1 - 查当月总签到数 →
BITCOUNT u:sign:123:202603
如果硬要用 1-based，所有后续操作（比如查首次签到用 BITPOS）都要手动 -1，极易出错，也不符合 Redis 社区惯例。
连续签到天数不能只靠位图推算，得靠服务端状态维护
位图能告诉你「哪几天打了卡」，但无法实时回答「今天签到后连续多少天」——因为要判断是否断签，得知道昨天有没有签。而 GETBIT u:sign:123:202603 13（查 3 月 14 日前一日）可能跨月，得切到 202602 键再查 offset=27（2 月 28 日），逻辑复杂且非原子。
更稳的做法是：每次成功签到时，用 Lua 脚本一次性完成三件事：
- 在当月位图设 bit
- 查昨日是否已签（自动跨月处理）
- 更新 MongoDB 中的
continuous_days字段（+1 或重置为 1）
这样业务层读 continuous_days 就是最终态，不用拼接多轮 Redis 查询，也规避了并发写导致状态不一致的风险。
月份键过期和冷热分离必须做，否则 Redis 内存爆掉
用户签到数据有强时效性：一般只查近 3–6 个月，历史数据可归档。若放任 u:sign:123:202501 这类键永远存在，100 万用户 × 12 个月 × 每个键约 4 字节 = 接近 50MB 内存，一年后就是 600MB+，纯属浪费。
上线就必须配 TTL：
- 签到成功后，执行
EXPIRE u:sign:123:202603 2592000（30 天） - 每月 1 号凌晨，用脚本批量为上月键延长 TTL（如再加 90 天），供报表使用
- 超过 180 天的键，由后台任务同步到 MongoDB 归档集合
user_sign_archive，然后DEL掉 Redis 键
不设过期，不是“省事”，是给运维埋雷；等某天 INFO memory 显示 used_memory > 95%，再补就晚了。
真正难的不是怎么写 SETBIT，而是想清楚哪些状态必须强一致、哪些可以异步补偿、哪些根本不用存——位图只是工具，建模逻辑才是分水岭。
