Bitmap 被选为签到数据结构因其内存效率高（一年仅46字节）、原子性强，但需正确设计 offset 映射、手动实现连续天数判定，并用 SetBit 返回值判断首次签到以保障并发安全。
签到数据结构为什么选 Bitmap 而不是 String 或 Hash
Bitmap 不是 Redis 的独立类型，而是对 STRING 类型的位操作封装。它比用 HSET 存每日签到状态省 90%+ 内存——比如一年 365 天，只占 CEIL(365/8)=46 字节；而用 Hash 存 365 个字段，每个 key 至少几十字节开销，轻松破 KB。
但 Bitmap 不能直接存用户 ID 或时间戳，只能存「偏移量」（offset）。所以必须把「用户 + 日期」映射成唯一整数 offset，常见错误是直接用 Unix 时间戳当 offset——1717027200 太大，Redis 会报 ERR bit offset is out of range（最大支持 ~2^32-1，但实际建议控制在千万级以内）。
- 推荐做法：以用户 ID 为前缀，按月分片，例如
"sign:uid_123:202405"，offset = 当月第几天 - 1（即 5 月 1 日 → offset 0） - 避免全局 offset：不拼接用户 ID 和日期生成大整数，防止越界和冲突
- 注意时区：用 UTC 还是本地时间？务必统一，否则凌晨签到可能算错月份
Go 中用 redis-go/v9 调用 SETBIT 和 GETBIT 的关键写法
官方客户端 redis-go/v9 没有封装 Bitmap 专用方法，全靠 SetBit、GetBit、BitCount 这几个底层命令。容易漏掉的是返回值类型和 error 判断逻辑——GetBit 返回 int64，但实际只有 0 或 1；SetBit 成功也返回 int64（旧值），不是布尔。
ctx := context.Background()
key := "sign:uid_123:202405"
offset := 4 // 5月5日
<p>// 签到：设置第 offset 位为 1
val, err := rdb.SetBit(ctx, key, int64(offset), 1).Result()
if err != nil {
// 注意：err 可能是 redis.Nil（key 不存在），不是业务错误
log.Printf("setbit fail: %v", err)
}
oldValue := val // 0 或 1，表示签到前状态</p><p>// 查询是否已签到
isSigned, err := rdb.GetBit(ctx, key, int64(offset)).Result()
if err != nil {
log.Printf("getbit fail: %v", err)
}
// isSigned 是 int64，需转 bool：isSigned == 1-
SetBit和GetBit的 offset 参数必须是int64，别传 uint 或 int（32 位系统可能溢出） - 不要用
Exists预判 key 是否存在——Bitmap 自动创建 key，且Exists增加一次 round-trip - 批量查询多天状态？用
BitField，但 v9 客户端需手动构造命令，不如单次GetBit清晰
连续签到天数计算为什么不能只靠 BITCOUNT
BITCOUNT 只能统计某 key 中所有为 1 的位数，无法区分是否「连续」。比如用户 5.1、5.3、5.5 都签到了，BITCOUNT 返回 3，但连续天数是 1。
立即学习“go语言免费学习笔记（深入）”；
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
真实场景要查「截至今天最多连续多少天」，得从今天往前逐位检查，直到遇到 0。这个逻辑必须在 Go 层做，Redis 没有原生连续位扫描指令。
// 从当天开始倒查连续天数（最多查 31 天）
days := 0
for i := todayOffset; i >= 0 && i >= todayOffset-30; i-- {
bit, _ := rdb.GetBit(ctx, key, int64(i)).Result()
if bit == 1 {
days++
} else {
break
}
}- 别用
BITPOS key 0 -1查第一个 0 的位置——它返回的是从右往左的偏移，语义反直觉，且不支持指定范围 - 如果要支持「历史最长连续签到」，得额外用 Sorted Set 记录每次断连点，复杂度陡增，多数业务只需「当前连续」
- 高频查询场景下，可把连续天数缓存到另一个 key（如
"sign_streak:uid_123:202405"），签到成功后更新，避免每次遍历
并发签到时 SETBIT 的原子性够不够用
SETBIT 本身是原子的，但「判断是否已签到 + 设置」是两个操作，中间可能被其他协程插入。常见错误是先 GETBIT 再 SETBIT，导致重复签到或覆盖。
正确做法是直接 SETBIT 并检查返回的旧值：oldValue == 0 表示本次是首次签到。这是唯一可靠方式。
- 不要用 Lua 脚本强行合并逻辑——除非你真需要「签到+发奖励+更新 streak」三步原子，否则纯签到用原生命令更轻量
- 如果签到要附带奖励（如积分），建议用 Redis 的
INCRBY更新积分，再用SETBIT记签到，二者独立，靠应用层幂等控制 - 注意：
SETBIT设置 1 之后再设 1，oldValue 还是 1，不会触发二次奖励逻辑——这正是你要的
Bitmap 看似简单，但 offset 设计、连续判定、并发语义这三点一旦错，轻则数据不准，重则内存爆炸或查询超时。尤其 offset 映射规则，上线前最好用脚本跑一遍全年边界 case。
