redis get 返回的 []byte 需高位优先 unpack：对每个字节从 bit7 到 bit0 遍历，全局 offset = byteidx*8 + (7 - bitpos)，否则位序全反；go-redis 中需用 .bytes() 并检查 redis.nil 和 error。
Redis GET 返回的 []byte 怎么转成按 offset 对齐的 []bool
Redis 的 GET 命令对 bitmap key 返回的是原始字节序列，比如 []byte{138}（二进制 10001010），但它的位序是高位在前：字节内 bit 7 对应 offset 0，bit 6 对应 offset 1……bit 0 对应 offset 7。直接按字节低位到高位遍历会把 offset 映射全搞反。
必须手动做“高位优先 unpack”：
-
getBitSet函数里，对每个字节要从bitPos = 7往0遍历 - 全局 offset 计算用
byteIdx*8 + (7 - bitPos)，不是byteIdx*8 + bitPos - 别依赖第三方 unpack 工具——Go 标准库和
redigo/go-redis都不提供等价于 Ruby"\x8a".unpack("B*")的功能
用 go-redis 时，GET 返回值怎么安全转成 []byte
go-redis 的 GET 命令返回 *redis.StringCmd，调用 .Bytes() 会 panic 如果 key 不存在或值不是字符串类型。生产环境必须显式处理 nil 和 error。
- 正确写法：
val, err := rdb.Get(ctx, "mykey").Bytes()，然后检查err == redis.Nil（key 不存在）或其它 error - 如果 key 可能为空，别直接
val, _ := ...，否则getBitSet(nil)会 panic（len(nil) 是 0，但循环里没判空） - 空 key 对应的
val是[]byte{}（非 nil），getBitSet([]byte{})返回空[]bool，符合预期
SETBIT 和 GETBIT 足够用，为什么还要解析整段 []byte
单点操作快，但批量场景下网络往返开销大。比如统计用户当月 31 天签到情况，发 31 次 GETBIT 不现实。
- 一次
GET拿回整个字节块，再本地 unpack，比 31 次 RTT 快一个数量级 - 注意 Redis 自动补零：
SETBIT mykey 100 1后，GET mykey返回至少 13 字节（101/8 向上取整），未设置的高位字节全是\x00 -
getBitSet对[]byte{0,0,0,1}返回长度为 32 的[]bool，其中 offset 0~23 全是false，offset 24 才是true——这和 Redis 行为严格一致
位图长度不确定时，如何避免内存浪费
Redis bitmap 是稀疏扩展的，SETBIT key 1000000 1 会让 value 占用约 125KB 内存，但你可能只关心前 100 位。
- 别无脑调用
getBitSet(data)——它总返回len(data)*8长度的切片 - 如果业务明确最大 offset（比如签到最多 31 天），解析后截断：
bits = getBitSet(data)[:31] - 如果 offset 分布极稀疏（如只设了 offset 1、1000、1000000），用
BITPOS或BITCOUNT配合小范围GETRANGE更省带宽
高位在前这个细节，90% 的 Go 开发者第一次解析时都会错；一旦 byteIdx 和 bitPos 的映射偏移写反，整个布尔切片就全错位了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
