BITOP AND 多日留存结果为0，主因是用户ID未映射为非负整数偏移量，导致位图索引错乱；且destkey存在时会被覆盖，需先DEL再操作。
BITOP AND 计算多日留存时，为什么结果总是 0？
因为 BITOP 的目标 key 如果已存在，会直接覆盖——但更常见的是：你把「活跃用户 ID」直接当成了 bitmap 的 bit 位索引，而没做去重或归一化映射。Redis bitmap 的每个 bit 对应一个**非负整数偏移量**，不是用户 ID 本身。比如用户 ID 是 10086，你得把它转成 10086 这个 offset（可行），但如果 ID 是字符串 "u_abc" 或超大数字（如 9223372036854775808），就完全无法存入。
- 必须确保所有参与
BITOP AND的 key，其 bit 位都代表同一组用户空间（例如统一用用户注册时分配的自增uid作为 offset） - 如果原始数据是字符串 ID，得先通过布隆过滤器、分段哈希或预建
user_id → offset映射表来转换，不能现场算 -
BITOP AND destkey srckey1 srckey2 ...中，destkey若已有值，会被清空重写；若想累加结果，得先DEL destkey
每天一个 bitmap，七日留存该用 BITOP 还是 BITCOUNT + 客户端交集？
取决于量级和实时性要求。BITOP 是服务端原子操作，快且省带宽，但有硬限制：BITOP 最多支持 16 个 source key，且所有 key 的最大 bit 偏移量必须在 2^32 范围内（约 512MB 内存）。如果你的日活百万、留存周期拉到 30 天，bitmap 可能撑到几百 MB，BITOP 执行时会阻塞主线程几毫秒到几十毫秒，高并发下容易抖动。
- 七日留存（7 个 key）完全适合
BITOP AND，实测万级 QPS 下延迟稳定在0.1ms内 - 超过 16 天或 key 数超限，得拆成两轮
BITOP（如先算前 8 天交集到 temp1，再算后 8 天到 temp2，最后BITOP AND result temp1 temp2） - 若需支持任意 N 日动态留存（如“过去 15 天中至少活跃 5 天的用户”），BITOP 不适用，得改用
BITCOUNT分别取各日基数，再在客户端用集合求交/并/条件统计
BITOP AND 后调用 BITCOUNT，结果比预期小很多
大概率是 bitmap 稀疏导致——你只设置了少量 bit（比如只标记了当天活跃的 10 万个用户），但 bitmap 实际长度由最大 offset 决定。如果某天最高 offset 是 9999999，那这个 key 占用近 1.25MB，但其中 99% 的 bit 都是 0。而 BITCOUNT 统计的是整个范围内所有 1 的个数，不是“有效用户数”。它没错，只是你误以为 bitmap 是稀疏压缩结构，其实 Redis bitmap 是纯数组。
- 检查最大 offset：用
BITPOS key 1 -1查最后一个 1 的位置，确认是否远大于实际用户量 - 避免用业务 ID 直接作 offset，优先用连续分配的
uid，控制 offset 上界 - 如果必须用大 ID，考虑分桶（如
uid % 1000为 bucket，再在 bucket 内用余数作 offset），但交集计算就得跨桶聚合，BITOP 就不直接适用了
Python 客户端执行 BITOP 失败，报错 ERR wrong number of arguments for 'bitop' command
这是 redis-py 的一个经典陷阱：它把 BITOP 当成普通命令封装，但没处理可变参数。你写 r.bitop('AND', 'retained', 'day1', 'day2', 'day3') 看似合理，其实底层传参格式错了——redis-py 2.x 默认把前两个参数固定为 operation 和 destkey，剩下全塞进一个 list，导致 Redis 收到的是 BITOP AND retained ['day1','day2','day3']，自然报错。
- 正确写法是用
execute_command：r.execute_command('BITOP', 'AND', 'retained', 'day1', 'day2', 'day3') - 或者升级到 redis-py 4.0+，它修复了这个问题，
bitop方法才真正支持多 srckey - Node.js 的 ioredis、Go 的 goredis 都无此问题，参数透传正常
INFO memory 才发现 used_memory_dataset_perc 长期 95%+。 
