Bitmaps本质是字符串，Redis的位操作命令作用于string类型的二进制位；不可跨数据类型操作，需规范命名、初始化、避免混用命令，并合理分片控制内存与性能。
Bitmaps 本质是字符串，不是独立数据类型
Redis 的 SETBIT、GETBIT、BITCOUNT 等命令操作的其实是 string 类型的底层二进制位。这意味着：你不能对一个已存为 hash 或 zset 的 key 执行 SETBIT，会报错 WRONGTYPE Operation against a key holding the wrong kind of value；也别指望用 KEYS 直接扫出“所有 Bitmap”，它们和普通字符串完全无法区分。
实操建议：
- 约定 key 命名规范，比如
sign:202405:user:{uid}，避免和其他 string 混淆 - 首次写入必须用
SETBIT或SET初始化（SET sign:202405:user:123 \x00再SETBIT也行），空 key 直接GETBIT返回 0，但BITCOUNT对不存在的 key 返回 0 —— 这点容易误判“没人签到” - 不要在同一个 key 上混用
APPEND或INCR，会破坏位布局
单日签到用 SETBIT + 用户 ID 偏移，不是时间戳
把用户 ID 当作 bit 偏移量最省空间，但前提是用户 ID 是连续或接近连续的整数（如自增主键）。例如用户 ID=1001，想标记其在 2024-05-01 签到，就执行：
SETBIT sign:20240501 1001 1
而不是用时间戳做 offset（SETBIT sign:uid:123 1714521600 1）——后者会导致位图极度稀疏，内存暴增。
常见错误现象：
- 用毫秒时间戳当 offset，一个 key 动辄占用几百 MB，
BITCOUNT变得极慢 - 用户 ID 是字符串（如 UUID），强行转成 int 导致溢出或冲突，应改用布隆过滤器或分片 hash（见下一条）
- 没控制 offset 上限，
SETBIT sign:20240501 999999999 1会分配近 120MB 内存，即使只设了 1 个 bit
超大用户量需分片：按用户 ID 取模 or 时间维度拆 key
单个 Bitmap 最好控制在几 MB 内。若用户 ID 范围大且稀疏（比如最大 ID 是 2 亿，但只有 50 万活跃用户），直接用 ID 做 offset 不现实。这时有两种主流分片方式：
-
按 UID 取模分片：比如
sign:20240501:0存 UID % 100 == 0 的用户，sign:20240501:1存 % 100 == 1 的……查某用户时先算uid % 100得到分片号，再GETBIT对应 key。缺点是聚合统计（如当日总签到人数）要BITCOUNT100 个 key 并累加 -
按时间+用户范围分片：如
sign:20240501:0_99999、sign:20240501:100000_199999，适合后台批处理场景，但需要维护用户 ID 区间映射表
性能提示：分片越多，BITCOUNT 聚合越慢；但单 key 越小，内存碎片和网络序列化开销越低。通常 16–64 分片是较稳的选择。
BITFIELD 能原子读写多天，但要注意 overflow 行为
如果要查用户「连续签到天数」，得读连续多天的 bit。用多次 GETBIT 不仅慢，还无法保证原子性。BITFIELD 可以一次读多个 offset，例如查用户 123 在 5 天内的签到情况：
BITFIELD sign:20240501 GET u1 123 GET u1 123 GET u1 123 GET u1 123 GET u1 123
（实际 offset 应为不同日期对应的不同 key，这里仅为示意语法）
更常见的是用 BITFIELD 做带溢出控制的计数器（比如记录本月签到次数），但注意：INCRBY u8 0 1 中的 u8 是无符号 8 位，值域 0–255，超限后默认回绕（255+1=0），不是报错。业务上需提前判断是否可能溢出，必要时用 i16 或拆成多个字段。
容易被忽略的点：Redis 6.0+ 默认开启 bitfield-max-heap-size 限制，大 offset 的 BITFIELD 可能触发内存分配失败，报错 OOM command not allowed when used memory > 'maxmemory' —— 即使实际只用了几个 bit。
