用 SETBIT 和 GETBIT 做存在性判断最直接：SETBIT 设定位为 1，GETBIT 查该位是否为 1，O(1) 时间、极省空间；不可用 BITCOUNT 替代，不支持三态，需确保 ID 到偏移量映射一致。
用 SETBIT 和 GETBIT 做存在性判断最直接
Redis 位图（Bitmap）本质是字符串的底层操作，SETBIT 把某一位设为 1，GETBIT 查某一位是否为 1——这比存完整 key 更省空间，也比用 EXISTS 查 key 是否存在更快（尤其在海量稀疏数据场景下）。但注意：位图不自动扩容，SETBIT 写入超出当前长度的位置会自动补零，而 GETBIT 查询未写过的位默认返回 0。
- 适合判断“某 ID 是否被标记过”，比如用户签到、设备在线状态、风控黑名单 ID
- 不要用它查“值是多少”，位图只存 0/1，没有中间态
-
SETBIT user:sign:20240501 <uid> 1中<uid>是整数偏移量，不是字符串 ID；如果原始 ID 是字符串，得先映射成唯一递增整数（比如用INCR或预分配 ID 段） - 单个字符串最大支持 2³² 位（约 512MB），超了会报错
ERR bit offset is not an integer or out of range
别把 BITCOUNT 当存在性检查用
BITCOUNT 统计 1 的个数，常被误用来“间接判断是否存在”——比如先 BITCOUNT 再看是否 > 0。这多了一次全量扫描，完全没必要。只要确认某一位是 1，就代表存在；查一位用 GETBIT 是 O(1)，查全量是 O(N)。
- 错误做法：
BITCOUNT user:sign:20240501然后判断结果是否非零 - 正确做法：
GETBIT user:sign:20240501 <uid>，返回 1 就存在，0 就不存在（注意：0 不代表“明确不存在”，而是“没被设过 1”） - 如果业务要求区分“从未设置”和“显式设为 0”，位图做不到——它没有三态，只有 0 和 1，且未设置位默认读作 0
用 BITOP AND 做交集判断时小心空 key
想判断“用户是否在多个条件集合中都存在”，比如“既签到又完成实名又通过风控”，常用 BITOP AND dest k1 k2 k3 得到共同位，再 GETBIT dest uid。但只要任意一个源 key 不存在，BITOP 会把它当作全 0 字符串参与运算，结果可能全 0，导致误判。
- 必须确保所有参与
BITOP的 key 都已存在（哪怕只是空字符串），否则逻辑崩坏 - 安全做法：对每个 key 先
EXISTS，或统一用SETNX初始化空位图（SETNX user:realname:20240501 ""） -
BITOP结果写入新 key，不能原地操作；目标 key 若已存在，会被覆盖 - 大位图做
BITOP有 CPU 开销，线上慎用于高频实时判断，更适合离线或低频聚合
位图内存不等于实际占用，STRLEN 才是真实字节数
位图的“大小”容易误解：GETBIT 支持最大偏移 2³²−1，但不代表你真要占 512MB。Redis 按需分配底层字符串空间，STRLEN 返回的是当前实际字节数。比如只设了第 100 万位，STRLEN 可能只有 125001 字节左右（1000000 ÷ 8 + 1）。
- 监控位图膨胀要用
STRLEN，不是靠偏移量估算 - 用
DEBUG OBJECT看编码类型，确认是raw还是embstr（小位图会优化存储） - 删除旧位图用
DEL，别用SET覆盖空字符串——后者仍保留 key，且可能触发 RDB/AOF 写入开销 - 位图不可压缩，LZF 压缩对纯位图效果差，别指望靠配置节省空间
