bitmap签到本质是将日期转为从基准日开始的天数差作为offset，用setbit操作位；需统一utc时区、避免手算闰年、单用户单key（如sign:uid:12345）、按月分key更实用，查连续签到须结合日期范围校验offset。
Bitmap 用 offset 记录签到，本质是位运算映射
Redis 的 SETBIT 不是存“日期字符串”，而是把某天映射成一个整数偏移量（offset），再把这个 offset 对应的 bit 设为 1。关键在怎么算这个 offset：不能直接用 2024-05-20 这种字符串，得转成从某个基准日开始的天数差。
比如选 2024-01-01 作为起始日，那么 2024-05-20 就是第 140 天（含首日），对应 offset = 139（因为 offset 从 0 开始）。算错 offset 是最常见问题——一旦偏移错一位，所有签到状态全乱。
- 务必统一时区，用 UTC 时间解析日期再转天数，避免本地时区导致跨日偏差
- 推荐用语言内置的日期差函数（如 Python 的
(date - base_date).days），别手算闰年 - offset 最大别超
2^31-1（约 21 亿），否则SETBIT会报ERR bit offset is not an integer or out of range
单用户签到用一个 key，key 名要有业务标识
不要用 sign:20240520 这种按天分 key 的方式——查某人连续签到天数会要遍历几十个 key，性能崩。正确做法是每个用户一个 key，比如 sign:uid:12345，每天签到只操作这一个 key 的不同 offset。
这样 BITCOUNT 查总签到数、BITPOS 查首次/末次签到、GETBIT 查某天是否签到，全部 O(1) 或 O(log N) 完成。
- key 命名必须带用户维度（uid / openid / account_id），否则无法反查是谁签的
- 避免 key 过长，
sign:user:12345比user_sign_in_status_record_for_user_id_12345更稳妥 - 如果用户量极大，可考虑加 hash tag 如
{sign:12345}:uid:12345控制分片
查连续签到天数不能只靠 BITPOS，得结合日期范围校验
BITPOS sign:uid:12345 1 能找到第一个 1 的位置，BITPOS sign:uid:12345 0 能找从某位置后第一个 0——但这两个结果只是 bit 位置，不是真实日期。如果你的基准日是 2024-01-01，offset=139 对应的是 2024-05-20，不是 “第 139 天” 就完事了。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
真正查“最近连续签到 X 天”，得：
- 先算出目标日期范围对应的 offset 区间，比如查“截至今天连续 7 天”，就取 [today_offset - 6, today_offset]
- 用
GETRANGE拿出这一段字节，或循环用GETBIT检查每一位是否为 1 - 注意：Redis Bitmap 是大端序，但
GETRANGE返回的是原始字节流，别误以为高位在前就自己反转
内存与精度权衡：按月分 key 可能更实用
一个用户存 10 年签到（3650 天）只要约 457 字节，看似很省——但实际中，老数据访问极少，全堆在一个 key 里会导致：BITCOUNT 统计全量时扫描范围过大；备份/迁移时单 key 体积突增；某些客户端对大 value 解析慢。
更平衡的做法是按自然月分 key：sign:uid:12345:202405 存 5 月数据，sign:uid:12345:202406 存 6 月……
- 每月最多 31 天 → offset 范围 0~30 → 单 key 最大 4 字节，极轻量
- 查当月连续签到直接操作一个 key；跨月查询则最多 fetch 2 个 key（如 5.28–6.3）
- 过期策略清晰：
EXPIRE sign:uid:12345:202401 0直接删掉 1 月数据，不用删 bit
偏移量本身很简单，难的是把日期、时区、分 key 策略和业务查询模式拧在一起——少算一天 offset，或者忘了删过期 key，后面都得翻日志捞数据补。
