Go语言操作Redis实现位图签到功能：语言学习中的高效存储-Golang-PHP中文网

redis位图签到在go中需注意字节序（高位优先）、bitfield替代get避免解析错误、跨月连续统计需双key或拼接扫描、bitcount须指定字节范围、月key需定时清理。

go语言操作redis实现位图签到功能：语言学习中的高效存储

Redis 位图签到在 Go 中不是“直接用 SETBIT 就完事”，关键在于字节序映射、跨月连续性、以及客户端返回值的正确解析——错一位，整个月的签到状态就全偏。

Go 里读 `GET` 到的位图字节必须按高位优先（big-endian）拆解

Redis 底层把 SETBIT 写入的位序列存为紧凑字节数组，GET 返回的是原始 []byte，比如 []byte{129} 对应二进制 10000001，其中最高位（bit 7）对应 offset 0，最低位（bit 0）对应 offset 7。很多人误以为是 LSB 在前，结果把第 0 天当成最低位，导致所有日期错位。

错误写法：bitset[i] = (data[i/8] >> (i%8)) & 1 —— 这是 LSB-first，会把 offset 0 当作字节最低位
正确逻辑：offset i 落在字节索引 i/8，该字节内位置是 7 - i%8（即从高位开始数）
推荐封装函数：hasBit(b byte, pos uint) 判断 b 的第 pos 位（pos 为 7→0），再配合 globalOffset = byteIdx*8 + (7 - bitPos)

`BITFIELD` 比 `GET` + 手动解析更安全、更省带宽

当只需要读取当月全部签到状态（比如渲染日历），用 GET 拿整个字节数组再解析，不仅多一次内存拷贝，还容易因字节长度不固定（如只签了前 5 天，Redis 可能只存 1 字节）而出错。而 BITFIELD 可以原子读取指定长度的无符号整数，天然适配月份场景。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

例如读取 31 天数据：BITFIELD key GET u31 0，返回一个 int64，高 31 位即为 1–31 日状态（bit30 对应 day1，bit0 对应 day31）
Go 客户端（如 github.com/go-redis/redis/v9）调用：client.BitField(ctx, key, "GET", "u31", "0").Result()
注意：如果 key 不存在或位数不足，BITFIELD 默认补 0，不会 panic；而 GET 返回空 []byte，需额外判空

连续签到天数不能只靠 `BITPOS`，得结合时间边界和跨月逻辑

BITPOS key 1 -1 只能拿到最后一个 1 的位置，但无法判断是否连续。比如用户 5 月 30、31 日签到，6 月 1 日也签了，若 key 按月分片（u:sign:123:202605 / u:sign:123:202606），单查一个 key 必然断掉。

方案一（推荐）：签到时同时写两个 key —— 月粒度 u:sign:uid:yyyyMM + 年粒度 u:sign:uid:yyyy，后者用于跨月连续统计
方案二：用 BITFIELD 分别读本月最后几天 + 上月最后几天，拼接后扫描最长连续 1 段（注意：需限制扫描范围，避免 O(n) 全量遍历）
切忌用 BITPOS key 0 [start] 倒推断点——Redis 不保证返回的是“最近一个 0”，它只返回范围内第一个匹配位

Key 设计必须包含可预测的长度约束，否则 `BITCOUNT` 统计会出错

Redis 位图自动扩容，但 BITCOUNT 默认统计整个字符串所有位。如果你用 SETBIT key 100 1，Redis 会分配至少 13 字节（101/8 向上取整），其中 offset 32～100 之间全是 0。这时 BITCOUNT key 会把这中间的 0 都算进去？不，它只统计值为 1 的位——但问题在于：你本意只想统计当月 31 天，结果 key 里混进了历史残留位。