Bitmap 比 String 省内存是因为直接操作位数组，1 bit 表示一个状态，100 万用户仅需约 125 KB；而 String 存布尔值至少占 50+ 字节，同等数据超 50 MB。
Bitmap 为什么比 String 节省内存
Redis 的 String 存储一个布尔状态（比如“用户是否签到”）时，哪怕只存 "1" 或 "0"，实际会占用至少 50+ 字节：包括 SDS 头部、编码元信息、字符串内容本身。而 BITFIELD 或 SETBIT 操作的 Bitmap 是直接操作底层位数组，1 个 bit 就能表示一个状态——100 万个用户的状态，只需约 125 KB；同等数量用 String 存，轻松突破 50 MB。
关键不是“能不能用”，而是“有没有被当成整块内存来管理”：Bitmap 本质是 String 类型的特殊用法，但 Redis 对它的位操作做了零拷贝优化，不解析内容，只算偏移量。
- Bitmap 不是独立类型，底层仍是
String，所以GET key会返回乱码二进制，别用它查值 - 位索引从 0 开始，
SETBIT user:sign:20240601 999999 1表示第 100 万个用户（ID=999999）当天已签到 - 单个 key 最大支持 2³²−1 位（约 512 MB 内存），超了会报错
ERR bit offset is not an integer or out of range
用 SETBIT 和 GETBIT 做单点状态存取
这是最常用也最容易出错的入口。很多人以为 SETBIT 是“设一个键”，其实它是“在某个 key 的某一位上写 0 或 1”。key 不存在会自动创建，但位偏移超出当前长度时，Redis 会用 0 填充中间空位——这可能导致意外的内存膨胀。
- 避免用大偏移量初始化稀疏状态，比如
SETBIT status 999999999 1会立刻分配 ~125 MB 空间 - 真实场景建议按用户 ID 分片，例如
user:sign:20240601:{uid % 1000}，把 1000 万用户打散到 1000 个 key，防止单 key 过大 -
GETBIT返回整数0或1，不是字符串，应用层别直接 JSON.stringify() 它导致"0"变成字符串
批量统计用 BITCOUNT，但要注意时间复杂度
BITCOUNT 在无参数时扫描整个位图，O(N) 时间，N 是字节数。对一个存了 1 亿用户的 key（约 12.5 MB），执行一次全量统计可能耗时 5–20 ms，在高并发写入时容易成为瓶颈。
- 加
START/END参数可限制范围，比如按天分段后，只算BITCOUNT user:sign:20240601 0 1000000（前 100 万用户） - 如果只需要“是否至少有一个 1”，用
BITPOS key 1更快，找到第一个就返回，平均 O(1) 到 O(N) - 不要在主从同步延迟敏感的场景里高频调
BITCOUNT全量 key，从库可能还没同步完就返回旧结果
用 BITOP 做多日交集/并集，小心 key 数量和大小差异
计算“连续 7 天都签到的用户”就是典型的 BITOP AND 场景，但 Redis 要求所有参与运算的 key 长度一致：短 key 会被隐式补 0。如果某天只有 10 万用户签到，另 6 天有 100 万，那 BITOP AND 结果中后 90 万位全是 0——看起来没错，但浪费了空间和计算。
- 务必保证参与
BITOP的 key 使用相同的分片策略和用户范围，否则结果不可信 -
BITOP是阻塞命令，多个大 key 运算可能卡住主线程，生产环境建议在低峰期或用后台任务触发 - 替代方案：用
BITFIELD+INCRBY维护一个计数器 bitmap，每天SETBIT后再INCRBY对应位，最后BITCOUNT值为 7 的位——更省内存，但逻辑稍重
Bitmap 省的是字节，不是脑细胞。偏移量算错、分片不均、盲目全量统计，这三个地方踩一个，内存省不下，反而更容易出线上问题。
